I tried some random URIs and always received a 404 back in my tests.
This could be a problem with the filter on the welcome application. It
currently has a context-root of "/" and the filter is registered with a
URL pattern of "/*".
Joe
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.
>
> 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
>>
>
