Злоумышленник, владеющий веб-сайтом и заставляющий вас посещать его (стандартный сценарий CSRF), обычно не имеет возможности в современных браузерах узнать, какие другие веб-сайты вы открывали на разных вкладках браузера (хотя всплыло несколько уловок время от времени, например, пытаясь встроить аутентифицированный ресурс с предполагаемого веб-сайта и проверить, не приводит ли это к ошибке, указывающей, что вы не вошли в систему - классика). Но они также могут просто угадать и провести атаку вслепую - может быть, они не будут знать, удалась ли она в конкретном случае, но иногда достаточно, если будут случайные успехи, неважно какие. CSRF есть CSRF, независимо от того, сможет ли злоумышленник узнать, сработало ли оно. Они все еще могут быть полезны в более сложных атаках в качестве строительного блока.
Что касается вашего другого вопроса - конечно, если ваш браузер не отправляет информацию для аутентификации, CSRF невозможен. Обратите внимание, что это не означает, строго говоря, файлы cookie, базовая HTTP-аутентификация также сохраняется для сеанса, и клиентские сертификаты также отправляются автоматически. Может быть, маргинальные, но иногда весьма важные. :) Также обратите внимание, что простой выход из пользовательского интерфейса не обязательно делает CSRF недействительным - сервер также должен правильно выйти из системы, что не всегда так. В качестве простого примера рассмотрим SAML SSO, когда у вас есть долгосрочный сеанс с поставщиком удостоверений и кратковременный сеанс с приложением. Вы нажимаете «Выйти», сеанс вашего приложения завершается, но единого выхода из системы может и не быть. Когда затем выполняется попытка CSRF с чем-то вроде полного http-сообщения, вы можете быть перенаправлены к IdP, а затем к приложению, которое может автоматически войти в систему и выполнить действие — без какого-либо взаимодействия с пользователем, облегчая CSRF. Опять же, возможно, крайний случай, но в некотором смысле все это касается крайних случаев.
person
Gabor Lengyel
schedule
15.01.2019
