On Oct 03, 2008, at 02:25 , Shane Bryzak wrote:
> Any other tab or browser window on her client can also send a
> request to your server. So all the attacker has to do is get her to
> 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
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
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
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
> 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?