Межсайтовый скриптинг: Что такое межсайтовый скриптинг (XSS) и XSS-атаки?

Что такое межсайтовый скриптинг (XSS) и XSS-атаки?

Что такое межсайтовый скриптинг?

Атаки XSS нацелены на код (также известный как скрипт) веб-сайта, который выполняется в браузере пользователя, а не на сервере, где располагается данный сайт. Если вы стали жертвой подобной атаки, в ваш браузер был внедрен вредоносный скрипт, угрожающий безопасности вашего ПК. Существует бесконечное множество видов атак межсайтового скриптинга, большинство из которых нацелены на кражу конфиденциальных данных, переадресацию пользователя на подконтрольные хакерам сайты или на манипуляцию компьютера в интересах злоумышленников.

Как происходит атака межсайтового скриптинга?

Веб-сайты хранят данные и постоянно отправляют информацию вашему браузеру: атаки межсайтового скриптинга происходят, когда ненадежные источники отправляют пользователям вредоносное содержимое посредством уязвимостей в веб-сайтах с целью кражи персональных данных или нанесения ущерба вашему компьютеру. Например: когда пользователь ищет что-то онлайн, веб-сайт отправляет браузеру данные в форме поисковой выдачи. При атаках типа XSS передаваемая информация содержит вредоносный код и может помочь злоумышленниках украсть персональные данные пользователя. По причине того, что практически каждый веб-сайт хранит и отправляет данные браузерам, межсайтовый скриптинг на сегодняшний день представляет наиболее распространенную уязвимость программного обеспечения.

Как распознать атаку межсайтового скриптинга?

К сожалению, ваш браузер не способен распознать надежность принимаемого скрипта и автоматически выполняет любой полученный скрипт. Это означает, что вредоносные скрипты имеют возможность получить доступ к любым хранимым в браузере или на веб-сайте данным. Все это делает обнаружение атак типа XSS практически невозможным.

Как устранить уязвимость межсайтового скриптинга?

Обнаружить и устранить уязвимость типа XSS — это задача владельца сайта, так как именно на сайте находится вредоносный код, заражающий ничего не подозревающих посетителей. Убеждать пользователей избегать веб-сайтов с низкой репутацией малоэффективно в данном отношении, так как этим уязвимостям в одинаковой степени подвержены как сайты с низкой, так и высокой репутацией. К счастью, существуют инструменты, которые можно загрузить онлайн, чтобы просканировать любой сайт на наличие уязвимости типа XSS.

Как избежать межсайтового скриптинга

• Установите качественное антивирусное решение на свой компьютер
• Настройте автоматическое обновление всех сторонних программ
• Загрузите инструмент для сканирования веб-сайтов на предмет наличия в коде уязвимостей типа XSS

Защититесь от межсайтового скриптинга

Для того, чтобы обезопасить себя от межсайтового скриптинга, недостаточно просто избегать сайтов с низкой репутацией. Чтобы обеспечить свой ПК надежной защитой от любого типа заражения и нанесения ущерба как самому ПК, так и хранимых на нем данных, весьма рекомендуется установить современный титулованный антивирус, например, антивирус Avast.

Что такое XSS-уязвимость и как тестировщику не пропустить ее / Хабр

По моему наблюдению довольно много тестировщиков когда-либо слышали такое понятие, как XSS-уязвимость. Но мало кто может просто и на пальцах рассказать на собеседовании про нее. Или эффективно проверить веб-сайт на наличие этой уязвимости. Давайте вместе разберемся со всем этим подробнее и попробуем сами найти несложную XSS-уязвимость на демо-странице, которую я специально подготовил к этой статье.

Если вы гуру тестирования безопасности и на раз-два участвуете в баунти-программах крупных IT-компаний, а количество найденных вами XSS исчисляется десятками или даже сотнями — можно смело проходить мимо этой статьи. Если же вы новичок в теме и только начинаете интересоваться поиском уязвимостей — добро пожаловать под кат.

Определение

XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — довольно распространенная уязвимость, которую можно обнаружить на множестве веб-приложений. Ее суть довольно проста, злоумышленнику удается внедрить на страницу JavaScript-код, который не был предусмотрен разработчиками. Этот код будет выполняться каждый раз, когда жертвы (обычные пользователи) будут заходить на страницу приложения, куда этот код был добавлен. А дальше существует несколько сценариев развития.

Первый: злоумышленнику удастся заполучить авторизационные данные пользователя и войти в его аккаунт.

Второй: злоумышленник может незаметно для жертвы перенаправить его на другую страницу-клон. Эта страница может выглядеть совершенно идентично той, на которой пользователь рассчитывал оказаться. Но вот принадлежать она будет злоумышленнику. Если пользователь не заметит подмены и на этой странице введет какие-то sensitive data, то есть личные данные, они окажутся у злоумышленника.

Третий… да в общем-то много чего еще можно придумать. Почти все, что может JavaScript, становится доступным для злоумышленника. Чуть ниже мы рассмотрим подробнее один из таких примеров. А пока давайте попробуем чуть подробнее обсудить, как именно устроена уязвимость. И почему злоумышленнику удается внедрить свой код в чужое приложение без доступа к его исходникам.

Небольшое предупреждение. Вся информация далее представлена исключительно в информационных целях. Тестировщик должен уметь проверять свое веб-приложение на уязвимости. Однако, использование XSS-уязвимостей на чужих ресурсах является незаконным.

Если говорить про действующее российское законодательство, когда исследователь тестирует чужой продукт на предмет уязвимостей или проникает в чужую сеть без ведома и согласия владельца, его действия могут быть расценены как неправомерные.

Но вернемся к XSS.

Как устроена уязвимость?

Прежде всего, как именно удается внедрить на страницу JavaScript-код, которого там раньше не было? И как получается распространить этот код среди других пользователей?

Например, можно добавить JavaScript-код в поле ввода, текст из которого сохраняется и в дальнейшем отображается на странице для всех пользователей. Это может быть поле для ввода информации о себе на странице профиля социальной сети или комментарии на форуме.

Злоумышленник вводит текст (и за одно вредоносный код), который сохраняется на странице.

Когда другие пользователи зайдут на эту же страницу, вместе с текстом они загрузят и JavaScript-код злоумышленника. Именно в момент загрузки этот код отработает. Конечно, уязвимость сработает, только если текст при сохранении не будет обезопасен. О том, как это сделать, и почему разработчики иногда забывают об этом, поговорим чуть позже.

Это лишь самый простой и очевидный пример того, где может быть спрятана уязвимость. Более интересный пример мы с вами чуть ниже рассмотрим на специально подготовленной демо-страничке.

А пока давайте двигаться дальше.

Почему такие ошибки часто встречаются на веб-проектах?

Суть в том, что браузер не может самостоятельно отличить обычный текст от текста, который является CSS, HTML или JavaScript-кодом. Он будет пытаться обрабатывать все, что находится между тегами <script>, как JavaScript-код. Все, что находится между тегами <style>, считать CSS. И все, что похоже на тег, считать HTML-кодом.

Если разработчик хочет, чтобы какой-то текст только выглядел как код, но таковым не являлся (то есть не обрабатывался браузером, а выводился как есть), этот текст надо специально обработать прежде, чем отдать его браузеру. Такая обработка называется “экранированием”.

В процессе экранирования текста в этом тексте все спец. символы заменяются их “аналогами”, и браузер уже знает наверняка, что это просто текст. Важнее всего обрабатывать тот текст, который приходит от пользователя, так как любой пользователь может оказаться злоумышленником и вместе с текстом прислать какой-нибудь код. Увы, иногда разработчики забывают об экранировании в тех или иных местах веб-приложения, и текст выводится без всякой обработки. Причин для этого может быть несколько.

Например, не всегда программист держит в уме все места, где текст, заданный пользователем, попадает на страницу. Более того, иногда разные части сайта могут создаваться в разное время и/или разными людьми. В этом случае вероятность ошибки возрастает.

Еще причина может быть в том, что уязвимость находится не в коде самого разработчика, а в коде библиотеки, которую он использует. Обычно это какие-то готовые фреймворки для создания веб-сервисов. В таком случае разработчик, конечно, может даже не подозревать то, что подключая к проекту этот фреймворк, он автоматически подключает к нему же уже готовую уязвимость.

Такой риск есть всегда. Все же писать приложение полностью с нуля, не используя вообще никаких библиотек, в наше время долго и дорого. Далеко не каждая компания может позволить себе разработку такого уровня.

В этом случае вся надежда на тестировщиков.

Чем опасна XSS-уязвимость?

Давайте еще раз, более детально, поговорим об опасности XSS-уязвимости. Сама по себе уязвимость не является опасной. Опасной она становится тогда, когда ее находит злоумышленник и начинает ее использовать в своих целях. Использование уязвимости называется “вектором атаки”. В случае XSS векторов атаки довольно много.

Самый простой пример — кража авторизационных cookie пользователей веб-приложения. Чаще всего сайт, на котором присутствует авторизация, отличает авторизованного пользователя по так называемой сессионной cookie. Если ее нет, то пользователь не авторизован. А если она есть, то по значению этой cookie сервер может отличить одного пользователя от другого.

Все cookie хранятся на компьютере пользователей. Если я авторизуюсь своим пользователем, я буду видеть свое значение cookie. А значение чужой просто так узнать не смогу.

То же касается JavaScript-кода, который выполняется в браузере пользователя. Этот JavaScript-код будет видеть значение cookie того пользователя, в браузере которого он исполняется и только его.

Теперь допустим, что злоумышленнику удастся внедрить JavaScript-код на страницу веб-приложения. У любого пользователя, который теперь зайдет на эту страницу, будет исполняться в браузере JavaScript-код. Он будет читать значение cookie этого пользователя (теперь уже жертвы). Осталось только передать это значение злоумышленнику — и дело сделано. Но как передать значение, ведь вредоносный код исполняется в браузере жертвы?

Все довольно просто. Этот же JavaScript-код может создать AJAX-запрос на удаленный сервер. Например, на вот такой URL: www.zloy-site.ru/stolen={значение_cookie_жертвы}

Домен zloy-site принадлежит злоумышленнику из нашего примера. Все запросы, которые приходят на этот домен, записываются в базу данных. Посмотрев на параметры URL, злоумышленник узнает значения cookie жертв и сможет их использовать, чтобы попасть в их аккаунты.

Как мы обсудили выше — это не единственное, чем опасна XSS-уязвимость. Так что ради безопасности и для защиты своих пользователей необходимо уметь искать и закрывать подобные уязвимости на ваших проектах.

Где искать XSS? Как с ней бороться? Демо-страница с примером

В первую очередь стоит проверять на XSS-уязвимости те места на сайте, в которых у обычного пользователя есть возможность повлиять на контент. Если он может добавить в какое-то место определенный текст, он сможет попытаться добавить и JavaScript-код.

Давайте это рассмотрим на конкретном примере. Я подготовил очень простую песочницу, где спряталась XSS-уязвимость. Предлагаю попробовать ее найти вместе.

Открываем песочницу: https://playground.learnqa.ru/demo/xss

Для начала посмотрим, как устроена страница. Это по сути очень простой каталог книг, в котором есть поиск. Если ввести в запросе “Рей Брэдбери” мы увидим все книги, которые есть в этом каталоге этого автора.

Внимательный пользователь уже заметил, что текст, который мы вводили в поле поиска, тут же оказался в URL. Нам этот момент еще пригодится.

А пока давайте попробуем вставить какую-нибудь ерунду в поле поиска: “fwefewf”.

Мы увидим, что в этом случае ничего найти на странице не удалось. А текст запроса повторился в тексте ошибки:

Итак, мы с вами обнаружили место, где появляется текст, вводимый нами. Следовательно, это и есть потенциальное место для XSS-уязвимости. Давайте попробуем вставить самый популярный JavaScript-код для проверки, есть ли там уязвимость.

<script>alert(123)</script>

В случае, если страница является уязвимой, после ввода этого кода на странице появится вот такое окошко:

Оно и будет означать, что наш JavaScript-код исполнился и мы нашли XSS-уязвимость.

Итак, вводим код и видим следующее предупреждение:

Форма не позволяет нам осуществить поиск по такому значению, так как форма валидируется и хочет работать только с буквами и цифрами. На первый взгляд кажется, что разработчик все учел и защитил страницу от XSS, но это не совсем так.

Помните, чуть выше мы с вами заметили, что текст, который мы вводим в поле поиска, отображается в URL в так называемом GET-параметре? Имя этого параметра “q”, а значение — то, что мы вводим в поле поиска. Это сделано для того, чтобы можно было скопировать URL вместе с этой самой строкой поиска и в следующий раз открыть страницу сразу с нужными авторами.

Например, вот такой URL откроет страницу сразу только с книгами Рея Брэдбери: playground.learnqa.ru/demo/xss?q=Рей+Брэдбери

В отличие от формы, валидацию URL разработчик сделать не мог — любой пользователь в своем браузере может ввести любой URL, какой захочет, в том числе и с любым значением GET-параметра. Задача разработчика в этом случае — не забыть учесть все варианты и написать правильный обработчик значения этого GET-параметра.

Проверим, не забыл ли наш разработчик все учесть тут. Попробуем в GET-параметр “q” подставить тот самый JavaScript-код: https://playground.learnqa.ru/demo/xss?q=<script>alert(123)</script>

Перейдя по этому URL мы видим, что на странице появилось окошко со значением 123. Но почему?

Все довольно просто. Помните, когда сайт не может найти нужные книги по заданному поисковому запросу, он текст этого поискового запроса выводит в тексте ошибке? Мол, не нашли ничего по запросу “бла-бла”. Вот вместо этого “бла-бла” у нас теперь JavaScript-код с алертом. Разработчик написал валидацию поля ввода и решил, что так он защитил сайт от того, чтобы JavaScript мог оказаться в поисковом запросе. И не стал экранировать текст ошибки. Нам же удалось обойти валидацию через URL, поменяв там значение поискового запроса.

Ради интереса теперь можем вывести значение нашей сессионной cookie, для этого вместо <script>alert()</script> в URL надо подставить другой код: <script>alert(document.cookie)</script>

С этим я уже предоставлю поиграться вам самостоятельно. 🙂

Найдя ошибку, стоит обратиться к разработчикам — они ее исправят.

Способов закрыть ошибку довольно много. Экранировать текст — не единственный из них. Еще можно запретить самому JavaScript видеть некоторые cookie. Для этого у cookie есть специальный параметр “http only”. Если он выставлен в TRUE, JavaScript никак не сможет узнать, что такая cookie вообще выставлена и не сможет ее прочитать и передать злоумышленнику даже в том случае, если ему удастся найти XSS на вашем проекте.

Все это — лишь малый, далеко не полный список манипуляций, предотвращающий XSS-уязвимости. Как писалось выше — при обнаружении XSS в ходе тестирования лучше всего пообщаться с программистами.

Если Вам интересно знать больше про тестирование безопасности, хочется лучше разобраться в устройстве клиент-серверной архитектуры, понять и отточить самые эффективные способы поиска уязвимостей на настоящем веб-приложении, приходите на мой курс “Тестирование безопасности”. Вся необходима информация есть в моем профиле.

Вас ждет только полезная и нужная теория без воды и большое количество практических примеров и заданий. Вы будете исследовать множество веб-страниц, напичканных самыми разными уязвимостями. Итоговой работой станет большое исследование либо вашего рабочего проекта, либо одного из веб-приложений таких гигантов как Google, Facebook, Twitter и так далее.

Что такое межсайтовый скриптинг? Типы XSS, примеры и защита

< Вернуться к руководствам

• Главная страница
• Направляющие
• Что такое межсайтовый скриптинг?

В наши дни гораздо правильнее думать о веб-сайтах как о онлайн-приложениях, выполняющих ряд функций, а не как о старых статических страницах. Большая часть этой надежной функциональности связана с широким использованием языка программирования JavaScript. Хотя JavaScript позволяет веб-сайтам делать довольно интересные вещи, он также представляет новые и уникальные уязвимости — межсайтовый скриптинг (XSS) является одной из самых серьезных угроз.

Защитите свой сайт

Что такое межсайтовый скриптинг (XSS)?

Межсайтовый скриптинг, обычно называемый XSS, происходит, когда хакеры запускают вредоносный код JavaScript в браузере жертвы.

В отличие от атак удаленного выполнения кода (RCE), код запускается в браузере пользователя. После первоначальной инъекции сайт обычно не полностью контролируется злоумышленником. Вместо этого злоумышленник прикрепляет свой вредоносный код к законному веб-сайту, фактически обманывая браузеры, заставляя их запускать свое вредоносное ПО всякий раз, когда сайт загружается.

Использование JavaScript в межсайтовых сценариях

JavaScript — это язык программирования, который запускается на веб-страницах в вашем браузере. Этот клиентский код добавляет веб-странице функциональность и интерактивность и широко используется во всех основных приложениях и платформах CMS.

В отличие от серверных языков, таких как PHP, код JavaScript внутри вашего браузера не может повлиять на веб-сайт для других посетителей. Он привязан к вашему собственному навигатору и может выполнять действия только в окне вашего браузера.

Хотя JavaScript является клиентской стороной и не запускается на сервере, его можно использовать для взаимодействия с сервером путем выполнения фоновых запросов. Злоумышленники могут использовать эти фоновые запросы для добавления нежелательного спам-контента на веб-страницу без ее обновления, сбора аналитики о браузере клиента или выполнения действий асинхронно.

Как работают атаки с использованием межсайтовых сценариев?

Когда злоумышленники внедряют свой собственный код на веб-страницу, что обычно достигается путем использования уязвимости в программном обеспечении веб-сайта, они затем могут внедрить свой собственный скрипт, который выполняется браузером жертвы.

Поскольку JavaScript запускается на странице браузера жертвы, конфиденциальные данные о аутентифицированном пользователе могут быть украдены из сеанса, что, по сути, позволяет злоумышленнику атаковать администраторов сайта и полностью скомпрометировать веб-сайт.

Другое популярное использование атак с использованием межсайтовых сценариев — когда уязвимость доступна на большинстве общедоступных страниц веб-сайта. В этом случае злоумышленники могут внедрить свой код для целевых посетителей веб-сайта, добавив собственную рекламу, фишинговые подсказки или другой вредоносный контент.

Какие существуют типы атак с использованием межсайтовых сценариев?

Теперь, когда мы рассмотрели основы, давайте углубимся. В зависимости от своих целей злоумышленники могут использовать межсайтовые сценарии различными способами. Давайте рассмотрим некоторые из наиболее распространенных типов атак.

1 Сохраненный (постоянный) межсайтовый скриптинг

Атаки с хранимым межсайтовым скриптингом происходят, когда злоумышленники хранят свою полезную нагрузку на скомпрометированном сервере, в результате чего веб-сайт доставляет вредоносный код другим посетителям.

Поскольку этот метод требует от злоумышленника только начальных действий и впоследствии может скомпрометировать многих посетителей, это наиболее опасный и наиболее часто используемый тип межсайтового скриптинга.

Примеры сохраненных атак с использованием межсайтовых сценариев включают поля профиля, такие как ваше имя пользователя или адрес электронной почты, которые сохраняются на сервере и отображаются на странице вашей учетной записи.

2Отраженный (непостоянный) межсайтовый скриптинг

Атаки с отраженным межсайтовым скриптингом происходят, когда полезная нагрузка сохраняется в данных, отправляемых из браузера на сервер. Эти атаки популярны в попытках фишинга и социальной инженерии, потому что уязвимые веб-сайты предоставляют злоумышленникам бесконечный набор веб-сайтов, выглядящих как законные, которые они могут использовать для атак.

Примеры отраженных атак с использованием межсайтовых сценариев включают в себя случаи, когда злоумышленник сохраняет вредоносный сценарий в данных, отправленных из формы поиска или контакта на веб-сайте.

Типичным примером отраженного межсайтового скриптинга является форма поиска, где посетители отправляют свой поисковый запрос на сервер, и только они видят результат.

Злоумышленники обычно отправляют жертвам настраиваемые ссылки, которые направляют ничего не подозревающих пользователей на уязвимую страницу. На этой странице они часто используют различные методы для подтверждения концепции.

3Самостоятельный межсайтовый скриптинг

Самостоятельный межсайтовый скриптинг возникает, когда злоумышленники используют уязвимость, которая требует очень специфического контекста и ручных изменений. Единственный, кто может быть жертвой, — это вы сами.

Эти конкретные изменения могут включать в себя такие вещи, как значения файлов cookie или установку вашей собственной информации в полезную нагрузку.

Примером самостоятельного межсайтового скриптинга является запуск непроверенного кода на платформах социальных сетей или в онлайн-играх, где за запуск кода предлагается некоторое вознаграждение или информация.

4Слепой межсайтовый скриптинг

Атаки с использованием слепого межсайтового скриптинга происходят, когда злоумышленник не может видеть результат атаки. В этих атаках уязвимость обычно находится на странице, доступ к которой имеют только авторизованные пользователи.

Этот метод требует большей подготовки для успешного запуска атаки; в случае сбоя полезной нагрузки злоумышленник не будет уведомлен.

Чтобы повысить вероятность успеха этих атак, хакеры часто используют полиглоты, которые предназначены для работы во многих различных сценариях, например, в атрибуте, в виде обычного текста или в теге скрипта.

Примером слепой атаки с использованием межсайтовых сценариев может быть случай, когда имя пользователя уязвимо для XSS, но только с административной страницы, ограниченной для пользователей-администраторов.

5Межсайтовые сценарии на основе DOM

Атаки на основе межсайтовых сценариев на основе DOM происходят, когда не сам сервер уязвим для XSS, а JavaScript на странице.

Поскольку JavaScript используется для добавления интерактивности на страницу, аргументы в URL-адресе можно использовать для изменения страницы после ее загрузки. Изменяя DOM, когда он не очищает значения, полученные от пользователя, злоумышленники могут добавить вредоносный код на страницу.

Примером атаки межсайтового скриптинга на основе DOM может быть, когда веб-сайт меняет выбор языка с языка по умолчанию на язык, указанный в URL-адресе.

Как предотвратить атаки с использованием межсайтовых сценариев?

Злоумышленники используют различные методы для использования уязвимостей веб-сайтов. В результате не существует единой стратегии снижения риска атаки с использованием межсайтовых сценариев.

Концепция межсайтового скриптинга основана на небезопасном вводе данных пользователем, который напрямую отображается на веб-странице. Если пользовательский ввод должным образом дезинфицировать, атаки с использованием межсайтовых сценариев будут невозможны. Существует несколько способов гарантировать, что пользовательский ввод не может быть скрыт на ваших веб-сайтах.

Чтобы защитить свой веб-сайт, мы рекомендуем вам усилить безопасность веб-приложений с помощью следующих защитных мер.

1Значения списка разрешений

Ограничить ввод пользователя определенным списком разрешений. Эта практика гарантирует, что на сервер отправляются только известные и безопасные значения. Ограничение пользовательского ввода работает только в том случае, если вы знаете, какие данные вы получите, например содержимое раскрывающегося меню, и непрактично для пользовательского содержимого.

2Избегайте и ограничивайте использование HTML во входных данных

Хотя HTML может потребоваться для расширенного содержимого, его следует ограничить доверенными пользователями. Если вы разрешаете стилизацию и форматирование входных данных, вам следует рассмотреть возможность использования альтернативных способов создания контента, таких как Markdown.

Наконец, если вы используете HTML, обязательно очистите его с помощью надежного дезинфицирующего средства, такого как DOMPurify, чтобы удалить весь небезопасный код.

3Sanitize Values ​​

Когда вы используете пользовательский контент на странице, убедитесь, что это не приведет к HTML-контенту, заменив небезопасные символы соответствующими объектами. Сущности выглядят так же, как обычные символы, но их нельзя использовать для создания HTML.

4Использовать флаги HTTPOnly для файлов cookie

Сеансовые файлы cookie — это механизм, который позволяет веб-сайту распознавать пользователя между запросами, и злоумышленники часто крадут сеансы администратора, удаляя их файлы cookie. После кражи файла cookie злоумышленники могут войти в свою учетную запись без учетных данных или авторизованного доступа.

Используйте файлы cookie HttpOnly, чтобы запретить JavaScript читать содержимое файла cookie, что усложнит злоумышленнику кражу сеанса.

Примечание: Этот метод только предотвращает чтение файла cookie злоумышленниками. Злоумышленники по-прежнему могут использовать активный сеанс браузера для отправки запросов, действуя от имени пользователя-администратора. Этот метод также полезен только при использовании файлов cookie в качестве основного механизма идентификации.

5Используйте WAF для защиты от атак с использованием межсайтовых сценариев

Вы можете использовать брандмауэр для виртуального исправления атак против вашего веб-сайта. Этот метод перехватывает такие атаки, как XSS, RCE или SQLi, еще до того, как вредоносные запросы достигнут вашего веб-сайта. Он также имеет преимущество защиты от крупномасштабных атак, таких как DDOS.

Действия после взлома

В случае межсайтового скриптинга существует ряд шагов, которые вы можете предпринять, чтобы исправить свой веб-сайт.

1Locate Vulnerable Code

Первым шагом в восстановлении после межсайтового сценария является определение места расположения уязвимости. Вы можете обратиться к нашему полезному руководству по взломанному веб-сайту для получения подробных инструкций.

2Удаление вредоносного содержимого и бэкдоров

Получив информацию о местонахождении вредоносного ПО, удалите любое вредоносное содержимое или неверные данные из базы данных и восстановите ее до чистого состояния. Вы также захотите проверить остальную часть вашего веб-сайта и файловых систем на наличие бэкдоров.

3Исправьте уязвимость

Хакеры часто используют уязвимости в базах данных, приложениях и сторонних компонентах. Как только вы определили уязвимое программное обеспечение, примените исправления и обновления к уязвимому коду вместе с любыми другими устаревшими компонентами.

4Обновите свои учетные данные

При компрометации важно изменить все ваши пароли и секреты приложений, как только уязвимость будет исправлена. Предотвратите повторное заражение, очистив свои данные, чтобы убедиться, что в базе данных нет мошеннических пользователей-администраторов или бэкдоров.

5Настройка WAF

Рассмотрите возможность настройки брандмауэра веб-приложений для фильтрации вредоносных запросов на ваш веб-сайт. Они могут быть особенно полезны для защиты от новых уязвимостей до того, как будут выпущены исправления.

Если вы считаете, что ваш веб-сайт подвергся атаке с использованием межсайтовых сценариев, и вам нужна помощь, наши услуги по удалению и защите от вредоносных программ могут отремонтировать и восстановить ваш взломанный веб-сайт.

Наша специальная группа реагирования на инциденты и брандмауэр веб-сайта могут безопасно удалить вредоносный код из файловых систем и базы данных вашего веб-сайта, полностью восстановив его до исходного состояния.

Дополнительные ресурсы

Узнайте, как определить проблемы, если вы подозреваете, что ваш сайт WordPress был взломан.

Смотреть сейчас

Присоединяйтесь к нашей серии электронных писем, поскольку мы предлагаем практические шаги и основные методы обеспечения безопасности для владельцев сайтов WordPress.

Зарегистрироваться

По нашим данным, тремя наиболее часто заражаемыми платформами CMS были WordPress, Joomla! и Мадженто.

Прочитать

Изучите передовые методы обеспечения безопасности для веб-сайтов WordPress, чтобы улучшить состояние веб-сайта и снизить риск взлома.

См. сейчас

Что такое межсайтовый скриптинг (XSS)? Определение и предотвращение

Что такое межсайтовый скриптинг (XSS)?

Межсайтовый скриптинг (XSS) — это атака безопасности путем внедрения кода, нацеленная на веб-приложения, которая доставляет вредоносные клиентские сценарии в веб-браузер пользователя для выполнения. Цели не подвергаются прямым атакам, скорее уязвимые веб-сайты и веб-приложения используются для выполнения атак с использованием межсайтовых сценариев, когда пользователи взаимодействуют с этими сайтами/приложениями.

Ничего не подозревающий пользователь, например, посещает скомпрометированный веб-сайт, после чего вредоносный сценарий злоумышленника загружается и выполняется браузером пользователя. Это может привести к эксфильтрации/краже конфиденциальных данных, перехвату сеанса и многому другому. Из-за широкой поддержки во многих веб-браузерах и платформах JavaScript был популярным выбором для авторов XSS-атак, но атака может быть реализована на любом языке, поддерживаемом браузерами. Хотя XSS-атаки существуют уже более 15 лет, они доказали свою высокую эффективность и до сих пор часто рассматриваются как распространенный и жизнеспособный вектор атак.

 

Воздействие межсайтовых сценариев

Когда веб-страница скомпрометирована с помощью межсайтовых сценариев, может быстро возникнуть ряд проблем. Возможные проблемы включают, но не ограничиваются:

• Раскрытие конфиденциальных пользовательских данных
• Злоумышленники захватывают онлайн-аккаунты и выдают себя за пользователей
• Вандализм в отношении представления содержимого веб-сайта
• Загрузка вредоносных «троянских программ»
• Перенаправление веб-страниц в опасные места

Межсайтовые сценарии могут нанести ущерб организации, если они не будут обнаружены и не обработаны в кратчайшие сроки. Поскольку компании и клиенты подвергаются риску XSS-атак, репутация и профессиональные отношения могут быть негативно затронуты после успешной инъекции вредоносного ПО.

Неудачный пример межсайтового скриптинга произошел во время курортного сезона 2018 г., когда появилось вредоносное ПО для скимминга кредитных карт под названием «Magecart». впервые такое масштабное нападение произошло. Информация о кредитной карте пользователя, вероятно, была загружена на сервер, контролируемый злоумышленником, и потенциально продана или использована для мошеннических покупок.

Типы атак с использованием межсайтовых сценариев

Атаки с использованием межсайтовых сценариев обычно относятся к одному из следующих типов.

• Отраженный XSS
• Постоянный XSS
• XSS на базе домена

Отраженный XSS

Отраженная XSS-атака включает в себя уязвимый веб-сайт, принимающий данные (т. е. вредоносный скрипт), отправленные собственным веб-браузером цели для атаки. Поскольку вредоносный скрипт отправляется самим клиентом и не хранится на уязвимом сервере, этот тип атаки также называют «непостоянным».

Простым примером отраженной атаки XSS может быть создание злоумышленником URL-адреса, который передает небольшой вредоносный скрипт в качестве параметра запроса на веб-сайт, страница поиска которого уязвима для XSS:

            http://vulnerable- веб-сайт.com/search?search_term=»»

Затем злоумышленнику необходимо, чтобы цели посещали этот URL-адрес из своих веб-браузеров. Этого можно добиться, отправив электронное письмо, содержащее URL-адрес (с разумной причиной, чтобы заставить пользователя щелкнуть по нему), или опубликовав URL-адрес на общедоступном, неуязвимом веб-сайте, чтобы цели могли щелкнуть.

Когда цель щелкает ссылку, уязвимый сайт принимает параметр запроса «search_term», ожидая, что это значение представляет собой то, что цель хочет найти на сайте уязвимый-website. com, когда на самом деле значение является вредоносным сценарий. Затем страница поиска, как и большинство страниц поиска веб-сайта, когда пользователь что-то ищет, отображает «Поиск …», но поскольку уязвимый сайт не очистил значение search_term, внедряется вредоносный скрипт. на веб-страницу, которую загружает целевой браузер, а затем выполняется целевым браузером.

Постоянная XSS

Как следует из названия, постоянная XSS-атака сохраняется/сохраняется на самом уязвимом сервере. В отличие от отраженной атаки, когда вредоносный скрипт отправляется целью, пользователи уязвимого веб-сайта или веб-приложения могут быть атакованы во время их обычного взаимодействия с уязвимым сайтом/приложением.

Простым примером постоянной XSS-атаки может быть размещение злоумышленником сообщения на форуме, размещенном на уязвимом веб-сайте. Вместо обычного безобидного поста на форуме этот пост содержит вредоносный скрипт злоумышленника. Когда пользователь посещает этот пост на форуме, его веб-браузер загружает и выполняет вредоносный скрипт.

Как видите, ключевым отличием отраженных и постоянных XSS-атак является то, что постоянные XSS-атаки рассматривают всех пользователей уязвимого сайта/приложения в качестве целей для атаки.

XSS на основе DOM

Другой тип атаки XSS основан на DOM, при этом уязвимость существует в сценариях на стороне клиента, которые сайт/приложение всегда предоставляет посетителям. Эта атака отличается от отраженных и постоянных XSS-атак тем, что сайт/приложение не отправляет вредоносный скрипт напрямую в браузер цели. При атаке XSS на основе DOM сайт/приложение имеют уязвимые сценарии на стороне клиента, которые доставляют вредоносный сценарий в браузер цели. Подобно отраженной атаке, атака на основе DOM не сохраняет вредоносный скрипт на самом уязвимом сервере.

Простой пример атаки XSS на основе DOM может включать ту же настройку для приведенного выше примера отраженного сценария XSS. Злоумышленник создает URL-адрес с вредоносным скриптом в качестве «search_term» и запрашивает его у потенциальных целей. Как только цель щелкает URL-адрес, их браузер загружает страницу поиска по сайту и уязвимые сценарии обработки на стороне клиента. Хотя «seach_term» по-прежнему предоставляется серверной части сайта в качестве параметра запроса для обработки, сам сайт не создает веб-страницу с внедренным вредоносным скриптом. Вместо этого уязвимые клиентские сценарии сайта предназначены для локальной (в браузере цели) динамической замены значения поискового запроса (т. е. вредоносного сценария) на странице поиска цели, в результате чего браузер цели загружает и выполняет сценарий злоумышленника. .

XSS-атаки на основе DOM подчеркивают тот факт, что XSS-уязвимости не ограничиваются серверным программным обеспечением.

Как предотвратить атаки с использованием межсайтовых сценариев

При наличии нескольких вариантов атак с использованием межсайтовых сценариев организациям необходимо знать, как надлежащим образом защитить себя и предотвратить будущие проблемы. За веб-сайтами становится все труднее строго следить, чем когда-либо прежде, из-за того, насколько они усложняются. Частота атак, вероятно, будет продолжать расти с течением времени.

Следующие рекомендации могут помочь защитить ваших пользователей от XSS-атак:

Дезинфекция пользовательского ввода:

• Проверка для перехвата потенциально вредоносного пользовательского ввода.
• Кодируйте выходные данные, чтобы потенциально вредоносные данные, предоставленные пользователем, не вызывали автоматическую загрузку и выполнение в браузере.

Ограничить использование предоставленных пользователем данных:

• Использовать только там, где это необходимо.

Использовать политику безопасности контента:

• Обеспечивает дополнительные уровни защиты и смягчения последствий попыток XSS.

Регулярно используйте инструмент сканирования уязвимостей веб-приложений для выявления уязвимостей XSS в вашем программном обеспечении.

Несмотря на то, что XSS-атаки продолжают оставаться популярным (и успешным) направлением атак, продуманный дизайн и тестирование могут иметь большое значение для защиты вашего веб-сайта или веб-приложения от уязвимости (и защиты ваших пользователей).