[seam-dev] XSRF and JSF2

[Christian Bauer]

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.

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.

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.

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.