[seam-dev] XSRF and JSF2

[Shane Bryzak]

Christian Bauer wrote:
>
> 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.

Why couldn't it just request the application's home page and parse the 
response to extract the token value?
>
>>> 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.

Ok, so in this case prevention is the best medicine, and if I'm 
understanding correctly there's not much that can be done to protect 
against/detect an XSS attack once the security hole has been exploited.
>
> Can anybody check how strong the view-id in JSF is, that is, how it is 
> generated? Can it be guessed?
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev