Re: [seam-dev] XSRF and JSF2
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.