Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
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.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
CSRF protection method
Posted by: christ1an
Date: January 18, 2007 03:56PM

Hello,

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?

Best regards, Chris

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0

Options: ReplyQuote
Re: CSRF protection method
Posted by: eyeced
Date: January 19, 2007 08:49AM

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

http://christ1an.blogspot.com/search?q=%3C%2F%74%69%74%6C%65%3E%3C%69%66%72%61%6D%65%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%77%77%77%32%2E%62%6C%6F%67%67%65%72%2E%63%6F%6D%2F%6C%6F%67%6F%75%74%2E%67%22%20%77%69%64%74%68%3D%22%31%30%30%25%22%20%68%65%69%67%68%74%3D%22%31%30%30%25%22%3E%3C%2F%69%66%72%61%6D%65%3E

Hmmm... maybe you should try these tactics on your blog cheif ;)

Options: ReplyQuote
Re: CSRF protection method
Posted by: christ1an
Date: January 19, 2007 11:52AM

Quote

as if they are are able to get CSRF working then its most likely they have found an XSS flaw
I'm sorry, I do not agree with this statement. You can not talk about Cross Site Request Forgeries if there is an XSS vulnerability on a site.

Did you get my question right? Maybe I described it badly, since english is not my mother language.

And by the way:
Blogspot isn't secure at all. There are various XSS vulnerablities, which obviously won't be fixed -.- I didn't even know that my signature contains a link to my blog site.

Options: ReplyQuote
Re: CSRF protection method
Posted by: hasse
Date: January 19, 2007 11:57AM

Well there doesn't have to be an XSS hole just because you can use CSRF.

EDIT: Didn't see christ1an's post.



Edited 1 time(s). Last edit at 01/19/2007 12:23PM by hasse.

Options: ReplyQuote
Re: CSRF protection method
Posted by: eyeced
Date: January 19, 2007 12:45PM

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.

Options: ReplyQuote
Re: CSRF protection method
Posted by: hasse
Date: January 19, 2007 01:08PM

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.



Edited 1 time(s). Last edit at 01/19/2007 01:08PM by hasse.

Options: ReplyQuote
Re: CSRF protection method
Posted by: christ1an
Date: January 19, 2007 03:02PM

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:
Quote

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

Regards, christ1an



Edited 2 time(s). Last edit at 01/22/2007 03:56PM by christ1an.

Options: ReplyQuote
Re: CSRF protection method
Posted by: hasse
Date: January 19, 2007 06:00PM

I think that definately sounds like a workable method. I've been involved personally with a website that's decided to use that method.

As long as an attacker can't figure out the sid of a user and/or figure out the way the suffix is generated.

Options: ReplyQuote
Re: CSRF protection method
Posted by: christ1an
Date: January 20, 2007 07:56AM

Sounds good. I was a bit unsure because I never read about this method, though it is quite obvious.

Options: ReplyQuote
Re: CSRF protection method
Posted by: eyeced
Date: January 20, 2007 08:37AM

Sorry, reading your last post i now get what you meant.

Options: ReplyQuote
Re: CSRF protection method
Posted by: rsnake
Date: January 21, 2007 09:20PM

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
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF protection method
Posted by: hasse
Date: January 22, 2007 01:13PM

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.

Options: ReplyQuote
Re: CSRF protection method
Posted by: rsnake
Date: January 22, 2007 01:38PM

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
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF protection method
Posted by: hasse
Date: January 22, 2007 01:58PM

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?)

Options: ReplyQuote
Re: CSRF protection method
Posted by: christ1an
Date: January 22, 2007 03:06PM

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?

Quote

With 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?



Edited 1 time(s). Last edit at 01/22/2007 03:55PM by christ1an.

Options: ReplyQuote
Re: CSRF protection method
Posted by: rsnake
Date: January 22, 2007 03:35PM

Yes, christian, that's what I was saying. Do you need more info? Have you checked the link? There is a PoC on Secunia.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF protection method
Posted by: christ1an
Date: January 22, 2007 04:14PM

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?

Options: ReplyQuote
Re: CSRF protection method
Posted by: hasse
Date: January 22, 2007 04:37PM

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.

Options: ReplyQuote
Re: CSRF protection method
Posted by: rsnake
Date: January 22, 2007 08:07PM

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

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF protection method
Posted by: christ1an
Date: January 23, 2007 08:17AM

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?

Options: ReplyQuote
Re: CSRF protection method
Posted by: rsnake
Date: January 23, 2007 03:53PM

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

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF protection method
Posted by: christ1an
Date: January 23, 2007 05:15PM

Well, I think the principle should be clear and how it'll be put into practice depends on the situation.

Quote

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.
Hm? I thought this image trick would work at least in IE? Whatever, this isn't the point.

I wonder whether one could take adventage of this issue regarding this thread... but probably not.

Options: ReplyQuote
Re: CSRF protection method
Posted by: rsnake
Date: January 23, 2007 06:01PM

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.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF protection method
Posted by: hasse
Date: January 24, 2007 02:33AM

Do you have to be able to modify the server headers? Couldn't you use "meta refresh" or JavaScript to redirect instead?



Edited 3 time(s). Last edit at 01/24/2007 02:34AM by hasse.

Options: ReplyQuote
Re: CSRF protection method
Posted by: rsnake
Date: January 25, 2007 10:46AM

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/

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote


Sorry, only registered users may post in this forum.