You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/manual/src/docs/asciidoc/_includes/servlet/exploits/channel.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
[[ns-requires-channel]]
2
-
==HTTPS
2
+
= HTTPS
3
3
4
-
=== Adding HTTP/HTTPS Channel Security
4
+
== Adding HTTP/HTTPS Channel Security
5
5
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>`:
Copy file name to clipboardExpand all lines: docs/manual/src/docs/asciidoc/_includes/servlet/exploits/headers.adoc
+31-31Lines changed: 31 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,9 @@
1
1
[[headers]]
2
2
[[ns-headers]]
3
-
==Security HTTP Response Headers
3
+
= Security HTTP Response Headers
4
4
This section discusses Spring Security's support for adding various security headers to the response.
5
5
6
-
=== Default Security Headers
6
+
== Default Security Headers
7
7
Spring Security allows users to easily inject the default security headers to assist in protecting their application.
8
8
The default for Spring Security is to include the following headers:
9
9
@@ -157,7 +157,7 @@ If necessary, you can disable all of the HTTP Security response headers with the
157
157
----
158
158
159
159
[[headers-cache-control]]
160
-
=== Cache Control
160
+
== Cache Control
161
161
In the past Spring Security required you to provide your own cache control for your web application.
162
162
This seemed reasonable at the time, but browser caches have evolved to include caches for secure connections as well.
163
163
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 {
229
229
----
230
230
231
231
[[headers-content-type-options]]
232
-
=== Content Type Options
232
+
== Content Type Options
233
233
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].
234
234
This allowed browsers to improve the user experience by guessing the content type on resources that had not specified the content type.
235
235
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.
236
236
237
237
[NOTE]
238
-
====
238
+
===
239
239
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.
240
240
However, these measures are out of the scope of what Spring Security provides.
241
241
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
+
===
243
243
244
244
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.
245
245
For example, some sites may allow users to submit a valid postscript document to a website and view it.
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].
294
294
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).
295
295
@@ -298,10 +298,10 @@ Once mybank.example.com is added as a https://tools.ietf.org/html/rfc6797#sectio
298
298
This greatly reduces the possibility of a Man in the Middle attack occurring.
299
299
300
300
[NOTE]
301
-
====
301
+
===
302
302
In accordance with https://tools.ietf.org/html/rfc6797#section-7.2[RFC6797], the HSTS header is only injected into HTTPS responses.
303
303
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
+
===
305
305
306
306
One way for a site to be marked as a HSTS host is to have the host preloaded into the browser.
307
307
Another is to add the "Strict-Transport-Security" header to the response.
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.
364
364
365
365
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
372
372
If the server delivers an unknown public key, the client should present a warning to the user.
373
373
374
374
[NOTE]
375
-
====
375
+
===
376
376
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
+
===
378
378
379
379
Enabling this feature for your site is as simple as returning the Public-Key-Pins HTTP header when your site is accessed over HTTPS.
380
380
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:
Allowing your website to be added to a frame can be a security issue.
440
440
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]).
441
441
For example, a user that is logged into their bank might click a button that grants access to other users.
442
442
This sort of attack is known as https://en.wikipedia.org/wiki/Clickjacking[Clickjacking].
443
443
444
444
[NOTE]
445
-
====
445
+
===
446
446
Another modern approach to dealing with clickjacking is to use <<headers-csp>>.
447
-
====
447
+
===
448
448
449
449
There are a number ways to mitigate clickjacking attacks.
450
450
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].
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].
504
504
This is by no means foolproof, but does assist in XSS protection.
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).
559
559
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.
560
560
561
561
[NOTE]
562
-
====
562
+
===
563
563
Content Security Policy is not intended to solve all content injection vulnerabilities.
564
564
Instead, CSP can be leveraged to help reduce the harm caused by content injection attacks.
565
565
As a first line of defense, web application authors should validate their input and encode their output.
566
-
====
566
+
===
567
567
568
568
A web application may employ the use of CSP by including one of the following HTTP headers in the response:
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.
607
607
608
608
[[headers-csp-configure]]
609
-
==== Configuring Content Security Policy
609
+
=== Configuring Content Security Policy
610
610
611
611
It's important to note that Spring Security *_does not add_* Content Security Policy by default.
612
612
The web application author must declare the security policy(s) to enforce and/or monitor for the protected resources.
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
713
713
page the user was on.
@@ -722,7 +722,7 @@ Referrer-Policy: same-origin
722
722
The Referrer-Policy response header instructs the browser to let the destination knows the source where the user was previously.
723
723
724
724
[[headers-referrer-configure]]
725
-
==== Configuring Referrer Policy
725
+
=== Configuring Referrer Policy
726
726
727
727
Spring Security *_doesn't add_* Referrer Policy header by default.
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.
770
770
@@ -777,7 +777,7 @@ With Feature Policy, developers can opt-in to a set of "policies" for the browse
777
777
These policies restrict what APIs the site can access or modify the browser's default behavior for certain features.
778
778
779
779
[[headers-feature-configure]]
780
-
==== Configuring Feature Policy
780
+
=== Configuring Feature Policy
781
781
782
782
Spring Security *_doesn't add_* Feature Policy header by default.
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:
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`.
907
907
908
908
Let's take a look at an example of using an custom instance of `XFrameOptionsHeaderWriter`.
0 commit comments