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