Merge branch '5.8.x' into 6.0.x

Closes gh-13406

Author: rwinch

docs/modules/ROOT/pages/features/authentication/password-storage.adoc

@@ -25,7 +25,6 @@ Assume that your bank's website provides a form that allows transferring money f
 For example, the transfer form might look like:
 
 .Transfer form
-====
 [source,html]
 ----
 <form method="post"
@@ -40,12 +39,10 @@ For example, the transfer form might look like:
 	value="Transfer"/>
 </form>
 ----
-====
 
 The corresponding HTTP request might look like:
 
 .Transfer HTTP request
-====
 [source]
 ----
 POST /transfer HTTP/1.1
@@ -55,13 +52,11 @@ Content-Type: application/x-www-form-urlencoded
 
 amount=100.00&routingNumber=1234&account=9876
 ----
-====
 
 Now pretend you authenticate to your bank's website and then, without logging out, visit an evil website.
 The evil website contains an HTML page with the following form:
 
 .Evil transfer form
-====
 [source,html]
 ----
 <form method="post"
@@ -79,7 +74,6 @@ The evil website contains an HTML page with the following form:
 	value="Win Money!"/>
 </form>
 ----
-====
 
 You like to win money, so you click on the submit button.
 In the process, you have unintentionally transferred $100 to a malicious user.
@@ -134,7 +128,6 @@ Assume that the actual CSRF token is required to be in an HTTP parameter named `
 Our application's transfer form would look like:
 
 .Synchronizer Token Form
-====
 [source,html]
 ----
 <form method="post"
@@ -152,15 +145,13 @@ Our application's transfer form would look like:
 	value="Transfer"/>
 </form>
 ----
-====
 
 The form now contains a hidden input with the value of the CSRF token.
 External sites cannot read the CSRF token since the same origin policy ensures the evil site cannot read the response.
 
 The corresponding HTTP request to transfer money would look like this:
 
 .Synchronizer Token request
-====
 [source]
 ----
 POST /transfer HTTP/1.1
@@ -170,7 +161,6 @@ Content-Type: application/x-www-form-urlencoded
 
 amount=100.00&routingNumber=1234&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721
 ----
-====
 
 
 You will notice that the HTTP request now contains the `_csrf` parameter with a secure random value.
@@ -191,12 +181,10 @@ Spring Framework's https://docs.spring.io/spring-framework/docs/current/javadoc-
 An example, of an HTTP response header with the `SameSite` attribute might look like:
 
 .SameSite HTTP response
-====
 [source]
 ----
 Set-Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly; SameSite=Lax
 ----
-====
 
 Valid values for the `SameSite` attribute are:
 
@@ -245,7 +233,6 @@ However, you must be very careful, as there are CSRF exploits that can impact JS
 For example, a malicious user can create a http://blog.opensecurityresearch.com/2012/02/json-csrf-with-parameter-padding.html[CSRF with JSON by using the following form]:
 
 .CSRF with JSON form
-====
 [source,html]
 ----
 <form action="https://bank.example.com/transfer" method="post" enctype="text/plain">
@@ -254,13 +241,11 @@ For example, a malicious user can create a http://blog.opensecurityresearch.com/
 		value="Win Money!"/>
 </form>
 ----
-====
 
 
 This produces the following JSON structure
 
 .CSRF with JSON request
-====
 [source,javascript]
 ----
 { "amount": 100,
@@ -269,13 +254,11 @@ This produces the following JSON structure
 "ignore_me": "=test"
 }
 ----
-====
 
 If an application were not validating the `Content-Type` header, it would be exposed to this exploit.
 Depending on the setup, a Spring MVC application that validates the Content-Type could still be exploited by updating the URL suffix to end with `.json`, as follows:
 
 .CSRF with JSON Spring MVC form
-====
 [source,html]
 ----
 <form action="https://bank.example.com/transfer.json" method="post" enctype="text/plain">
@@ -284,7 +267,6 @@ Depending on the setup, a Spring MVC application that validates the Content-Type
 		value="Win Money!"/>
 </form>
 ----
-====
 
 [[csrf-when-stateless]]
 === CSRF and Stateless Browser Applications
@@ -394,7 +376,6 @@ Some applications can use a form parameter to override the HTTP method.
 For example, the following form can treat the HTTP method as a `delete` rather than a `post`.
 
 .CSRF Hidden HTTP Method Form
-====
 [source,html]
 ----
 <form action="/process"
@@ -405,7 +386,6 @@ For example, the following form can treat the HTTP method as a `delete` rather t
 		value="delete"/>
 </form>
 ----
-====
 
 
 Overriding the HTTP method occurs in a filter.

docs/modules/ROOT/pages/features/exploits/csrf.adoc

@@ -24,7 +24,6 @@ Spring Security provides a default set of security related HTTP response headers
 The default for Spring Security is to include the following headers:
 
 .Default Security HTTP Response Headers
-====
 [source,http]
 ----
 Cache-Control: no-cache, no-store, max-age=0, must-revalidate
@@ -35,7 +34,6 @@ Strict-Transport-Security: max-age=31536000 ; includeSubDomains
 X-Frame-Options: DENY
 X-XSS-Protection: 0
 ----
-====
 
 [NOTE]
 ====
@@ -65,14 +63,12 @@ If a user authenticates to view sensitive information and then logs out, we do n
 The cache control headers that are sent by default are:
 
 .Default Cache Control HTTP Response Headers
-====
 [source]
 ----
 Cache-Control: no-cache, no-store, max-age=0, must-revalidate
 Pragma: no-cache
 Expires: 0
 ----
-====
 
 To be secure by default, Spring Security adds these headers by default.
 However, if your application provides its own cache control headers, Spring Security backs out of the way.
@@ -105,12 +101,10 @@ A malicious user might create a http://webblaze.cs.berkeley.edu/papers/barth-cab
 By default, Spring Security disables content sniffing by adding the following header to HTTP responses:
 
 .nosniff HTTP Response Header
-====
 [source,http]
 ----
 X-Content-Type-Options: nosniff
 ----
-====
 
 [[headers-hsts]]
 == HTTP Strict Transport Security (HSTS)
@@ -140,12 +134,10 @@ For example, Spring Security's default behavior is to add the following header,
 
 
 .Strict Transport Security HTTP Response Header
-====
 [source]
 ----
 Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
 ----
-====
 
 The optional `includeSubDomains` directive instructs the browser that subdomains (such as `secure.mybank.example.com`) should also be treated as an HSTS domain.
 
@@ -193,12 +185,10 @@ While not perfect, the frame breaking code is the best you can do for the legacy
 A more modern approach to address clickjacking is to use https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options[X-Frame-Options] header.
 By default, Spring Security disables rendering pages within an iframe by using with the following header:
 
-====
 [source]
 ----
 X-Frame-Options: DENY
 ----
-====
 
 [[headers-xss-protection]]
 == X-XSS-Protection
@@ -213,12 +203,10 @@ The filter has been deprecated in major browsers, and https://cheatsheetseries.o
 
 By default, Spring Security blocks the content by using the following header:
 
-====
 [source]
 ----
 X-XSS-Protection: 0
 ----
-====
 
 
 [[headers-csp]]
@@ -250,25 +238,21 @@ A security policy contains a set of security policy directives, each responsible
 For example, a web application can declare that it expects to load scripts from specific, trusted sources by including the following header in the response:
 
 .Content Security Policy Example
-====
 [source]
 ----
 Content-Security-Policy: script-src https://trustedscripts.example.com
 ----
-====
 
 An attempt to load a script from another source other than what is declared in the `script-src` directive is blocked by the user-agent.
 Additionally, if the https://www.w3.org/TR/CSP2/#directive-report-uri[report-uri] directive is declared in the security policy, the violation will be reported by the user-agent to the declared URL.
 
 For example, if a web application violates the declared security policy, the following response header instructs the user-agent to send violation reports to the URL specified in the policy's `report-uri` directive.
 
 .Content Security Policy with report-uri
-====
 [source]
 ----
 Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/
 ----
-====
 
 https://www.w3.org/TR/CSP2/#violation-reports[Violation reports] are standard JSON structures that can be captured either by the web application's own API or by a publicly hosted CSP violation reporting service, such as https://report-uri.io/.
 
@@ -279,12 +263,10 @@ When a policy is deemed effective, it can be enforced by using the `Content-Secu
 Given the following response header, the policy declares that scripts can be loaded from one of two possible sources.
 
 .Content Security Policy Report Only
-====
 [source]
 ----
 Content-Security-Policy-Report-Only: script-src 'self' https://trustedscripts.example.com; report-uri /csp-report-endpoint/
 ----
-====
 
 If the site violates this policy, by attempting to load a script from `evil.example.com`, the user-agent sends a violation report to the declared URL specified by the `report-uri` directive but still lets the violating resource load.
 
@@ -311,12 +293,10 @@ page the user was on.
 Spring Security's approach is to use the https://www.w3.org/TR/referrer-policy/[Referrer Policy] header, which provides different https://www.w3.org/TR/referrer-policy/#referrer-policies[policies]:
 
 .Referrer Policy Example
-====
 [source]
 ----
 Referrer-Policy: same-origin
 ----
-====
 
 The Referrer-Policy response header instructs the browser to let the destination knows the source where the user was previously.
 
@@ -331,12 +311,10 @@ See the relevant sections to see how to configure both xref:servlet/exploits/hea
 https://wicg.github.io/feature-policy/[Feature Policy] is a mechanism that lets web developers to selectively enable, disable, and modify the behavior of certain APIs and web features in the browser.
 
 .Feature Policy Example
-====
 [source]
 ----
 Feature-Policy: geolocation 'self'
 ----
-====
 
 With Feature Policy, developers can opt-in to a set of "`policies`" for the browser to enforce on specific features used throughout your site.
 These policies restrict what APIs the site can access or modify the browser's default behavior for certain features.
@@ -353,12 +331,10 @@ See the relevant sections to see how to configure both xref:servlet/exploits/hea
 https://w3c.github.io/webappsec-permissions-policy/[Permissions Policy] is a mechanism that lets web developers selectively enable, disable, and modify the behavior of certain APIs and web features in the browser.
 
 .Permissions Policy Example
-====
 [source]
 ----
 Permissions-Policy: geolocation=(self)
 ----
-====
 
 With Permissions Policy, developers can opt-in to a set of "policies" for the browser to enforce on specific features used throughout your site.
 These policies restrict what APIs the site can access or modify the browser's default behavior for certain features.
@@ -374,12 +350,10 @@ See the relevant sections to see how to configure both xref:servlet/exploits/hea
 
 https://www.w3.org/TR/clear-site-data/[Clear Site Data] is a mechanism by which any browser-side data (cookies, local storage, and the like) can be removed when an HTTP response contains this header:
 
-====
 [source]
 ----
 Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"
 ----
-====
 
 This is a nice clean-up action to perform on logout.