Ответ 1
Прежде всего, вы можете повторно использовать идентификатор сеанса как токен CSRF, поскольку он будет защищать вас от CSRF и не создает автоматически серьезных дыр в безопасности. Однако по довольно обоснованным причинам OWASP явно рекомендовал против. (Теперь они не затрагивают вопрос вообще.)
Аргумент против повторного использования идентификатора сеанса как токена CSRF можно суммировать следующим образом (ключевые точки выделены жирным шрифтом, с обоснованием ниже):
-
Идентификатор сеанса, получаемый злоумышленником, обычно является более серьезным нарушением безопасности, чем токен CSRF, который получает злоумышленник.
Все, что злоумышленник получает от наличия токена CSRF (при условии, что некоторая другая защищенная часть информации, такая как идентификатор сеанса, не была повторно использована как токен CSRF), является способностью выполнять атаки CSRF. Это дает им два огромных ограничения, которых у них не было бы, если бы они действительно приобрели идентификатор сеанса:
- Им по-прежнему нужно заманить пользователя с помощью соответствующего токена сеанса на страницу атаки (или попросить их прочитать сообщение об атаке или просмотреть объявление атаки в iframe и т.д.), чтобы использовать токен CSRF любым способом вообще, С идентификатором сеанса им просто нужно поместить его в свой браузер, а затем использовать веб-сайт, как если бы он был этим пользователем.
- Пока они могут отправлять запросы с использованием учетных данных пользователя, Same Origin Policy по-прежнему препятствует просмотру ответов на эти запросы. Это может (или не может, в зависимости от структуры API, которую вы защищаете, и изобретательности злоумышленника) на практике означает, что, хотя злоумышленник может выполнять действия от имени пользователя, они не могут получать конфиденциальную информацию, которую пользователь имеет право просматривать, (Какое из них вам больше нравится, зависит от контекста - предполагается, что злоумышленник предпочтет, чтобы содержимое вашего банковского счета просто знало, что это такое, но что они также скорее знают вашу медицинскую историю, чем вандализм Это.)
-
Значок CSRF потенциально легче для злоумышленника приобрести, чем идентификатор сеанса
- Атаки XSS, вероятно, позволят злоумышленнику получить токен CSRF, поскольку обычная практика испекает его в DOM (например, как значение элемента
<input>в<form>). Сессионные файлы cookie, с другой стороны может быть хранится в секрете даже перед лицом успешной атаки XSS с использованием флага HttpOnly, требуя больше работы от злоумышленника до полезно использовать уязвимость XSS. - Если токен CSRF отправляется обратно на сервер в качестве параметра запроса, а не в пользовательский HTTP-заголовок (это гарантируется, когда он включается в обычный HTML
<form>), тогда журналы доступа к веб-серверу обычно записываются в журнал токен CSRF в запросах GET (как часть URL-адреса). Таким образом, злоумышленник, которому удается просмотреть журнал доступа, сможет получить много токенов CSRF. - Страницы или скрипты, в которые выточен токен CSRF, могут быть кэшированы в пользовательском браузере, что позволяет злоумышленнику извлекать их из кеша (возможно, релевантно после того, как пользователь использует, например, общедоступный компьютер в библиотеке или Интернете кафе, а затем либо очистили файлы cookie, но не их кеш, либо использовали кнопку "Выход", которая удаляет их cookie сеанса из браузера, не отменяя его на стороне сервера).
- Атаки XSS, вероятно, позволят злоумышленнику получить токен CSRF, поскольку обычная практика испекает его в DOM (например, как значение элемента
-
Но если вы повторно используете идентификатор сеанса в качестве токена CSRF, любая атака, которая позволяет им приобретать токен CSRF, автоматически дает им идентификатор сеанса.
-
Поэтому вам не следует повторно использовать токен CSRF в качестве идентификатора сеанса, поскольку он делает идентификатор сеанса более уязвимым.
Честно говоря, я отношусь ко всему выше, как к более теоретической, чем к практической. Слабой точкой аргумента является точка 2; единственные реалистичные уязвимости, о которых я могу думать, которые могут быть использованы для приобретения токенов CSRF, но не для получения файлов сеансов cookie, по-прежнему остаются серьезной уязвимостью. Если у вас есть дыра XSS на вашем сайте, или у злоумышленника есть доступ к вашим журналам журналов, возможно, вы все равно трахаетесь. И в большинстве библиотек и интернет-кафе, в которых я был, сотрудники не были подкованны в безопасности, и было бы довольно легко установить незарегистрированный кейлоггер и просто собирать пароли - не было бы необходимости, чтобы злоумышленник усилие ожидания, когда люди используют машину, а затем копируют содержимое своего кеша браузера.
Однако, если ваши обстоятельства каким-то образом затрудняют хранение дополнительного случайного токена для CSRF наряду с случайным идентификатором сеанса, почему бы просто не сделать это в любом случае за любую умеренную выгоду безопасности, которую он вам дает?