Угнать за 9 символов
Сегодня я расскажу вам историю об уязвимости, которая существовала в одном интернет-банке много лет. Её эксплуатация была настолько элементарной, а опасность была настолько не очевидна, что ни кто так и не обратил на неё внимание.
С этим банком у меня была договорённость о поиске уязвимостей и все мои действия были санкционированными. В тот вечер я уже потратил приличное время на поиск более-менее критичной уязвимости и так не найдя ничего стоящего, было уже отчаялся. Но тут мой взгляд зацепился за один параметр в череде запросов к серверу в момент авторизации. К слову, этот банк использовал передовую и очень надежную технологию авторизации, а именно двухфакторную авторизацию через смс. Так вот, параметр GET запроса, на который я обратил внимание, имел вид: go=/path/to/some/page и формировался на стороне сервера для дальнейшей переадресации. Но проблемой было то, что путь для переадресации был относительным и добавлялся к домену сайта и поэтому я игнорировал этот запрос в своих предыдущих исследованиях. К тому же, что бы в нем существовала потенциальная уязвимость, должен был иметь место ряд факторов, а именно:
1). возможность при помощи значения параметра go обеспечить переадресацию на сторонний домен
2). возможность на клиенте задавать значение этого параметра
3). и наконец, после авторизации при редиректе на сторонний домен должна передаться какая нибудь ценная информация
В итоге, с малой надеждой на какой либо результат, я начал искать пути эксплуатации потенциальной уязвимости.
Читать дальше →
С этим банком у меня была договорённость о поиске уязвимостей и все мои действия были санкционированными. В тот вечер я уже потратил приличное время на поиск более-менее критичной уязвимости и так не найдя ничего стоящего, было уже отчаялся. Но тут мой взгляд зацепился за один параметр в череде запросов к серверу в момент авторизации. К слову, этот банк использовал передовую и очень надежную технологию авторизации, а именно двухфакторную авторизацию через смс. Так вот, параметр GET запроса, на который я обратил внимание, имел вид: go=/path/to/some/page и формировался на стороне сервера для дальнейшей переадресации. Но проблемой было то, что путь для переадресации был относительным и добавлялся к домену сайта и поэтому я игнорировал этот запрос в своих предыдущих исследованиях. К тому же, что бы в нем существовала потенциальная уязвимость, должен был иметь место ряд факторов, а именно:
1). возможность при помощи значения параметра go обеспечить переадресацию на сторонний домен
2). возможность на клиенте задавать значение этого параметра
3). и наконец, после авторизации при редиректе на сторонний домен должна передаться какая нибудь ценная информация
В итоге, с малой надеждой на какой либо результат, я начал искать пути эксплуатации потенциальной уязвимости.
Читать дальше →
Источник: Хабрахабр
Похожие новости
- Как работает безопасность, когда никто никому не доверяет — Zero Trust на пальцах
- Централизация биткойн-майнинга в 2025 году: концентрация хешрейта усиливается
- Новости кибербезопасности за неделю с 19 по 25 мая 2025
- [Перевод] Преступный ИИ уже существует, и он доступен любому
- [Перевод] Postman логирует все ваши секреты и переменные окружения
- Math Agency: Google AI Mode: новая модель поиска, которая меняет всё
- Атака клонов или темная сторона Open Source
- А вам точно нужно делать и продвигать приложение? Два главных вопроса бизнесу перед разработкой
- Гайд по криптостойкости, как защитить наши данные
- [Перевод] Взлом моей машины, и, вероятно, вашей — уязвимости в приложении Volkswagen