All,
I'm having an issue where a URL which already contains a CSRF token is
having another one added. This happens, for example, when redirecting a
user to a URL which came from the HTTP Referer header.
It also happens when I use my application framework to build URLs in
complex ways.
I wrote this short test to demonstrate:
@Test
public void testMultipleTokens() {
String nonce = "TESTNONCE";
String testURL = "/foo/bar?" +
Constants.CSRF_NONCE_SESSION_ATTR_NAME + "=sample";
CsrfPreventionFilter.CsrfResponseWrapper response = new
CsrfPreventionFilter.CsrfResponseWrapper(new NonEncodingResponse(),
Constants.CSRF_NONCE_SESSION_ATTR_NAME, nonce, null);
Assert.assertTrue("Original URL does not contain CSRF token",
testURL.contains(Constants.CSRF_NONCE_SESSION_ATTR_NAME));
String result = response.encodeURL(testURL);
int pos = result.indexOf(Constants.CSRF_NONCE_SESSION_ATTR_NAME);
Assert.assertTrue("Result URL does not contain CSRF token",
pos >= 0);
pos = result.indexOf(Constants.CSRF_NONCE_SESSION_ATTR_NAME,
pos + 1);
Assert.assertFalse("Result URL contains multiple CSRF tokens: "
+ result,
pos >= 0);
}
This fails with this somewhat expected message:
junit.framework.AssertionFailedError: Result URL contains multiple CSRF
tokens:
/foo/bar?org.apache.catalina.filters.CSRF_NONCE=sample&org.apache.catalina.filters.CSRF_NONCE=TESTNONCE
I wrote another test where the URL is passed-through the encodeURL()
method once where the original URL already contained the exact same CSRF
token.
I tested encoding of the session identifier in the URL and it behaves
the same way: calling encodeURL twice gets you two ";jsessionid=abc"
tokens in the resulting URL. I never noticed because cookie-based
session tracking is almost always being used.
I'm curious about the expectations, here. If a URL ends up being
passed-through HttpServletResponse.encodeURL() more than once, is that
an application bug or should the container take steps to avoid adding
the same information to the URL multiple times?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
