Хотя я для развития пробовал и очень сложные методы взлома, такие как срыв стека, реальный опыт показал, что очень часто многое ломается гораздо проще. Все перечисленные уязвимости были в реальных проектах/компаниях. А некоторые даже есть и сейчас (но это был не мой клиент, NDA не заключался). Названия компаний я не упоминаю по понятным причинам.
- Использование SessionID в адресе почтовой страницы (CommuniGate Pro в вебмейле городского сайта). При переходе по ссылке SessionID передавался в хидере REFERER. Отправляем жертве письмо, она кликает по ссылке, перехватываем сессию, читаем чужую почту!
- Доступ во внутреннюю сеть компании через VPN с простым паролем. Пара логин/пароль была настолько простая, что даже брутфорс не понадобился, просто ручное вбивание самых простых и дурацких логинов-паролей в форму входа позволило попасть в сеть. А внутри уже незапароленные ресурсы с документами.
- Stored XSS на сайте СМИ, в веб-статистике. Статистика вебсервера для вебмастера доступна по адресу вроде /logs/. И включала себя Reverse DNS записи для хостов визиторов. Управляя своим реверсом можно было внедрять на страницу любой (не слишком длинный) HTML/JS код.
- Хранение паролей пользователей в хешах без соли (salt). В результате, в случае утечки хэшей легко было получить пароли пользователей (проблема для компании) и использовать их на других аккаунтах этого пользователя (проблема для клиента). Использование соленых хешей потребовало бы всего несколько строк кода, исправить легко, но ни у кого не болело. Скорее всего, разработчики знали, что соленые хеши лучше, но сделали черновик, а потом забыли доработать (или были увлечены другими важными задачами, или база уже начала заполняться) и система ушла в продакшн.
- ClickJacking уязвимость. Устраняется одним HTTP хидером, но это не было сделано. Для демонстрации взлома была сделана черновая страничка (без требуемой для реальной атаки реалистичности и красивости), но аккуратно позиционировав на ней элементы, удавалось заставить пользователя сделать действия в пределах его аккаунта на атакуемом сайте. К счастью, сам функционал системы был такой, что даже при успешной атаке мало что можно было получить.
- Хранение паролей в LocalStorage. В итоге, все пользователи компьютера не только могут зайти в систему, но и могут видеть пароль в plain виде (и есть шанс, что он подойдет и для взлома других ресурсов пользователя)
- Передача паролей в GET запросах. No comments :-)
- Форма логина без защиты от CORS и без капчи. Для демонстрации (и для удовольствия) была сделана страничка с ютуб-роликом (тихий джаз на фоне красивого пляжа) и простым JavaScript кодом для перебора паролей. Я пробовал даже на телевизоре (LG, smart) эту страничку открывать, и мой телевизор(!) взламывал пароль на сайте пока я наслаждался музыкой. Если подобный код разместить на более популярном ресурсе, чем моя тестовая страничка, возник бы распределенный брутфорс.
- Типичный Broken Authentication (сайт с некоторыми персональными файлами). Для входа в личный кабинет требуется пароль (все пока выглядит хорошо) но чтобы скачать свой файл - надо нажать кнопку. При этом передается номер заказа, и возвращается загадочное имя файла, который скачивается. Например /files/46ea1712d4b13b55b3f680cc5b8b54e8.zip. Сам файл скачивается без аутентификации и идея в том, что никто не угадает такое имя файла. Разумно. Но вот это волшебное имя 46ea1712d4b13b55b3f680cc5b8b54e8 не случайное, а всего лишь md5 от номера заказа. И если мой недавний заказ - номер 1000, то логично предположить, что в интервале от 800 до 1200 будут еще интересные файлы. Перебираем номера заказов, считаем по каждому хэш, сливаем. 5 минут, зашли и вышли!. Мне очень нравится эта уязвимость тем, что нигде нет явной грубой проблемы (даже скачивание файла без аутентификации достаточно безопасно в ситуации, когда угадать имя файла сложнее, чем угадать пароль). Проблема становится огромной только от сочетания факторов, которые можно подсмотреть даже в DevTools в каждом браузере.
