[seam-dev] XSRF and JSF2

[Christian Bauer]

On Oct 03, 2008, at 02:25 , Shane Bryzak wrote:

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

That "same" Seam application is not supposed to give anyone the  
ability to insert malicious Javascript that can generate POST requests  
automatically. :) The whole issue is that it works across sites, hence  
XS request forgery.

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

It's a hidden field in the original form, for example. Think JSF view  
identifier. So the only valid POST request would be the one submitting  
that form. Not any other POST request that just happens to get the URI  
and some of the parameters right.

> Couldn't a XSRF attack simply retrieve the token in the very same way?

You'd have to retrieve the token value, that means you need to scrape  
it off the form's hidden field. This is the same challenge as stealing  
someone's session cookie, i.e. usually done through an XSS attack.

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

Protecting against an XSS attack is relatively easy: Never show any  
data on your website that has been entered by a user. If a user enters  
data and you want to later on show that data, you need to filter it.

Implementing a filter that is valid until the next XSS trick is  
discovered (browsers these days parse all kinds of sh*t, even if you  
escape it) is not trivial.

Again, XSS is not XSRF. An XSS security hole can make your XSRF  
protection useless. But you need XSRF protection in the first place.

Can anybody check how strong the view-id in JSF is, that is, how it is  
generated? Can it be guessed?