Discussing software, the web, politics, sexuality and the unending supply of human stupidity.


Firefox 52 adding insecure form warnings

The latest version of Firefox’s Developer Edition (formerly known as Aurora) now ships with more prominent warnings for when you send passwords from an insecure context. For a long time, some sites have attempted to justify having login forms on insecure HTTP pages with the argument that the credentials would be encrypted in transmission as they were being sent to an HTTPS endpoint. The problem with this is that it doesn’t actually prevent password sniffing, it just makes it slightly harder. Rather than sniffing the credentials as they go over the wire, you instead use a man-in-the-middle attack to intercept the HTTP page and insert JavaScript into it that sniffs the password upon entry and then sends it via Ajax to the interceptor.

Firefox’s new implementation uses a fairly simple algorithm described in the new W3C Secure Contexts spec that is attempting to standardise some of the key concepts of browser-side security. Hopefully, users being warned that they are submitting passwords insecurely will start prompting websites to stop doing the login-form-on-HTTP-that-submits-via-HTTPS anti-pattern.

My usual go-to example when illustrating the problem is airline websites, specifically the online checkin or frequent flyer account login page. You give airlines quite substantial amounts of money and personal information. For a long time, most were vulnerable to this kind of attack. Malicious hackers also have been known to steal and sell frequent flyer miles, although not necessarily though man-in-the-middle attacks on the login forms.

British Airways used to have a login form for their Executive Club frequent flyer programme on their homepage—they’ve now fixed this and the whole site seems to be HTTPS.

But the following (mostly randomly selected) airlines still are vulnerable to man-in-the-middle password stealing through JavaScript injection.

And that’s just one sector: airlines. There’s plenty more sites that ordinary people use everyday that have potential vulnerabilities caused by these purportedly-secure-but-really-not login forms. Browsers giving prominent and irritating warnings about it is the first step to getting the companies to pay attention.

When the next big attack happens, there will–as always–be non-technical people from government and business lamenting how difficult all this information security stuff is, and how the vectors of attack are always changing. Let it be on the record that this kind of vulnerability is extremely simple, well-known and relatively easy to exploit. There are interesting and ingenious ways to attack Transport Layer Security, but if you don’t turn it on to start with, one doesn’t need to DROWN POODLEs or really do anything that will make technical people go “ooh, that’s clever”. Firefox warning users about this really old and boring way of breaking user security might mean that people spend less time speculating about the scary difficult emerging threats and fix the basic glaring security errors right in front of them.

If you do Rails, add fresh_when to your controllers. This will let you generate ETags and Last-Modified headers. Which means that browsers can cache stuff. And you can… implement AppCache.

Or perhaps not. Using fresh_when caused me to get AbstractController::DoubleRenderError in Rails 3. Any ideas?

@t linked me to @veganstraightedge’s take on JSON-LD.

I disagree that JSON-LD is “unneeded”.

In an ideal world, we’d switch to putting data inside HTML. But lots of people seem to think JSON is useful. (There’s a reason microformats2 parsing is specified with reference to transforming it into a JSON document.) JSON APIs are an existing practice.

The reason JSON-LD is useful stems from the simple fact that (a) lots of people publish JSON, and (b) it’d be quite useful if we could actually layer a bit of semantics on top of that. Combined with something like Hydra, it means we might not have to write a special snowflake RubyGem or Python library or JAR or whatever for each different web service out there.

While JSON APIs continue to exist, I’d rather have self-describing, semantically-rich RESTful JSON APIs than the crap I see created by programmers who keep on reinventing the damn wheel badly.