Как уменьшить атрибут SameSite cook ie до None в ASP. NET? - PullRequest
Новая
       32

Как уменьшить атрибут SameSite cook ie до None в ASP. NET?

4 голосов
/ 07 февраля 2020

Во избежание CSRF (подделка межсайтовых запросов) большинство браузеров (начиная с конца 2019 г.) автоматически считают, что любой повар ie, который явно не определяет атрибут SameSite, будет считаться Lax вместо None, который был предыдущий по умолчанию.

И в последнее время (февраль 2020 г., начиная с Chrome 80) браузеры также игнорируют файлы cookie, которые определяют SameSite = None и не являются безопасными.

Как изменить файлы cookie сеанса на автоматические изменилось на None (чтобы сохранить работоспособность моей интеграции единого входа) в моем файле Web.config?

Ответы [ 2 ]

4 голосов
/ 07 февраля 2020

Это чистое решение web.config, которое:

  • Определяет, что сеансовые куки должны отображаться с SameSite=None
  • Добавляет SameSite=None к любому кулинару ie, который явно не определяет атрибут SameSite
  • Добавляет атрибут Secure к любому повару ie, который еще не является безопасным (если это запрос https) 
<!-- This sets ASP.NET_SessionId cookie to SameSite=None, avoiding current default which is LAX -->
<system.web>
<!-- in newer framework versions you can set the default samesite level like this -->
<!-- in old versions these attributes might not be allowed -->
<sessionState cookieSameSite="None" />
<httpCookies sameSite="None"/>
<authentication mode="Forms">
    <forms ..... cookieSameSite="None" />
</authentication>

...
</system.web>
...
<system.webServer>
<rewrite>
      <outboundRules>
        <!-- for old versions the only solution is to intercept/modify cookies -->

        <!-- Add "SameSite=None" to any cookie which does NOT have it yet-->
        <rule name="Add SameSite" preCondition="No SameSite">
          <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
          <action type="Rewrite" value="{R:0}; SameSite=None" />
        </rule>

        <!-- Add "Secure" to any cookie which does NOT have it yet, as long as it's HTTPS request or else a secure cookie would just be ignored -->
        <rule name="Add Secure" preCondition="No Secure">
          <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
          <action type="Rewrite" value="{R:0}; Secure" />
        </rule>

        <preConditions>
          <preCondition name="No SameSite">
            <add input="{RESPONSE_Set_Cookie}" pattern="." />
            <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=" negate="true" />
          </preCondition>
          <preCondition name="No Secure">
            <add input="{RESPONSE_Set_Cookie}" pattern="." />
            <add input="{RESPONSE_Set_Cookie}" pattern="; Secure" negate="true" />
            <add input="{HTTPS}" pattern="on" ignoreCase="true" />
          </preCondition>
        </preConditions>

      </outboundRules>
</rewrite>
</system.webServer>

Если вы не используйте <sessionState cookieSameSite="None" />, некоторые более новые ASP. NET версии Framework по умолчанию будут отображать SameSite=Lax. И если бы у вас были правила перезаписи, добавляющие SameSite=None ко всем файлам cookie, вы бы дважды получили атрибут SameSite, который, согласно моим тестам, работает в НЕКОТОРЫХ браузерах, таких как Chrome и Firefox (которые будут использовать last вхождение атрибута SameSite), но не будет работать в некоторых случаях, например в Edge (в котором используется first вхождение атрибута).

Поскольку этот первый тег <sessionState cookieSameSite="None" /> автоматически установит SameSite=None, но не будет автоматически добавлять атрибут Secure, я настроил SameSite=None и Secure как независимые правила. Если бы у меня было все в одном правиле, я бы получил дублированный атрибут SameSite=None, который мог бы сломать браузеры (как объяснено выше, он недействителен, и браузеры могут обрабатывать это непоследовательно).

* Secure только добавляется, если это HTTPS-запрос, поэтому, если вы все еще принимаете HTTP-соединения, к вашим сеансовым куки-файлам не добавляется Secure, что заставит браузеры игнорировать ваш повар ie (и сессия вообще не будет работать). Если вы находитесь за балансировщиком нагрузки или обратным прокси-сервером, вам следует использовать атрибут HTTP_X_FORWARDED_PROTO

Последнее: в есть некоторые ошибки в некоторых версиях Safari , из-за которых браузер не не понимаю SameSite=None и воспринимает это как SameSite=Strict. Таким образом, для этих указанных c версий вы можете решить не отображать SameSite=None, хотя, если не указано, по умолчанию используется уровень SameSite=Lax, который может быть не тем, что вам нужно (не нашли решения для этого).

0 голосов
/ 28 марта 2020

Вы правы, моя проблема в том, что срок действия сертификата истек. Работает хорошо, спасибо.

...