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

XSS

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

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

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

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

Со времени создания термина в 2000 году его значение несколько расширилось в последние годы. Первоначально он использовался для ссылки на процесс загрузки стороннего веб-приложения с некоторым фрагментом кода JavaScript; то есть, используя непостоянную уязвимость XSS. С тех пор этот термин расширился и включает постоянные и не JavaScript-векторы, такие как VBScript, ActiveX, Flash и даже HTML. Как таковые, большинство классифицировало недостатки, связанные с двумя типами; постоянные и непостоянные недостатки XSS.

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

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

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

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

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

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

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

Мутантный XSS (mXSS) — это когда внедрение кода злоумышленника выглядит безопасным для браузера, но затем каким-то образом изменяется браузером. Этот метод трудно идентифицировать и поэтому; sanitize, и может быть чем-то таким же простым, как браузер, добавляющий закрывающие кавычки в незамкнутый параметр.

Профилактические меры

К счастью, существуют некоторые меры, которые могут быть реализованы с помощью хорошей практики, и на переднем крае списка находится кодирование вывода и экранирование ввода. По сути, это может быть достигнуто путем использования подходящей схемы экранирования в зависимости от того, где должна находиться недоверенная строка в файле HTML. Это включает в себя кодирование сущности HTML, экранирование JavaScript, экранирование CSS и кодирование URL. Эти методы имеют большое значение для предотвращения уязвимостей XSS для веб-приложений, которые не принимают расширенные данные; использование библиотеки кодирования безопасности может быть лучше, чем использование кодировки сущностей HTML для 5 ключевых слов XML (кавычка, амперсанд, апостроф, знак «меньше» и «больше»), что обычно рекомендуется.

Другим методом является использование средства очистки или очистки HTML, что обычно делают почтовые приложения и форумы, которые позволяют использовать ограниченную разметку HTML. Эти механизмы обычно работают путем внесения в черный список определенной разметки HTML, которая имеет более высокий риск быть вредоносной (например, script, link и iframe). Однако следует признать, что этот метод все еще имеет некоторые недостатки, поскольку учитываются не все возможные ключевые слова (img src = «javascript: doSomethingEvil ()» может, например, обойти большинство из этих механизмов).

Также существуют меры, которые не фокусируются на фильтрации содержимого, такие как добавление дополнительной безопасности при использовании аутентификации пользователя на основе файлов cookie. Поскольку сеансовые cookie-файлы являются основным использованием многих веб-приложений для проверки между HTTP-запросами, многие веб-приложения привязывают IP-адрес пользователя к cookie-файлу, так что только этот человек может получить доступ к cookie-файлу. Этот процесс смягчает угрозу атаки XSS; особенно если злоумышленник только после этого куки; однако это становится менее эффективным в сценариях, когда злоумышленник находится за тем же IP-адресом трансляции сетевого (NATed) или веб-прокси, что и цель, или если жертва меняет свой мобильный IP-адрес (MIP).

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

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

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

0 0 vote
Article Rating
Подписаться
Уведомление о
guest
0 Комментарий
Inline Feedbacks
View all comments