Шрифт:
Вопросы безопасности приобретают особую важность, когда речь заходит о передаче управления элементам ActiveX и модулям расширения. Апплеты Java, например, могут иметь низкоуровневый доступ к сетевым возможностям. Защитная «песочница» для Java не позволяет апплетам взаимодействовать с серверами, отличными от того, откуда они были получены; тем самым закрывается брешь в системе безопасности. Но остается основная проблема: если модуль расширения может управляться из сценария, необходимо полное доверие не только системе безопасности броузера, но и системе безопасности самого модуля расширения. На практике модули расширения Java и Flash, похоже, не имеют проблем с безопасностью и не вызывают появление этих проблем в клиентских сценариях на языке JavaScript. Однако элементы управления ActiveX имеют более пестрое прошлое. Броузер IE обладает возможностью доступа из сценариев к самым разным элементам управления ActiveX, которые являются частью операционной системы Windows и которые раньше уже были источниками проблем безопасности.
13.6.4. Межсайтовый скриптинг
Термин межсайтовый скриптинг (cross-site scripting), или XSS, относится к области компьютерной уязвимости, когда атакующий внедряет HTML-теги или сценарии в документы на уязвимом веб-сайте. Организация защиты от XSS-атак -обычное дело для веб-разработчиков, занимающихся созданием серверных сценариев. Однако программисты, разрабатывающие клиентские JavaScript-сценарии, также должны знать о XSS-атаках и предпринимать меры защиты от них.
Веб-страница считается уязвимой для XSS-атак, если она динамически создает содержимое документа на основе пользовательских данных, не прошедших предварительную обработку по удалению встроенного HTML-кода. В качестве тривиального примера рассмотрим следующую веб-страницу, которая использует JavaScript-сценарий, чтобы приветствовать пользователя по имени:
В этом двустрочном сценарии используется метод
В этом случае будет выведен текст «Привет, Давид». Но что произойдет, если страница будет запрошена с использованием следующего URL-адреса:
С таким содержимым URL-адреса сценарий динамически сгенерирует другой сценарий (коды %ЗС и %ЗЕ - это угловые скобки)! В данном случае вставленный сценарий просто отобразит диалоговое окно, которое не представляет никакой опасности. Но представьте себе такой случай:
Межсайтовый скриптинг потому так и называется, что в атаке участвует более одного сайта. Сайт В (или даже сайт С) включает специально сконструированную ссылку (подобную только что показанной) на сайт А, в которой содержится сценарий с сайта В. Сценарий evil.js размещается на сайте злоумышленника В, но теперь этот сценарий оказывается внедренным в сайт А и может делать все, что ему заблагорассудится с содержимым сайта А. Он может стереть страницу или вызвать другие нарушения в работе сайта (такие как отказ в обслуживании, о чем рассказывается в следующем разделе). Это может отрицательно сказаться на посетителях сайта А. Гораздо опаснее, что такой злонамеренный сценарий может прочитать содержимое cookies, хранящихся на сайте А (возможно, содержащих учетные номера или другие персональные сведения), и отправить эти данные обратно на сайт В. Внедренный сценарий может даже отслеживать нажатия клавиш и отправлять эти данные на сайт В.
Универсальный способ предотвращения XSS-атак заключается в удалении HTML-тегов из всех данных сомнительного происхождения, прежде чем использовать их для динамического создания содержимого документа. Чтобы исправить эту проблему в показанном ранее файле greet.html, нужно добавить следующую строку в сценарий, которая призвана удалять угловые скобки, окружающие тег
Простейшая операция, представленная выше, заменит в строке все угловые скобки на соответствующие им мнемоники языка HTML, тем самым экранировав и деактивировав любые HTML-теги, присутствующие в строке. IE8 определяет более точный метод
Метод