Joe Walker - csrf tag

Fixing browser security: SameRefererOnly

Tue, 07 Aug 2007 12:33:55 GMT

Web security is horribly broken, and lot has been said about CSRF, XSS, DNS-Pinning, etc, but not enough about what we can do to fix the mess.

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

The official spec for Set-Cookie is RFC 2109/2965 which says this:

Set-Cookie: <name>=<value>[; <name>=<value>][; expires=<date>] \
            [; domain=<domain_name>][; path=<some_path>][; secure]

Microsoft's HttpOnly spec adds this to the end:

            [; HttpOnly]

I propose that we further add this:

            [; SameRefererOnly]

Any cookie marked SameRefererOnly MUST only be sent to servers when the domain of the cookie matches the referring domain. The cookie MUST NOT be sent when there is no referring domain (this might help to prevent CSRF / Phishing mash-ups).

It's worth noting that this protection breaks in the presence of XSS flaws in a site, because XSSed commands come from the compromised domain, however that does not make this protection useless.

Plug-ins like Java and Flash that have their own HTTP pipelines generally don't send cookies so these systems probably do not need to be patched.

This proposal has 3 places where it can come in handy:

As an additional defence-in-depth layer of protection for a site that already has other CSRF protection.
On an Intranet site where access through browsers that implement SameRefererOnly can be mandated
In a future world where enough browsers implement this, that other browsers can be excluded.

Note on spelling: The pedant might note that this should be spelt SameReferrerOnly - i.e. with a double 'r', and the pedant would normally be correct however this misspelling is so common that the HTTP spec makes it, and hence we all follow unquestioningly.

I'm sure there must be some holes in this suggestion, but I make it anyway so someone can move the discussion on.

CSRF, Anti-DNS Pinning and NTLM

Wed, 18 Apr 2007 09:22:26 GMT

Mark Goodwin has written a neat discussion of the extra problems that CSRF causes when used alongside DNS pinning attacks and against intranets that use NTLM authentication (AKA Integrated Windows Auth)

The short version is that you might be able to use CSRF and anti-DNS pinning attacks to steal resources from an intranet, including those that need auth NTML authentication.

Getahead predates DWR by quite a while, and Mark has worked with me on a few projects. For the past few years he's been a serious security head, and he's just started blogging.

I'm not going to link to all his posts, so if you are interested in security; subscribe, and I'll get on with the Ajax and Java stuff.

How to Protect a JSON or Javascript Service

Wed, 04 Apr 2007 08:32:14 GMT

There have been lots of explanations recently of the dangers of JSON or JavaScript remoting. This post is about what you can do to protect your scripts.

The Problem

The issues have been explained before, so I'm going to assume some knowledge of the problem. If you're not sure, some stuff to read:

I blogged that JSON is not as safe as people think it is, and updated it with more issues the next day. I've also written about CSRF too.
Dan Morrill has written an excellent and lengthy summary. The fixes are focused on GWT, but the issues are the same for everyone.
Brent Ashley has just published on developerWorks, about the future of cross-domain requests. The article is tangentially relevant, but there is a particularly good set of linked articles.

The Solutions

So what are the solutions? I think there are 3 options. Each has their pros and cons:

Use a Secret in the Request
Force pre-eval() Processing
Force POST requests

This post is a shortened version of the detailed description of what DWR does If you are interested in the options DWR takes and how you can configure it, you should read page.

1. Use a Secret in the Request

If you can only support one of these protections, this is the one to chose. Including a secret in the request allows the server to reject the request as invalid before any actions take place. It is common to include the secret in the URL, however this is a slightly vulnerable position for a secret since it is likely to turn up in web server log files and so on.

It is possible to use cookie values like PHPSESSIONID or JSESSIONID read using Javascript as the secret. The browsers cross-domain rules should prevent attackers from discovering this cookie. However this method will stop working as people begin to switch to using HttpOnly cookies. So it is better to start with a separate secret.

2. Force pre-eval() Processing

Since <script> tag remoting does not allow you to process the JSON or Javascript before it is eval()ed you can protect your JSON by forcing it to be manipulated before eval(). All 3 of these techniques will prevent your request from being pure JSON, however you may rank security above purity. There are 3 ways to do this:

Wrap the JSON in a comment. For example, /* { 'data':'protected' } */. When this is eval()ed, there will be no result, however if you have fetched the data using XHR or iframe, you can do some string manipulation before eval() to remove the leading /* and trailing */.
This method is good for plain JSON, however if you are using Javascript which could contain /* comments */, then you should not use this technique because comments in Javascript do not nest.
Prefix the script with 'while(1);' Since this is an infinite loop, if causes browsers to hang, and maybe give an error message. Either way the script does not get executed.
There is a potential vulnerability that some browser may allow you to override the action of while using something like this: 'function while() {}'. However I don't know of any such browser.
Google use this method to protect data in GMail. 'while(1);' is possibly better than 'while(true);' in case there are any browsers that allow you to redefine truth.
Prefix the script with 'throw new Error("message");'. This is a neat solution in that it allows you to explain what is wrong to users that get the message by mistake. DWR uses this method.
It is potentially vulnerable to some browser allowing an attacker to redefine the Error or String constructors to prevent the throw from happening, however this does not work on any browser that I know of, and it's hard to see how it could happen.

3. Force POST Requests

Since browsers use GET to process <script> tags, you can prevent <script> tags from working by denying GET requests for some JavaScript resource. This is the most common solution, however it is also perhaps the weakest.

Firstly XHR-POST doesn't work with older versions of Safari, so some support for GET is often useful.

More importantly future versions of Firefox are touted to include cross-domain XHR support. While we don't have exact knowledge of how this will happen, it would be foolish to base your security plans on this technique holding up.

Finally, we're working in an environment where new possibilities are popping up every day - betting your security on a system that works more by fluke than design isn't a great idea in my opinion.

By default DWR denies POST requests for belt and braces security, however this is customizable to allow support for older versions of Safari.

JSON is not as safe as people think it is

Mon, 05 Mar 2007 19:31:52 GMT

I saw some discussion recently about using JSON for secured data, and I'm not sure that everyone understands the risks.

I believe that JSON is unsafe for anything but public data unless you are using unpredictable URLs.

There are 2 problems. CSRF (Cross Site Request Fogery) allows attackers to bypass cookie based authentication. I blogged about it a while ago. Wikipedia talks about it. CSRF allows you to invoke cookie protected actions on a remote server. It allows Mr. Evil to trick Mrs. Innocent into transferring money from her bank account into his.

Far less known perhaps, is the JSON/Array hack that allows a user to steal JSON data on Mozilla and any other platform with a modern JavaScript interpreter.

Update: It's not just Arrays - it you can steal data from objects too.

There are many ways to fetch data from a server, but the interesting cases here are: XHR, iframe and script-tags. Without knowledge of the JSON/Array hack it's easy to reason like this:

XHR: Browser cross-domain rules prevent the attacker from making the request in the first place.
iframe: The attacker can embed an iframe that points at some remote server (the bank in the above example) and ask to be sent some JSON, but browser cross-domain rules prevent scripts from the attackers domain from reading the reply, so the JSON is safe because it will never be eval()ed.
Script-Tags: The attacker can embed a script tag pointing at a remote server and the browser will effectively eval() the reply for you, however it throws away the response and since JSON is all response, you're safe.

It's the last of these arguments that is suspect. The dynamic nature of JavaScript will let you redefine how the browser evaluates the JSON.

Here's how it works, and you can follow along with any JavaScript console:

Redefine the Array constructor:
```
function Array() { alert("hi"); }
```
Verify that this constructor is called when arrays are created:
```
var a = [ 43 ];
```

Use the new feature to manipulate the array:

function Array() {
  this[1] = 50;
}
var a = [40];
alert(a[0] + a[1]); // Gives 90

So we can call secure JSON data using CSRF with a script tag to by-pass the cookie authentication, and then use the JSON/Array hack to steal the JavaScript data from the browser as it processes the script-tag.

So we've redefined the Array constructor, how do we actually get the data out? The syntax below works in current versions of Firefox, although from my reading of the spec proposals, it's not a part of Javascript 2, and it appears to fail in IE/Safari/Opera.

Create a web page at evil.com, with a couple of script tags like this:

<script type='text/javascript'>
function Array() {
  var obj = this;
  var ind = 0;
  var getNext = function(x) {
    obj[ind++] setter = getNext;
    if (x) alert(Data stolen from array: " + x.toString());
  };
  this[ind++] setter = getNext;
}
</script>
<script type='text/javascript' src='http://bank.com/jsonservice'> </script>

As a demo, I've redefined the Array constructor in this page, so if you're on Firefox, you should get an alert dialog from the following script: . Update: This was killing Google Analytics, which we added later, so I've removed the array hack script from this page.

(If you're reading this in a blog aggregator, then the script above should have been stripped out, so it won't work. You need to try it on this page. If the script has not been stripped, get a new aggregator - your current one has a horrible security flaw.)

The long and short is that JSON is not safe in any system that uses cookies for authentication.

With DWR we use full JavaScript which is as vulnerable as JSON, however DWR's CSRF protection automatically uses the doubly-submitted cookie pattern to provide extra safety.

I'm by no means the first person to think of this; Jeremiah Grossman used it to break GMail over a year ago.

Update: If you are doing JSON 100% properly, then you will only have objects at the top level. Arrays, Strings, Numbers, etc will all be wrapped. A JSON object will then fail to eval() because the JavaScript interpreter will think it's looking at a block rather than an object. This goes a long way to protecting against these attacks, however it's still best to protect your secure data with un-predictable URLs.

CSRF Pharming

Thu, 08 Feb 2007 09:14:56 GMT

In short: If you still have the default password on your router then go and change it now. Don't stop to read this post before you change it.

This post describes an attack that combines CSRF with an older technique - Pharming (see particularly the section on "Pharming vulnerability at home").

CSRF allows an attacker to script an attack on a foreign website, this could potentially be used against a user's home router to change DNS settings, and affect a pharming attack by DNS poisoning. Having altered the DNS settings for a victim, they are at heightened risk of man-in-the-middle attacks, phishing and cookie theft.

CSRF Pharming makes use of the fact that a large number of home routers have the default passwords unchanged. However default passwords are easy to find. There are several lists of default passwords in home routers published on the internet. Google ranks one at phenoelit.de highly. My guess is that something like 25% of home users have default passwords set on their routers.

Exploiting the Flaw

The victim of a CSRF Pharming attack visits a web page that has been created or manipulated by an attacker to include some Javascript that uses CSRF to pass the default admin username and password to the default IP address of a number of common home routers. Sometimes the attack is simple enough that Javascript is not required and a single iframe resource is all that is needed.

Having altered the DNS settings to query an alternative DNS server, the attacker can provide accurate IP addresses for most queries, but fake IP addresses for banking and other important services. The users are then at heightened risk of man-in-the-middle attacks, phishing and cookie theft.

The attacker can use a number of CSS based techniques to detect routers or it can simply cycle through all known vulnerable routers since each attack is fairly quick.

There are 2 methods of authentication used in most home routers: http-auth and form/cookie.

http-auth

Routers using http-auth are vulnerable to attacks from older browsers that allow URLs with the following style: http://<username>:<password>@<address>/ This allows scripted access to http-auth protected resources.

Routers from the following manufacturers use http-auth: DLink, Modern Netgear and Linksys.

For some routers a single line of HTML is all that is required:

<iframe src="http://admin:@192.168.0.1/cgi-bin/prim?attack-params-here"></iframe>

form/cookie

Using CSRF it is possible to script a sequence of URLs, although it is not possible to read the responses. Routers using form/cookie authentication are susceptible attacks from almost any web browser with Javascript enabled.

Routers from the following manufacturers use form/cookie authentication: Belkin, Buffalo, SMC, Asante, Zyxel and reportedly Older Netgear and Linksys routers.

Issues for the Attacker

An attacker wishing to exploit this problem must discover a URL sequence which affects each model of home router. Frequently sets of routers from a manufacturer will use similar firmware, so often an attack will work across a large number of router models. Knowledge of the attack URL sequences can be easily shared.

An attacker must also persuade a user to view some attack HTML. There are a number of mechanisms by which this may happen. Spyware vendors have had significant success placing spyware in many websites around the internet. Since this attack does not require the website to host binaries it may also be possible to host the attack-HTML on bulletin boards.

Protection

The only side effect of the attack is altered DNS settings in the router, so detecting the attack is hard. Detection probably involves making assumptions about the correct IP settings and comparing with those found from a lookup.

Patching home routers to protect them from CSRF attacks is unlikely to be successful since it is generally too complex a task for many users.

Altering browsers to not allow URL based http-auth will not protect against all CSRF attacks, and has been done in most common browsers.

The best current solution is for users is to change the password on their router. Since many users will know less about their routers than their attackers, this is still tricky.

It may be possible for trusted websites to detect default passwords on vulnerable routers by attempting to read a protected resource like an image, using Javascript and CSS to read image attributes like 'clientWidth', and then using the reported values to infer if the image read was successful. A trusted website could then re-direct the user to a page with instructions on how to change the router password. This technique, whist technically possible does come with some legal challenges - could this be classed as 'hacking'?

Website owners can provide some extra protection by using HTTPS. An attacker may be able to redirect web traffic using this attack, however they are theoretically not able to provide SSL certificates to match the spoofed URL. This protection does rely on user's ability to recognize correct HTTPS connections. This would be a shaky reliance.

The credit for applying these techniques to pharming should really go to Mark Goodwin who had the original idea, although Jeremiah Grossman wrote about using CSRF against network devices first; he comes very close to it in this paper without actually mentioning it specifically.