The Harry Callahan Postulate

What kind of weight do you put in different browser defenses?

  • Process separation?
  • Plugin isolation and sandboxes?
  • Tab isolation?
  • X-Frame-Options, X-XSS-Protection? Built-in reflected XSS protection? NoScript?
  • HSTS, HPKP?
  • Automatic updates?
  • Anti-virus? Safe browsing lists?

Instead of creating a matrix to compare browsers, versions, and operating systems try adopting the Harry Callahan Postulate:

Launch your browser. Open one tab for your web-based email, another for your online bank. Login to both. Then click on one of the shortened links below. Being as this is the world wide web, the most dangerous web in the world, and would blow your data clean apart, you’ve got to ask yourself one question: Do I feel lucky?

Well, do ya punk?

http://bit.ly/SAFEST

. . .

Clicking on links is how the web works. It’s a default assumption that users are expected to click links, and it’s a disproportionate security burden to expect them to scrutinize the characters, TLS hygiene, or provenance of links.

If the presence or absence of a single lock icon conveys ambiguous meaning about “security”, then attempting to discern multiple characters will be even harder. That lock icon is more about identity, i.e. “this is the app your browser is talking to”, than security in the sense of, “it is safe to give information to this app.”

In an ideal world, we should be able to click on any link without risk of that action impacting the security context or relationship with an app unassociated with the origin in that link.

Think of this like an Other Origin Policy for the persona associated with each app you use. Other origins shouldn’t have an unintended effect on the security context of another. When it does have an intended effect, it should be an interactive one that requires an explicit approval from the user.  It shouldn’t be a silent killer. (Well-informed approval is yet another challenge.)

Even so, CSRF countermeasures can’t protect against social engineering attacks and many effective XSS exploits happily work within the Same Origin Policy.

AlchemistIn this real world, users must keep their browsers up to date, they should remove historically vulnerable and ever-contaminated plugins like Flash and Java. But they must also rely on browser vendors to build software with strong isolation. They must rely on app developers to implement resilient designs like enforcing HTTPS connections, implementing pervasive anti-CSRF tokens, and offering multi-factor authentication.

With such distributed responsibility, it’s not hard to see why errors happen. The Other Origin Policy is an aspirational goal. With effective appsec, clicking on a malicious link should lead to nothing worse than an, “Oops!”.

Eventually, you’ll feel comfortable enough to click on any link. Until then, we’ll have to continue educating users, creating safe default behaviors and safe default decisions within browsers, and improving the security architecture of apps.

3 thoughts on “The Harry Callahan Postulate”

  1. You can get an informational page for a bit.ly link, including the destination URL and page title, by appending a plus sign to the URL. So, for example, navigating to http://bit.ly/ddoHd8+ will inform you that it links to an MSDN article about JSON without actually taking you there.

    I rather like the appropriateness of SAFEST’s referent, given its name.

    Out of curiosity, what’s A6Ca targeting? It looks like some kind of NAT gateway, given the IP. If I had to guess I’d say it’s a Linksys home router.

  2. [Spoilers!] A6Ca was taken from a CSRF example. It’s meant to show how a link on the Internet can affect your intranet — even your very own home router. (And it’s quite old by now that that even though it’s “weaponized” it shouldn’t affect anyone who pays minimal attention to security updates or security settings.)

Comments are closed.