Merge branch '5.6.x' into 5.7.x

Closes gh-13404

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 the actual CSRF token is required to be in an HTTP parameter named `_csrf
 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, 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 JSO
 For example, a malicious user can create a http://blog.opensecurityresearch.com/2012/02/json-csrf-with-parameter-padding.html[CSRF with JSON 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 will produce the following JSON structure
 
 .CSRF with JSON request
-====
 [source,javascript]
 ----
 { "amount": 100,
@@ -269,13 +254,11 @@ This will produce the following JSON structure
 "ignore_me": "=test"
 }
 ----
-====
 
 If an application were not validating the Content-Type, then 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 shown below:
 
 .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
@@ -393,7 +375,6 @@ In some applications a form parameter can be used to override the HTTP method.
 For example, the form below could be used to treat the HTTP method as a `delete` rather than a `post`.
 
 .CSRF Hidden HTTP Method Form
-====
 [source,html]
 ----
 <form action="/process"
@@ -404,7 +385,6 @@ For example, the form below could be used to treat the HTTP method as a `delete`
 		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: 1; mode=block
 ----
-====
 
 NOTE: Strict-Transport-Security is only added on HTTPS requests
 
@@ -62,14 +60,12 @@ If a user authenticates to view sensitive information and then logs out, we don'
 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
 ----
-====
 
 In order to be secure by default, Spring Security adds these headers by default.
 However, if your application provides its own cache control headers Spring Security will back out of the way.
@@ -102,12 +98,10 @@ A malicious user might create a http://webblaze.cs.berkeley.edu/papers/barth-cab
 Spring Security disables content sniffing by default 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)
@@ -137,12 +131,10 @@ For example, Spring Security's default behavior is to add the following header w
 
 
 .Strict Transport Security HTTP Response Header
-====
 [source]
 ----
 Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
 ----
-====
 
 The optional `includeSubDomains` directive instructs the browser that subdomains (e.g. secure.mybank.example.com) should also be treated as an HSTS domain.
 
@@ -247,25 +239,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 will be 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, then 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 will instruct 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.com/.
 
@@ -276,12 +264,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 may 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.com_, the user-agent will send a violation report to the declared URL specified by the _report-uri_ directive, but still allow the violating resource to load nevertheless.
 
@@ -308,12 +294,10 @@ page the user was on.
 Spring Security's approach is to use 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.
 
@@ -328,12 +312,10 @@ Refer to the relevant sections to see how to configure both xref:servlet/exploit
 https://wicg.github.io/feature-policy/[Feature Policy] is a mechanism that allows 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.
@@ -350,12 +332,10 @@ Refer to the relevant sections to see how to configure both xref:servlet/exploit
 https://w3c.github.io/webappsec-permissions-policy/[Permissions Policy] is a mechanism that allows web developers to 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.