From 28dabf9c0685ecbae9b4cb643637b3694c45a48a Mon Sep 17 00:00:00 2001 From: Luke Taylor Date: Sat, 12 Apr 2008 16:51:10 +0000 Subject: [PATCH] SEC-653: added info on session fixation --- src/docbkx/namespace-config.xml | 60 ++++++++++++++++++++++----------- 1 file changed, 41 insertions(+), 19 deletions(-) diff --git a/src/docbkx/namespace-config.xml b/src/docbkx/namespace-config.xml index f6c109415b..45715f6484 100644 --- a/src/docbkx/namespace-config.xml +++ b/src/docbkx/namespace-config.xml @@ -161,12 +161,11 @@ ]]> Which says that we want all URLs within our application to be secured, requiring the role - ROLE_USER - to access them. - You can use multiple <intercept-url> elements to define + ROLE_USER to access them. + You can use multiple <intercept-url> elements to define different access requirements for different sets of URLs, but they will be evaluated in the order listed and the first match will be used. So you must put the most specific matches at the top. - + To add some users, you can define a set of test data directly in the namespace: This defines two users, their passwords and their roles within the application (which will - be used for access control). - - If you are familiar with previous versions of the framework, you can probably - already guess roughly what's going on here. The <http> element is - responsible for creating a FilterChainProxy and the - filter beans which it uses. Common issues like incorrect filter ordering are no - longer an issue as the filter positions are predefined. - The <authentication-provider> - element creates a DaoAuthenticationProvider - bean and the <user-service> element creates an - InMemoryDaoImpl. A ProviderManager - bean is always created by the namespace processing system and the - AuthenticationProvider - is automatically registered with it. - + be used for access control). It is also possible to load user information from + a standard properties file using the properties attribute on + user-service. The <authentication-provider> element specifies that the user information will be registered with the authentication manager and used to process authentication requests. + + If you are familiar with previous versions of the framework, you can probably + already guess roughly what's going on here. The <http> element is + responsible for creating a FilterChainProxy and the + filter beans which it uses. Common issues like incorrect filter ordering are no + longer an issue as the filter positions are predefined. + The <authentication-provider> + element creates a DaoAuthenticationProvider + bean and the <user-service> element creates an + InMemoryDaoImpl. A ProviderManager + bean is always created by the namespace processing system and the + AuthenticationProvider + is automatically registered with it. + At this point you should be able to start up your application and you will be required to log in to proceed. Try it out, or try experimenting with the "tutorial" sample application @@ -451,6 +452,27 @@ that you want your filter to appear before or after the entire stack, respectively. + +
+ Session Fixation Attack Protection + + Session fixation + attacks are a potential risk where it is possible for a malicious attacker to create + a session by accessing a site, then persuade another user to log in with the same session + (by sending them a link containing the session identifier as a parameter, for example). Spring Security + protects against this automatically by creating a new session when a user logs in. If you don't require + this protection, or it conflicts with some other requirement, you can control the behaviour using the + session-fixation-protection attribute on <http>, which + has three options + + migrateSession - creates a new session and copies the existing + session attributes to the new session. This is the default. + none - Don't do anything. The original session will be retained. + newSession - Create a new "clean" session, without copying the existing session data. + + +
+