Skip to content

Commit badb0a0

Browse files
committed
Fix exploits indendation
Issue gh-2567
1 parent 2827af1 commit badb0a0

File tree

2 files changed

+33
-33
lines changed

2 files changed

+33
-33
lines changed

docs/manual/src/docs/asciidoc/_includes/servlet/exploits/channel.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
[[ns-requires-channel]]
2-
== HTTPS
2+
= HTTPS
33

4-
=== Adding HTTP/HTTPS Channel Security
4+
== Adding HTTP/HTTPS Channel Security
55
If your application supports both HTTP and HTTPS, and you require that particular URLs can only be accessed over HTTPS, then this is directly supported using the `requires-channel` attribute on `<intercept-url>`:
66

77
[source,xml]

docs/manual/src/docs/asciidoc/_includes/servlet/exploits/headers.adoc

Lines changed: 31 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11
[[headers]]
22
[[ns-headers]]
3-
== Security HTTP Response Headers
3+
= Security HTTP Response Headers
44
This section discusses Spring Security's support for adding various security headers to the response.
55

6-
=== Default Security Headers
6+
== Default Security Headers
77
Spring Security allows users to easily inject the default security headers to assist in protecting their application.
88
The default for Spring Security is to include the following headers:
99

@@ -157,7 +157,7 @@ If necessary, you can disable all of the HTTP Security response headers with the
157157
----
158158

159159
[[headers-cache-control]]
160-
=== Cache Control
160+
== Cache Control
161161
In the past Spring Security required you to provide your own cache control for your web application.
162162
This seemed reasonable at the time, but browser caches have evolved to include caches for secure connections as well.
163163
This means that a user may view an authenticated page, log out, and then a malicious user can use the browser history to view the cached page.
@@ -229,17 +229,17 @@ public class WebMvcConfiguration implements WebMvcConfigurer {
229229
----
230230

231231
[[headers-content-type-options]]
232-
=== Content Type Options
232+
== Content Type Options
233233
Historically browsers, including Internet Explorer, would try to guess the content type of a request using https://en.wikipedia.org/wiki/Content_sniffing[content sniffing].
234234
This allowed browsers to improve the user experience by guessing the content type on resources that had not specified the content type.
235235
For example, if a browser encountered a JavaScript file that did not have the content type specified, it would be able to guess the content type and then execute it.
236236

237237
[NOTE]
238-
====
238+
===
239239
There are many additional things one should do (i.e. only display the document in a distinct domain, ensure Content-Type header is set, sanitize the document, etc) when allowing content to be uploaded.
240240
However, these measures are out of the scope of what Spring Security provides.
241241
It is also important to point out when disabling content sniffing, you must specify the content type in order for things to work properly.
242-
====
242+
===
243243

244244
The problem with content sniffing is that this allowed malicious users to use polyglots (i.e. a file that is valid as multiple content types) to execute XSS attacks.
245245
For example, some sites may allow users to submit a valid postscript document to a website and view it.
@@ -289,7 +289,7 @@ WebSecurityConfigurerAdapter {
289289
----
290290

291291
[[headers-hsts]]
292-
=== HTTP Strict Transport Security (HSTS)
292+
== HTTP Strict Transport Security (HSTS)
293293
When you type in your bank's website, do you enter mybank.example.com or do you enter https://mybank.example.com[]? If you omit the https protocol, you are potentially vulnerable to https://en.wikipedia.org/wiki/Man-in-the-middle_attack[Man in the Middle attacks].
294294
Even if the website performs a redirect to https://mybank.example.com a malicious user could intercept the initial HTTP request and manipulate the response (i.e. redirect to https://mibank.example.com and steal their credentials).
295295

@@ -298,10 +298,10 @@ Once mybank.example.com is added as a https://tools.ietf.org/html/rfc6797#sectio
298298
This greatly reduces the possibility of a Man in the Middle attack occurring.
299299

300300
[NOTE]
301-
====
301+
===
302302
In accordance with https://tools.ietf.org/html/rfc6797#section-7.2[RFC6797], the HSTS header is only injected into HTTPS responses.
303303
In order for the browser to acknowledge the header, the browser must first trust the CA that signed the SSL certificate used to make the connection (not just the SSL certificate).
304-
====
304+
===
305305

306306
One way for a site to be marked as a HSTS host is to have the host preloaded into the browser.
307307
Another is to add the "Strict-Transport-Security" header to the response.
@@ -359,7 +359,7 @@ WebSecurityConfigurerAdapter {
359359
----
360360

361361
[[headers-hpkp]]
362-
=== HTTP Public Key Pinning (HPKP)
362+
== HTTP Public Key Pinning (HPKP)
363363
HTTP Public Key Pinning (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to prevent Man in the Middle (MITM) attacks with forged certificates.
364364

365365
To ensure the authenticity of a server's public key used in TLS sessions, this public key is wrapped into a X.509 certificate which is usually signed by a certificate authority (CA).
@@ -372,9 +372,9 @@ When the client visits the server again, it expects a certificate containing a p
372372
If the server delivers an unknown public key, the client should present a warning to the user.
373373

374374
[NOTE]
375-
====
375+
===
376376
Because the user-agent needs to validate the pins against the SSL certificate chain, the HPKP header is only injected into HTTPS responses.
377-
====
377+
===
378378

379379
Enabling this feature for your site is as simple as returning the Public-Key-Pins HTTP header when your site is accessed over HTTPS.
380380
For example, the following would instruct the user-agent to only report pin validation failures to a given URI (via the https://tools.ietf.org/html/rfc7469#section-2.1.4[*_report-uri_*] directive) for 2 pins:
@@ -435,16 +435,16 @@ WebSecurityConfigurerAdapter {
435435
----
436436

437437
[[headers-frame-options]]
438-
=== X-Frame-Options
438+
== X-Frame-Options
439439
Allowing your website to be added to a frame can be a security issue.
440440
For example, using clever CSS styling users could be tricked into clicking on something that they were not intending (https://www.youtube.com/watch?v=3mk0RySeNsU[video demo]).
441441
For example, a user that is logged into their bank might click a button that grants access to other users.
442442
This sort of attack is known as https://en.wikipedia.org/wiki/Clickjacking[Clickjacking].
443443

444444
[NOTE]
445-
====
445+
===
446446
Another modern approach to dealing with clickjacking is to use <<headers-csp>>.
447-
====
447+
===
448448

449449
There are a number ways to mitigate clickjacking attacks.
450450
For example, to protect legacy browsers from clickjacking attacks you can use https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Best-for-now_Legacy_Browser_Frame_Breaking_Script[frame breaking code].
@@ -499,7 +499,7 @@ WebSecurityConfigurerAdapter {
499499
----
500500

501501
[[headers-xss-protection]]
502-
=== X-XSS-Protection
502+
== X-XSS-Protection
503503
Some browsers have built in support for filtering out https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)[reflected XSS attacks].
504504
This is by no means foolproof, but does assist in XSS protection.
505505

@@ -553,17 +553,17 @@ WebSecurityConfigurerAdapter {
553553
----
554554

555555
[[headers-csp]]
556-
=== Content Security Policy (CSP)
556+
== Content Security Policy (CSP)
557557

558558
https://www.w3.org/TR/CSP2/[Content Security Policy (CSP)] is a mechanism that web applications can leverage to mitigate content injection vulnerabilities, such as cross-site scripting (XSS).
559559
CSP is a declarative policy that provides a facility for web application authors to declare and ultimately inform the client (user-agent) about the sources from which the web application expects to load resources.
560560

561561
[NOTE]
562-
====
562+
===
563563
Content Security Policy is not intended to solve all content injection vulnerabilities.
564564
Instead, CSP can be leveraged to help reduce the harm caused by content injection attacks.
565565
As a first line of defense, web application authors should validate their input and encode their output.
566-
====
566+
===
567567

568568
A web application may employ the use of CSP by including one of the following HTTP headers in the response:
569569

@@ -606,7 +606,7 @@ Content-Security-Policy-Report-Only: script-src 'self' https://trustedscripts.ex
606606
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.
607607

608608
[[headers-csp-configure]]
609-
==== Configuring Content Security Policy
609+
=== Configuring Content Security Policy
610610

611611
It's important to note that Spring Security *_does not add_* Content Security Policy by default.
612612
The web application author must declare the security policy(s) to enforce and/or monitor for the protected resources.
@@ -695,7 +695,7 @@ WebSecurityConfigurerAdapter {
695695
----
696696

697697
[[headers-csp-links]]
698-
==== Additional Resources
698+
=== Additional Resources
699699

700700
Applying Content Security Policy to a web application is often a non-trivial undertaking.
701701
The following resources may provide further assistance in developing effective security policies for your site.
@@ -707,7 +707,7 @@ https://developer.mozilla.org/en-US/docs/Web/Security/CSP[CSP Guide - Mozilla De
707707
https://www.w3.org/TR/CSP2/[W3C Candidate Recommendation]
708708

709709
[[headers-referrer]]
710-
=== Referrer Policy
710+
== Referrer Policy
711711

712712
https://www.w3.org/TR/referrer-policy[Referrer Policy] is a mechanism that web applications can leverage to manage the referrer field, which contains the last
713713
page the user was on.
@@ -722,7 +722,7 @@ Referrer-Policy: same-origin
722722
The Referrer-Policy response header instructs the browser to let the destination knows the source where the user was previously.
723723

724724
[[headers-referrer-configure]]
725-
==== Configuring Referrer Policy
725+
=== Configuring Referrer Policy
726726

727727
Spring Security *_doesn't add_* Referrer Policy header by default.
728728

@@ -764,7 +764,7 @@ WebSecurityConfigurerAdapter {
764764

765765

766766
[[headers-feature]]
767-
=== Feature Policy
767+
== Feature Policy
768768

769769
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.
770770

@@ -777,7 +777,7 @@ With Feature Policy, developers can opt-in to a set of "policies" for the browse
777777
These policies restrict what APIs the site can access or modify the browser's default behavior for certain features.
778778

779779
[[headers-feature-configure]]
780-
==== Configuring Feature Policy
780+
=== Configuring Feature Policy
781781

782782
Spring Security *_doesn't add_* Feature Policy header by default.
783783

@@ -815,7 +815,7 @@ WebSecurityConfigurerAdapter {
815815
----
816816

817817
[[headers-clearsitedata]]
818-
=== Clear Site Data
818+
== Clear Site Data
819819

820820
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:
821821

@@ -827,7 +827,7 @@ Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"
827827
This is a nice clean-up action to perform on logout.
828828

829829
[[headers-clearsitedata-configure]]
830-
==== Configuring Clear Site Data
830+
=== Configuring Clear Site Data
831831

832832
Spring Security *_doesn't add_* the Clear Site Data header by default.
833833

@@ -854,12 +854,12 @@ It's not recommended that you configure this header writer via the `headers()` d
854854
The reason for this is that any session state, say the `JSESSIONID` cookie, would be removed, effectively logging the user out.
855855

856856
[[headers-custom]]
857-
=== Custom Headers
857+
== Custom Headers
858858
Spring Security has mechanisms to make it convenient to add the more common security headers to your application.
859859
However, it also provides hooks to enable adding custom headers.
860860

861861
[[headers-static]]
862-
==== Static Headers
862+
=== Static Headers
863863
There may be times you wish to inject custom security headers into your application that are not supported out of the box.
864864
For example, given the following custom security header:
865865

@@ -902,7 +902,7 @@ WebSecurityConfigurerAdapter {
902902
----
903903

904904
[[headers-writer]]
905-
==== Headers Writer
905+
=== Headers Writer
906906
When the namespace or Java configuration does not support the headers you want, you can create a custom `HeadersWriter` instance or even provide a custom implementation of the `HeadersWriter`.
907907

908908
Let's take a look at an example of using an custom instance of `XFrameOptionsHeaderWriter`.
@@ -951,7 +951,7 @@ WebSecurityConfigurerAdapter {
951951

952952

953953
[[headers-delegatingrequestmatcherheaderwriter]]
954-
==== DelegatingRequestMatcherHeaderWriter
954+
=== DelegatingRequestMatcherHeaderWriter
955955
At times you may want to only write a header for certain requests.
956956
For example, perhaps you want to only protect your log in page from being framed.
957957
You could use the `DelegatingRequestMatcherHeaderWriter` to do so.

0 commit comments

Comments
 (0)