Повторно использовать одноразовый сценарий CSP на протяжении всего сеанса? - PullRequest
Новая
       38

Повторно использовать одноразовый сценарий CSP на протяжении всего сеанса?

1 голос
/ 03 мая 2019

Это продолжение https://github.com/w3c/webappsec-csp/issues/215. arturjanc , предложенное перенести это обсуждение в stackoverflow.

Мы пытаемся реализовать CSP для сценариев в JSF и не знаем, безопасно ли повторно использовать одноразовый номер сценария в течение сеанса. Или, как предложил arturjanc, отправьте исходный документ на сервер, который генерирует будущие ответы, в исходном документе.

Предполагая, что повторно использовать одноразовый номер в течение сеанса небезопасно, было бы хорошо просто включить исходный одноразовый номер в скрытый ввод данных, как в настоящее время реализовано здесь . (на данный момент игнорируем уязвимости заголовка CSP / внедрения XSS - это всего лишь прототип)

@ arturjanc: Хотели бы вы снова присоединиться?

Редактировать: Дополнительные мысли относительно ответа arturjanc:

Не могли бы вы подробнее рассказать о том, как реализовать одноразовые одноразовые запросы в типичном современном приложении JSF, то есть просто иметь одну полную загрузку страницы в самом начале и последующую связь только по XHR?

Если я вас правильно понял, вы бы всегда предлагали повторно отправлять изначально сгенерированный одноразовый номер в каждом запросе XHR. Однако на практике это фактически то же самое, что и одноразовые сеансы, не так ли? Просто сложнее в плане реализации.

Строгое реализация одноразовых номеров для каждого ответа подразумевает, что последующие ответы также должны включать все одноразовые номера, созданные ранее в этом сеансе, поэтому мы каким-то образом отследим все одноразовые значения в этом сеансе.

Установка новых заголовков CSP для каждого XHR-ответа, содержащего только недавно созданный одноразовый номер для ответа, вероятно, не будет работать из-за того, что браузеры обрабатывают несколько заголовков CSP по ответам, объединяя их, используя стратегию пересечения, т.е. Content-Security-Policy: 'nonce-1' в ответе 1 и Content-Security-Policy: 'nonce-2' в ответе 2 сделает оба одноразовых номера недействительными после ответа 2.

1 Ответ

1 голос
/ 07 мая 2019

К сожалению, нет однозначного правильного ответа на ваши вопросы: нет ничего плохого в том, чтобы иметь одноразовый одноразовый номер, но он создает риск того, что всякий раз, когда одноразовый номер может быть пропущен злоумышленником, его можно будет повторно использовать при загрузке другой страницы., позволяя злоумышленнику использовать ошибку XSS, которая в противном случае была бы устранена CSP.

В частности, когда вы включаете одноразовый номер в скрытое поле ввода, он позволяет эксфильтрации значения с помощью злоупотреблять селекторами CSS;обратите внимание, что та же атака не будет работать против атрибута script#nonce, поскольку браузер скрывает значение этого атрибута от DOM для защиты от таких атак.

Моя рекомендация будет двоякой:

  • Попробуйте сделать одноразовый номер для ответа, а не для сеанса.Таким образом, даже если одноразовый номер может быть отфильтрован, злоумышленнику будет трудно использовать его повторно.
  • Если вам необходимо повторно использовать одноразовый номер, чтобы разрешить асинхронно извлекаемую разметку с сервера, содержащую сценарии справильное значение одноразового номера, сделайте это без копирования одноразового номера в DOM.Например, если вы используете XHR для URL с параметром nonce, сделайте что-то вроде xhr.open("/my/url?nonce=" + document.currentScript.nonce)
...