Tuesday, August 7th, 2007

Fixing browser security: SameRefererOnly, and DNS Pinning

Category: Security

<p>Joe Walker has spoked about adding SameRefererOnly to the cookie spec.

I think we could adapt an idea like HttpOnly to tackle CSRF – I’d like to see a “SameRefererOnly” marker for cookies.

SameRefererOnly is an indication that a cookie should only be sent to a Site when the referring domain is the same as the destination domain.

A number of people have commented that you could use server based referer checking to fix CSRF, however that doesn’t work for 2 reasons, firstly sometimes referers are not sent, and secondly using old versions of Flash, you can forge referer headers anyway.

However if we move the checking into the browser, then we should be able to instruct browsers to be more careful what they do without our cookies.

In other security news, Christian Matthies has explained DNS Pinning which includes pretty pictures:

Related Content:

Posted by Dion Almaer at 12:26 pm
8 Comments

+++--
3.9 rating from 19 votes

8 Comments »

Comments feed TrackBack URI

However if we move the checking into the browser, then we should be able to instruct browsers to be more careful what they do without our cookies.

We have no control over the browser. A malicious actor could be writing out posts and gets by hand and sending them along via telnet/netcat for all we know. Or our users could be running a custom build of firefox that some attacker provided them via a Man in the Middle attack when they upgraded.

Trusting that the user agent will provide security solutions for us is naive. The only environment we have any amount of control over is the server. And that’s the only place we have any amount of confidence that our application is running the way we like it.

The browser is a great place to do things we aren’t depending on going as planned from a security standpoint. But only that.

Comment by tack — August 7, 2007

Why not use a per session token part of the url. The token will be validated before performing an action on the server side and that way there is no way a hacker site would be able to make a request forgery call as it cannot get (or guess) the per session token.

Comment by Kishore Senji — August 8, 2007

CSRF is a problem that crops up because *someone-elses* browser isn’t as careful with cookies as you would like it to be. The hand-roll issue isn’t relevant here.

If you are hand-rolling requests and as a result of sending requests to 2 websites at the same time get conned by one into sending a request to the other that you didn’t want to, then you deserve all you get. This proposal does not help that situation.

Comment by Joe Walker — August 8, 2007

I was not talking about hand-rolling issue. From the reason, that was mentioned for the Referers not working, it sounded like a hacker website embeds a link to a genuine site that the user already logged in to (in another tab or used remember me). The cookies are sent to the genuine site and things are done on behalf of the hacker site by the consent of the user without the user knowing it. For this thing you mentioned Referrer is not a good idea because they can be compromised as well. So, that why I was referring to always expect a token in all the urls. If the genuine site is visited by the user, all the urls would have tokens in them. If the hacker site tries to embed a link to that genuine site the hacker site cannot possible form a valid url to execute the CSRF stuff. Please let me know if I’m missing something here.

Comment by Kishore Senji — August 8, 2007

@Kishore: my earlier reply was to tack
Putting security features into URLs might work. It’s probably dangerous because URLs get mailed around, bookmarked, and probably other things.
The real point however is that you should not need to do it. If all browsers supported SameRefererOnly you could just flip the switch and be done.

Comment by Joe Walker — August 8, 2007

and can you check out Host header in your application?
Like here: http://www.servletsuite.com/servlets/hostflt.htm
On the picture above: Host header still points to the original site, rather than to attacked. So site can simply discard requests with a wrong Host header

Comment by Dmitry — August 8, 2007

My hand-rolling example was there just to bring up the point that you can’t trust that the client side will play ball. Not as an example of a specific attack in this context. Joe Walker proves my point unintentionally:
If all browsers supported SameRefererOnly you could just flip the switch and be done.
All browsers supporting something… the same way… are we kidding ourselves? We can’t even be sure that what we’re dealing with is a browser at all. Depending on a client side app to solve our security problems is unwise.

Comment by tack — August 8, 2007

Putting security features into URLs might work. It’s probably dangerous because URLs get mailed around, bookmarked, and probably other things.
The real point however is that you should not need to do it. If all browsers supported SameRefererOnly you could just flip the switch and be done.

Comment by legoitalia — February 18, 2011

Leave a comment

You must be logged in to post a comment.