问题
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.
And more recently (Feb 2020, since Chrome 80) browsers are also ignoring cookies which define SameSite=None and are not secure.
How can I change my session cookies to be automatically changed to None (to keep my SSO integrations working) in my Web.config?
回答1:
This is a pure web.config solution which:
- 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>
<sessionState cookieSameSite="None" />
...
<rewrite>
<outboundRules>
<!-- 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.web>
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).
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).
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
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).
来源:https://stackoverflow.com/questions/60117726/how-to-reduce-samesite-cookie-attribute-back-to-none-in-asp-net