#api #params

> Ничего не могу найти на сайте, может ещё что-то посмотреть?

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

Однако, бывают уязвимости, которые не видны с первого взгляда. Например (CAPEC-460) HTTP Parameter Pollution или (CWE-472) External Control of Assumed-Immutable Web Parameter. Данные ошибки возникают из-за неожиданного поведения в функциях обработки параметров.

Давайте рассмотрим первую атаку HTTP Parameter Pollution, она состоит из возможности добавления повторяющихся параметров с помощью специальных разделителей запроса.

Например, у нас открыт сайт по продаже арбузов в браузере

🌐 example.com/profile.jsp?client_id=1

Для кнопки "Открыть профиль" устанавливается динамически в ответе от сервера html:

<a href="profile.jsp?client_id=1&action=view

А теперь изменим запрос добавив в него параметр и закодировав разделитель & как %26:

🌐 example.com/profile.jsp?client_id=1%26action%3Ddelete

В результате для кнопки "Открыть профиль" задаётся html:

<a href="profile.jsp?client_id=1&action=delete&action=view

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

Это происходит, потому что Apache Tomcat 🐈 при анализе двух одинаковых параметров (action) берёт значение первого:

&action=delete&action=view

Вот так выглядит код на стороне сервера:

String client_id = request.getParameter("client_id");
GetMethod get = new GetMethod("https://example.com/profile");
get.setQueryString("client_id=" + client_id + "&action=" + action);

href_link=get.URL;

Разработчик должен был учесть такое поведение и проверить возможность внедрения параметра action в client_id

Вообще, приоритет и процесс обработки параметров можно взять из этой таблицы ниже:

Technology/HTTP backend        | Parsing Result    | Example         |
---------------------------------------------------------------------
ASP.NET/IIS                    | All occurrences   | par1=val1,val2  |
ASP/IIS                        | All occurrences   | par1=val1,val2  |
PHP/Apache                     | Last occurrence   | par1=val2       |
JSP Servlet/Apache Tomcat      | First occurrence  | par1=val1       |
JSP Servlet/Oracle Application | First occurrence  | par1=val1       |
IBM HTTP Server                | First occurrence  | par1=val1       |

Так, для Server: Apache Tomcat будет взято значение из первого совпадения action=delete
А для Server: Apache значение уже будет action=view — последний параметр

Но не все сервера используют приоритет порядка, так, например, ASP.NET/IIS конкатенирует значения. Поэтому в случаях, когда выполнению XSS мешает санитизация или WAF, можно составить следующий payload:

example.com/search?param=<audio/n="&param="src/onerror=alert()>

В результате на странице html будет <audio n="," src/onerror=alert()> и XSS успешно сработает 💣

Помимо приоритетов, нужно также вспомнить о разделителях для параметров. Существует не только привычный & (амперсанд) и , (запятая) но и ряд других символов, тут нужно обратиться к стандартам и поискать реализации. Если открыть (rfc6570) URI Template можно найти Path-Style Parameter

Обычный URL будет следующим:

example.com/users?role=admin&firstName=N

А теперь преобразуем его в вид Path-Style:

example.com/users;role=admin;firstName=N

Использование в качестве разделителя ; (точки с запятой) не повсеместно. Это приводит к различиям обработки во фреймворках и как следствие к уязвимостям, в частности, на микросервисных архитектурах:

• CVE-2021-23336 — Python библиотека urllib.parse.parse_qsl не игнорирует точку с запятой.

• ParseThru — Go библиотека net/url не игнорирует точку с запятой и выводит предупреждение http: URL query contains semicolon...

Следует помнить, что уязвимость HTTP Parameter Pollution может возникать не только в URL, но и в любой части POST/GET запроса, а также в теле JSON.

{"client_id":4, "client_id":17, "action":"delete"}

#api #wordlist

Раньше мы выполняли брутфорс только для статических файлов и папок. Но в современных реалиях, мы всё больше встречаем приложения, которые работают посредством конечных точек API. Это означает, что подход должен меняться, давайте рассмотрим специфику.

Возьмём, в качестве примера, запрос на удаление аккаунта пользователя:

DELETE /api/v1/users/<int> HTTP/2
Host: example.com
Content-Type: application/xml

HTTP/2 200 OK
Connection: close

1. Для того чтобы обнаружить эту конечную точку, в словаре должны быть сущности : api, v1, users
2. Вам нужно в запросе использовать метод DELETE
3. Поставить верный Content-Type
4. В последнем пути — нужно добавить число.

В противном случае ответ будет: 404 Not Found

Из этого следует, что нужен хороший словарь, специфичный для API, а также ротация методов GET, POST, DELETE, etc.

При брутфорсе нас интересуют следующие поля (%s):

%s /api/v1/%s/<int> HTTP/2
Host: example.com
Content-Type: %s

Поскольку обычные словари не нацелены на API спецификацию, я собрал свой. Для этого использовал замечательный массив данных от Assetnote из 67 500 файлов Swagger, собранных с помощью Google BigQuery.

Нарезал сущности и отфильтровал их по популярности — файл прикреплён к посту.

#api #params #tool

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

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

public class User {
   private String userid;
   private String password;
   private String email;
   private boolean isAdmin;
}

Чтобы правильно и эффективно находить такие вещи, нам нужен подход или утилита. Самые известные вот эти две: Param Miner и Arjun

Первая это плагин для BurpSuite. Вторая — консольная утилита на Python.

Относительно недавно, появилась новая консольная утилита x8

Она написана на языке Rust, разработчиком является багхантер @sh1y0
Около 40% уязвимостей на h1 он нашёл с её использованием

К слову, багхантеры за рубежом не стесняются встраивать её в свои конвейеры для поиска уязвимостей.

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

1. Arjun, в отличие от x8, имеет фиксированное значение параметров при брутфорсе (по умолчанию 500).

Это значит, что в запросе из вордлиста будут отсылаться сразу 500 параметров:

/?param1=test&param2=test&...&param500=test

Проблема здесь заключается в том, что многие серверы будут отдавать 414 URI Too Long, либо банально игнорировать последние 200 параметров. Таким образом, даже если в вашем текстовом файле есть нужный параметр — он не будет найден.

2. Ещё одним важным отличием являются функции сравнения ответов на странице.

Arjun сохраняет тело первого ответа и сравнивает с ответом нового запроса. Если есть разница — выводит сообщение о том что параметр влияет на ответ.

Естественно, проблема здесь очевидна, содержимое в ответе может быть всегда динамическим. Например, в теле ответа иногда встроен datetime.

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

HTTP/1.1 200 OK
Content-Length: 18

<html>
- Time 13:36:23

<id="test">

Как видно из примера, строка которая содержит время, исключена и помечена как динамическая.

HTTP/1.1 200 OK
Content-Length: 37

<html>
- Time 13:37:48

+ <id="admin_param">

Здесь x8 понимает, что параметр найден из-за изменений в теге id.

3. Arjun поддерживает методы только GET и POST, а Param Miner не умеет искать рекурсивным поиском.

Кроме того, в x8 есть гибкая настройка отправки параметров — концепция шаблонов и injection pointов, которая отсутствует в других инструментах.

Вообще, автор создал табличку, где сравнивает все три решения sh1yo.art/x8stats/
Так можно оценить эффективность работы на реальных сайтах.

Пример использования: x8 -u "https://example.com/" -w <wordlist>