#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"}

#web #portswigger #burp #api

New topic on Web Security Academy — API testing

By guiding you step-by-step through the process of testing APIs, we will teach you to spot, understand, and then exploit them to their full potential.

Ready to get stuck in?

https://portswigger.net/web-security/api-testing

5 new labs are also here for you:

Exploiting an API endpoint using documentation

Exploiting server-side parameter pollution in a query string

Finding and exploiting an unused API endpoint

Exploiting a mass assignment vulnerability

Exploiting server-side parameter pollution in a REST URL