Re: [seam-dev] XSRF and JSF2
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev