Почему бы не использовать идентификатор сеанса как токен XSRF?

Почему Play Framework использует [подписанную версию идентификатора сеанса] как Подделку запроса на межсайтовый сайт (XSRF/CSRF), а не сам идентификатор сеанса?

(с токеном предотвращения XSRF, я имею в виду магическое значение, которое должно быть включено в представление формы, чтобы webapp принимал форму.)

Если есть подслушивающее устройство, он все равно найдет токен XSRF и файл cookie SID (?).

Если есть эксплойт XSS, тогда код вредоносного JavaScript может читать как токен XSRF, так и файл cookie SID (?).

Однако:

Злоумышленник не может создать действительный токен XSRF, учитывая SID, поскольку у него нет секретного ключа, используемого при подписании SID для получения токена XSRF. - Но как могло случиться, что злоумышленник получает только SID, а не токен XSRF? Это надуманный?
Если SID отправляется в cookie только HTTP, у злоумышленника не будет идентификатора SID, даже если он нашел токен XSRF, и, возможно, злоумышленнику действительно нужен SID? - Это надуманный?

Фрагменты кода:

Здесь Play строит его токен XSRF (getId возвращает идентификатор сеанса): (Воспроизведение/рамки/SRC/воспроизведение/MVC/Scope.java)

    public String getAuthenticityToken() {
        return Crypto.sign(getId());
    }

Здесь Play проверяет, что a <form> имеет действительный токен XSRF: (Воспроизведение/рамки/SRC/воспроизведение/MVC/Controller.java)

protected static void checkAuthenticity() {
    if(Scope.Params.current().get("authenticityToken") == null ||
       !Scope.Params.current().get("authenticityToken").equals(
                       Scope.Session.current().getAuthenticityToken())) {
        forbidden("Bad authenticity token");
    }
}

Update:

Play изменил способ генерации токенов XSRF, теперь SID больше не используется, вместо этого используется случайное значение и используется! (Я только что обновил свою платформу Play Framework Git repo от старой версии версии 1.1 до версии 1.2. Возможно, мне следовало это сделать... вчера, хм.)

    public String getAuthenticityToken() {
        if (!data.containsKey(AT_KEY)) {
            data.put(AT_KEY, Crypto.sign(UUID.randomUUID().toString()));
        }
        return data.get(AT_KEY);
    }

Ну, тогда почему они сделали это изменение?

Я нашел commit:
[# 669] Исправить ошибку и применить к Flash и ошибкам, а также d6e5dc50ea11fa7ef626cbdf01631595cbdda54c

Из журнала # 669:
создавать сеанс только в случае необходимости Куки файлы сеанса создаются по каждому запросу ресурса. игра должна создавать только cookie сеанса, если в сеансе действительно хранятся данные.

Таким образом, они используют случайное значение, а не идентификатор SID, поскольку SID еще не был создан. Хорошо, что причина не использовать производную от SID в качестве токена XSRF. Но не поясняет, почему они подписали/хэшировали SID, в прошлом, когда они его использовали.

Ответ 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 сеанса из браузера, не отменяя его на стороне сервера).
Но если вы повторно используете идентификатор сеанса в качестве токена CSRF, любая атака, которая позволяет им приобретать токен CSRF, автоматически дает им идентификатор сеанса.
Поэтому вам не следует повторно использовать токен CSRF в качестве идентификатора сеанса, поскольку он делает идентификатор сеанса более уязвимым.

Честно говоря, я отношусь ко всему выше, как к более теоретической, чем к практической. Слабой точкой аргумента является точка 2; единственные реалистичные уязвимости, о которых я могу думать, которые могут быть использованы для приобретения токенов CSRF, но не для получения файлов сеансов cookie, по-прежнему остаются серьезной уязвимостью. Если у вас есть дыра XSS на вашем сайте, или у злоумышленника есть доступ к вашим журналам журналов, возможно, вы все равно трахаетесь. И в большинстве библиотек и интернет-кафе, в которых я был, сотрудники не были подкованны в безопасности, и было бы довольно легко установить незарегистрированный кейлоггер и просто собирать пароли - не было бы необходимости, чтобы злоумышленник усилие ожидания, когда люди используют машину, а затем копируют содержимое своего кеша браузера.

Однако, если ваши обстоятельства каким-то образом затрудняют хранение дополнительного случайного токена для CSRF наряду с случайным идентификатором сеанса, почему бы просто не сделать это в любом случае за любую умеренную выгоду безопасности, которую он вам дает?

Ответ 2

Чистая атака CSRF не имеет доступа к файлам cookie браузера, поэтому, когда вы говорите "eavesdropper", это будет только достижимо, если они обнюхивают пакеты (т.е. нет SSL, public wifi).

В зависимости от конфигурации Play Framework (я не знаком с этим, так что рассмотрите это как общий совет веб-приложений), cookie сеанса и аутентификации почти наверняка будет отмечен как HttpOnly, чтобы они не могли быть прочитаны с клиента через XSS.

В конечном счете, идея использования шаблона токена синхронизации для защиты от XSRF заключается в использовании уникального значения (предпочтительно криптографически сильного), известного только серверу и клиенту и уникальное для этого сеанса. Основываясь на этой цели, Play Framework, похоже, отлично справляется.

Ответ 3

Возможно, Play Framework не хочет SID в HTML. Конечный пользователь Bob может загрузить веб-страницу, и если на этой веб-странице есть <form>, SID будет включен в загруженный HTML (если сам SID используется как токен XSRF). Если Боб затем отправит свою загруженную страницу в Мэллори, тогда Мэллори найдет SID и сможет выдать себя за Боба??

(Еще одна небольшая причина не использовать SID: как я упоминал в своем обновлении, SID может просто не быть доступен. Возможно, он сгенерирован как можно раньше, чтобы сохранить ресурсы ЦП.)