geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: Session creation triggered by XSS/XSRF filter
Date Tue, 30 Jun 2009 14:09:58 GMT
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.

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....


-Donald


Kevan Miller wrote:
> I was investigating a problem and happened to notice that our XSS/XSRF 
> filters are triggering the creation of Session objects. I then noticed 
> that they are creating a session when I hit an arbitrary url (I'm 
> expecting a 404). This is plain wrong, IMO. This was on 2.1.4, but I 
> would assume that 2.2 has the same behavior.
> 
> http-0.0.0.0-8080-1@10 daemon, priority=5, in group 'main', status: 
> 'RUNNING'
>       at 
> org.apache.catalina.session.StandardManager.createSession(StandardManager.java:284) 
> 
>       at 
> org.apache.catalina.connector.Request.doGetSession(Request.java:2,312)
>       at 
> org.apache.catalina.connector.Request.getSession(Request.java:2,075)
>       at 
> org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) 
> 
>       at 
> org.apache.geronimo.console.filter.XSRFHandler.isInvalidSession(XSRFHandler.java:79)

> 
>       at 
> org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:109) 
> 
>       at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

> 
>       at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

> 
>       at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) 
> 
>       at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 
> 
>       at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)

> 
>       at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406)

> 
>       at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)

> 
>       at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) 
> 
>       at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 
> 
>       at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 
> 
>       at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
>       at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>       at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
>       at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

> 
>       at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>       at java.lang.Thread.run(Thread.java:613)
> 
> --kevan
> 

Mime
View raw message