Cross site scripting (xss)

Что понимается под межсайтовым скриптингом?

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

Эти атаки в большинстве случаев проводятся в рамках систем онлайн-сообщений, блогов и пользовательских конференций (в совокупности называемых «системами онлайн-сообщений» в статье), в которых сообщения хранятся на постоянной основе. При их создании используются технологии HTML, JavaScript, VBScript, ActiveX, Flash и другие технологии сценариев на стороне клиентов.

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

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

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

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

Поиск сайтов уязвимых к XSS

Дорки для XSS

Первым шагом является выбор сайтов, на которых мы будем выполнять XSS атаки. Сайты можно искать с помощью дорков Google. Вот несколько из таких дорков, которые скопируйте и вставьте в поиск Гугла:

• inurl:search.php?q=
• inurl:.php?q=
• inurl:search.php
• inurl:.php?search=

Перед нами откроется список сайтов. Нужно открыть сайт и найти на нём поля ввода, такие как форма обратной связи, форма ввода, поиск по сайту и т.д.

Сразу замечу, что практически бесполезно искать уязвимости в популярных автоматически обновляемых веб-приложениях. Классический пример такого приложения – WordPress. На самом деле, уязвимости в WordPress, а в особенности в его плагинах, имеются. Более того, есть множество сайтов, которые не обновляют ни движок WordPress (из-за того, что веб-мастер внёс в исходный код какие-то свои изменения), ни плагины и темы (как правило, это пиратские плагины и темы). Но если вы читаете этот раздел и узнаёте из него что-то новое, значит WordPress пока не для вас… К нему обязательно вернёмся позже.

Самые лучшие цели – это разнообразные самописные движки и скрипты.

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

<script>alert(1)</script>

Обращайте внимание, в какие именно тэги HTML кода попадает ваш внедрённый код. Вот пример типичного поля ввода (input ):

<input type="text" class="ui-input query" name="q" value="наволочка"/><script>alert(1)</script><input value="" />

Наша полезная нагрузка попадёт туда, где сейчас слово «наволочка». Т.е. превратиться в значение тэга input. Мы можем этого избежать – закроем двойную кавычку, а затем и сам тэг с помощью «/>

В результате полезная нагрузка приобретает вид:

"/><script>alert(1)</script>

Давайте попробуем её для какого-нибудь сайта:

Отлично, уязвимость имеется

Что такое XSS

Межсайтовый скриптинг (XSS) – это уязвимость, которая заключается во внедрении кода, исполняемого на стороне клиента (JavaScript) в веб-страницу, которую просматривают другие пользователи.

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

Если кто-то из пользователей ввёл:

Привет! Нравится твой сайт.

То веб-страница отобразит:

Привет! Нравится твой сайт.

А если пользователь введёт так:

Привет! Нравится твой сайт.<script>alert("Pwned")</script>

То отобразится это так:

Браузеры хранят множества кукиз большого количества сайтов. Каждый сайт может получить кукиз только сохранённые им самим. Например, сайт example.com сохранил в вашем браузере некоторые кукиз. Вы заши на сайт another.com, этот сайт (клиентские и серверные скрипты) не могут получить доступ к кукиз, которые сохранил сайт example.com.

Если сайт example.com уязвим к XSS, то это означает, что мы можем тем или иным способом внедрить в него код JavaScript, и этот код будет исполняться от имени сайта example.com! Т.е. этот код получит, например, доступ к кукиз сайта example.com.

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

Внедрённый код умеет всё то, что умеет JavaScript, а именно:

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

Простейший пример с кукиз:

<script>alert(document.cookie)</script>

На самом деле, alert используется только для выявления XSS. Реальная вредоносная полезная нагрузка осуществляет скрытые действия. Она скрыто связывается с удалённым сервером злоумышленника и передаёт на него украденные данные.

Типы XSS-уязвимостей

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

Рисунок 3. Типы XSS-уязвимостей

Уязвимости, вызванные кодом на стороне сервера (Java, PHP, .NET и т. д.):

Традиционные XSS-атаки:

1. Отраженные (непостоянные). Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке. Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента, без надлежащей обработки.
2. Хранимые (постоянные). Хранимые XSS возможны, когда злоумышленнику удается внедрить на сервер вредоносный код, выполняющийся в браузере каждый раз при обращении к оригинальной странице. Классическим примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML-формате.

Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.):

Также известные как DOM-модели:

1. Отраженные (непостоянные). То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.
2. Хранимые (постоянные). Аналогичны хранимым XSS на стороне сервера, только в этом случае вредоносная составляющая сохраняется на клиентской стороне, используя хранилище браузера.

Уязвимости, вызванные инфраструктурой (браузер, плагины, сервера и т. д.):

Встречаются очень редко, но являются более опасными:

1. Инфраструктура на стороне клиента. Происходит, когда вредоносная составляющая производит какие-либо манипуляции с функционалом браузера, например с его XSS-фильтром и т.п.
2. Инфраструктура на стороне сервера. Возникает, когда веб-сервер некорректно обрабатывает запросы, позволяя модифицировать их.
3. Сеть. Происходит, когда возможно внедриться в связь между клиентом и сервером.

Уязвимости, вызванные пользователем:

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

Практический пример XSS на тестовом сайте

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

Введите в браузере адрес следующей страницы: http://testasp.acunetix.com/Search.asp, Вы увидите, что это простая страница с полем ввода текста поискового запроса

Рисунок 1
Попробуйте вставить следующий код в поле поиска и обратите внимание на то, как на странице будет отображаться поле регистрации: Please login with the form below before proceeding:

Login:
Password:

После вставки кода просто нажмите кнопку «Поиск». Рисунок 2

Из-за уязвимости страницы к XSS, стало возможным создать поддельную форму регистрации, которое можно использовать для сбора параметров доступа пользователя. На этапе 2 видно, что код содержит элемент «destination.asp». Здесь хакер может определить, куда поддельная форма регистрации будет отсылать параметры доступа для дальнейшего использования в преступных целях.

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

http://testasp.acunetix.com/Search.asp?tfSearch=%3Cbr%3E%3Cbr%3EPlease+login+with+the+form+below+before+ proceeding%3A%3Cform+action%3D%22test.asp%22%3E%3Ctable%3E%3Ctr%3E%3Ctd%3ELogin%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+ length%3D20+name%3Dlogin%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3Ctd%3EPassword%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+ length%3D20+name%3Dpassword%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput+type%3Dsubmit+value%3DLOGIN%3E%3C%2Fform%3E

 

Рисунок 3

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

Способы защиты от XSS уязвимостей при разработке

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

Первый вариант защиты от XSS уязвимостей при разработке – это использование возможностей веб-фреймворка. Например, в C# фреймворке ASP.NET можно в файлах .cshtml и .razor смешивать HTML разметку и C# код:

В этом файле на странице отображается результат C# выражения Model.RequestId. Чтобы данный тип файла скомпилировался, C# выражение или блок C# кода должен начинаться с символа ‘@’. Однако этот символ не только позволяет использовать C# вместе с HTML разметкой в одном файле, но и указывает ASP.NET, что если блок кода или выражение возвращают значение, то перед его отображением на странице необходимо в значении кодировать символы HTML в HTML-сущности. HTML-сущности — это части текста («строки»), которые начинаются с символа амперсанда (&) и заканчиваются точкой с запятой (;). Сущности чаще всего используются для представления специальных символов (которые могут быть восприняты как часть HTML-кода) или невидимых символов (таких как неразрывный пробел). Таким образом ASP.NET защищает разработчиков от XSS атак.

Однако особое внимание стоит уделить файлам с расширением .aspx в ASP.NET (более старая версия файлов HTML страниц с поддержкой C# кода). Этот тип файлов не кодирует автоматически результаты C# выражений

Для кодирования HTML символов в C# выражениях в этом типе файлов необходимо помещать C# код в блок кода . Например:

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

• System.Web.HttpUtility.HtmlEncode(string);
• System.Net.WebUtility.HtmlEncode(string);
• System.Web.Security.AntiXss.HtmlEncode(string);
• System.Text.Encodings.Web.HtmlEncoder.Default.Encode(string).

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

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

При написании этой функции была использована особенность свойства Element.innerHTML. Используем эту функцию на HTML странице из примера XSS атаки:

Здесь мы кодируем значение xss параметра при помощи функции htmlEncode перед отображением на странице.

Теперь откроем эту страницу, передав в параметре xss строку <script>alert(«You’ve been hacked! This is an XSS attack!»)</script>:

Как видите, при кодировании строки со скриптом браузер просто отображает эту строку на странице, а не выполняет скрипт.

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

How to Prevent XSS

To keep yourself safe from XSS, you must sanitize your input. Your application code should never output data received as input directly to the browser without checking it for malicious code.

For more details, refer to the following articles: Preventing XSS Attacks and How to Prevent DOM-based Cross-site Scripting. You can also find useful information in the XSS Prevention Cheat Sheet maintained by the OWASP organization.

How to Prevent Cross-site Scripting (XSS) – Generic Tips

Preventing Cross-site Scripting (XSS) is not easy. Specific prevention techniques depend on the subtype of XSS vulnerability, on user input usage context, and on the programming framework. However, there are certain general strategic principles that you should follow to keep your web application safe.

	To keep your web application safe, everyone involved in building the web application must be aware of the risks associated with XSS vulnerabilities. You should provide suitable security training to all your developers, QA staff, DevOps, and SysAdmins. You can start by referring them to this page.
	Treat all user input as untrusted. Any user input that is used as part of HTML output introduces a risk of an XSS. Treat input from authenticated and/or internal users the same way that you treat public input.
	Use an appropriate escaping/encoding technique depending on where user input is to be used: HTML escape, JavaScript escape, CSS escape, URL escape, etc. Use existing libraries for escaping, don’t write your own unless absolutely necessary.
	If the user input needs to contain HTML, you can’t escape/encode it because it would break valid tags. In such cases, use a trusted and verified library to parse and clean HTML. Choose the library depending on your development language, for example, HtmlSanitizer for .NET or SanitizeHelper for Ruby on Rails.
	To mitigate the consequences of a possible XSS vulnerability, set the HttpOnly flag for cookies. If you do, such cookies will not be accessible via client-side JavaScript.
	To mitigate the consequences of a possible XSS vulnerability, also use a Content Security Policy (CSP). CSP is an HTTP response header that lets you declare the dynamic resources that are allowed to load depending on the request source.
	Step 7: Scan regularly (with Acunetix) XSS vulnerabilities may be introduced by your developers or through external libraries/modules/software. You should regularly scan your web applications using a web vulnerability scanner such as Acunetix. If you use Jenkins, you should install the Acunetix plugin to automatically scan every build.

Виды XSS

Самое главное, что нужно понимать про виды XSS то, что они бывают:

• Хранимые (Постоянные)
• Отражённые (Непостоянные)

Пример постоянных:

• Введённое злоумышленником специально сформированное сообщение в гостевую книгу (комментарий, сообщение форума, профиль) которое сохраняется на сервере, загружается с сервера каждый раз, когда пользователи запрашивают отображение этой страницы.
• Злоумышленник получил доступ к данным сервера, например, через SQL инъекцию, и внедрил в выдаваемые пользователю данные злонамеренный JavaScript код (с ки-логерами или с BeEF).

Пример непостоянных:

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

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

DOM-модели

Включение заголовка X-XSS-Protection

Заголовок предназначен для включения фильтра межсайтового скриптинга, встроенного во всех современных браузерах. Он позволит, например, предотвратить выполнение тега <script> в URL страницы.

Значение	Описание
Фильтрация XSS отключена
1	Фильтрация XSS включена, браузер очистит страницу от опасного содержимого при обнаружении атаки
1; mode=block	Фильтрация XSS включена, браузер предотвратит загрузку страницы при обнаружении атаки
1; report=URL	Фильтрация XSS включена, браузер очистит страницу от опасного содержимого при обнаружении атаки и отправит отчёт

Директива для отправки отчётов действует аналогично директиве report-uri (или report-to) Content Security Policy (CSP), указывая браузеру пользователя сообщать о попытках нарушения политики безопасности контента. Об этом я расскажу в отдельной статье.

Отчёт о нарушениях формируется в формате JSON и отправляется POST-запросами по указанному адресу URL.

Возвращаясь к основной теме, рекомендую настроить сервер таким образом, чтобы HTTP заголовок включал фильтрацию и при XSS-атаке блокировал загрузку страницы с небезопасным содержимым. В файле дополнительной конфигурации .htaccess (или httpd.conf, если у вас есть полный доступ к серверу) веб-сервера Apache необходимо добавить следующую запись:

Для сервера Nginx дополните файл nginx.conf в разделе HTTP записью:

В том случае, если доступ к конфигурационным файлам сервера отсутствует, но есть поддержка PHP, тогда используйте функцию:

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

Надеюсь, теперь вы стали немного больше понимать в HTTP-заголовках сервера и X-XSS поможет предотвратить межсайтовый скриптинг. Я использую заголовки безопасности на всех своих сайтах и настоятельно рекомендую вам сделать тоже самое. Вместе мы можем сделать интернет более безопасным!

Автоматизированный поиск XSS уязвимостей

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

И все-таки более логичным и дешёвым вариантом является поиск и исправление уязвимостей на ранних стадиях разработки. Значительную помощь в этом оказывают XSS сканеры и статические анализаторы кода. Например, в контексте разработки на языке C# одним из таких статических анализаторов является PVS-Studio. В этом анализаторе недавно появилась новая C# диагностика — V5610, которая как раз ищет потенциальные XSS уязвимости. Также можно использовать оба типа инструментов, потому что каждый из них имеет собственную зону ответственности. Благодаря этому вы обнаружите как существующие уязвимости в проекте, так и уязвимости, которые будут возникать при развитии проекта.

Классификация XSS

1. Светоотражающий XSS

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

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

Когда жертва нажимает на эту ссылку, внедренный сценарий будет отправлен на страницу search.asp целевого сервера в качестве ключевого слова поиска, затем на странице возврата результата поиска этот сценарий будет использоваться как ключевое слово поиска. И встроен. Таким образом, когда пользователь получает страницу результатов поиска, этот сценарий также выполняется. Это принцип отраженной XSS-атаки. Видно, что злоумышленник ловко использует отраженный метод XSS-атаки для достижения цели выполнения сценария в браузере жертвы. Поскольку введенный код представляет собой динамически генерируемую страницу, а не постоянную страницу, этот метод атаки работает только при нажатии на ссылку, поэтому он называется непостоянным XSS.

2. Сохраненный XSS

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

Пассивные XSS

Те XSS-атаки, что я описывал выше, относятся к разряду «активных». Пользователь совсем от них не защищен,
достаточно посетить страницу с вставленным скриптом, и все, уязвимость сработает. Такие атаки
опасней всего, но обычно от них вебмастера все-таки делают защиту. Но бывают еще пассивные XSS,
одна из них как раз и описана в статье на Хабре (ссылка чуть выше).

Основанием для таких атак являются, например, формы поиска на сайтах. Текст, вводимый в них, тоже нужно фильтровать,
но об этом владельцы сайтов часто забывают. А зря. Да, если хакер введет скрипт прямо в форму поиска,
выполнится он только на его компьютере. Но что он еще может сделать — так это сформировать ссылку на «результаты поиска».
Если кто-нибудь проследует по такой ссылке, то скрипт выполнится и у него.

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

← Смена хостинга

Удаленная помощь →

Кража cookies

Как же злоумышленник крадет cookies? К счастью, он не сможет при помощи xss украсть ваши cookies
от произвольного сайта. То есть чтобы украсть логин от моего форума, ему нужно будет сначала разместить
соответствующий скрипт именно на моем форуме (тем самым, нужно, чтобы на моем форуме была
дыра в безопасности). А чтобы украсть вашу почту на mail.ru, ему нужно разместить соответствующий
скрипт в блогах mail.ru или аналогичном месте. Думаете, такого не бывает? Тогда почитайте
занимательную статью на Хабре про недавно обнаруженную уязвимость на mail.ru.

Так что за скрипт размещается для кражи cookies? На самом деле, такой скрипт устроен очень просто.
Он не выводит сообщение на экран,
а вместо этого берет cookie, относящуюся к этому документу (метод document.cookie), и передает
ее на сайт злоумышленника (где уже другой скрипт сохраняет «печеньку» в файл).

Действия вебмастеров

Как же вебмастера борются с XSS-атаками на своих сайтах? Как я и сказал выше, нужно фильтровать размещаемые
пользовательские данные. Причем, нужно делать это с умом. Приведу простой пример. Если просто удалять слово <script>
из текста, да и делать это только один раз, то размещенный на вашем сайте кусок кода
<scr<script&gtipt>alert(‘xss’)</script> изначально будет безобиден, но именно после работы
скрипта превратится в упомянутый выше <script>alert(‘xss’)</script>. Так что у нас тут получается
борьба между фильтрами и изворотливыми хакерами.

Где нужно безопасно обрабатывать входящую информацию

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

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

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

Шифрование

Шифрование – это способ экранирования пользовательского ввода: браузер интерпретирует его только как данные, а не как код. Наиболее распространенный тип шифрования в веб-разработке – это HTML-экранирование, трансформирующее символы вроде < и > в &lt; и &gt; соответственно.

Псевдокод ниже – это пример того, как пользовательский ввод может быть закодирован с использованием HTML-экранирования, а затем вставлен на страницу серверным скриптом:

print "<html>"print "Latest comment: "print encodeHtml(userInput)print "</html>"Если пользовательский ввод – это строка <script>...</script>, HTML в результате будет таким:<html>Latest comment:&lt;script&gt;...&lt;/script&gt;</html>Так как все символы особого назначения были экранированы, браузер не воспримет такой ввод, как HTML.

Противодействие XSS-атакам

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

Мероприятия для клиентов или пользователей

Современные версии браузера Mozilla Firefox достаточно безопасны. Например, Firefox автоматически кодирует символы и (в последовательности и соответственно) в параметре в случае, когда URL не введен напрямую в адресную строку. Таким образом, данный браузер не уязвим к атакам, проводимым с использованием модели DOM. Для повышения безопасности работы браузера следует также установить дополнения (расширения), такие, как NoScript, FlashBlock и панель инструментов Netcraft.

Вы также можете попробовать браузер Google Chrome, имеющий встроенную защиту от XSS-атак.

Если при создания ссылки использовался сервис по сокращению длины URL, такой, как «tiny», «tinyurl», «bit.ly», «is.gd», «shorturl», «snipurl», и.т.д., будьте осторожны. Вы можете даже установить второй браузер для посещения «ненадежных» сайтов; не входите на доверенные или важные сайты с помощью этого браузера, а используйте его только для переходов по подозрительным ссылкам

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

Для разработчиков

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

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

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

Не храните пароли или другие данные в куках без шифрования или с применением нестойкого алгоритма шифрования. Простое хеширование пароля с использованием алгоритма MD5 не является безопасным, поскольку длина хэша составляет всего 16 байт и его расшифровка возможна при помощи метода перебора вариантов.

Если это возможно и осуществимо, данные аутентификации в куках должны быть ассоциированы с IP-адресом клиента. Обнаружение идентичных данных кук, отправленных с другого IP-адреса, должно восприниматься как попытка проведения атаки.

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

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

Куки, отправленные по протоколу HTTPS недоступны сценариям при помощи свойства , поэтому постарайтесь отправлять куки только по протоколу HTTPS. Также постарайтесь использовать для передачи форм метод POST вместо GET.