Brad Hill (@hillbrad) works at PayPal work works with the W3C on security issues.
You can’t read anything about security without huge hyperbole about HTML security. Is it correct? Brad says no. The state of security on the web is better than it’s ever been an HTML5 is largely responsible for that.
Script injectiong (or XSS, or “Cross Site Scripting”) is the most common application vulnerability (~ 95% of all web apps).
“If someone else’s code gets to run in you’re web app, it’s not your web app anymore.”
- Input filtering – strip dangerous stuff
- Output filtering – encode user data so it isn’t treated as markup
There is more of this in HTML5 (hence the hyperbole), but these filters were already broken.
Book on this subject: Web Application Obfuscation.
“XSS filters were doomed from the start.”
Because: browsers are different, algorithms were secret, browsers have proprietary features, etc.
HTML5 now has an “official” parsing model (for the first time). By standardizing this, it’s a posture change in security on the web.
— Tim Hettler (@timhettler) February 22, 2013
Content Security Policy (invented by Mozilla, now in W3C). HTTP header to enforce, in the client, a least-privilege environment for scripts and other content. Not a new idea. Brad relates this to the story of Homer, who ties himself to the mast and tells everyone to to listen to anything he says.
The Content Security Policy is like a set of instructions (whitelist/blacklist) of things to ignore/allow. For example, only allow scripts from this domain. Only allow iframes from these other domains (perhaps YouTube and Vimeo). Only allow fonts from these other domains (perhaps your CDN). Reminds me of an app cache manifest file. I had no idea this existed. Apply via meta tag.
Templating is the most common pattern of construction web applications. “They are a hive of XSS vulnerabilities”. There is a new spec for templates that solves this.
These type of apps incorporate content from multiple origines under one. Pretty much every app is this, in one way or another.
In the past, Flash allowed this because it had a
“A star (“*”) in your crossdomain.xml is a huge disaster.”
— Faruk Ateş (@KuraFire) February 22, 2013
How do you do cross domain in HTML? There has always been a loophole. You can load a script from another domain, and you can put content in that script to use. (JSONP). Brad has been worried about this for a long time but nobody was listening. They listened when Facebook had a huge problem with it a few weeks ago.
Cross-Origin Resource Sharing (CORS) (been around 4-6 years) is the way forward from this.
— Kevin Marks (@kevinmarks) February 22, 2013
“Voluntarily relax the Same-Origin Policy.”
Some say “beware the promiscuous asterisk” in CORS as well, but it’s actually much less of a big deal.
If you need data from elsewhere, there are more options.
- Sandboxed iframes –
<iframe sandbox="allow-scripts" src="different.domain"></iframe>
- postMessage –
window.parent.postMessage(loginName, "trusted.mydomain.com");, test when you get it
“The most important paper in web security in a long time:” Privilege Separation in HTML5 Applications (PDF) by Devdatta Akhawe, Prateek Saxena, and Dawn Song.
“Treat your own code like a mashup.”
There is TONS coming to the future of security. Future = bright.