Hi all

I've created a few scripts to defend against CSRF which are available here:-
http://www.businessinfo.co.uk/labs/csrf_defend/csrf_demos.php

I would appreciate any feedback or improvements. I will release the source code once I've finished the scripts. I will of course provide anyone who helps with full credit and web site link on my blog and labs site.

Cheers

cool Gareth, i just went throught the whole thing, its simple yet easily understandable.

http://hackathology.blogspot.com

Problem is not the site owner but the end-user since it's an attack on the user than on the site owner. Now that might be the biggest problem of all, to my knowledge there is virtuall nothing you can do other to make sure you don't use tabbed browsing or cookies.

@hackathology

Thanks glad it is easy to understand, I tried to make it as simple as possible

@Ronald

Yeah true. But if XSS is not found on the site then these techniques can help. Could you explain why tabbed browsing is a bad idea? Have you found a vulnerability with tabs?

There are a few issue with tabbed browsing, but I meant that some services remain a session state until the tab is closed, simple PHP session lifetime. In the same time we could trace wether this user has this tab open and make a CSRF call in the tab that has the focus.

Yes true the session remains open but what if the site employed form tokens and url tokens. So in my examples each user has a custom url either in the get string or using rewrite, also a unique form token is generated for the submit form and is unique to that user and finally a javascript session is created. Now in order to perform CSRF attacks on that user you would need the correct form token, url token and the correct javascript session. Each token expires after 5 minutes within the session.

The only way I can see round this without using XSS is session fixation. Please correct me if I'm wrong Ronald.



Edited 1 time(s). Last edit at 08/21/2007 08:10AM by Gareth Heyes.

Well I am beginning to see CSRF in a different way now. I think it facilitates most attacks including but not limited to XSS. See Javascript worms for instance. Actually any unauthenticated software call wether it is done by a remote site or the software itself is a Unauthenticated Request. I think it's time we step off the term CSRF since it's not limited to cross request websites alone.

I think there might be a reason the give it another name, because it's not limited to sites only, browsers and even your computer and router can be vulnerable to. It also means that any protection will fail if the same origin policy is broken, like you know that is very exotic, but when a hole is found all protection schemes fail: so we can't solve it.

I'm trying to puzzle together all the risks right now for my article next month, and I'm really shocked by it's potential. Right now it's impossible to protect yourself, Javascript isn't even needed. Your router settings maybe changed while you visit sla.ckers.org. And your would not even know it happened. Disabling cookies, js, Java, flash is not going to stop it.

It's possible to load about 100 popular services into a page enumerate through them server-side and spit out the appropiate iframe which could hijack one or two services you are subscribed to. Spamming youtube with your account, digging articles, adding millions of friends to a social networks, removing your friends. It's endless.

I think it's safely to say that everyone is vulnerable right now, it may already happened. Only way to be sure is to monitor all TCP traffic, which I guess not many do - I do - ^^

But yes, the web is flawed.

Ronald are you talking about DNS Rebinding (DNS pinning) here? Or something else?

I'm very interested in your article and if you need it proof reading before you release it, I'll be happy to :)

Right, routers are vulnerable to CSRF, especially if default password wasn't changed. This attack is referred to as Drive-by pharming:

http://www.symantec.com/enterprise/security_response/weblog/2007/02/driveby_pharming_how_clicking_1.html

As far as I understand (and I may be wrong) re-confirmation, like for example re-entering username and/or password or even as CAPTCHAs, prevents CSRF. I saw that on some sites. Before any action is processed the re-confirmation that involves user interaction takes place. Now, putting that in practice may be a different story...

/nul

You have seen my Lan scanner haven't you? It's worse then you think.

Yah indeed, only there are routers without a default password. I saw a brand come by, one of the biggest mexican router producers. Which is used for drive-by-pharming indeed. it's one asset, but it will be worse. Far worse.

It's all about bad system design really. If each system/router/web app used CSRF protection like in my demos then it would be a lot harder to exploit. It really becomes obvious with identity systems and single sign on. You won't believe the state some of them are in.

Ok, so the scripts you have uploaded are:

- URL tokens demo
- Form tokens demo
- IFRAME protection demo
- Combined CSRF demo

The first two are known and used, the URL method is ugly, there's nothing new here.

"IFRAME protection demo" - is this meant to protect against this kind of attack: [ha.ckers.org]?

First of all, if you'd read the links posted in the other thread you posted this to, more specificaly this link: [crypto.stanford.edu] then you'd know that this method doesn't work.

Furthermore, such attacks are only applicable in a very small number of situations, namely those where all you need is for a user to click (technically you might be able to do more, but it would require significant user gullibility and interaction), so essentially its click fraud and things like digg being gamed by hijacking clicks.

"Combined CSRF demo" - Same issue(s) as above.

Huh did I say they were new?

Why aren't these techniques being used, that's my point. So many sites don't use the protection methods discussed. The iframe protection will detect even if the security=restricted parameter is used but requires javascript. The frame busting technique works on Firefox and Safari so it does work.

Gareth Heyes Wrote:
-------------------------------------------------------
> Huh did I say they were new?
>
> Why aren't these techniques being used, that's my
> point. So many sites don't use the protection
> methods discussed.

AFAIK, they're not being used because people don't know about the problem.

The iframe protection will
> detect even if the security=restricted parameter
> is used but requires javascript. The frame busting
> technique works on Firefox and Safari so it does
> work.

Sorry, my mistake, I posted before testing, yet again, sorry.

I just saw your frame busting code, but now I see that its the javascript after it.

Though I do stand by my point that this is relevant in very few cases (its really only relevant where a button performs an action without any values, I realised after posting the last post that banner fraud would not be stopped, since all the banners have to be rendered inside iframes anyway).

Sorry, 'bout that.

$mouth->remove (FOOT);

Warning: Removing FOOT from the object ($mouth) is useless, since it will simply put back there next time the talk method is called.

No probs Kuza55

>>AFAIK, they're not being used because people don't know about the problem.

Yeah that's why I wrote the demos, hopefully OpenID providers and others will read them. I'm going to release the source code as well.

>>Though I do stand by my point that this is relevant in very few cases (its really only relevant where a button performs an action without any values

I don't understand that point really, please can you clarify. Do you mean without url/form tokens?



Edited 1 time(s). Last edit at 08/22/2007 03:30AM by Gareth Heyes.

Gareth Heyes Wrote:
-------------------------------------------------------
> I don't understand that point really, please can
> you clarify. Do you mean without url/form tokens?

I meant the iframe protection demo. Sure, it is more silent if it is all done in an iframe, but that isn't a requirement for the attack. So the only thing this stops is the click hijacking, as RSnake described here: http://ha.ckers.org/blog/20070116/stealing-mouse-clicks-for-banner-fraud/

This is especially true when you consider that if standard CSRF protections (Form/URL tokens) are applied then csrf is no longer an issue, and so the iframe protection code is superfluous, since any attack would already need to be able to read http responses (with cookies sent), and so would be able to make the requests themselves.

All I'm saying is that the problem it solves is not really encountered by most applications, and that the requirement for javascript is a reason to not use it when its not necessary (i.e. the scenario of someone hijacking clicks by placing an iframe under the user's cursor).

Thanks for the clarification I understand your point, the idea was to provide layers of security and the combined demo shows all the techniques used. Ideally URL/Form tokens should be used but each method could be used in different sites/situations and so the developer could choose which method is right for the task.

The idea with the iframe one was to identify when a site was inside one even if security=restricted. I've had further ideas with this and I'd love to hear your thoughts. Check it out:-

<noscript>
<meta http-equiv="refresh" content="0;url=safe.subdomain" />
</noscript>
<script type="text/javascript">
if(top != self) {
top.location.href = 'your url';
}
</script>

@Gareth - I don't know if you have seen this or not, but looks like there is another product out there: http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project

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

@rsnake

Cool I'll check it out thanks :)

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Thing is, tokens are not always enough to correlate the user to it's request.

I have another idea I blog about soon,
which is based upon the actuall user TCP/IP stream where the TCP header is unique with each ACK number from the server in question.
Thus I will already make use of the (lame actually, but practical) implemented security features of TCP.



Edited 1 time(s). Last edit at 12/10/2007 11:53AM by Ronald.

how about defending by requesting the referer url? If it doesn't match the domain, than sth is wrong and it should deny acc. to the scripts. Yes, I'm aware of the new race condition bug (Referer Spoofing Using JavaScript) ;)

It's way too easy to spoof a referrer, and moreover many people have it disabled all together.

-tx @ lowtech-labs.org

How it's easy?

- There is a website with a mails.js for example. In this file there're emails of a currently logged-in user, maybe in a JSON.

So wannabe-hacker lures a victim into a website with js code <script src=vuln.com/mails.js> and then tries to show the emails with alert.

SO, the administrator of a website with mails.js requires checking of a referer.

If a legitimate user clicks 'read mail', then js will send a query to the mails.js + referer.

And how that can be bypassed?

> .. requires checking of a referer.
useless attempt, as explained infinite times

> And how that can be bypassed?
in many ways
But that's probably not the question. How would you deal with client not providing a refer(r)er? 'cause snipped of by a proxy elsewhere (for good reason:)

kirke Wrote:
-------------------------------------------------------
> > .. requires checking of a referer.
> useless attempt, as explained infinite times
>
> > And how that can be bypassed?
> in many ways
> But that's probably not the question. How would
> you deal with client not providing a refer(r)er?
> 'cause snipped of by a proxy elsewhere (for good
> reason:)

If a client doesn't provide a referer then he/she doesn't have access to a webpage.

so, please tell me how to get variables from a legitimate user from that js file :)

so, no answer...so it's not possible to bypass this method. ..for the time being

Guesty22, it totally depends on what you are talking about. If the referrer is checking for the base domain, it can be bypassed by XSS. If it is checking for a specific page you have tons of implementation issues if you use variables in the QUERY_STRING. If you are relying on it not being pulled by robots, they can spoof it (I run across this regularly and it usually takes about 10 seconds to bypass with the -referrer flag in wget or even with burp proxy by hand). If you are relying on not being able to forge headers, you had better hope one of the Flash header vulns doesn't re-surface and that your users have the most current version of flash installed - if they don't they're still vulnerable to it. It also entirely depends on which browser they are using: http://www.webmasterworld.com/forum46/48.htm and how the page is called, since META refresh for instance doesn't send a referrer (neither does file: or https: in certain browsers).

And lastly, the poor schmucks who use the various security technologies like Norton personal firewall and Zonelabs Zone Alarm Pro (as discussed here http://ha.ckers.org/blog/20070105/lessons-learned-from-adobe-pdf-xss-patching/), the webdeveloper plugin with no referrer set and the tons of proxies that strip that kind of information out can't use your site. Not exactly a great solution. It's fine to flag that as a possibly bad use of your site, but I don't think it's wize to make decisions based on that fact.

Just think about HTTP referrers as Forrest Gump thinks about life and chocolate - "You never know what you're going to get."

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

Ok,

for example we've got gmail account and some time ago there was a bug that allowed to read email and other stuff via csrf. So they've fixed it by adding while(1) at the beginning of the file. Great.
Now, suppose instead of adding while(1) they've decided to check the referrer. Yes, it can be bypassed locally, by robots, but what I meant was how can it be spoofed remotely, so that user won't know a thing. Sorry I see I didn't explain it earlier.

Gmail would have a lot of support calls for idiots who couldn't use their system if they tried that. Companies can't afford that kind of thing. Google has done ridiculously stupid things like that before, though. Don't get me wrong.

Case in point:



Yay, yes, turning off your firewall should help the page load. Great idea!

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