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: domain of kevan.miller@gmail.com
 designates 209.85.217.210 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=cBMk6XqZk9rT8mpNgXb13xEZsN8ww2YA1N3QM5icZmcnvOYxcZTH49xy4HPO0xG0C2
         jb+rxFvr/81G/N9gsMsMgPrKVDkWq15K7TZippFfNCofGQLJHJXZMPZxPOH3FHBpuHsH
         3qAxlPP6n/VSsiSZec+OPakieeNi5HYTcpIlc=
Message-Id: <A1327FEF-9CFA-486B-BA60-20E50554606D@gmail.com>
From: Kevan Miller <kevan.miller@gmail.com>
To: dev@geronimo.apache.org
In-Reply-To: <4A4A1CB6.2030503@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Session creation triggered by XSS/XSRF filter
Date: Tue, 30 Jun 2009 10:40:22 -0400
References: <19C49411-7FD5-4D95-BCA9-20369A4AAAD7@gmail.com>
 <4A4A1CB6.2030503@apache.org>


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