1. Предпосылки
Недавно в группе исследований и разработок компании было обнаружено, что некоторые люди сообщали, что междоменный доступ внутреннего веб-сайта к Mo Ming имел проблемы с перенаправлением сайта, и все они появились после версии Google 80.
2. Исследуйте
Причиной перенаправления является не что иное, как отсутствие файла cookie, что приводит к отсутствию состояния входа в систему. В соответствии с этим направлением мышления мы запустили серию исследований.
2.1 Обзор 1, Настройки Google, Разрешить сторонние файлы cookie
Результат: Ошибка, проблема не решена
2.2 Исследование 2, браузер меняет настройки SameSite
- Ввод адресной строки Google Chrome: chrome://flags/
- Найдено: файлы cookie SameSite по умолчанию, файлы cookie без SameSite должны быть безопасными.
- Установите два вышеуказанных параметра на «Отключить».
Результат: Решено успешно, но это решение немного ограничено, если все столкнутся с этой проблемой, то нужно еще раз всем рассказать, нужно открывать chrome://flags/, ставить SameSite, боже, слишком хлопотно. Блокировать выход слишком хлопотно, конечно, это тоже временное решение, так что нам все же придется принять решение попроще, а именно решать его из исходников.
2.3 Исследование 3, установка файла cookie для изменения настроек SameSite
Междоменный доступ к веб-сайту Мо Мин появляется перенаправление сайта, где источник, то есть в месте единого входа, если мы настроим SameSite в месте единого входа, решается ли это во всех местах, где используется текущее состояние входа ?эта проблема. Как это работает. Операция очень проста, на самом деле это установить cookie в сообщении и добавить SameSite=None; Secure
Результат: идеальное решение раз и навсегда. Не объясняйте всем, что вам нужно делать.
3. Причина
Наконец, я вернулся и задумался о том, почему это произошло. Все обнаружили, что в процессе исследования настройки SameSite в основном менялись до того, как они были успешно решены. Атрибут файла cookie SameSite используется для ограничения сторонних файлов cookie, тем самым снижая риски безопасности. Он может установить три значения:
- Strict
Strict является самым строгим, полностью запрещает сторонние файлы cookie и не будет отправлять файлы cookie ни при каких обстоятельствах при межсайтовом размещении. Другими словами, только URL-адрес текущей веб-страницы соответствует цели запроса, файл cookie будет доставлен.
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
Это правило слишком строгое и может привести к очень плохому пользовательскому опыту. Например, если на текущей веб-странице есть ссылка GitHub, у пользователя не будет файла cookie GitHub, когда он нажмет, чтобы перейти, и переход всегда будет в состоянии «не вошел в систему».
- Lax
Нестрогие правила немного смягчены, и в большинстве случаев сторонние файлы cookie не отправляются, за исключением запросов Get, которые переходят к целевому URL-адресу.
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
После установки Strict или Lax атаки CSRF практически исключены. При условии, конечно, что браузер пользователя поддерживает атрибут SameSite.
- None
Веб-сайты могут явно отключить свойство SameSite, установив для него значение None. Однако предпосылка заключается в том, что атрибут «Безопасный» должен быть установлен одновременно (файлы cookie могут отправляться только по протоколу HTTPS), в противном случае он недействителен.
Set-Cookie: widget_session=abc123; SameSite=None; Secure
После обновления Chrome до версии 80 (точнее, после версии 78) значение атрибута SameSite файла cookie по умолчанию изменилось с None на Lax, что и является основной причиной этого инцидента.
Этот вопрос также обсуждается в сообществе, адрес обсуждения:GitHub.com/Google/ о боже...