Проверка неработающей аутентификации
Когда функции аутентификации, относящиеся к приложению, не реализованы правильно, это позволяет хакерам скомпрометировать пароли или идентификаторы сеанса или использовать другие недостатки реализации, используя учетные данные других пользователей.
Давайте разберемся с агентами угроз, векторами атак, слабостями безопасности, техническим воздействием и последствиями для бизнеса этой уязвимости с помощью простой диаграммы.
пример
An e-commerce application supports URL rewriting, putting session IDs in the URL −
http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptopАвторизованный пользователь сайта пересылает URL своим друзьям, чтобы узнать о скидках. Он отправляет по электронной почте указанную выше ссылку, не зная, что пользователь также передает идентификаторы сеанса. Когда его друзья используют ссылку, они используют его сеанс и кредитную карту.
Руки вверх
Step 1- Войдите в Webgoat и перейдите в раздел «Недостатки управления сеансом». Давайте обойдем аутентификацию, подделав cookie. Ниже приведен снимок сценария.
Step 2 - Когда мы авторизуемся с использованием учетных данных webgoat / webgoat, мы обнаруживаем из Burp Suite, что идентификатор JSESSION - C8F3177CCAFF380441ABF71090748F2E, а AuthCookie = 65432ubphcfx после успешной аутентификации.
Step 3 - Когда мы входим в систему с использованием аспекта / аспекта учетных данных, мы обнаруживаем из Burp Suite, что идентификатор JSESSION - C8F3177CCAFF380441ABF71090748F2E, а AuthCookie = 65432udfqtb после успешной аутентификации.
Step 4- Теперь нам нужно проанализировать шаблоны AuthCookie. Первая половина «65432» является общей для обеих аутентификаций. Следовательно, теперь мы заинтересованы в анализе последней части значений authcookie, таких как - ubphcfx для пользователя webgoat и udfqtb для пользователя аспекта соответственно.
Step 5- Если мы внимательно посмотрим на значения AuthCookie, последняя часть имеет ту же длину, что и имя пользователя. Следовательно, очевидно, что имя пользователя используется с некоторым методом шифрования. После использования механизмов проб и ошибок / перебора мы обнаруживаем, что после изменения имени пользователя webgoat; мы получаем taogbew, а затем перед алфавитным символом используется как AuthCookie. т.е. ubphcfx.
Step 6- Если мы передадим это значение cookie и посмотрим, что произойдет. После аутентификации в качестве пользователя webgoat измените значение AuthCookie, чтобы имитировать пользователя Алису, найдя AuthCookie для того же пользователя, выполнив шаги №4 и №5.
Предотвращающие механизмы
Разработайте строгий контроль аутентификации и управления сеансом, чтобы он отвечал всем требованиям к аутентификации и управлению сеансом, определенным в стандарте проверки безопасности приложений OWASP.
Разработчики должны убедиться, что они избегают недостатков XSS, которые могут быть использованы для кражи идентификаторов сеансов.