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