(The series concludes today with guesses about the future of web security. The first, second, and third parts have been published as well as the accompanying slides.)

Design, Doom & Destiny

Mobile devices and apps change they way we consume the web. Even native mobile apps connect to URLs or access web-based APIs.

Who cares about the URL anymore? From QR codes to small screens, there’s minimal real estate to show off a complete link. And all of the padlocks, green text for EVSSL certs, and similar hints are barely useful for desktop browsers.

Mobile app security is currently a nightmare of assorted markets, outright malicious apps, and poorly crafted apps. Mobile apps that interface to web sites don’t always do so securely. And it’s impossible to distinguish bad apps at a glance. Apps that interact with web APIs often employ browser-like features, not a browser. There’s a subtle, but important distinction there.

For example, Twitter’s API is accessible via HTTP or HTTPS. If you use the Twitter web site you can set your account to always use HTTPS. Sadly, that doesn’t affect how apps might use the API. The official Twitter app uses HTTPS. It also refuses to connect if it receives a certificate error. On the other hand, other apps may connect over HTTP, or use HTTPS but not bother to apply certificate validation. A year ago, in 2011, Twitter listed some third-party software projects that used OAuth and Twitter APIs. They ranged in languages from Java to C++ to PHP. Three out of four didn’t even use https:// links. The one that did use https:// didn’t bother to verify the server’s cert.

Update January 15, 2014: Twitter now requires HTTPS access to its API.

Personal data is valuable. In Silicon Valley, the dollar is made of people. We could debate the pros and cons of compliance standards like PCI for credit cards. In an age where companies have billion-dollar valuations based on their user bases, it should be evident that credit cards aren’t the only kind of data coveted by hackers and companies alike. In the last few years several companies have been forced to apologize for privacy breaches or abuse. Set aside the concern about compromise, that was behavior deemed “normal” by the companies in question. Normal until exposed to the scrutiny of the masses.

Privacy is area where HTML5 has tried to balance reasonable design with features users and devs expect from native mobile apps. Before geolocation started showing up in phones or browsers, people could still be tracked by geolocation data marked by cameras in digital photos’ EXIF information. Browser plugins have been abused to create supercookies. It was up to Flash to enforce a privacy policy for its equivalent to the cookie, the Local Shared Object. And, of course, HTML5 has the Web Storage API.

Privacy has to be an area where browsers take the lead on implementing features like providing clear controls for objects stored in a browser and privacy-related headers like Do-Not-Track. The DNT header is another example of browser developers pushing for a new technology, but meeting resistance due to technical as well as business concerns. For example, if 98% of your company’s revenue depends on tracking technologies, then you’ll be sensitive to features like this. Perhaps even reluctant to implement it.

From a design perspective, HTML5 offers many new features that make it easier for web developers to create powerful, useful apps without sacrificing security. The various specs around HTML5 even carry warnings and recommendations about security and privacy for these new technologies.

The implementation of HTML5 will occasionally run into flaws, but that’s to be expected of any large software engineering effort. The use of iframes and sharing resources across documents will likely be a source of problems. At the very least, think in terms of balancing information leakage around framed content. On one hand, it might be desirable to prevent a framed advertising banner from knowing the origin that has framed it. But for sites that aggregate functions (we use to call them mashups), this kind of parent – or child – node information might be useful. And there’s the challenge of making sure a node’s Origin attribute remains stable and correct as complex JavaScript moves it around the DOM, removes it from the DOM, or tries to keep it orphaned and running in the background.

And finally, the password problem has yet to be solved. Regardless of a site’s backend security and use of HTTPS, look how prevalent it is to send the plaintext password from browser to server. That’s begging for some kind of challenge-response that provides better confidentiality for the password. But doing so likely requires browser support and careful design so that there’s clarity around what threats a challenge-response would mitigate and those it wouldn’t. It’s unlikely phishing will disappear any time soon.

There are other positive steps towards password management in the form of OAuth and OpenID. These solutions shift the burden of authentication management from the site to a trusted third-party site. But again we could come up with new threats that this may introduce. For example, strong password security behavior reinforces the idea that you should verify that you’re typing credentials for a site into a form that is served from that site. With OAuth, we’re adjusting the behavior by showing users it’s acceptable to enter important credentials (Google, Facebook, Twitter, etc.) for an unrelated site. There are always going to be engineering problems that don’t have complete technical solutions. Even as users need to remain vigilant about protecting their passwords, developers still need to treat OAuth tokens and the site’s session tokens securely, just as they would passwords.

There are also always going to be ways that secure technologies are used insecurely. HTML5 has done a good job of providing security restrictions or security recommendations. Developers shouldn’t ignore them. Nor should developers forget key principles of secure design, from things like understanding that HTTPS everywhere is good for users’ privacy, but has no bearing on SQL injection or XSS. To maintaining authentication and authorization checks on server-side resources even if the client has similar checks.

Adopt HTML5 now. Start with leading your pages with <!doctype html>. Push your visitors to use a modern web browser. If you don’t have to support IE6, then why bother going through the pain of creating markup for an obsolete browser? Apply trivial headers that only require server-side changes. X-Frame-Options blocks clickjacking (for those using browser that support it). HSTS minimizes sniffing and intermediation threats; we’ll still need secure DNS to make it complete. We can’t just rely on browsers to become better. Sites need to keep up with security improvements. Try enabling only TLS 1.1 and 1.2. See how many sites fail for you.

HTML5 is the promethean technology of the web’s future. Preserving the security and privacy of data from a mobile app or an HTML5 web site should be the driving force behind the app’s design. The implementation of your site and how it applies HTML5’s feature to user data will determine security. Don’t rely on a standards body or browser security to do it for you.