You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kevan Miller <ke...@gmail.com> on 2009/06/30 15:29:03 UTC

Session creation triggered by XSS/XSRF filter

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

Re: Session creation triggered by XSS/XSRF filter

Posted by Kevan Miller <ke...@gmail.com>.
On Jun 30, 2009, at 1:06 PM, Joe Bohn wrote:

> Thanks for the input Donald and Rex. So it sounds like we all agree  
> that we should remove the filter from welcome.
>
> Kevan,
> Did you want to remove this or would you like me to make the change?  
> Did you already create a JIRA for this?

Just created https://issues.apache.org/jira/browse/GERONIMO-4722 Would  
be great if you could fix... Thanks!

--kevan

Re: Session creation triggered by XSS/XSRF filter

Posted by Joe Bohn <jo...@earthlink.net>.
Thanks for the input Donald and Rex. So it sounds like we all agree that 
we should remove the filter from welcome.

Kevan,
Did you want to remove this or would you like me to make the change? 
Did you already create a JIRA for this?

Thanks,
Joe


Donald Woods wrote:
> Probably can be removed, since we no longer allow users to install 
> Sample plugins from the welcome page.
> 
> As long as the Login page and everything behind it is protected, we 
> should be okay.
> 
> 
> -Donald
> 
> 
> Joe Bohn wrote:
>> Kevan Miller wrote:
>>>
>>> On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote:
>>>
>>>> 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 "/*".
>>>
>>> OK, that would explain it... So, is there any reason to run XSS 
>>> filtering on the welcome app?
>>
>> I'm not sure if there is a strong reason to have the filter applied to 
>> the welcome application.  I have this vague recollection of somebody 
>> raising an issue earlier ... but I can't find any reference and after 
>> a quick glance I don't see any obvious exposures.
>>
>> It primarily includes links into our wiki documentation along with a 
>> few other links (such as to the console and to subscribe to the 
>> mailing lists).
>> Perhaps the mail subscription links might present an exposure?
>> Or perhaps on the IRC link?
>>
>> Does anybody have an idea if this is really necessary?  It seems like 
>> overkill to me.
>>
>> Joe
>>
>>
>

Re: Session creation triggered by XSS/XSRF filter

Posted by Donald Woods <dw...@apache.org>.
Probably can be removed, since we no longer allow users to install 
Sample plugins from the welcome page.

As long as the Login page and everything behind it is protected, we 
should be okay.


-Donald


Joe Bohn wrote:
> Kevan Miller wrote:
>>
>> On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote:
>>
>>> 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 "/*".
>>
>> OK, that would explain it... So, is there any reason to run XSS 
>> filtering on the welcome app?
> 
> I'm not sure if there is a strong reason to have the filter applied to 
> the welcome application.  I have this vague recollection of somebody 
> raising an issue earlier ... but I can't find any reference and after a 
> quick glance I don't see any obvious exposures.
> 
> It primarily includes links into our wiki documentation along with a few 
> other links (such as to the console and to subscribe to the mailing lists).
> Perhaps the mail subscription links might present an exposure?
> Or perhaps on the IRC link?
> 
> Does anybody have an idea if this is really necessary?  It seems like 
> overkill to me.
> 
> Joe
> 
>

Re: Session creation triggered by XSS/XSRF filter

Posted by Rex Wang <rw...@gmail.com>.
IMO, I don't think the welcome page need this filter. The filter only deal
with the links that have the request parameters and the form request, but in
the welcome page, there is no such links, so the filter won't take any
effects.

The reason why add the filtering to welcome project, as the G-4597
indicated, seems just want to comply with some sort of security standards..
so add this filter to all of our web projects(welcome, console....), just my
guess..

-Rex
2009/7/1 Joe Bohn <jo...@earthlink.net>

>  Kevan Miller wrote:
>
>>
>> On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote:
>>
>> 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 "/*".
>>>
>>
>> OK, that would explain it... So, is there any reason to run XSS filtering
>> on the welcome app?
>>
>
> I'm not sure if there is a strong reason to have the filter applied to the
> welcome application.  I have this vague recollection of somebody raising an
> issue earlier ... but I can't find any reference and after a quick glance I
> don't see any obvious exposures.
>
> It primarily includes links into our wiki documentation along with a few
> other links (such as to the console and to subscribe to the mailing lists).
> Perhaps the mail subscription links might present an exposure?
> Or perhaps on the IRC link?
>
> Does anybody have an idea if this is really necessary?  It seems like
> overkill to me.
>
> Joe
>
>

Re: Session creation triggered by XSS/XSRF filter

Posted by Joe Bohn <jo...@earthlink.net>.
Kevan Miller wrote:
> 
> On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote:
> 
>> 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 "/*".
> 
> OK, that would explain it... So, is there any reason to run XSS 
> filtering on the welcome app?

I'm not sure if there is a strong reason to have the filter applied to 
the welcome application.  I have this vague recollection of somebody 
raising an issue earlier ... but I can't find any reference and after a 
quick glance I don't see any obvious exposures.

It primarily includes links into our wiki documentation along with a few 
other links (such as to the console and to subscribe to the mailing 
lists).
Perhaps the mail subscription links might present an exposure?
Or perhaps on the IRC link?

Does anybody have an idea if this is really necessary?  It seems like 
overkill to me.

Joe

Re: Session creation triggered by XSS/XSRF filter

Posted by Kevan Miller <ke...@gmail.com>.
On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote:

> 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 "/*".

OK, that would explain it... So, is there any reason to run XSS  
filtering on the welcome app?

--kevan

Re: Session creation triggered by XSS/XSRF filter

Posted by Joe Bohn <jo...@earthlink.net>.
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
>>
>

Re: Session creation triggered by XSS/XSRF filter

Posted by Kevan Miller <ke...@gmail.com>.
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

Re: Session creation triggered by XSS/XSRF filter

Posted by Donald Woods <dw...@apache.org>.
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
>