CSRF protections are not doomed by XSS

Tuesday, November 21. 2006

Tuesday, November 21. 2006



Today I was looking at rsnake's blog where he described how visiting two URLs in a row bypassed a CSRF protection implemented by last.fm. While it is funny that someone believes enforcing some kind of application flow control by URL checks can stop CSRF it was not what caught my attention.


It was one of the comments to that post that annoyed me. People like my special "friend" have claimed in the past that with an XSS on the site all CSRF protections are doomed. This is however not true.


The problem with XSS and simple CSRF protections is that at the moment there is an XSS on a site, the attack becomes a local one and is no longer a Cross Site Request Forgery. Because JavaScript comes with neat things like XMLHttpRequest or FlashRequest it becomes possible to read tokens embedded in local HTML forms and even fake HTTP headers. Therefore XSS can be used as a simple browser remote control.


However XSS attacks are limited (if there is no browser bug) to the current domain, therefore the answer to XSS attacks against CSRF protections is very simple: Keep XSS away from the HTML form's domain. For the application design this means: embedd all HTML forms in IFRAMEs that use a different source domain.

Example:
<iframe src="http://session_id.formular_id.example.com/">

While this makes application design trickier it keeps XSS from remote controlling your browser. If you embedd a formular id into the domain you can even have XSS in one of your formulars and XSS can still not control the other forms.


Update: the iframe URL was a bit unclear.... the formular_id is NOT the formular token. That is still embedded in the FORM. The id is simply an id that is different for all forms. Same for the session_id. It is not necessary the session_id of the user but an "encoded or encrypted" variant that allows having different domain names for different sessions.

Posted by Stefan Esser in Security, PHP at 11:01
Comments (17)
Link to this post


Comments
Display comments as (Linear | Threaded)

#1 Dave ()
What you say makes sense, but there has to be a better way than by polluting DNS?
posted on Tuesday, November 21. 2006
#1.1 Stefan Esser wrote (Link) ()
Domain boundaries are the only protection against XSS.

Alternate solutions would only work if browsers support some kind of httpOnly forms. However this means you loose any possibility to check FORM values...

(Of cours, in the end there is always the possibility to require CAPTCHA or iTAN number for every transaction)
posted on Tuesday, November 21. 2006
#2 wesley ()
Would it also be possible to just have the form in there as html but have the form action attribute point to "sub.domain.com"? Since xmlhttprequest wouldn't be able to submit to that either right, so it doesn't matter if they can read the token.

I've read that you could circumvent that domain restriction though, haven't really looked into it. Probably with a flash request.

However, they still can read the session_id cookie so they can still do it in other ways.
posted on Tuesday, November 21. 2006
#2.1 Stefan Esser wrote (Link) ()
1) Simple JavaScript can POST to different domains, you do not need XMLHttpRequest for that.

2) The session_id cookie should be httpOnly of course.

3) Yes you can circumvent some domain restrictions but only with buggy or crappy software like Flash and only in some conditions.
posted on Tuesday, November 21. 2006
#3 wesley ()
Doesn't that simple javascript only work if the XSS exploit is on the same page as the form is on? In all other cases it would require xmlhttprequest, right?
posted on Tuesday, November 21. 2006
#3.1 Stefan Esser wrote (Link) ()
Nothing stops JavaScript from simply loading any URL into an IFRAME and read/modify/use it's content. (As long it is on the same domain).
posted on Tuesday, November 21. 2006
#4 wesley ()
Oh, I thought subdomains would do the trick as well, was a little confused by session_id.formular_id.example.com

So it has to be a completely separate domain?

example.com
example2.com
posted on Tuesday, November 21. 2006
#4.1 Stefan Esser wrote (Link) ()
Well depends on your defitiniton of domain

domain is actually the complete domain

blub.example.com
blub2.example.com

Are two different domains on the same 2nd level domain. 'blub' and 'blub2' are two subdomains of example.com. But the complete name is a domainname. (Atleast to the normal definition I and JavaScript use).
posted on Tuesday, November 21. 2006
#5 Peter ()
The talk of iframes reminded me of microsoft's security attribute.

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/properties/security.asp

Though not sure how effective it would be.
posted on Tuesday, November 21. 2006
#6 Sencer wrote (Link) ()
While you are correct that such subdomains solve the techincal problem, I am not sure I would consider them to be a very advisable solution, because it teaches "normal users" that "gibberish-looking" urls are fine and so they may easier fall for tricks that phishers like to play ( like http://hotmail.com.longgibberishstring.attackersdomain.tld). Of course people that know how to correctly read domains are safe, but unfortunately that can't be counted on.
posted on Tuesday, November 21. 2006
#6.1 Stefan Esser wrote (Link) ()
I have never seen users looking through the HTML source to identify the src of iframes or the targets of form actions.

It is very unlikely that an average user will ever see that the form comes from a different host.

So I see no problem at all.
posted on Tuesday, November 21. 2006
#7 Ilia Alshanetsky wrote (Link) ()
So you are saying that you are going to rely on browser's restriction that prevents data JS from domain A to access data from B.A, something that so far has been notoriously unreliable.

What happens is the form itself contains XSS, which is the most common situation, since that's the element of the page that collects user data and is the one likely to have issues?

Also, what about generic event listener that captures all events rather then trying to use DOM and/or regex to extract elements of the page?

You also need to consider various adblock and alike plugins that sometimes will refuse to load content from different domains/sub-domains unless explicitly permitted. This means for users of those plug-ins your site is broken unless special exceptions are made.
posted on Tuesday, November 21. 2006
#8 Stefan Esser wrote (Link) ()
a) Excuse me, but when was the last time a browser had a bug that allowed cross domain JS? There is only the browser to rely upon. Fact is: Javascript is allowed to do everything on the same domain. It is IMPOSSIBLE for a webapplication to protect a FORM against CSRF if there is a XSS on the same domain. (Unless the FORM contains a CAPTCHA or TAN/PIN)

b) In otherwise secure applications FORMs are the less likely place for XSS to surface. And if you read my post you will see that all the forms are on different domains. This means the XSS in the FORM itself cannot modify the content of the whole page and it cannot access the other FORMs. So the attacker is trapped inside this single FORM.

c) Show me a generic event listener that is able to extract something from a different subdomain

d) Adblock solutions that filter away iframes containing formulars are broken. People using this kind of anti social plugins maybe see a broken page. However many big sites have f.e. images on different hosts that only serve static data. IIRC php.net does the same... So if your point is valid then PHP.net users should have lots of problems...

e) Speaking of Plugins... With something like noscript it would be much easier to disallow JS on all FORM hosts and allow it on the main host.
posted on Wednesday, November 22. 2006
#8.1 Ilia Alshanetsky wrote (Link) ()
a) I'll compile a list of JS cross-domain bypasses in browsers due to bugs.

b) True, if you compromise even one form that's enough to inject content that could be used to submit that form on behalf of the user or simply modify the form's action to send the data to another domain.

c) I'll cookup something using Yahoo lib

d) Some people do have those problems and the answer was to allow from a sub-domain but disallow . I am not saying you will have problems with this approach every time, but you need to keep it in mind.

e) No JS would be nice, httpOnly like flag for forms you suggested in your blog post would be even nicer.
posted on Wednesday, November 22. 2006
#8.1.1 Stefan Esser wrote (Link) ()
Well after looking into the history of Firefox and IE there are indeed a few cross domain vulnerabilities not long ago.

However: Vulnerabilities will always exist. (e.g. why bothering CSRF if there is a remote URL include in the application). But cross domain JS access is considered a vulnerability and when a trick like this comes up it will get fixed in the browsers.

The main problem is: cross domain boundaries are the only way to stop JS. That is atleast the only way using the JS design. Of course it is not 100% perfect because of Browser vulnerabilities, but thats like still using telnet because SSH had more vulnerabilities in the past.
posted on Thursday, November 23. 2006
#9 Gareth Heyes ()
I've been working on a simple solution for comment spam where a unique session id is generated each time a form is displayed that session id is passed in a hidden field on submit using javascript, the session id is compared with that of the hidden field on the next page. Would this not also prevent CSRF as well?

The above solution solved our comment spam problem I also delayed the second page by 20 seconds to annoy spammers. The only downside with it is that javascript is required.

I must be missing something?
posted on Wednesday, November 22. 2006
#9.1 Stefan Esser wrote (Link) ()
Yeah well Gareth, it is all a question of definition.

The moment there is XSS somewhere on your site it isn't CSRF anymore. Therefore my topic is a little bit wrong. However the question is: how do you protect against FORM submission if the attacker is able to inject JavaScript into your site.

In your case the attacker could load the form submission page in an iframe and then hijack your javascript routine to fill in the token, ...
posted on Thursday, November 23. 2006

Add Comment

Standard emoticons like :-) and ;-) are converted to images.
 

Submitted comments will be subject to moderation before being displayed.
 
Calendar
Back August '08 Forward
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Archives
August 2008
July 2008
June 2008
Recent...
Older...
Categories

All categories
Syndicate This Blog
Protected By

Hardening-Patch for PHP