commit
42225371d7
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
====
|
||||
|
||||
|
|
Loading…
Reference in New Issue