Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=bjzNc0wxKR6wAU57SA+tMsodnkvvX2ViP7Ci5iYHmXsxyb+lA1L9DLFZ3XQRCc3b;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <4A4A2097.3080809@earthlink.net>
Date: Tue, 30 Jun 2009 10:26:31 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Session creation triggered by XSS/XSRF filter
References: <19C49411-7FD5-4D95-BCA9-20369A4AAAD7@gmail.com>
 <4A4A1CB6.2030503@apache.org>
In-Reply-To: <4A4A1CB6.2030503@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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