Как использовать User Agent для атак на сайты

[ФСБ]

Пользовательский агент (User Agent) — это строка текста, идентифицирующая браузер и операционную систему для веб-сервера. User Agent передаётся в HTTP заголовке когда браузер делает запрос к веб-серверу.

Вы можете посмотреть передаваемые HTTP заголовки, в том числе User Agent в Инструментах разработчика веб-мастера. Например, в Chrome для этого нажмите F12, перейдите на вкладку Network и в окне General найдите Request Headers (заголовки запроса):

​

Или можете сделать ещё проще — перейти на страницу одного из многочисленных сервисов, которые показывают User Agent:

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

Пример User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Строка не особо понятная — ясно, что это Chrome и что его версия 86. Если вам любопытно, почему строка такая длинная и что в ней означают остальные элементы, то посмотрите статью «

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

», там объяснено значение строк и почему их так много.

Как можно использовать User Agent при атаках на сайты? Я знаю по крайней мере 3 варианта:

1. SQL-инъекции через User Agent
2. XSS с помощью User Agent
3. Подмена User Agent для обмана сервера

Эта инструкция расскажет, как менять User Agent и делать инъекции через User Agent чтобы притвориться другим устройством или выполнить атаки на сайт.

XSS через User Agent
XSS уязвимости бывают:

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

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

Начнём мы с простейшего способа менять User Agent — прямо в веб-браузере. Конечно же, для это есть множество расширений браузеров, но подменить User Agent можно даже без них — подробно как это сделать вместе со скриншотами смотрите в статье «

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

».

Здесь же просто напомним краткий алгоритм:
Google Chrome/Chromium

• Инструменты разработчика (F12)
• Нажмите кнопку меню справа от вкладки «Console» в нижней части панели инструментов разработчика и выберите «Network conditions»
• На вкладке «Network conditions» снимите флажок «Select automatically» рядом с «User agent».
• Затем вы можете выбрать пользовательский агент из списка или скопировать и вставить пользовательский агент в поле.

Firefox:

• Ведите about:config в адресную строку Firefox и нажмите Enter.
• Введите general.useragent.override в поле фильтра. Он, вероятно, не существует в вашей системе. Чтобы добавить эту настройку, переключитесь тип значения на «Строка» и нажмите + (плюс).
• Введите желаемый пользовательский агент.

Если для сайта

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

ввести в качестве строки User Agent

<script>alert(1)</script>

То получим всплывающее окно alert.

​

Это сайт

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

:

​

Это сайт

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

​

Сайт

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

​

На сайт

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

нет XSS инъекции, но поломался JavaScript код.

​

В принципе, можно было бы далеко не ходить за примерами, у меня у самого на SuIP.biz была точно такая же проблема (

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

), но я её починил. На самом деле, пользователь действительно может как угодно изменять показываемую ему страницу на лету. Если эту страницу кроме него никто не видит, то проблем нет. Другое дело, если значения User Agent сохраняются и затем могут сработать, то есть если значения User Agent сохраняются и затем показываются кому-либо ещё, например, владельцу сайта (скажем, при анализе статистики) или другим пользователям (например, виджете популярных или последних User Agent посетителей).

Как делать SQL-инъекцию через User Agent
Вы тоже уже успели об этом подумать? Если программисты забывают о том, что User Agent'у не стоит доверять как абсолютно всему остальному, приходящему от пользователей, то значит там могут не фильтроваться теги и специальные символы? Пример этому мы уже увидели — на всех приведённых выше сайтах не фильтруется и не заменяются специальные символы в теге <script>.

А что если специальные символы тоже не фильтруются и значение User Agent сохраняется в базу данных? А это уже SQL-инъекция! Среди приложений, которые могут сохранять значения User Agent в базу данных: программы для сбора статистики веб-сайтов, метрики, виджеты «браузеры последних посетителей» и т. д.

В

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

есть пример инъекции через User Agent. Там она называется «SQL Injection - Stored (User-Agent)».

Если в качестве значения User Agent ввести что-нибудь вроде

Chrome'

То на выходе мы получим замечательное сообщение:

Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'Chrome', '192.168.0.89')' at line 1

​

Конечно же, там где SQLi, там и

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

. Чтобы протестировать SQL-инъекцию в User Agent используйте опцию --user-agent, в которой место инъекции укажите символом * (звёздочкой). Пример команды:

sqlmap -u 'http://192.168.0.96/bWAPP/sqli_17.php' --user-agent="Chrome*" --cookie 'PHPSESSID=a3400ca39ae4c6c1b25bb1eeb91c5410; security_level=0' --dbs

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

​

На странице

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

вы найдёте ссылки на подробнейшие инструкции по sqlmap и скоро будет добавлена ещё одна — SQL инъекции в User Agent, Referer, Cookie и произвольные HTTP заголовки.

Как подменить User Agent в командной строке
Чтобы поменять User Agent для утилиты cURL используйте опцию -A. Сравните вывод двух команд:

curl -I https://suip.biz
curl -I -A 'Chrome' https://suip.biz

​

Как подменить User Agent в Burp Suite
В

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

перейдите на вкладку «Proxy» → «Options», найдите раздел «Match and Replace» (совпадения и замена). Там уже присутствует несколько правил по замену User Agent для эмуляции запросов от различных устройств.

​

Вы можете включить имеющиеся правила или создать новое. Для создания нового нажмите кнопку «Add».
В качестве «Type» выберите «Request header».
В качестве значения поля «Match» укажите: ^User-Agent.*$

В поле «Replace» впишите значение, на которое будет заменён HTTP заголовок пользовательского агента. Обратите внимания, что поскольку мы заменяем заголовок целиком, то начинаться он должен со строки «User-Agent: ».
В поле «Comment» впишите любой комментарий, чтобы быстро вспомнить, для чего нужен этот заголовок.

Поставьте галочку «Regex match».

​

Включите его поставив галочку в столбце «Enabled».

По умолчанию Burp Suite в качестве прокси прослушивает localhost:8080.

Если вы хотите, чтобы Burp Suite стал перехватывающим прокси для веб-браузеров, в том числе для HTTPS трафика, то смотрите инструкциям в статье «

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

».

Если вы хотите использовать свой собственный SSL сертификат, то смотрите статью «

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

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

С cURL можно использовать опцию -x, чтобы отправить запрос через Burp Suite, например:

curl -x http://localhost:8080 -A 'Any User Agent' --cookie 'security_level=0; PHPSESSID=46d368f57a7c0e17905377f07846b5b0' 'http://192.168.0.96/bWAPP/sqli_17.php'

​

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

User-Agent Impersonation
В

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

есть задание «User-Agent Impersonation». Если вы воспользовались статьёй «

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

», то у вас это задание будет по адресу http://localhost/mutillidae/index.php?page=user-agent-impersonation.php.

​

На этой странице нам показывают сообщение:
Sorry. You do not look like an Apple iPad using Safari Browser.This page uses JavaScript browser and O/S fingerprinting to decide if the user-agent is allowed.
Перевод:
Извините, но не похоже, что вы используете Safari Browser на Apple iPad. Эта страница использует JavaScript браузера и отпечатки ОС для принятия решения, разрешён ли ваш user-agent.

Дальше есть вариант моего решения, но я рекомендую самостоятельно решить этот пример — он не такой простой, как кажется.

Данный пример готовился как самый первый в этой статье, поскольку обход проверки кажется элементарным. Казалось бы, выбираем в Инструментах разработчика правильный User Agent, вроде такого

Mozilla/5.0 (iPad; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1

и задание пройдено.

Но что-то пошло не так:

​

Страница никак не хочет принимать подходящий под условие User Agent.

Я посмотрел исходный код и обнаружил там:

if(
window.navigator.platform === "iPad" && window.navigator.appName === "Netscape" &&     window.navigator.appCodeName === "Mozilla" && window.navigator.appVersion.indexOf("iPad") !== -1 && window.navigator.appVersion.indexOf("Mac") !== -1 && window.navigator.appVersion.indexOf("AppleWebKit") !== -1 && window.navigator.appVersion.indexOf("Safari") !== -1 && window.navigator.product === "Gecko" && window.navigator.productSub === "20030107"
){
lResultTD.innerHTML = "Congratulations. You look like an iPad using Safari Browser to me."; lResultTD.className = "success-header";
}else{
lResultTD.innerHTML = "Sorry. You do not look like an Apple iPad using Safari Browser.<br />This page uses JavaScript browser and O/S fingerprinting to decide if the user-agent is allowed."; lResultTD.className = "error-header";
}

Я не знаю, насколько всё в порядке с этим кодом, возможно, в современных браузерах он просто неадекватен. Но можно заметить, что очень легко поломать логику всех этих многочисленных проверок добавив в конце « || 1» что означает «ИЛИ истина». То есть независимо от того, какой будет результат всех предыдущих проверок, это условие всё равно всегда будет возвращать «Истина».

Я воспользовался методом из статьи «

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

». И проверка соблюдения условия у меня получилась такой:

if(
window.navigator.platform === "iPad" && window.navigator.appName === "Netscape" && window.navigator.appCodeName === "Mozilla" && window.navigator.appVersion.indexOf("iPad") !== -1 && window.navigator.appVersion.indexOf("Mac") !== -1 && window.navigator.appVersion.indexOf("AppleWebKit") !== -1 && window.navigator.appVersion.indexOf("Safari") !== -1 && window.navigator.product === "Gecko" && window.navigator.productSub === "20030107" || 1
)

Такой подход устроил механизм проверки Пользовательского Агента и задание пройдено.

​