It seems to be obvious but apparently this idea still isn’t common knowledge — HTTP Referer header is unreliable, and it is especially unsuited for any security measures. The Referer header isn’t always present because of users going to a page directly (via bookmark and similar), using an “unusual” browser (most commonly download helper applications), using filtering firewalls (privacy protection) etc. The Referer header might be incorrect because of the same filtering firewalls (some prefer to advertise rather than remove the header entirely), special browser extensions to manipulate the Referer header etc.
And in addition to that we also have the fact that referring websites can remove the Referer header with tricks like META refresh. With slightly more advanced tricks these websites can even send POST requests without a Referer header. Sending a fake Referer header is harder but in the past it was possible via XMLHttpRequest or Flash — and it still might be possible somehow.
pdp over at GNUCITIZEN claims to have found a vulnerability in some common OpenID libraries. And I really tried hard to understand what he means and how it is related to the title of the article. In the end, I got the impression that he simply explains in a lengthy way that anybody could run an OpenID server and use it to log into OpenID-enabled services without having to register. Now isn’t this the whole purpose of OpenID?
Apparently, I wasn’t the only one who got this impression — while the first commenter totally misinterpreted the article (which wasn’t hard), the second comment was already: “Isn’t this by design?” And pdp answered confirming that my interpretation of his article was correct, the point being really about authentication with OpenID being easier than registration (no captcha and the like). So why didn’t he just tell that, in one simple sentence rather than 7 (seven!) paragraphs of text? Why talk about CSRF, OpenID libraries or hijacking when apparently none of them have anything to do with the issue? Why providing a meaningless piece of code only to obfuscate the meaning even further?
A little more than half a year ago I wrote an article on how security solutions using whitelists are better than those using blacklists. At the same time I noted that even using whitelists is not always enough — for example when your whitelist is predictable and the attacker can make sure the whitelisting rule applies to him. NoScript extension was the example I used, and its author reacted by adding “XSS protection” assuming that this would invalidate my claims.
Webmasters probably know one particularly “helpful” feature of Internet Explorer — if you happen to misconfigure your web server and it sends HTML files designated as text files, Internet Explorer will silently correct this mistake and display the files anyway. Of course, if you wanted to display HTML as text (because you want to show the source code, or because it really is a text file with HTML snippets in it) it still will be displayed as HTML. And if you, as a user of a non-IE browser, ever came across a misconfigured server that displays HTML/images/Flash as plain text — now you know why nobody bothered fixing the mistake. This feature is called “MIME sniffing” and many articles have been written about it, so I don’t need to repeat them.
However, there is a less known side of MIME sniffing. Have a look at this image. Doesn’t look dangerous, right? Now try to open it in Internet Explorer. What happened? As it comes out, MIME sniffing in Internet Explorer isn’t limited to text files. If it finds anything resembling HTML code in images it will interpret the image as an HTML page. In this case a comment in the image contains a SCRIPT tag, and Internet Explorer promptly executes the script. This opens an XSS vulnerability in any site that allows users to upload images (many forums do).
The Chilling Effect is quite interesting read (yes, the article is a few months old but I only discovered it now). It shows nicely how security research on web applications is different from research on software you install on your computer. It also shows why responsible disclosure of vulnerabilities is so rare in this field. I also find it very interesting how it explains that most software is of a low quality.
Disclamer: This post is only about using NoScript as a security solution, not as a way to block annoyances.
I had a lengthy discussion with Giorgio Maone (author of the NoScript extension) about what is a security solution and what isn’t. Starting point was my statement that, while being excellent for getting rid of annoyances, neither Adblock Plus nor NoScript are really security solutions. Both have the potential, so why not?
Let’s look at the easier case first: Adblock Plus. Adblock Plus is structured as a blacklist, you usually specify the addresses that you don’t want to load. So if there is a security issue that can be solved by blocking a certain address you will have to add a filter for this address. Requiring an action for each single vulnerability discovered disqualifies Adblock Plus, a real security solution would need to block everything unless explicitly allowed. Right now only the extremely rare case of malware-infested ads would be blocked by default however.
What is this about? In this particular case somebody tried to use a security hole in an older phpBB version to execute PHP code loaded from another server. I had several hundreds of entries like this one in the last month, targeting vulnerabilities in all kinds of PHP scripts (most of which are not even installed here). The attackers tried to install backdoors, defacement tools or in one case a simple script to send all e-mail addresses from the local phpBB installation to its owner. The requests are usually done by other web servers, I guess those have the backdoor already installed (a botnet).
I recently linked to an article stating that users of Internet Explorer have been exposed to known critical vulnerabilities for 284 days last year. That sounds bad enough but unfortunately it is not all. For example I came across a vulnerability in Internet Explorer that has been ranked “Less critical” for reasons I don’t understand. What this does — it basically eliminates same-origin checks, any web site can read contents of another site. I put up an example that can check whether you are logged in on Google or Yahoo and read out your user name — provided that you use Internet Explorer. It could just as well read out your mail or change your mail password. It could also go into your banking account if you happen to be logged in. Information on this vulnerability has been published April last year and still unpatched in both Internet Explorer 6.0 and 7.0.