如何在ASP.NET中将SameSite Cookie属性减少回None? [英] How to reduce SameSite cookie attribute back to None in ASP.NET?

查看:389
本文介绍了如何在ASP.NET中将SameSite Cookie属性减少回None?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为了避免CSRF(跨站点请求伪造),大多数浏览器(自2019年末开始)会自动考虑将未明确定义SameSite属性的任何cookie都视为Lax,而不是以前的默认设置为None.

In order to avoid CSRF (Cross-site request forgery) most browsers are (since late 2019) automatically considering that any cookie which does not define SameSite attribute explicitly will be considered as Lax, instead of None which was the previous default.

最近(从Chrome 80开始,2020年2月)浏览器也忽略了定义SameSite = None并且不安全的cookie.

And more recently (Feb 2020, since Chrome 80) browsers are also ignoring cookies which define SameSite=None and are not secure.

如何在Web.config中将会话cookie更改为自动更改为无"(以保持SSO集成正常工作)?

How can I change my session cookies to be automatically changed to None (to keep my SSO integrations working) in my Web.config?

推荐答案

这是一个纯粹的web.config解决方案,

This is a pure web.config solution which:

  • 定义应使用SameSite=None
  • 呈现会话cookie
  • SameSite=None附加到任何未明确定义SameSite属性的cookie
  • Secure属性附加到任何尚不安全的cookie(只要它是https请求)
  • Defines that session cookies should be rendered with SameSite=None
  • Appends SameSite=None to any cookie which does not explicitly defines SameSite attribute
  • Appends Secure attribute to any cookie which is not yet secure (as long as it's https request)
<!-- 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.而且,如果您只是在所有Cookie上添加了SameSite=None的重写规则,则会获得两次SameSite属性,根据我的测试,该属性在某些浏览器(例如Chrome和Firefox)中会起作用(它们将使用 last 但不能在某些类似Edge(使用 first 出现的属性)的系统中使用.

If you don't use the the <sessionState cookieSameSite="None" /> some newer ASP.NET Framework versions will by default render a SameSite=Lax. And if you just had the rewrite rules adding SameSite=None to all cookies you would get the SameSite attribute twice, which according to my tests work in SOME browsers like Chrome and Firefox (which will use the last occurrence of the SameSite attribute) but won't work in some like Edge (which uses the first occurrence of the attribute).

由于第一个标签<sessionState cookieSameSite="None" />将自动设置SameSite=None,但不会自动添加Secure属性,因此我将SameSite=NoneSecure配置为独立规则.如果将所有内容放在一条规则中,我将得到重复的属性SameSite=None,这可能会破坏浏览器(如上所述),这是无效的,浏览器可能会不一致地处理此问题.

Since this first tag <sessionState cookieSameSite="None" /> will automatically set SameSite=None but will not automatically add Secure attribute, I've configured SameSite=None and Secure as independent rules. If I had it all in a single rule I would end up with duplicated attribute SameSite=None, which could break browsers (as explained above it's invalid and browsers may handle this inconsistently).

仅在它是HTTPS请求时才添加Secure,因此,如果您仍在接受HTTP连接,则会话cookie不会添加Secure,这会使浏览器忽略您的cookie(会话不会工作).如果您位于负载平衡器或反向代理之后,则应使用

The Secure is only added if it's HTTPS request, so if you're still accepting HTTP connections your session cookies won't have the Secure added, which would make browsers ignore your cookie (and session wouldn't work at all). If you're behind a load balancer or reverse proxy you should use the HTTP_X_FORWARDED_PROTO attribute

最后,某些版本的Safari 中存在一个错误,其中浏览器无法理解SameSite=None并将其视为SameSite=Strict.因此,对于那些特定版本,您可能决定不渲染SameSite=None,尽管如果未指定,默认值仍为SameSite=Lax级别,这可能不是您所需要的(尚未找到解决方案).

Last, there's a bug in some versions of Safari in which the browser doesn't understand SameSite=None and treat it as SameSite=Strict. So for those specific versions you might decide not to render SameSite=None, although if not specified the default is still SameSite=Lax level, which might not be what you need (haven't found a solution for that).

这篇关于如何在ASP.NET中将SameSite Cookie属性减少回None?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆