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