Merge branch '6.0.x' into 6.1.x

Closes gh-14114
This commit is contained in:
Josh Cummings 2023-11-07 16:33:45 -07:00
commit 42225371d7
No known key found for this signature in database
GPG Key ID: A306A51F43B8E5A5
3 changed files with 11 additions and 11 deletions

View File

@ -97,13 +97,13 @@ Spring provides two mechanisms to protect against CSRF attacks:
[NOTE]
====
Both protections require that <<csrf-protection-idempotent,Safe Methods be Idempotent>>.
Both protections require that <<csrf-protection-read-only,Safe Methods be Read-only>>.
====
[[csrf-protection-idempotent]]
=== Safe Methods Must be Idempotent
[[csrf-protection-read-only]]
=== Safe Methods Must be Read-only
For <<csrf-protection,either protection>> against CSRF to work, the application must ensure that https://tools.ietf.org/html/rfc7231#section-4.2.1["safe" HTTP methods are idempotent].
For <<csrf-protection,either protection>> against CSRF to work, the application must ensure that https://tools.ietf.org/html/rfc7231#section-4.2.1["safe" HTTP methods are read-only].
This means that requests with the HTTP `GET`, `HEAD`, `OPTIONS`, and `TRACE` methods should not change the state of the application.
[[csrf-protection-stp]]
@ -119,7 +119,7 @@ For example, requiring the actual CSRF token in an HTTP parameter or an HTTP hea
Requiring the actual CSRF token in a cookie does not work because cookies are automatically included in the HTTP request by the browser.
We can relax the expectations to require only the actual CSRF token for each HTTP request that updates the state of the application.
For that to work, our application must ensure that <<csrf-protection-idempotent,safe HTTP methods are idempotent>>.
For that to work, our application must ensure that <<csrf-protection-read-only,safe HTTP methods are read-only>>.
This improves usability, since we want to allow linking to our website from external sites.
Additionally, we do not want to include the random token in HTTP GET, as this can cause the tokens to be leaked.
@ -190,7 +190,7 @@ Valid values for the `SameSite` attribute are:
* `Strict`: When specified, any request coming from the https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1[same-site] includes the cookie.
Otherwise, the cookie is not included in the HTTP request.
* `Lax`: When specified, cookies are sent when coming from the https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1[same-site] or when the request comes from top-level navigations and the <<Safe Methods Must be Idempotent,method is idempotent>>.
* `Lax`: When specified, cookies are sent when coming from the https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1[same-site] or when the request comes from top-level navigations and the <<Safe Methods Must be Read-only,method is read-only>>.
Otherwise, the cookie is not included in the HTTP request.
Consider how <<csrf-explained,our example>> could be protected using the `SameSite` attribute.

View File

@ -7,14 +7,14 @@ This section discusses Spring Security's xref:features/exploits/csrf.adoc#csrf[C
== Using Spring Security CSRF Protection
The steps to using Spring Security's CSRF protection are outlined below:
* <<webflux-csrf-idempotent,Use proper HTTP verbs>>
* <<webflux-csrf-read-only,Use proper HTTP verbs>>
* <<webflux-csrf-configure,Configure CSRF Protection>>
* <<webflux-csrf-include,Include the CSRF Token>>
[[webflux-csrf-idempotent]]
[[webflux-csrf-read-only]]
=== Use Proper HTTP Verbs
The first step to protecting against CSRF attacks is to ensure your website uses proper HTTP verbs.
This is covered in detail in xref:features/exploits/csrf.adoc#csrf-protection-idempotent[Safe Methods Must be Idempotent].
This is covered in detail in xref:features/exploits/csrf.adoc#csrf-protection-read-only[Safe Methods Must be Read-only].
[[webflux-csrf-configure]]
=== Configure CSRF Protection

View File

@ -4,7 +4,7 @@
In an application where end users can xref:servlet/authentication/index.adoc[log in], it is important to consider how to protect against xref:features/exploits/csrf.adoc#csrf[Cross Site Request Forgery (CSRF)].
Spring Security protects against CSRF attacks by default for xref:features/exploits/csrf.adoc#csrf-protection-idempotent[unsafe HTTP methods], such as a POST request, so no additional code is necessary.
Spring Security protects against CSRF attacks by default for xref:features/exploits/csrf.adoc#csrf-protection-read-only[unsafe HTTP methods], such as a POST request, so no additional code is necessary.
You can specify the default configuration explicitly using the following:
[[csrf-configuration]]
@ -592,7 +592,7 @@ By default, Spring Security defers loading of the `CsrfToken` until it is needed
[NOTE]
====
The `CsrfToken` is needed whenever a request is made with an xref:features/exploits/csrf.adoc#csrf-protection-idempotent[unsafe HTTP method], such as a POST.
The `CsrfToken` is needed whenever a request is made with an xref:features/exploits/csrf.adoc#csrf-protection-read-only[unsafe HTTP method], such as a POST.
Additionally, it is needed by any request that renders the token to the response, such as a web page with a `<form>` tag that includes a hidden `<input>` for the CSRF token.
====