Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc....

I am new to sla.ckers.org. I have been trying to find the answer to a question.
In the clickjacking paper by rsnake on http://www.sectheory.com/clickjacking.htm, he has said that "Nonce evasion requires that the browser somehow gains access to data in another domain.". I dont understand this, because why would I want to gain access to data in another domain if the nonce is taken from the same domain on which I am performing CSRF. Also, can't this nonce evasion be done if there is an xss issue in the transaction against which I am performing the CSRF.

If there's a XSS issue then CSRF isn't needed because you can access the domain and content. However if there aren't any XSS holes then information disclosure on parts of the site can reveal tokens (Nonces).

If you combine this with minor browser issues you can get tokens from sites without breaking SOP. A good case study for this is the MyOpenID exploit I did a few years ago.

http://www.thespanner.co.uk/2007/06/29/openid-security-issues/

Here I use a vulnerability in Safari to steal the contents of a url cross domain, MyOpenID stored the token in the url which made this possible.

@Gareth Heyes
Thanks for the quick reply.
If there is an xss issue, I will be able to access the content on that domain;very true. Correct me If I am wrong, But for performing an arbitrary transaction on the site (even if there is an xss issue in the transaction) I would still have to do a CSRF; isnt that correct??
Thanks
dragunov

@lightos
I completely understand ur point. We can perform requests by submitting the form or use XHR to GET/POST any arbitrary transaction. But I am still confused cause this action will still use the session of the authenticated target user to be successful, and it wont work if we dont target an authenticated user; so arent we still riding the session and that is what CSRF is.
Thanks
@dragunov

If the application was vulnerable to XSS then you could pass the session data or whatever using Images or any remote request. If the application wasn't vulnerable to XSS then the CSRF attack would only work if there are no tokens or the token can be accessed in some way like my previous post stated.

You could define XSS and CSRF as the same technique however it's possible to perform CSRF without the need for scripting so I think it makes sense to discuss them separately.

Hey all
all right
I got the point rsnake was trying to make(actually I was taking the concept in the wrong context).
@Gareth Heyes
Thanks for the reply.
Your point that CSRF attack would only work if there are no tokens or the token can be accessed in some way is perfectly true.
thanks and Cheers!