Межсайтовый скриптинг с применением java script – наиболее популярная разновидность атак. В данном материале мы расскажем вам о том, какие неприятности вызывает использование java script и как обезопасить себя от XSS атак.
Что такое XSS атака?XSS – тип атак на пользователей Интернет-ресурсов, целью которых является похищение аутентификационных данных админов сайтов для получения доступа к административной части, прочих пользователей, которые имеют возможность персонального доступа к закрытым частям ресурса.
Данные атаки могут проводиться не только с целью взлома сайта, но также и для похищения:
- Учётных данных для доступа к сторонним ресурсам;
- Номеров банковских карт;
- Данных для доступа к электронным кошелькам;
- Контактных данных;
- Иных пользовательских конфиденциальных данных.
Данный тип атак имеет два направления:
Активные – разновидность атак, когда злоумышленник пытается найти уязвимые места в фильтре Интернет-ресурса. Посредством определённой комбинации символов и тегов хакер создаёт такой запрос, который ресурс понимает и выполняет команду. После нахождения уязвимого места в системе безопасности, в запрос вкладывается вредоносный код, который, например, будет пересылать все cookie в комфортное для хакера место.
Пассивные – предполагают вмешательство субъекта атаки. Суть – заставить пользователя перейти по вредоносной ссылке для реализации вредоносного кода. Данные атаки труднореализуемы, поскольку требуют наличия у злоумышленника отличных технических знаний и хороших познаний в области психологии.
Правила безопасностиЧтобы не стать жертвой атаки XSS следует придерживаться следующих правил безопасности:
По статистике 84% Интернет-ресурсов хорошо защищены от XSS атак. Прочие 16% не в состоянии эффективно противостоять им. Устранение этого грубого недочёта требует от владельцев сайтов дополнительных капиталовложений в безопасность, на что большинство из них не готовы. Однако ужесточение законодательства относительно повреждения, утечки и разглашения персональных данных всё больше заставляет недобросовестных владельцев улучшать безопасность своих сайтов.
Межсайтовые скрипты (XSS) относятся к атаке инъекции кода на стороне клиента, в которой злоумышленник может выполнять вредоносные скрипты на веб-сайте или веб-приложении. XSS является одним из наиболее распространенных уязвимостей веб-приложения и происходит, когда веб-приложение не использует валидацию или кодирование вводимы-выводимых данных.
Используя XSS, злоумышленник не нацеливается непосредственно на жертву. Вместо этого он воспользуется уязвимостью веб-сайта или веб-приложения, которое посетит жертва, по существу используя уязвимый веб-сайт в качестве средства доставки вредоносного сценария в браузер жертвы.
В то время как XSS может быть использован в VBScript, ActiveX и Flash (хотя последний в настоящее время считается устаревшим), бесспорно, им наиболее широко злоупотребляют в JavaScript – в первую очередь потому, что JavaScript имеет фундаментальное значение для большинства сайтов.
Как работает межсайтовый скрипт
Чтобы запустить вредоносный код JavaScript в браузере жертвы, злоумышленник должен сначала найти способ внедрить полезные данные на веб-страницу, которую посещает жертва. Конечно, злоумышленник может использовать методы социальной инженерии, чтобы убедить пользователя посетить уязвимую страницу с введенной полезной нагрузкой JavaScript.
Для атаки на XSS уязвимый веб-сайт должен непосредственно включать пользовательский ввод на своих страницах. Затем злоумышленник может вставить строку, которая будет использоваться на веб-странице и обрабатываться браузером жертвы как код.
Следующий псевдо-код на стороне сервера используется для отображения последнего комментария на веб-странице.
Print "" print "Most recent comment" print database.latestComment print "" Приведенный выше скрипт просто распечатывает последний комментарий из базы данных комментариев и печатает содержимое на HTML-странице, предполагая, что распечатанный комментарий состоит только из текста.
Вышеупомянутый код страницы уязвим к xss, потому что злоумышленник может оставить комментарий, который содержит вредоносную нагрузку, например
doSomethingEvil();. Пользователи, посещающие веб-страницу, получат следующую HTML-страницу.
Most recent comment doSomethingEvil(); Когда страница загружается в браузере жертвы, вредоносный скрипт злоумышленника будет выполняться, чаще всего без осознания или возможности пользователя предотвратить такую атаку.
Важное примечание: -xss-уязвимость может существовать только если полезная нагрузка (вредоносный скрипт), который злоумышленник вставляет, в конечном счете обрабатывается (как HTML в данном случае) в браузере жертвы
Что может сделать злоумышленник с JavaScript?
Последствия того, что злоумышленник может сделать с возможностью выполнения JavaScript на веб-странице, могут не сразу проявиться, тем более что браузеры запускают JavaScript в очень жестко контролируемой среде и что JavaScript имеет ограниченный доступ к операционной системе пользователя и файлам пользователя.
Однако, учитывая, что JavaScript имеет доступ к следующему, легче понять, что творческие злоумышленники могут получить с JavaScript.
Вредоносный JavaScript имеет доступ ко всем тем же объектам, что и остальная часть веб-страницы, включая доступ к cookies. Файлы cookie часто используются для хранения маркеров сеансов, если злоумышленник может получить файл cookie сеанса пользователя, он может олицетворять этого пользователя.
JavaScript может использовать XMLHttpRequest для отправки http-запросов с произвольным содержанием в произвольных направлениях.
JavaScript в современных браузерах может использовать API HTML5, такие как доступ к геолокации пользователя, веб-камера, микрофон и даже конкретные файлы из файловой системы пользователя. В то время как большинство из этих API требуют участия пользователя, XSS в сочетании с некоторой умной социальной инженерией может принести злоумышленнику неплохие результаты.
Вообще, в сочетании с социальной инженерией, это способы позволяют злоумышленникам организовывать такие атаки, как кражу кук, кейлоггинг, фишинг и кражи личных данных. Критично, что уязвимости XSS обеспечивают идеальную почву для нападающих для эскалации атак на более серьезные.
Разве межсайтовые скрипты не проблема пользователя?
Нет. Если злоумышленник может злоупотребить уязвимостью XSS на веб-странице, чтобы выполнить произвольный JavaScript в браузере посетителя, безопасность этого веб-сайта или веб - приложения и его пользователей была скомпрометирована-xss не является проблемой пользователя, как и любая другая Уязвимость безопасности, если она затрагивает ваших пользователей, это повлияет на вас.
Анатомия межсайтовой скриптовой атаки
Для Xss-атаки нужны три участника: сайт, жертва и нападающий. В приведенном ниже примере предполагается, что целью злоумышленника является выдача себя за жертву путем кражи куки жертвы. Отправка файлов cookie на сервер злоумышленника может быть осуществлена различными способами, одним из которых является выполнение следующего кода JavaScript в браузере жертвы с помощью уязвимости XSS.
window.?cookie=” + document.cookie На рисунке ниже показано пошаговое руководство по простой атаке XSS.
- Злоумышленник вводит полезные данные в базу данных веб-сайта, отправляя уязвимую форму с помощью вредоносного кода JavaScript
- Жертва запрашивает веб-страницу с веб-сайта
- Веб-сайт служит браузеру жертвы страница с полезной нагрузкой злоумышленника как часть тела HTML.
- Браузер жертвы будет выполнять вредоносный скрипт внутри тела HTML. В этом случае он отправит куки жертвы на сервер злоумышленника. Теперь злоумышленник должен просто извлечь файл cookie жертвы, когда HTTP-запрос поступает на сервер, после чего злоумышленник может использовать украденный файл cookie жертвы.
Ниже приведен небольшой список сценариев атаки XSS, которые злоумышленник может использовать для нарушения безопасности веб-сайта или веб-приложения.
тег
Этот тег является наиболее прямой xss уязвимостью. Тег script может ссылаться на внешний код JavaScript.
alert("XSS"); тег
При xss инъекция может быть доставлена внутрь тега с помощью onload атрибута или другим более темным атрибутом, таким как background.
тег Некоторые браузеры будут выполнять JavaScript, когда он находится в .
тег Этот тег позволяет встраивать другую HTML-страницу в родительскую. IFrame может содержать JavaScript, однако важно отметить, что JavaScript в iFrame не имеет доступа к DOM родительской страницы из-за политики безопасности содержимого браузера (CSP). Тем не менее, IFrames по-прежнему являются очень эффективным средством для фишинговых атак.
тег
В некоторых браузерах, если этот type атрибут тега имеет значение image, он может использоваться для размещения скрипта.
тег
В теге, который часто используется для ссылки на внешние таблицы стилей, могут содержаться скрипт.
теги можно указать фон, и поэтому вставить скрипт.
тег Этот тег может использоваться для включения в скрипт с внешнего сайта. Уязвим ли ваш сайт для межсайтового скриптинга? Уязвимости XSS являются одними из наиболее распространенных уязвимостей веб-приложений в интернете. К счастью, легко проверить, если ваш веб-сайт или веб-приложение уязвимы для XSS и других уязвимостей, просто обратившись ко мне. Я за небольшую плату с помощью специальных программ просканирую ваш ресурс, найду потенциальные уязвимости и подскажу, как их устранить. Все мы знаем, что такое межсайтовый скриптинг, правда? Это уязвимость, при которой атакующий посылает злонамеренные данные (обычно это HTML, содержащий код Javascript), которые позднее возвращаются приложением, что вызывает исполнение Javascript кода. Итак, это неверно! Существует тип XSS атак не соответствующий этому определению, по крайней мере, в основных фундаментальных принципах. XSS атаки, определение которых приведено выше, подразделяются на моментальные (злонамеренные данные встраиваются в страницу, которая возвращается браузеру сразу же после запроса) и отложенные (злонамеренные данные возвращаются через некоторое время). Но есть еще третий тип XSS атак, в основе которого не лежит отправка злонамеренных данных на сервер. Несмотря на то, что это кажется противоречащим здравому смыслу, есть два хорошо описанных примера такой атаки. Эта статья описывает третий тип XSS атак – XSS через DOM (DOM Based XSS). Здесь не будет написано ничего принципиально нового об атаке, скорее новшество этого материала в выделении отличительных черт атаки, которые являются очень важными и интересными. Разработчики и пользователи прикладных приложений должны понимать принципы атаки XSS через DOM, так как она представляет угрозу для web приложений и отличается от обычного XSS. В сети интернет есть много web приложений уязвимых к XSS через DOM и при этом проверенных на XSS и признанных “неуязвимыми” к этому типу атак. Разработчики и администраторы сайтов должны ознакомиться с методами обнаружения и защиты от XSS через DOM, так как эти методики отличаются от приемов, используемых при работе со стандартными XSS уязвимостями. ВведениеЧитатель должен быть знаком с основными принципами XSS атак (, , , , ). Под XSS обычно подразумевается моментальный () и отложенный межсайтовый скриптинг. При моментальном XSS злонамеренный код (Javascript) возвращается атакуемым сервером немедленно в качестве ответа на HTTP запрос. Отложенный XSS означает, что злонамеренный код сохраняется на атакуемой системе и позднее может быть внедрен в HTML страницу уязвимой системы. Как было упомянуто выше, такая классификация предполагает, что фундаментальное свойство XSS состоит в том, что злонамеренный код отсылается из браузера на сервер и возвращается в этот же браузер (моментальный XSS) или любой другой браузер (отложенный XSS). В этой статье поднимается вопрос о том, что это неверная классификация. Возможность осуществления XSS атаки, не основывающейся на внедрении кода в страницу, возвращаемую сервером, оказала бы серьезное влияние на методы защиты и обнаружения. Принципы таких атак обсуждаются в этой статье. Пример и комментарииПеред описанием простейшего сценария атаки важно подчеркнуть, что методы, описываемые здесь, уже неоднократно демонстрировались публично (например, , и ). Я не претендую на то, что приведенные ниже методики описываются впервые (хотя некоторые из них имеют отличия от ранее опубликованных материалов). Признаком уязвимого сайта может служить наличие HTML страницы, использующей данные из document.location, document.URL или document.referrer (или любых других объектов на которые может влиять атакующий) небезопасным способом. Примечание для читателей незнакомых с этими объектами Javascript: когда код Javascript выполняется в браузере, он получает доступ к нескольким объектам, представленных в рамках DOM (Document Object Model – Объектная Модель Документа). Объект document является главным среди этих объектов и предоставляет доступ к большинству свойств страницы. Этот объект содержит много вложенных объектов, таких как location, URL и referrer. Они управляются браузером в соответствии с точкой зрения браузера (как будет видно ниже, это весьма существенно). Итак, document.URL и document.location содержат URL страницы, а точнее, то, что браузер подразумевает под URL. Обратите внимание, эти объекты не берутся из тела HTML страницы. Объект document содержит объект body, содержащий обработанный (parsed) HTML код страницы. Не сложно найти HTML страницу, содержащую Javascript код, который анализирует строку URL (получив к ней доступ через document.URL или document.location) и в соответствии с ее значением выполняет некоторые действия на стороне клиенте. Ниже приведен пример такого кода. По аналогии с примером в рассмотрим следующую HTML страницу (предположим, что это содержание http://www.vulnerable.site/welcome.html ):
Welcome!
Hi
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
Однако запрос наподобие этого – http://www.vulnerable.site/welcome.html?name=alert(document.cookie) вызвал бы XSS. Рассмотрим, почему: браузер жертвы, получивший это ссылку, отправляет HTTP запрос на www.vulnerable.site и получает вышеупомянутую (статическую!) HTML страницу. Браузер жертвы начинает анализировать этот HTML код. DOM содержит объект document, имеющий поле URL, и это поле заполняется значением URL текущей страницы в процессе создания DOM. Когда синтаксический анализатор доходит до Javascript кода, он выполняет его, что вызывает модификацию HTML кода отображаемой страницы. В данном случае, код ссылается на document.URL и так как часть этой строки во время синтаксического разбора встраивается в HTML, который сразу же анализируется, обнаруженный код (alert(…)) выполняется в контексте той же самой страницы. Замечания: 1. Злонамеренный код не встраивается в HTML страницу (в отличие от других разновидностей XSS). В примере выше злонамеренный код все еще передается на сервер (как часть HTTP запроса), поэтому атака может быть обнаружена, так же как и любая другая XSS атака. Но это решаемая проблема. Рассмотрим следующий пример: http://www.vulnerable.site/welcome.html#name=alert(document.cookie) Обратите внимание на символ ‘#’ справа от имени файла. Он говорит браузеру, что все после этого символа не является частью запроса. Microsoft Internet Explorer (6.0) и Mozilla не отправляет фрагмент после символа ‘#’ на сервер, поэтому для сервера этот запрос будет эквивалентен http://www.vulnerable.site/welcome.html, т.е. злонамеренный код даже не будет замечен сервером. Таким образом, благодаря этому приему, браузер не отправляет злонамеренную полезную нагрузку на сервер. Но все же в некоторых случаях невозможно скрыть полезную нагрузку: в и злонамеренная полезная нагрузка является частью имени пользователи (username) в URL типа http://username@host/. В этом случае браузер отправляет запрос с заголовком Authorization, содержащий имя пользователи (злонамеренная полезная нагрузка), в результате чего злонамеренный код попадает на сервер (закодированный с помощью Base64 – следовательно IDS/IPS для обнаружения атаки должны вначале декодировать эти данные). Однако сервер не обязан внедрять эту полезную нагрузку в одну из доступных HTML страниц, хотя это является необходимым условием выполнения XSS атаки. Очевидно, что в ситуациях, когда полезная нагрузка может быть полностью скрыта, средства обнаружения (IPS) и предотвращения (IPS, межсетевые экраны для web приложений) не могут полностью защитить от этой атаки. Даже если полезную нагрузку нужно отсылать на сервер, во многих случаях для избежания обнаружения она может быть преобразована определенным образом. Например, если какой-то параметр защищен (к примеру, параметр name в примере выше), небольшое изменение сценария атаки может принести результат: (document.cookie) Более строгая политика безопасности требовала бы обязательной отсылки параметра name. В этом случае вы может сделать следующий запрос: http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe Если политика безопасности ограничивает дополнительные имена параметров (например: foobar), можно использовать следующий вариант: http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe Обратите внимание, что игнорируемый параметр (foobar) должен идти первым и в своем значении содержать полезную нагрузку. Сценарий атаки, описанный в , еще более предпочтителен для атакующего, так как в HTML страницу пишется полное значение document.location (Javascript код не производит поиск специфичного имени параметра). Таким образом, атакующий может полностью скрыть полезную нагрузку, отправив следующее: /attachment.cgi?id=&action=foobar#alert(document.cookie) Даже если полезная нагрузка анализируется сервером, защита может гарантироваться только в том случае, если запрос будет отклонен или ответ будет заменен на некоторый текст ошибки. Обратимся снова к и : если заголовок Authorization будет просто удален промежуточной системой защиты, это не принесет никакого эффекта, если будет возвращена оригинальная страница. Аналогично любая попытка обработки данных на сервере, путем удаления или кодирования запрещенных символов, будет неэффективна против этой атаки. В случае с document.referrer, полезная нагрузка отсылается на сервер через заголовок Referer. Однако если браузер пользователя или промежуточная защита удалит этот заголовок — не останется никаких следов атаки, которая можно пройти полностью незамеченной. Подводя итоги, делаем вывод, что традиционные методы, а именно 1. Кодирование данных HTML на стороне сервера Автоматический поиск уязвимости путем “бомбардировки” злонамеренными данными (иногда называемый fuzzing) не будет работать, так как программы, использующие эту методику, обычно делают выводы на основе того, присутствуют ли внедренные данные в возвращенной странице или нет (вместо выполнения кода в контексте браузера на стороне клиента и наблюдения за результатами). Однако, если программа может статически анализировать код Javascript, обнаруженный на странице, она может указать на подозрительные признаки (см. ниже). И конечно, если средства защиты могут исполнять код Javascript (и корректно инициализировать DOM объекты) или эмулировать такое исполнение, они смогут обнаружить эту атаку. Ручной поиск уязвимости с помощью браузера также будет работать, так как браузер может выполнять клиентский код Javascript. Средства поиска уязвимостей могут принять на вооружение этот метод и выполнять код на стороне клиента для слежения за результатами его выполнения. Избегать перезаписи документа на стороне клиента, переадресацию или другие подобные действия, использующие данные на стороне клиента. Большинство этих действий может быть выполнено с использованием динамических страниц (на стороне сервера). Анализ и повышение защищенности кода (Javascript) на стороне клиента. Ссылки на объекты DOM, на которые может влиять пользователь (атакующий), должны быть тщательно проверены. Особое внимание нужно уделять следующим объектам (но не ограничиваться ими): Обратите внимание: на свойства объектов document и window можно сослаться несколькими способами: явно (пример — window.location), неявно (пример — location) или через получения дескриптора и использования его (пример — handle_to_some_window.location). Особое внимание нужно уделить коду, где модифицируется DOM, явно или есть потенциальная возможность, а также через прямой доступ к HTML или через доступ непосредственно к DOM. Примеры (это ни в коем случае не исчерпывающий список): Что такое XSS-уязвимость? Стоит ли ее опасаться? Межсайтовый скриптинг (сокращенно XSS) - широко распространенная уязвимость, затрагивающая множество веб-приложений. Она позволяет злоумышленнику внедрить вредоносный код в веб-сайт таким образом, что браузер пользователя, зашедшего на сайт, выполнит этот код. Обычно для эксплуатации подобной уязвимости требуется определенное взаимодействие с пользователем: либо его заманивают на зараженный сайт при помощи социальной инженерии, либо просто ждут, пока тот сам посетит данный сайт. Поэтому разработчики часто не воспринимают всерьез XSS-уязвимости. Но если их не устранять, это может нести серьезную угрозу безопасности. Представим, что мы находимся в панели администратора WordPress, добавляем новый контент. Если мы используем для этого уязвимый к XSS плагин, он может заставить браузер создать нового администратора, видоизменить контент и выполнить другие вредоносные действия. Межсайтовый скриптинг предоставляет злоумышленнику практически полный контроль над самым важным программным обеспечением в наши дни - браузером. XSS: Уязвимость для инъекцииЛюбой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму: Рисунок 1. Форма ввода данных Наше имя будет храниться в базе данных сайта для последующего взаимодействия с нами. Наверняка, когда вы проходили авторизацию на каком-либо сайте, вы видели персональное приветствие в стиле «Добро пожаловать, Илья». Именно для таких целей имена пользователей хранятся в базе данных. Инъекцией называется процедура, когда вместо имени или пароля вводится специальная последовательность символов, заставляющая сервер или браузер отреагировать определенным, нужным злоумышленнику образом. Межсайтовым скриптингом называется инъекция, внедряющая код, который будет выполнять действия в браузере от имени веб-сайта. Это может происходить как с уведомлением пользователя, так и в фоновом режиме, без его ведома. Рисунок 2. Наглядная схема межсайтового скриптинга В качестве простейшего примера можно привести элементарный скрипт, показывающий окно с уведомлением. Выглядит он примерно так: Таблица 1. Скрипт, вызывающий всплывающее окно alert(" ЭТО XSS- УЯЗВИМОСТЬ !!!") Данный скрипт вызывает окно с надписью «ЭТО XSS-УЯЗВИМОСТЬ!!!». Браузер пользователя воспринимает и выполняет этот скрипт как часть легитимного кода сайта. Типы XSS-уязвимостейНе все уязвимости XSS одинаковы, их существует множество типов. Здесь перечислены типы и способы их взаимодействия: Рисунок 3. Типы XSS-уязвимостей Уязвимости, вызванные кодом на стороне сервера (Java, PHP, .NET и т. д.): Традиционные XSS-атаки: Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.): Также известные как DOM-модели: Уязвимости, вызванные инфраструктурой (браузер, плагины, сервера и т. д.): Встречаются очень редко, но являются более опасными: Уязвимости, вызванные пользователем: Как можно защитить свой сайт от XSS? Как проверить код на наличие уязвимости? Существуют технологии вроде Sucuri Firewall, специально разработанные для того, чтобы избежать подобных атак. Но если вы разработчик, вы, безусловно, захотите узнать подробнее, как идентифицировать и устранить XSS-уязвимости. Об этом мы поговорим в следующей части статьи, посвященной XSS. Ори Сигал (Ory Segal) Узнайте, как хакеры используют атаку типа "межсайтовый скриптинг", что она повреждает (а что - нет), как их определять, а также как защитить свой Web-сайт и его посетителей от подобных злоумышленных нарушений конфиденциальности и безопасности. Межсайтовый скриптинг (cross-site scripting, или сокращенно XSS) - это одна из самых частых атак уровня приложения, которую хакеры используют для взлома Web-приложений. XSS - это атака на конфиденциальность информации клиентов определенного Web-сайта. Она может привести к полному разрушению системы безопасности, когда данные клиента крадутся и используются в дальнейшем для каких-либо целей. Большинство атак подразумевает участие двух сторон: либо злоумышленника и Web-сайт, либо злоумышленника и жертву-клиента. Однако в атаке XSS участвуют три стороны: злоумышленник, клиент и Web-сайт. Целью атаки XSS является кража с компьютера клиента файлов cookie или другой конфиденциальной информации, которая может идентифицировать клиента на Web-сайте. Располагая информацией для идентификации в качестве легального пользователя, злоумышленник может действовать на сайте в качестве такого пользователя, т.е. притворяться им. Например, при одном аудите, проводимом в большой компании, можно было с помощью атаки XSS получить частную информацию пользователя и номер его кредитной карты. Это было достигнуто путем запуска специального кода на JavaScript. Этот код был запущен в браузере жертвы (клиента), у которой были привилегии доступа на Web-сайт. Есть очень ограниченное число привилегий JavaScript, которые не дают доступ скрипта ни к чему, кроме информации, относящейся к сайту. Важно подчеркнуть, что, хотя уязвимость и существует на Web-сайте, сам он напрямую не повреждается. Но этого достаточно, чтобы скрипт собрал файлы cookie и отправил их злоумышленнику. В итоге злоумышленник получает нужные данные и может имитировать жертву. Давайте назовем атакуемый сайт следующим образом: www.vulnerable.site . В основе традиционной атаки XSS лежит уязвимый скрипт, который находится на уязвимом сайте. Этот скрипт считывает часть HTTP-запроса (обычно параметры, но иногда также HTTP-заголовки или путь) и повторяет его для ответной страницы, полностью или только часть. При этом не производится очистка запроса (т.е. не проверяется, что запрос не содержит код JavaScript или тэги HTML). Предположим, что этот скрипт называется welcome.cgi, и его параметром является имя. Его можно использовать следующим образом: Как этим можно злоупотребить? Злоумышленник должен суметь завлечь клиента (жертву), чтобы он щелкнул мышью ссылку, которую злоумышленник ему предоставляет. Это тщательно и злонамеренно подготовленная ссылка, которая заставляет Web-браузер жертвы обратиться к сайту (www.vulnerable.site) и выполнить уязвимый скрипт. Данные для этого скрипта содержат код на JavaScript, который получает доступ к файлам cookie, сохраненным браузером клиента для сайта www.vulnerable.site. Это допускается, поскольку браузер клиента "думает", что код на JavaScript исходит от сайта www.vulnerable.site. А модель безопасности JavaScript позволяет скриптам, исходящим от определенного сайта, получать доступ к файлам cookie, которые принадлежат этому сайту. Ответ уязвимого сайта будет следующим:
Браузер клиента-жертвы интерпретирует этот запрос как HTML-страницу, содержащую часть кода на JavaScript. Этот код при выполнении получит доступ ко всем файлам cookie, принадлежащим сайту www.vulnerable.site. Следовательно, он вызовет всплывающее окно в браузере, показывающее все файлы cookie клиента, которые относятся к www.vulnerable.site. Конечно, реальная атака подразумевала бы отправку этих файлов атакующему. Для этого атакующий может создать Web-сайт (www.attacker.site) и использовать скрипт для получения файлов cookie. Вместо вызова всплывающего окна злоумышленник написал бы код, который обращается по URL-адресу к сайту www.attacker.site. В связи с этим выполняется скрипт для получения файлов cookie. Параметром для этого скрипта служат украденные файлы cookie. Таким образом, злоумышленник может получить файлы cookie с сервера www.attacker.site. Немедленно после загрузки этой страницы браузер выполнит вставленный туда код JavaScript и перешлет запрос скрипту collect.cgi на сайте www.attacker.site вместе со значением файлов cookie с сайта www.vulnerable.site, которые уже есть в браузере. Это подрывает безопасность файлов cookie сайта www.vulnerable.site, которые есть у клиента. Это позволяет злоумышленнику притвориться жертвой. Конфиденциальность клиента полностью нарушена. Примечание.
Атака может произойти только в браузере жертвы, том же самом, который использовался для доступа к сайту (www.vulnerable.site). Атакующий должен заставить клиента получить доступ к вредоносной ссылке. Этого можно добиться несколькими способами.
Вредоносный код на JavaScript может получить доступ к любой перечисленной ниже информации:
Данные для идентификации, авторизации и аутентификации обычно хранятся в виде файлов cookie. Если эти файлы cookie постоянные, то жертва уязвима для атаки даже тогда, когда она не использует браузер в момент доступа к сайту www.vulnerable.site. Однако если файлы cookie - временные (например, они хранятся в оперативной памяти), то на стороне клиента должен существовать сеанс связи с сайтом www.vulnerable.site. Еще одна возможная реализация идентификационной метки - это параметр URL. В подобных случаях можно получить доступ к другим окнам, используя JavaScript следующим образом (предположим, что имя страницы с нужными параметрами URL - foobar):
Чтобы запустить скрипт на JavaScript, можно использовать множество тэгов HTML, помимо . На самом деле, вредоносный код JavaScript также можно разместить на другом сервере, а затем заставить клиента загрузить скрипт и выполнить его. Это может быть полезным, если нужно запустить большой объем кода, либо если код содержит специальные символы. Вот несколько вариаций этих возможностей.
Иногда данные, внедренные в ответную страницу, находятся в платном HTML-контексте. В этом случае сначала нужно "сбежать" в бесплатный контекст, а затем предпринять атаку XSS. Например, если данные вставляются в качестве значения по умолчанию для поля формы HTML: А итоговый код HTML будет следующим:
|