Comments on: Fixing browser security: SameRefererOnly, and DNS Pinning

By: legoitalia

legoitalia — Fri, 18 Feb 2011 06:42:25 +0000

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.

By: tack

tack — Wed, 08 Aug 2007 18:47:30 +0000

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.

By: Dmitry

Dmitry — Wed, 08 Aug 2007 10:14:25 +0000

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

By: Joe Walker

Joe Walker — Wed, 08 Aug 2007 09:11:02 +0000

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

By: Kishore Senji

Kishore Senji — Wed, 08 Aug 2007 07:32:18 +0000

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.

By: Joe Walker

Joe Walker — Wed, 08 Aug 2007 07:02:43 +0000

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.

By: Kishore Senji

Kishore Senji — Wed, 08 Aug 2007 06:57:01 +0000

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.

By: tack

tack — Wed, 08 Aug 2007 00:16:01 +0000

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.