On Jun 30, 2009, at 10:09 AM, Donald Woods wrote:
To catch XSS/XSRF attacks, the code is run as the first item in the filter chain before the web app's servlet is ever reached. The session has to be created before the request gets to the webapp, so we can register the session id and a unique value before a response is created to protect against the XSRF attacks.
Right. I don't have a problem with this...
Not sure why you are seeing a session get created for a non-existent URI, given the filter is registered in the web.xml and should have the same mappings applied to it. But, for the console, anything under the root context is accepted, as there could be any number of portlets registered (is this your scenario?) If so, I don't know if there is an easy way to change this behavior without major changes to how we use Pluto (like integrating the protection into Pluto) and we would still need the filter for the stand-alone webapps....
I don't know why we're creating a session either. But we're definitely running the XSSXSRFFilter for the following url -- localhost:8080/ nonexistenturl
Anybody interested in taking a look at this? --kevan
