From 3e95f1c12e78d3b809d8ef342a8001bf77c57409 Mon Sep 17 00:00:00 2001 From: Rob Winch Date: Fri, 27 Sep 2013 16:41:06 -0500 Subject: [PATCH] SEC-2282: Polish CSRF Documentation --- docs/manual/src/docbook/csrf.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/manual/src/docbook/csrf.xml b/docs/manual/src/docbook/csrf.xml index 894a96593f..2daeebf28f 100644 --- a/docs/manual/src/docbook/csrf.xml +++ b/docs/manual/src/docbook/csrf.xml @@ -222,11 +222,11 @@ public class WebSecurityConfig extends AccessDeniedHandler, the browser will get an HTTP 403 and display a poor error message. One might ask why the expected CsrfToken isn't stored in a cookie. This is because there are known exploits in which headers - (i.e. specify the cookies) can be set by another domain. Another disadvantage is that by removing the state (i.e. the timeout) you lose the ability - to forcibly terminate the token if something got compromised. This is the same reason Ruby on Rails + (i.e. specify the cookies) can be set by another domain. This is the same reason Ruby on Rails no longer skips CSRF checks when the header X-Requested-With is present. See this webappsec.org thread - for details on how to perform the exploit. + 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 something got compromised. A simple way to mitigate an active user experiencing a timeout is to have some JavaScript that lets the user know their session is about to expire. The user can click a button to continue and refresh the session.