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....

Today I thought a bit about how to protect ones website against CSRF attacks. The standard approaches were discussed here: http://www.cgisecurity.com/articles/csrf-faq.shtml , including CAPTCHA's, iTans etc.

I wondered whether it would be a adequate protection to generate an url suffix, based on the users session id. If this suffix turns out to be not valid, the task won't be executed.

This sounds so simple that I really assume to have forgotten something critical.
Just something that came into my mind... comments?

Im pretty sure though that using AJAX that the session id could easily be retrieved, as if they are are able to get CSRF working then its most likely they have found an XSS flaw and if this is the case they could poke round the source for session id, or cookie stealing...

I didnt say there had to be, i said it was more than likely there was. However obviously there doesn't need to be obviousy, as CSRF could be achieved in many ways, but surely the best way for this to happen on the page loading would be using xss, as many of the more popular sites block img tags to images that aren't actually images as well as many of the other useful tags. Although they could just send the requests from another site as in the name, but it would be by chance that you were logged in, so IMHO it would more practical if they had found an XSS hole.

eyeced Wrote:
-------------------------------------------------------
> I didnt say there had to be, i said it was more
> than likely there was. However obviously there
> doesn't need to be obviousy, as CSRF could be
> achieved in many ways, but surely the best way for
> this to happen on the page loading would be using
> xss, as many of the more popular sites block img
> tags to images that aren't actually images as well
> as many of the other useful tags. Although they
> could just send the requests from another site as
> in the name, but it would be by chance that you
> were logged in, so IMHO it would more practical if
> they had found an XSS hole.

Well if you for example send the link to the external page that you've prepared via PM or in the forum of the site you're doing the CSRF against, odds are very very high that visitors to the link are logged in on the correct site.

eyeced: I really think you understood something wrong, correct me if that isn't the case.

I'll try to make it clear:
In the moment there is a XSS vulnerability on a site, the attack is a local one and not cross-site anymore because the request is sent from the website you want to exploit.

Usually, users (user-groups) who are considered to have specific rights on a website, are attacked through CSRF and not arbitrary users in arbitrary communities. So if you inject such an attack (of course this happens via a kind of XSS) it's pretty likely that you will have success. This is, what hasse explained.

Now back to your first statement:

QuoteIm pretty sure though that using AJAX that the session id could easily be retrieved, as if they are are able to get CSRF working then its most likely they have found an XSS flaw and if this is the case they could poke round the source for session id, or cookie stealing...

Please explain me, how you want to steal cookies from domain B if your XSS attack is not on that domain but on domain A.

Anyway, this kind of discussion is not what was my original intention. My thought was, whether it is possible to prevent CSRF attacks on your website (for example one-click-shopping) by adding a session_id based suffix on the url, which will be checked before a security relevant task is executed.

Example:
A registered users sid is 012345. Your application creates a suffix of it, which could be 543210 - just to illustrate what I mean. Now a valid url to buy an item must be like: http://myexampleshop.com/buy.php?item=83&suffix=543210
Since this suffix is based on the sid, it's pretty hard to be guessed and a CSRF attack would be prevented in this case, isn't it?

Of course this will not work if there is a XSS vulnerablity on myexampleshop.com

Sorry, I'm catching this way late, but with the mhtml vulnerability still out there you always have read access to the page (effectively what XMLHTTPRequest gives you). So although you don't need XSS you don't have to have it. http://ha.ckers.org/blog/20061019/ie60-and-ie70-vulnerable-to-complete-cross-domain-leakage/

With that you can read any information from any page (the page that links to the unique token).

rsnake Wrote:
-------------------------------------------------------
> Sorry, I'm catching this way late, but with the
> mhtml vulnerability still out there you always
> have read access to the page (effectively what
> XMLHTTPRequest gives you). So although you don't
> need XSS you don't have to have it.
> http://ha.ckers.org/blog/20061019/ie60-and-ie70-vu
> lnerable-to-complete-cross-domain-leakage/
>
> With that you can read any information from any
> page (the page that links to the unique token).

That looks interesting. Although I'm not sure I completely grasp it. The browser does send cookies to the site using that method? I mean if the nonce is on a page you have to be logged in to reach.

Yah, the mhtml vuln assumes you have already authenticated to the site you are trying to steal data from. You can use the CSS history hack (or an IE variant of that) to check to make sure they have been to the site in question before.

rsnake Wrote:
-------------------------------------------------------
> Yah, the mhtml vuln assumes you have already
> authenticated to the site you are trying to steal
> data from. You can use the CSS history hack (or
> an IE variant of that) to check to make sure they
> have been to the site in question before.

Ok, that's what I thought. I was just unsure if the browser sent the cookies to the site when you're using this technique. Like when you POST the data from a flash-file the cookie-data doesn't get sent. (Or does it?)

Actually I don't understand the mhtml vulnerability. I do know several facts about it but I can't pull it together with stealing valid tokens (my approach above).

I know that this only works with IE and because of it's Outlook connection, I know that you can fetch data from an arbitrary website (example often was news.google.com) because IE does obviously something "wrong".

Could anyone try to explain me this issue?

QuoteWith that you can read any information from any page (the page that links to the unique token).

Which page, to which token?

Ah - maybe you mean with mhtml, one can try to read a page (of the url suffix protected website) where a link is embeeded which already contains the suffix?

So I'm right with assuming that the page from which the HTTP request is sent (back to CSRF) must be vulnerable to XSS to read the token/suffix or whatever.
Is this double white line solution effective to prevent MHTML requests?

christ1an Wrote:
-------------------------------------------------------
> If you meant this, yes, I read it today in the
> morning.
>
> So I'm right with assuming that the page from
> which the HTTP request is sent (back to CSRF) must
> be vulnerable to XSS to read the token/suffix or
> whatever.
> Is this double white line solution effective to
> prevent MHTML requests?

No it doesn't require an XSS-hole right? Because you make the browser load the page under your domain so you can read the page with XMLHTTPRequest. That's how I understood it.

Right, the mhtml vuln does not require any XSS holes, it only requires that you have control over the user's machine to send them to the site in question to pull the results down from an XMLHTTPRequest. Then you read the token and create the CSRF attack based on the token (in this case the token is part of the URL string, but it doesn't really matter).

Reading again your blog entry I now understand the issue, I hope. The problem is just my english comprehension.

Quote... the site in question to pull the results down from an XMLHTTPRequest. Then you read the token and create the CSRF attack based on the token (in this case the token is part of the URL string, but it doesn't really matter).

Does that mean that the original CSRF changes? Example: You found an issue in phpBB's bbCode. A simple CSRF whould be to create something like this: <img src="http://blah.blogspot.com?logout" />. Some days later, blogger discovers this issue and fixes it by adding a suffix. The URL must be like http://blah.blogspot.com?logout&suffix=12345. Now the request from phpBB doesn't work anymore and you can't do header injection or similar XSS things which would let you inject arbitrary code. This is where the mhtml issue comes into play. You change the request in in phpBB to somethink like: <img src="http://mydomain.com/attack.php" /> This php script sends the request, reads the token and sends a new request to to blogger.com, including the token. It this what you meant or did I understand it wrong again?

Sure, although an image can't return data other than a hight and a width. So you probably have to get the user to click on a site that you have control over. If you can inject HTML (like an image tag) there are probably other issues in the site. This is assuming you have no access to the site whatsoever, but you can get the user to at least visit a page that you have control over on your own server somewhere (it has to be at least slightly under your control because you have to be able to redirect them to the mhtml: URL in question and then run XMLHTTPRequest).

I actually don't know that I agree with that statement. The only time it's useful is when you don't already have XSS on the site in question (because you can just bypass the need for mhtml and use XMLHTTPRequest directly). Otherwise you gain nothing by using your own server. The only case where that's incorrect is if for some reason you can't run JavaScript on the page but can call an iframe to a page you can control.

But anyway, I'm not sure what that second question is asking. Referencing a PHP file in an image will do nothing other than return an image (if the PHP file is set up to return an image binary) and run the php file in question. Unless the php file gives up the token in a cookie, that technique won't give you much information back. It won't render in the browser, so it can't pick up a token string and for use in a CSRF later.

That's why I'm saying the practice actually isn't ambiguous, it must work like I wrote it. ... unless I am totally not understanding what you are asking here.

No, unfortunately that wouldn't work. You need to do a server side redirection so the XHR thinks you are on the same domain: http://ha.ckers.org/blog/20061019/ie60-and-ie70-vulnerable-to-complete-cross-domain-leakage/