Last week I delivered a talk at the fantastic WebDU conference which focused on an area that I have been becoming increasingly concerned about over the last while – security in the browser. Unlike other areas of the web platform that have well defined and effective security mechanisms (SSL/TLS, firewalls, strong passwords, access control) the melting pot of HTML, CSS, Javascript that runs within the browser is increasingly being shown to be a weak link.

Photo courtesy of http://www.flickr.com/photos/webdu
The talk, aimed at a technical audience, hopes to raise awareness of the issues and solutions and makes the points that we as web developers carry a lot of the responsibility for minimising the impact and extent of the problem.
As I’ve gone through the process of publishing this presentation online I’ve been concerned about the loss of context that comes with publishing the slides alone. I’m still waiting to hear whether the conference organisers will be publishing the audio (or if it was recorded), but I will post a link if and when it is [UPDATE: Geoff has posted the link to the audio below!]. In the meantime, there are some footnotes below to give extra context, I’ve also collected up all the links I used for reseach at http://delicious.com/markstanton/js-security and comments and questions are welcome.
- Inpsiration for this talk came from a conversation with Doug Crockford after a presentation he gave at Web Directions South last year and from another presentation by Simon Willison I stumbled across a week or two later. Both of those presentations are worth checking out if you are working in this area. Google’s Browser Security Handbook is also essential reading.
- MySpace pursued Samy for his actions and in 2007 Samy was found guilty and sentenced to 3 years probation and 90 days community service. While this was a spectacular example of a JS based attack I’m certainly not advocating this sort of thing.
- Developers need to think about where all their data comes from, not just focus on form and url data. If you are syndicating feeds or pulling data from some back office system it should be treated with the same care & caution as online input.
- The context switching idea is key and needs to be clearly understood. The “I only allow some HTML” is generally a sign you need to look more closely at what you are doing. You think you’re only allowing HTML, but are you really sure? http://ha.ckers.org/xss.html is a useful resource for testing to see if context can be switched. OWASP have a good explanation of what context switching is and how it works.
- The demo is an over simplification. Part of the points I was trying to make here is that there is a level of trust between users and the sites they use – if a site is compromised this trust is open to abuse. The greater the level of trust the higher the risks.
- The full GMail/CSRF/stolen domain story from the victims perspective is at http://www.davidairey.com/google-gmail-security-hijack/. Scary stuff.
- The “don’t click” story is at http://softwareas.com/explaining-the-dont-click-clickjacking-tweetbomb. This is the only case of this type of attack that I am aware of.
- The question mark after 100% safe on the EASPI slide referrers to the fact that developers would need to use it 100% correctly 100% of the time which is unlikely unless you have good unit testing practices in place.
- Don’t look for one way to protect your site – protect it in as many ways as you can. The landscape is changing so what works today might not be 100% fail-safe next year. Start with the things that are easiest to implement in your environment and go from there.




July 23rd, 2009 at 11:56 am
You can get many of the session recordings online via the webdu session podcast — including “Be Afraid, Be Very Afraid”
Enjoy!
http://www.webdu.com.au/mxsession/feeditunes
July 28th, 2009 at 8:47 am
Thanks Geoff!