parent
5bfc6ea25a
commit
48aa5cceda
|
@ -310,7 +310,7 @@ There are a few special considerations to consider when implementing protection
|
|||
|
||||
In order to protect against https://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests[forging log in requests] the log in HTTP request should be protected against CSRF attacks.
|
||||
Protecting against forging log in requests is necessary so that a malicious user cannot read a victim's sensitive information.
|
||||
The attack is executed by:
|
||||
The attack is performed as follows:
|
||||
|
||||
* A malicious user performs a CSRF log in using the malicious user's credentials.
|
||||
The victim is now authenticated as the malicious user.
|
||||
|
@ -346,10 +346,10 @@ The user can click a button to continue and refresh the session.
|
|||
This allows the expected CSRF token to outlive the session.
|
||||
+
|
||||
One might ask why the expected CSRF token isn't stored in a cookie by default.
|
||||
This is because there are known exploits in which headers (i.e. specify the cookies) can be set by another domain.
|
||||
This is because there are known exploits in which headers (for example, to specify the cookies) can be set by another domain.
|
||||
This is the same reason Ruby on Rails https://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails/[no longer skips CSRF checks when the header X-Requested-With is present].
|
||||
See http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html[this webappsec.org thread] for details on how to perform the exploit.
|
||||
Another disadvantage is that by removing the state (i.e. the timeout) you lose the ability to forcibly terminate the token if it is compromised.
|
||||
Another disadvantage is that by removing the state (that is, the timeout), you lose the ability to forcibly invalidate the token if it is compromised.
|
||||
|
||||
// FIXME: Document timeout with lengthy form expire. We do not want to automatically replay that request because it can lead to exploit
|
||||
|
||||
|
|
|
@ -86,7 +86,7 @@ Refer to the relevant sections to see how to customize the defaults for both <<s
|
|||
|
||||
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].
|
||||
This allowed browsers to improve the user experience by guessing the content type on resources that had not specified the content type.
|
||||
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.
|
||||
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 run it.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
@ -95,9 +95,9 @@ However, these measures are out of the scope of what Spring Security provides.
|
|||
It is also important to point out when disabling content sniffing, you must specify the content type in order for things to work properly.
|
||||
====
|
||||
|
||||
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.
|
||||
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 perform XSS attacks.
|
||||
For example, some sites may allow users to submit a valid postscript document to a website and view it.
|
||||
A malicious user might create a http://webblaze.cs.berkeley.edu/papers/barth-caballero-song.pdf[postscript document that is also a valid JavaScript file] and execute a XSS attack with it.
|
||||
A malicious user might create a http://webblaze.cs.berkeley.edu/papers/barth-caballero-song.pdf[postscript document that is also a valid JavaScript file] and perform a XSS attack with it.
|
||||
|
||||
Spring Security disables content sniffing by default by adding the following header to HTTP responses:
|
||||
|
||||
|
|
|
@ -2584,8 +2584,8 @@ Access configuration attributes list that applies to all methods matching the po
|
|||
|
||||
[[nsa-protect-pointcut-expression]]
|
||||
* **expression**
|
||||
An AspectJ expression, including the 'execution' keyword.
|
||||
For example, 'execution(int com.foo.TargetObject.countLength(String))' (without the quotes).
|
||||
An AspectJ expression, including the `execution` keyword.
|
||||
For example, `execution(int com.foo.TargetObject.countLength(String))`.
|
||||
|
||||
|
||||
[[nsa-intercept-methods]]
|
||||
|
|
|
@ -74,7 +74,7 @@ val authorities = authentication.authorities
|
|||
|
||||
// FIXME: add links to HttpServletRequest.getRemoteUser() and @CurrentSecurityContext @AuthenticationPrincipal
|
||||
|
||||
By default the `SecurityContextHolder` uses a `ThreadLocal` to store these details, which means that the `SecurityContext` is always available to methods in the same thread of execution, even if the `SecurityContext` is not explicitly passed around as an argument to those methods.
|
||||
By default the `SecurityContextHolder` uses a `ThreadLocal` to store these details, which means that the `SecurityContext` is always available to methods in the same thread, even if the `SecurityContext` is not explicitly passed around as an argument to those methods.
|
||||
Using a `ThreadLocal` in this way is quite safe if care is taken to clear the thread after the present principal's request is processed.
|
||||
Spring Security's <<servlet-filterchainproxy,FilterChainProxy>> ensures that the `SecurityContext` is always cleared.
|
||||
|
||||
|
|
|
@ -222,7 +222,7 @@ Below are updates to the Spring Security configuration that handle Single Logout
|
|||
</bean>
|
||||
----
|
||||
|
||||
The `logout` element logs the user out of the local application, but does not terminate the session with the CAS server or any other applications that have been logged into.
|
||||
The `logout` element logs the user out of the local application, but does not end the session with the CAS server or any other applications that have been logged into.
|
||||
The `requestSingleLogoutFilter` filter will allow the URL of `/spring_security_cas_logout` to be requested to redirect the application to the configured CAS Server logout URL.
|
||||
Then the CAS Server will send a Single Logout request to all the services that were signed into.
|
||||
The `singleLogoutFilter` handles the Single Logout request by looking up the `HttpSession` in a static `Map` and then invalidating it.
|
||||
|
|
|
@ -246,7 +246,7 @@ class="org.springframework.security.web.session.ConcurrentSessionFilter">
|
|||
|
||||
|
||||
|
||||
Adding the listener to `web.xml` causes an `ApplicationEvent` to be published to the Spring `ApplicationContext` every time a `HttpSession` commences or terminates.
|
||||
Adding the listener to `web.xml` causes an `ApplicationEvent` to be published to the Spring `ApplicationContext` every time a `HttpSession` commences or ends.
|
||||
This is critical, as it allows the `SessionRegistryImpl` to be notified when a session ends.
|
||||
Without it, a user will never be able to log back in again once they have exceeded their session allowance, even if they log out of another session or it times out.
|
||||
|
||||
|
|
|
@ -133,8 +133,8 @@ executor.execute(originalRunnable);
|
|||
}
|
||||
----
|
||||
|
||||
Now our code is unaware that the `SecurityContext` is being propagated to the `Thread`, then the `originalRunnable` is executed, and then the `SecurityContextHolder` is cleared out.
|
||||
In this example, the same user is being used to execute each Thread.
|
||||
Now our code is unaware that the `SecurityContext` is being propagated to the `Thread`, then the `originalRunnable` is run, and then the `SecurityContextHolder` is cleared out.
|
||||
In this example, the same user is being used to run each thread.
|
||||
What if we wanted to use the user from `SecurityContextHolder` at the time we invoked `executor.execute(Runnable)` (i.e. the currently logged in user) to process ``originalRunnable``?
|
||||
This can be done by removing the `SecurityContext` argument from our `DelegatingSecurityContextExecutor` constructor.
|
||||
For example:
|
||||
|
@ -148,19 +148,19 @@ DelegatingSecurityContextExecutor executor =
|
|||
----
|
||||
|
||||
Now anytime `executor.execute(Runnable)` is executed the `SecurityContext` is first obtained by the `SecurityContextHolder` and then that `SecurityContext` is used to create our `DelegatingSecurityContextRunnable`.
|
||||
This means that we are executing our `Runnable` with the same user that was used to invoke the `executor.execute(Runnable)` code.
|
||||
This means that we are running our `Runnable` with the same user that was used to invoke the `executor.execute(Runnable)` code.
|
||||
|
||||
=== Spring Security Concurrency Classes
|
||||
|
||||
Refer to the Javadoc for additional integrations with both the Java concurrent APIs and the Spring Task abstractions.
|
||||
They are quite self-explanatory once you understand the previous code.
|
||||
|
||||
* DelegatingSecurityContextCallable
|
||||
* DelegatingSecurityContextExecutor
|
||||
* DelegatingSecurityContextExecutorService
|
||||
* DelegatingSecurityContextRunnable
|
||||
* DelegatingSecurityContextScheduledExecutorService
|
||||
* DelegatingSecurityContextSchedulingTaskExecutor
|
||||
* DelegatingSecurityContextAsyncTaskExecutor
|
||||
* DelegatingSecurityContextTaskExecutor
|
||||
* DelegatingSecurityContextTaskScheduler
|
||||
* `DelegatingSecurityContextCallable`
|
||||
* `DelegatingSecurityContextExecutor`
|
||||
* `DelegatingSecurityContextExecutorService`
|
||||
* `DelegatingSecurityContextRunnable`
|
||||
* `DelegatingSecurityContextScheduledExecutorService`
|
||||
* `DelegatingSecurityContextSchedulingTaskExecutor`
|
||||
* `DelegatingSecurityContextAsyncTaskExecutor`
|
||||
* `DelegatingSecurityContextTaskExecutor`
|
||||
* `DelegatingSecurityContextTaskScheduler`
|
||||
|
|
|
@ -277,8 +277,8 @@ public ModelAndView findMessagesForUser(@CurrentUser CustomUser customUser) {
|
|||
=== Spring MVC Async Integration
|
||||
|
||||
Spring Web MVC 3.2+ has excellent support for https://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-ann-async[Asynchronous Request Processing].
|
||||
With no additional configuration, Spring Security will automatically setup the `SecurityContext` to the `Thread` that executes a `Callable` returned by your controllers.
|
||||
For example, the following method will automatically have its `Callable` executed with the `SecurityContext` that was available when the `Callable` was created:
|
||||
With no additional configuration, Spring Security will automatically setup the `SecurityContext` to the `Thread` that invokes a `Callable` returned by your controllers.
|
||||
For example, the following method will automatically have its `Callable` invoked with the `SecurityContext` that was available when the `Callable` was created:
|
||||
|
||||
[source,java]
|
||||
----
|
||||
|
|
|
@ -51,8 +51,8 @@ the IDP sends an assertion to the SP.
|
|||
3. Requires the assertion to be signed, unless the response is signed
|
||||
4. Supports encrypted assertions
|
||||
5. Supports encrypted NameId elements
|
||||
6. Allows for extraction of assertion attributes into authorities using a `Converter<Assertion, Collection<? extends GrantedAuthority>>`
|
||||
7. Allows mapping and white listing of authorities using a `GrantedAuthoritiesMapper`
|
||||
6. Allows for extraction of assertion attributes into authorities by using a `Converter<Assertion, Collection<? extends GrantedAuthority>>`
|
||||
7. Allows mapping and approved access listing for authorities by using a `GrantedAuthoritiesMapper`
|
||||
8. Public keys in `java.security.cert.X509Certificate` format.
|
||||
9. SP Initiated Authentication via an `AuthNRequest`
|
||||
|
||||
|
@ -472,5 +472,3 @@ If we change our local SP entity ID to this value, it is still important that we
|
|||
out the correct single sign on URL (the assertion consumer service URL)
|
||||
for each registered identity provider based on the registration Id.
|
||||
`+{baseUrl}/login/saml2/sso/{registrationId}+`
|
||||
|
||||
|
||||
|
|
|
@ -208,7 +208,7 @@ public void getMessageWithUserDetails() {
|
|||
----
|
||||
|
||||
We can also customize the username used to lookup the user from our `UserDetailsService`.
|
||||
For example, this test would be executed with a principal that is returned from the `UserDetailsService` with the username of "customUsername".
|
||||
For example, this test would be run with a principal that is returned from the `UserDetailsService` with the username of "customUsername".
|
||||
|
||||
[source,java]
|
||||
----
|
||||
|
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
[[test-mockmvc]]
|
||||
== Spring MVC Test Integration
|
||||
|
||||
|
@ -140,7 +139,7 @@ mvc
|
|||
.perform(get("/").with(anonymous()))
|
||||
----
|
||||
|
||||
This is especially useful if you are running with a default user and wish to execute a few requests as an anonymous user.
|
||||
This is especially useful if you are running with a default user and wish to process a few requests as an anonymous user.
|
||||
|
||||
If you want a custom `Authentication` (which does not need to exist) you can do so using the following:
|
||||
|
||||
|
|
Loading…
Reference in New Issue