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
Pages: 12Next
Current Page: 1 of 2
CSRF defend demos
Posted by: Gareth Heyes
Date: August 21, 2007 06:23AM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: hackathology
Date: August 21, 2007 07:12AM

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

http://hackathology.blogspot.com

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Anonymous User
Date: August 21, 2007 07:26AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 21, 2007 07:31AM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Anonymous User
Date: August 21, 2007 07:38AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 21, 2007 07:52AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Anonymous User
Date: August 21, 2007 08:28AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 21, 2007 08:35AM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Anonymous User
Date: August 21, 2007 04:41PM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 21, 2007 06:20PM

/nul

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Anonymous User
Date: August 21, 2007 08:31PM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 21, 2007 08:42PM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: kuza55
Date: August 22, 2007 02:22AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 22, 2007 02:44AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: kuza55
Date: August 22, 2007 03:22AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 22, 2007 03:29AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: kuza55
Date: August 22, 2007 03:43AM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: August 22, 2007 04:26AM

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>

Options: ReplyQuote
Re: CSRF defend demos
Posted by: rsnake
Date: December 10, 2007 09:24AM

@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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Gareth Heyes
Date: December 10, 2007 09:35AM

@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]

Options: ReplyQuote
Re: CSRF defend demos
Posted by: Anonymous User
Date: December 10, 2007 11:50AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: guesty22
Date: December 17, 2007 05:50PM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: tx
Date: December 17, 2007 06:04PM

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

-tx @ lowtech-labs.org

Options: ReplyQuote
Re: CSRF defend demos
Posted by: guesty22
Date: December 22, 2007 12:12PM

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?

Options: ReplyQuote
Re: CSRF defend demos
Posted by: kirke
Date: December 23, 2007 02:46AM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: guesty22
Date: December 24, 2007 06:34PM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: guesty22
Date: December 30, 2007 07:48AM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: rsnake
Date: December 31, 2007 03:52PM

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

Options: ReplyQuote
Re: CSRF defend demos
Posted by: guesty22
Date: January 02, 2008 11:59AM

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.

Options: ReplyQuote
Re: CSRF defend demos
Posted by: rsnake
Date: January 03, 2008 04:45PM

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

Options: ReplyQuote
Pages: 12Next
Current Page: 1 of 2


Sorry, only registered users may post in this forum.