Атрибут Samesite для файлов cookie, установленных в ответе, не изменяется модулем cookie tomcat

Question

В последнее время браузеры повышают безопасность для предотвращения CSRF-атак за счет повышения параметра кулинарной проверки на одном и том же сайте ie значение по умолчанию для Lax, т. Е. Если тот же атрибут сайта не установлен сервером при настройке поваренного значения ie с помощью ответа set-cook ie заголовок, браузер будет рассматривать их как Lax и не будет сохранен, поэтому при последующих вызовах куки не отправляются обратно на сервер, если эти запросы не выполняются. Это происходит при междоменном обмене данными, когда междоменное приложение выполняется в iFrame на главном веб-сайте.

У нас есть одно такое серверное приложение, которое устанавливает два куки-файла в ответ на успешные запросы аутентификации, и эти куки-файлы предполагаются быть отправленным обратно на сервер при каждом последующем вызове, чтобы заставить сервер поверить, что запросы аутентифицированы для дальнейшей обработки. Эти куки не имеют какого-либо атрибута samesite, установленного явно, поэтому новые браузеры (Chrome 80) не отправляют их обратно при последующих вызовах.

Серверное приложение размещено на tomcat. Таким образом, чтобы смягчить проблему, мы использовали tomcat cookieprocessor , чтобы установить для атрибута samesite cook ie значение «none», чтобы можно было выполнять междоменные вызовы. К сожалению, это не сработало. Несмотря на явную установку атрибута samesite через cookieprocessor, этот ответ при проверке с помощью инструментов разработчика не показывает никаких следов атрибута samesite.

Итак, вот вопрос: правильно ли я понимаю, что tomcat должен изменить ответ сервера для добавления атрибута samesite к файлам cookie, которые устанавливаются через заголовок set-cook ie в ответе? Я попытался отладить код cookie-процессора, настроив удаленную отладку, но похоже, что ответы не перехвачены, и, следовательно, заголовок cook ie изменяется. Что я здесь не так делаю?

Примечание: я настроил cookie-процессор в мета-inf / context приложения. xml.

Answer 1

То есть вы используете Tomcat, но какую версию Tomcat вы используете?

В первоначальном выпуске поддержки CookieProcessor SameSite использовалось «None» для ссылки на поведение для сброса значения SameSite.

https://bz.apache.org/bugzilla/show_bug.cgi?id=63865

Fixed in:
- master for 9.0.28 onwards
- 8.5.x for 8.5.48 onwards

Я не уверен, что CookieProcessor от Tomcat учитывает User-Agent клиентов.

Если вы реализуете это Кстати, ваше приложение может не поддерживать известные несовместимые клиенты: Chrome 51-66, MacOSX Mojave (10.14) Safari / Embedded, iOS 12, UCBrowser до 12.13.2

https://www.chromium.org/updates/same-site/incompatible-clients

Мы решили наши обычные куки-файлы, используя addHeader для поддержки SameSite.

Мы решили наши сеансовые куки-файлы в нашем слое nginx.

Для JSESSIONID это кажется, вы также можете использовать фильтр, чтобы обернуть HttpServletRequest, чтобы добавить копию сеанса cook ie с надлежащими атрибутами при каждом создании нового сеанса. Хотя это добавляет ~ 80B для переопределения JSESSIONID.

Answer 2

Я на самом деле раскрыл тайну сам. Cookieprocessor работает только в том случае, если куки добавляются с помощью метода response.addCook ie (). Таким образом, если куки установлены с помощью методов установки / добавления заголовков, cookieporcessor ничего не сделает. На самом деле наше серверное приложение использует заголовочный подход для добавления метода cook ie, а не метода addCook ie ().