Wednesday, February 02, 2011

Web Browsers and Opt-In Security

The last decade has taught us much about computer and information security. We’ve learned the importance of Secure-By-Default because people rarely harden their “security” settings as standard practice. We’re also painfully aware that security is often a trade-off between functionality and usability, which requires a balance be made. Ideally this balance is decided between what level of security a product claims and the customer’s expectations. Operating systems and Web servers have taken a strong supporting stance with regards to Secure-By-Default. Web browsers, well, I think there is much room for improvement.

Let’s look at recent outcomes shall we. According to CA Technologies, "Browser-based exploits accounted for 84% of the total actively exploited known vulnerabilities in the wild." Other industry reports support these findings including, "Of the top-attacked vulnerabilities that Symantec observed in 2009, four of the top five being exploited were client-side vulnerabilities that were frequently targeted by Web-based attacks." 2010 wasn’t much different. This is typically the result of a combination of imperfect software and not keeping browsers & plug-in patches up-to-date.

Even in this context the browser vendors (Google, Microsoft, and Mozilla) should still be given a lot credit for having been vastly improved the overall security of their software in the last two or so years. They have better development practices, publish regular and timely patches, included easy scheduled update mechanisms, added anti-malware/phishing features, sandboxes, and bounty programs. Collectively speaking anyway, but that's where it ends. All great benefits that users receive automatically and/or enabled by default. That is, Secure-By-Default. Memory handling issues aside, where these protections mainly focus, are still many extremely devastating attack classes where users have practically zero ability to defend themselves.

I'm talking about Intranet Hacking, DNS Rebinding, Clickjacking (UI Redressing), Cross-Site Scripting, Cross-Site Request Forgery, CSS History Leaks, and WiFi Man-in-the Middle. I see these as being the most pressing. They break the back of the Same-Origin-Policy, the very foundation of browser security, and there’s evidence that most of these have been used maliciously in the wild. A malicious website can easily detect what websites a visitor is logged-in to, what sites they’ve recently visited, take over their online bank/email/socialnetwork/etc accounts, hack into their DSL router or corporate intranet. Or maybe the attacker wants to get the victim in legal trouble by forcing them to attack other systems, post spam, download illegal content, and so on.

Sure, an individual user can defend themselves with add-ons like NoScript, Adblock Plus, LastPass, Better Privacy and so on, of which I’m a fan and user. To reiterate though, this is in no way a demonstration of Secure-by-Default! Users have to first be aware, download the application, install, and finally configure. The reality is most users don’t know these attackers are possible and even easy to perform. Only the readers of this blog and the browser vendors themselves do. So from a 10,000ft view of Web security, if a protection feature is not enabled by default then it doesn’t matter. Case in point...

To combat these issues, keep the security-minded elite mildly happy, and show that "something" is being done, there’s a mile long list of well intentioned security features that extremely few people outside of out tiny Web security sphere have heard of let alone implemented. HTTP Strict Transport Security, SECURE cookie flag, httpOnly cookies, X-FRAME-OPTIONS header, Origin header, Do-Not-Track header, disable form AutoComplete, iFrame security restriction, Content Security Policy, privacy modes, hidden configuration settings, delete browser data, cookie controls, LSO controls, etc. All of these are opt-in, invisible or buried several mouse-clicks deep in the GUI, and likely implemented differently. No wonder "The Need for Coherent Web Security Policy Framework(s)" was published.

There are lots of competing arguments about why these things haven't been or shouldn't be formally adopted. My intention here is not to rehash those, but instead remind us all about the bigger picture. I mean, it is simply amazing how much we are able to do online with just a browser. We can shop, bank, pay bills, file taxes, share photos, keep in touch with friends and family, watch movies, play games, and so much more. Browsers are the most important connection we have to the Internet. And the “we” is a stunning two billion people strong. Clearly browsers play a vital role in online security. Everyone needs a Web browser that is not only fast and stable, but secure as well. Only it is difficult to say that they are (or have been)... secure. That needs to change, somehow, someway, and preferably soon.

15 comments:

Ericlaw said...

Some discussion of the value of Declarative security policies can be found here: http://blogs.msdn.com/b/ie/archive/2009/06/25/declaring-security.aspx

The Compatibility vs. Security tradeoff is often misunderstood. Users will remain on insecure browser versions if more secure versions break compatibility with things they care about. Declarative policies are one way to avoid this Catch-22.

Jeremiah Grossman said...

@Ericlaw: thanks for commenting. I think your Backwards Compatibility vs. Security trade-off explanation is much more succinct of the challenge than mine. At the same time as you point out in the post, a major drawback is "Adoption."

We've been trading in security for backwards compatibility in the browser space for so long and look where we are. When do we swing back the other way? I think I already know the answer. Unfortunately like always its when the attacks starts visibly happening and the motivation for change is clear as day.

Aaron Bryson said...

Amen!

Newer browser's are simply more secure than older version as aforementioned by Jeremiah with all it's built-in security features. However, the compatibility issues are not because of these new security features or the fact they use to be non-existent, but because of the inconsistency to follow a standard.

Not to play the blame game, but if you take a look at IE7 & IE8...web developers had to put in all these work-arounds, hacks, and snippets of code just to get certain things working in IE7. Well, when IE8 changed the way it handled certain code, all the previously coded web pages that had finally made themselves work with IE7 (read a majority of the internet) now stopped working in IE8. Lots of web developers are upset that all their websites that took a lot of extra work to make IE7 compatible, is now IE8 compatible.

Well, what good is a new browser that doesn't work with the majority of the internet? It's worthless. But it is not feasible for Microsoft to ask the entire internet to recode their now-broken-webpages to be IE8 compatible, so instead the created the "Compatibility View" feature in IE8. It is a necessary feature for the IE8 product to be backwards compatible with the IE7 internet so that the product could actually be used.

There is a trade-off between security and usability, however, this could have been avoided if the would stop flip-flopping and just decide if they are going to use a standard or not. It seems like Microsoft wanted to be the one to set that standard and assumed the internet would follow, and they did, and now Microsoft backed out of its' own standard to go with something else. Just make up your mind Microsoft!!!

I hope that makes sense.

Unknown said...

Oops typo (I should have proof read)...

This should say:

"Lots of web developers are upset that all their websites that took a lot of extra work to make IE7 compatible, is now IE8 INcompatible."

Anonymous said...

All the browser add-ons you are listing are nice tools but do not provide "secure by default" experience either. In fact, configuring them to improve security while not causing significant fallout on legit websites requires a security expert, not a regular user. Which is why browsers will most certainly not adopt these approaches.

What is missing are robust solutions for the problems that you mentioned that will work out of the box without configuring and without breaking the web. Mozilla finally found a way to fix the CSS history leak albeit a complicated one. Same needs to be done for the other issues.

But how does one fix XSS for example? With persistent XSS the browser doesn't have a chance, it looks like a regular website. With reflective XSS one can try - and MSIE did. I don't know for sure but my impression is that they failed to detect XSS reliably enough to make an impact. Which is probably what will happen to any browser-based attempt to solving XSS, websites tend to shoot themselves in the foot in too many different ways. If anything, the <jail> tag proposal (or whatever it mutated into now) might work - but it is still not spec'ed out and anyway, a web developer who would use it is aware of XSS issues which makes him an exception (most problematic websites were created by developers who are absolutely clueless).

As mentioned in the comments above, breaking the web isn't an option. Any single browser vendor who attempted to do it would see a significant decrease in his market share. Even if all major browser vendors would agree on an approach, many users would simply refuse to update - and create a bigger problem than all the issues you mentioned currently present.

Jeremiah Grossman said...

@Aaron: As Wladimir said, there is a careful balancing act that the browser vendors are playing. While reasonable people can disagree where to place the dividing line. For me personally, I think it worth breaking some stuff. The reality is the bad guys will face the issue soon enough.

@Wladimir: IMHO, in which you'd no doubt agree, Adblock Plus could easily be integrated and enabled by default. This would lead to much increased security and privacy, without breaking much of anything. Not to mention users would like it! So, why haven't they done this do you think?

Anonymous said...

In the meantime, is there a good document to guide a Firefox user who wants to maximize security with a combination of downloads and browser settings?

Andy Steingruebl said...

Jeremiah,

http://securityretentive.blogspot.com/2011/02/no-browser-is-island.html

Now I have to go and respond to Eric too :)

Aaron Bryson said...

Jeremiah: I agree that breaking things temporarily to get everyone on a standard, would be best in the long run, and also for the greater good. It would make life easier for web developers if there was consistency in browser behavior! SIGH....a man can dream.

dan said...

"Adblock Plus could easily be integrated and enabled by default. This would lead to much increased security and privacy, without breaking much of anything. Not to mention users would like it! So, why haven't they done this do you think?"

Um... Because the advertisers pay the bills? Like it or not, advertisers and their networks are "users" too.

Since we've been waiting on micro-payments since about 94, with little progress, it might not be time to opt us all out of advertising quite yet.

So, the thing you are breaking is the monetization scheme that the content owners/providers have bought into. Not to go all Rand'dian on you - but that's the engine.

On the other hand, maybe the signal to noise ratio goes up after you get rid of all the advertising supported content, swapping facebook for PBS so to speak. Maybe we should try it. :)

But I think I'd tire of the "wikithons" after a bit...

Jeremiah Grossman said...

@Dan: Your right, there’s really no denying that the most popular Web browsers right now are designed first to facilitate advertising delivery, everything else comes second. Apple, Google, and Microsoft are all major players in online advertising. Even Mozilla receives the bulk of their revenue from advertising, by way of Google.

Personally, I’ve got no problem with ads. But let’s face it, online advertising is synonymous with tracking. Default tracking without a user's knowledge or consent is creepy and invasive. If a someone decides to supply personal information in exchange for accessing a free web service -- that’s fine, it should be there choice. However, their privacy should be protected by default. I think browser users deserve to have an easy and accessible way to choose who to give their data to and when (by turning on ads).

Adblock Plus seemed like the natural choice.

Anonymous said...

Jeremiah, we have been discussing integrating Adblock Plus a while ago. This required quite significant time investment on my part however and I simply didn't have that much time.

Fact is, Adblock Plus user interface is still much too complicated for a mainstream browser (I am working on it). And even if one were to strip away all configurability - it relies on filter lists that can and will cause issues occasionally. It's these issues that are the biggest problem, an inexperienced user rarely has a chance to resolve them by himself. And I doubt that "site X works fine in Chrome but is entirely broken in Firefox" is something anybody wants to hear.

Jeremiah Grossman said...

@Wladimir: I'll of course have to take your word for it as you see the bug reports. However, I've been an Adblock Plus user for a long time and can't think of a single occasion where it noticeably "broke" a website. Adblock might miss an add here or there, but no big deal. On rare occasions some sites ask me to turn it off temporarily but that's about it.

What do you think is likelihood of being able to resolve the concerns you have and make it ready for everyone?

Anonymous said...

It is possible but it is a large project - one that Mozilla will not invest into as long as the Adblock Plus project is alive and kicking. If Adblock Plus suddenly deteriorated they would have to find a solution. But for now there are other priorities.

john said...

new browsers are really secure in old version.
developer friendly brower is internet explore7..