[seam-dev] XSRF and JSF2

[Shane Bryzak]

Christian Bauer wrote:
>
> On Oct 01, 2008, at 15:22 , Shane Bryzak wrote:
>
>> I created a new JIRA issue to remind me to do something about 
>> preventing/limiting XSS attacks in Seam Remoting:
>>
>> https://jira.jboss.org/jira/browse/JBSEAM-3482
>>
>> However I'm still not totally clear how I should be tackling this 
>> problem, probably because I don't fully understand the mechanism 
>> behind an XSS attack.  We already have an incremental call ID value 
>> passed with each remote request, so this could possibly be used as 
>> our "canary" value.  In any case, could you please walk me through 
>> the moving parts of an XSS attack step by step just so we're clear on 
>> what needs to be protected?
>
> First, it is not an XSS attack although an additional XSS problem 
> could disable any XSRF protection you might implement. The attack is 
> quite simple, this is a more sophisticated variation:
>
> You run a website that requires a session cookie and a logged-in user. 
> As soon as the user is logged-in, any request from her browser will 
> send the session cookie along, hence, it's considered a valid request 
> for any operation she has permission on (checked on the server).
>
> Any other tab or browser window on her client can also send a valid 
> request to your server. So all the attacker has to do is get her to 
> open his malicious webpage, which runs a little Javascript that sends 
> a POST request to your website. You will execute the operation because 
> there is a valid session cookie in the request. You don't know if the 
> request came from "your" form/window or the attackers Javascript.

So how is this different to having multiple browser tabs/windows open in 
the same Seam application?
>
> Typically you prevent this with a cryptographically strong nonce/token 
> that has to be present in addition to the session cookie - it is 
> internally tied into the session of course, so it can be validated. 
> Think view ID in JSF, the POST fails if the view with the given ID 
> can't be restored.

How is this token generated and propagated to the client?  Couldn't a 
XSRF attack simply retrieve the token in the very same way?
>
> If you also have an XSS hole on your website, the attacker can read 
> the nonce/token with Javascript and you are back to square one. Same 
> for a simple incremented value, an attacker can guess it.

That makes sense (and actually an incremented value won't really work 
anyway for other reasons).  Is there really any protection against XSS 
attacks though?  Besides making an effort to prevent them in the first 
place?
>
> It's even easier to exploit if you have unsafe GET operations, like 
> ?action=transferMoney&from=123&to=456... that's why <s:link action> is 
> really evil.
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev