Xss-атака

SQL-инъекция

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

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

Принцип атаки

Простой способ найти точки инъекции

1. Ищите веб-страницы с URL-адресами со строками запроса (например, запрашивайте страницы с «id =» в URL-адресе).

2. Отправьте запрос на этот веб-сайт и измените оператор id = на дополнительную одинарную кавычку (например: id = 123 ’).

3. Посмотрите на возвращаемый контент, найдите такие ключевые слова, как «sql», «statement» и т. Д. (Это также означает, что были возвращены определенные сообщения об ошибках, что само по себе плохо)

4. Указывает ли сообщение об ошибке, что параметры, отправленные на сервер SQL, неправильно закодированы? Если да, это означает, что веб-сайт может быть атакован с помощью SQL-инъекции.

Как предотвратить атаки с использованием SQL-инъекций

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

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

Так называемый параметризованный запрос (Parameterized Query или Parameterized Statement) относится к использованию параметров (Parameter) для предоставления значений при проектировании соединения с базой данных и доступе к данным, где значения или данные должны быть заполнены.

Пример: SELECT * FROM myTable WHERE myID = @myID

INSERT INTO myTable (c1, c2, c3, c4) VALUES (@ c1, @ c2, @ c3, @ c4) или INSERT INTO myTable (c1, c2, c3, c4) VALUES (?,?,?,?)

Укажите заполнитель с помощью (?). Разумеется, при добавлении параметров вы должны добавлять их в порядке (c1, c2, c3, c4), иначе возникнет ошибка.

Средства защиты

Защита на стороне сервера

• Кодирование управляющих HTML-символов, JavaScript, CSS и URL перед отображением в браузере. Для фильтрации входных параметров можно использовать следующие функции: (для кодирования URL), (для фильтрации HTML).
• Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project, HTML Purifier, htmLawed, Anti-XSS Class.
• Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструментов, как Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy.
• Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей.
• Обеспечение безопасности cookies, которая может быть реализована путём ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly, использованием SSL.
• Использование заголовка Content Security Policy, позволяющего задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.

Защита на стороне клиента

• Регулярное обновление браузера до новой версии.
• Установка расширений для браузера, которые будут проверять поля форм, URL, JavaScript и POST-запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox, NotScripts для Chrome и Opera.

Задний план

Безопасность в Интернете зависит от множества механизмов, включая базовую концепцию доверия, известную как политика одного и того же происхождения. По сути, это означает, что если контенту с одного сайта (например, https://mybank.example1.com ) предоставлено разрешение на доступ к ресурсам (таким как файлы cookie и т. Д.) В веб-браузере , то контент с любого URL-адреса с таким же (1) Схема URI, (2) имя хоста и (3) номер порта будут совместно использовать эти разрешения. Контенту из URL-адресов, где любой из этих трех атрибутов отличается, необходимо будет предоставлять разрешения отдельно.

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

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

Об уязвимостях XSS сообщалось и они использовались с 1990-х годов. Известные сайты, затронутые в прошлом, включают сайты социальных сетей ,
,
MySpace , YouTube и Orkut . С тех пор ошибки межсайтового скриптинга превзошли переполнение буфера и стали наиболее распространенной уязвимостью системы безопасности, о которой сообщалось ранее. Некоторые исследователи в 2007 году оценили, что до 68% веб-сайтов, вероятно, открыты для XSS-атак.

О реализации

Давайте генерировать новый токен на каждый запрос, не важно, каким HTTP-методом и с какой целью этот запрос сделан.
Таким образом мы получаем токен, который меняется постоянно.
Конечно, возникает вопрос организации multi-tab работы.
Синхронизация токенов между табами может быть реализована с использованием localStorage и его StorageEvent

Ограничиваем время жизни cookie, которое содержит токен, разумным значением. Например 30 минут.

Делаем cookie недоступной из JS (ставим HTTPOnly=true)

Используем TLS для предотвращения MITM
При этом отправляем cookie только по HTTPS (ставим Secure=true)

Размер токена не менее 32 байт.

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

XSS Examples with Code Snippets

Example 1.
For example, the HTML snippet:

is intended to illustrate a template snippet that, if the variable title has value Cross-Site Scripting, results in the following HTML to be emitted to the browser:

A site containing a search field does not have the proper input sanitizing. By crafting a search query looking something like this:

sitting on the other end, at the web server, you will be receiving hits where after a double space is the user’s cookie. If an administrator clicks the link, an attacker could steal the session ID and hijack the session.

Example 2.
Suppose there’s a URL on Google’s site, , which returns HTML documents containing the fragment

i.e., the value of the query parameter q is inserted into the page returned by Google. Suppose further that the data is not validated, filtered or escaped. 
Evil.org could put up a page that causes the following URL to be loaded in the browser (e.g., in an invisible<iframe>):

When a victim loads this page from , the browser will load the iframe from the URL above. The document loaded into the iframe will now contain the fragment

Loading this page will cause the browser to execute evil_script(). Furthermore, this script will execute in the context of a page loaded from www.google.com.

Насколько серьезны CSRF-уязвимости?

• Account takeover — атакующий захватывает аккаунт жертвы путем смены email через CSRF.
• Privilege Escalation — повышение привилегий за счет того, что атакующий через CSRF создает нового пользователя с высокими правами в системе.
• Remote code execution — выполнение кода за счет эксплуатации command injection в админке через CSRF.

OWASP Top 105 местетолько в 8% случаевBugcrowd VRTдостаточно серьезные уязвимости1. CSRF token

• Для каждой пользовательской сессии генерируется уникальный и высокоэнтропийный токен.
• Токен вставляется в DOM HTML страницы или отдается пользователю через API.
• Пользователь с каждым запросом, связанным с какими-либо изменениями, должен отправить токен в параметре или в HTTP-заголовке запроса.
• Так как атакующий не знает токен, то классическая CSRF-атака не работает.

2. Double submit cookie

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

3. Content-Type based protection

• Пользователь должен отправить запрос с определенным заголовком Content-Type, например, application/json.
• Так как в браузере через HTML форму или XHR API невозможно отправить произвольный Content-Type cross-origin, то классическая CSRF-атака опять не работает.

4. Referer-based protection

• Пользователь должен отправить запрос с определенным значением заголовка Referer. Бэкенд его проверяет, если он неверный, то считается, что это CSRF-атака.
• Так как браузер не может отправить произвольный Referer через HTML форму или XHR API, то классическая CSRF-атака не работает.

5. Password confirmation / websudo

• Пользователь должен подтверждать действие с помощью пароля (или секрета).
• Так как атакующий его не знает, то классическая CSRF-атака не работает.

6. SameSite Cookies в Chrome, Opera

• У куки устанавливается дополнительный атрибут — samesite, который может иметь два значения: lax или strict.
• Суть технологии в том, что браузер не отправляет куки, если запрос осуществляется с другого домена, например, с сайта атакующего. Таким образом это опять защищает от классической CSRF-атаки.

позволяют обходить CSRF защиты8 способах обхода защиты

Сценарии обхода:

1. XSS (cross-sitescripting)Можно только смириться2. Dangling markup

3. Уязвимый субдоменfoo.example.comsubdomain takeoverXSS.

• CSRF tokens;
• Double submit cookie;
• Content-Type based protection.

CORS

1. Access-Control-Allow-Origin: foo.example.com (foo.example.com — уязвимый субдомен);
2. Access-Control-Allow-Credentials: true — чтобы с помощью XHR API можно было сделать запрос с куками пользователя.

crossdomain.xml

foo.example.com

4. Bad PDFexample.com

leak.pdf5. Cookie injectionCRLFinjectionособенностями обработки куков браузеромбаги браузераCVE-2016-9078)6. Change Content-Type

7. Non-simple Content-Type

• text/plain;
• application/x-www-form-urlencoded;
• multipart/form-data.

• баги в браузерах (например, Navigator.sendBeacon);
• плагины: Flash plugin + 307 redirect и PDF plugin + 307 redirect;
• фреймворки на бэкэнде.

с именем ctypeизвестный багNavigator.sendBeacon().

thehackerblog.comredirect с кодом 3078. Spoof Refererбаг в Microsoft Edgeпробел

• All означает, что для всех браузеров;
• All* означает браузеры, которые не поддерживают SameSite Cookies, т.е. все кроме Chrome и Opera.

• Моделируйте угрозы и проверяйте реализацию CSRF-защиты (см. Итоговую таблицу).
• Имплементируйте SameSite Cookies. Сейчас только два браузера поддерживают, но в дальнейшем, наверное, их будет больше.
• Комбинируйте различные CSRF-защиты — defense in depth.
• Спрашивайте у пользователя пароль для выполнения критичных действий.
• Отдавайте загружаемые пользователем файлы с отдельного домена.

Метод реализации XSS-атаки

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

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

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

<script>alert(«cookie: «+document.cookie)</script>

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

Если сайт управляется какой-то популярной CMS, то бреши быть не должно, так как современные системы управления контентом сайта надежно защищены от XSS. Но, если вы расширяли функциональные возможности своего сайта при помощи каких-либо плагинов, модулей и дополнений, которые были разработаны сторонними веб-программистами, есть риск обнаружения уязвимости к XSS. А особенно это касается доработок для WordPress, Joomla, DLE и Bitrix. 

Альтернативный вариант поиска бреши на сайте — использование страниц, работающих с GET-запросами. К примеру, мы имеем ссылку http://site.com/catalog?p=7. В браузерной строке вместо идентификатора «7» мы вписываем скрипт «><script>alert(«cookie: «+document.cookie)</script>, после чего получаем ссылку вида http://site.com/catalog?p=»><script>alert(«cookie: «+document.cookie)</script>. Если на этой странице будет обнаружена уязвимость, на дисплее появится уведомление с соответствующей информацией. 

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

Почему межсайтовый скриптинг опасен?

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

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

• Взломать учетные записи пользователей
• Распространять вредоносное ПО
• Управлять компьютером пользователя удаленно
• Сканирование и использование приложений интрасети

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

Для борьбы с XSS-атаками крупные ИТ-компании запускают специальные программы по борьбе с ошибками. Эти программы внедряются многими организациями и предлагают компенсацию или признание пользователям, сообщающим об уязвимостях XSS в скриптах. Таким образом, компании вкладывают средства в кибербезопасность, заставляя других разработчиков выявлять их ошибки. Google даже запустил игру, в которой вы можете упражняться в устранении ошибок 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. Часто происходит в результате социальной инженерии, когда пользователь случайно запускает вредоносный код в своем браузере.

What Can the Attacker Do with JavaScript?

XSS vulnerabilities are perceived as less dangerous than for example SQL Injection vulnerabilities. Consequences of the ability to execute JavaScript on a web page may not seem dire at first. Most web browsers run JavaScript in a very tightly controlled environment. JavaScript has limited access to the user’s operating system and the user’s files. However, JavaScript can still be dangerous if misused as part of malicious content:

• Malicious JavaScript has access to all the objects that the rest of the web page has access to. This includes access to the user’s cookies. Cookies are often used to store session tokens. If an attacker can obtain a user’s session cookie, they can impersonate that user, perform actions on behalf of the user, and gain access to the user’s sensitive data.
• JavaScript can read the browser DOM and make arbitrary modifications to it. Luckily, this is only possible within the page where JavaScript is running.
• JavaScript can use the object to send HTTP requests with arbitrary content to arbitrary destinations.
• JavaScript in modern browsers can use HTML5 APIs. For example, it can gain access to the user’s geolocation, webcam, microphone, and even specific files from the user’s file system. Most of these APIs require user opt-in, but the attacker can use social engineering to go around that limitation.

The above, in combination with social engineering, allow criminals to pull off advanced attacks including cookie theft, planting trojans, keylogging, phishing, and identity theft. XSS vulnerabilities provide the perfect ground to escalate attacks to more serious ones. Cross-site Scripting can also be used in conjunction with other types of attacks, for example, Cross-Site Request Forgery (CSRF).

There are several types of Cross-site Scripting attacks: stored/persistent XSS, reflected/non-persistent XSS, and DOM-based XSS. You can read more about them in an article titled Types of XSS.

Что такое XSS атака и защититься от неё?

Что такое XSS атака?

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

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

• Учётных данных для доступа к сторонним ресурсам;
• Номеров банковских карт;
• Данных для доступа к электронным кошелькам;
• Контактных данных;
• Иных пользовательских конфиденциальных данных.

Направления атак XSS

Данный тип атак имеет два направления:

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

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

Правила безопасности

Чтобы не стать жертвой атаки XSS следует придерживаться следующих правил безопасности:

1. Главное правило для разрабов – использование любого фильтра.
2. Фильтровать все вложенные конструкции.
3. Шифрование. При создании фильтра следует обязательно учитывать риск кодировки атак. Есть масса программ-кодировщиков, с помощью которых можно зашифровать какую угодно атаку так, что не один фильтр «не увидит» её. Так что применяйте расшифровку в фильтре до начала выполнения кода запроса.
4. Применение тегов. Есть одно уязвимое место, связанное с тегами url, bb, img, имеющими множество параметров, включая lowsrc и dynsrc, содержащие javacsript. Данные теги следует фильтровать. Если не будете применять на своём ресурсе картинки, то вообще отключите их.
5. Используемый фильтр должен учитывать различные варианты комбинаций символов. Чем их больше, тем лучше.

Заключение

По статистике 84% Интернет-ресурсов хорошо защищены от XSS атак. Прочие 16% не в состоянии эффективно противостоять им. Устранение этого грубого недочёта требует от владельцев сайтов дополнительных капиталовложений в безопасность, на что большинство из них не готовы. Однако ужесточение законодательства относительно повреждения, утечки и разглашения персональных данных всё больше заставляет недобросовестных владельцев улучшать безопасность своих сайтов.

Противодействие 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.

Is Your Website or Web Application Vulnerable to Cross-site Scripting

Cross-site Scripting vulnerabilities are one of the most common web application vulnerabilities. The OWASP organization (Open Web Application Security Project) lists XSS vulnerabilities in their OWASP Top 10 2017 document as the second most prevalent issue.

Fortunately, it’s easy to test if your website or web application is vulnerable to XSS and other vulnerabilities by running an automated web scan using the Acunetix vulnerability scanner, which includes a specialized XSS scanner module. Take a demo and find out more about running XSS scans against your website or web application. An example of how you can detect blind XSS vulnerabilities with Acunetix is available in the following article: How to Detect Blind XSS Vulnerabilities.

Как избежать проблем?

Как вы уже поняли, способа безопасно вставить Javascript в HTML нет. Но есть способы сделать Javascript безопасным для вставки в HTML (почувствуйте разницу). Правда для этого нужно быть предельно внимательным всё время, пока вы пишете что-то внутри тега <script>, особенно если вы вставляете любые данные с помощью шаблонизатора.

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

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

Точно так же можно экранировать и отдельные строки.

Другой совет — не встраивайте в тег <script> ничего вообще. Храните данные в местах, где трансформации для вставки данных однозначны и обратимы. Например, в атрибутах других элементов. Правда смотрится это довольно грязно и работает только со строками, JSON придется парсить отдельно.

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

Особенности XSS основанных на DOM

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

http://example.com/search.php?q="/><script>alert(1)</script>

А при открытии исходного HTML кода мы видим что-то вроде такого:

<div class="m__search">          
	<form method="get" action="/search.php">              
	<input type="text" class="ui-input query" name="q" value=""/><script>alert(1)</script>" /> <button type="submit" class="ui-button">Найти</button>             
    </form>

А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код:

<!DOCTYPE html>
<html>
    <head>
        <title>HackWare.ru:::DOM XSS</title>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
    <body>
        <div id="default"> An error occurred...</div>

        <script>
            function OnLoad() {
                var foundFrag = get_fragment();
                return foundFrag;
            }

            function get_fragment() {
                var r4c = '(.*?)';
                var results = location.hash.match('.*input=token(' + r4c + ');');

                if (results) {
                    document.getElementById("default").innerHTML = "";
                    return (unescape(results));
                } else {
                    return null;
                }
            }

            display_session = OnLoad();
            document.write("Your session ID was: " + display_session + "<br><br>")
        </script>  

    </body>
</html>

Если мы перейдём по примерно такой ссылке

http://localhost/tests/XSS/dom_xss.html#input=tokenAlex;

То в браузере мы увидим:

Исходный код страницы:

Давайте сформируем адрес следующим образом:

http://localhost/tests/XSS/dom_xss.html#input=tokenAlex<script>alert(1)</script>;

Теперь страница выглядит так:

Но давайте заглянем в исходный код HTML:

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

Здесь приведён рабочий прототип XSS, для реальной атаки нам нужна более сложная полезная нагрузка, которая невозможна из-за того, что приложение останавливает чтение сразу после точки с запятой, и что-то вроде alert(1);alert(2) уже невозможно. Тем не менее, благодаря unescape() в возвращаемых данных мы можем использовать полезную нагрузку вроде такой:

http://localhost/tests/XSS/dom_xss.html#input=tokenAlex<script>alert(1)%3balert(2)</script>;

Где мы заменили символ ; на кодированный в URI эквивалент!

Теперь мы можем написать вредоносную полезную нагрузку JavaScript и составить ссылку для отправки жертве, как это делается для стандартного непостоянного межсайтового скриптинга.