While sitting is a couple of talks at BlackHat Abu Dhabi, I got to thinking about how we can improve browser defenses. Much of the problems we have are due to the same problem that has plagued systems since Captain Crunch first blew his whistle at 2600 hertz; the data and control channel are the same. Your browser can't tell the difference between attacker injected script and legitimate scripts and happily responds to both. It's what allows XSS and CSRF attacks, and even SQLi. Framebusting is a great example of this, a site owner doesn't want his page to sit in a frame, but has to compete in the arms race against attackers who want the site to be framed. What we need is some way for a site-owner to specify a security policy, that exists outside of the application. The site-owner should be able to specify that the site shouldn't be framed, and the browser respect that, without an attacker able to inject an alternate set of instructions (or at least not trivially via the actual app). Right now, even if a site-owner is aware of the problem, with a smart security team, all they can do is compete in the arms race.

There's a corollary to the problem however, third-party content. The web is made of mashups. Even single-source content providers still include a raft of third-party content, from RSS feeds, to advertising or JQuery. This introduces a whole set of potential interconnected vulnerability that a site owner can't control. If an ad provider is hacked and used to distribute malware, then the site-owner's only choice (if detected) is to remove the ad.

We need something that can give a site owner control back of their application. Something that can be specified outside of the page content. A security policy that puts all the controls we have available to us with software (enforced security policy & ability to disable features not required) back in the hand of the right people. Once we get it, there's a whole separate discussion about how to get it widely supported and implemented, but we would need to agree on what that should be first.

I've been playing with ways of nuking evercookie-style identifier dropping (note: killing the evercookie specifically is silly, I'm aiming for unknown reimplementation too) and have worked some stuff out about LSOs. LSO are Local Storage Objects, they are ways Flash and Silverlight can store info on your machine rather than the remote server. The most common uses appear to be to drop an identifier, which behaves in exactly the same way as a cookie, or to store preferences (e.g. youtube volume settings).

The following information pertains to OSX, I'll get to other OS'es but I imagine their implementations won't vary greatly.

UPDATE: An iPhone developer has turned this into an awesome little SBSetting addon. You'll still need a jailbroken phone but can install it via Cydia.

My previous experiments in killing the Evercookie in Safari sparked similar posts describing how to do the same for Chrome and Firefox. However, my second most frequent browsing platform is my iPhone, and I thought I would investigate how Apple IOS, MobileSafari & embedded WebKit fares. It does much worse. There are two problems; the first is, any app which embeds MobileWebKit has it's own stores for normal cookies, browser cache and HTML5 storage. Even if you go to your Safari settings (Settings -> Safari -> Clear {Cookies|Cache} & Settings -> Safari -> Databases -> Edit -> (delete all present) ) and delete everything, you haven't cleared the cookies, caches & stores in the other apps (e.g. even a simple cookie set for singe.za.net in Twitter.app's embedded browser, will still exist). The second problem is that, in MobileSafari, even if you do clear your MobileSafari store, the HTML5 localStorage mechanism isn't properly cleared and the evercookie reloads itself.

(Hi Slashdot & The Register readers. Make sure to check the 2nd part on killing iPhone Evercookie's too)

Samy Kamar recently released his tool, evercookie. This uses multiple persistent data stores to set unique identifiers that can be used to identify your browser to a website. While my default Firefox browsing setup is safe against it, I noticed that the "disposable" Safari instance I used was not. I sometimes use a clean Safari instance to test or access things the tinfoil on my Firefox does not let me. After each use I reset everything in it. However, I noticed that evercookie would persist. Here's how to delete it and others using the same mechanisms for Safari on OSX 10.6 (working out the same for other browsers/OS' isn't too difficult):

I'll be speaking at IS' Internetix 2010 conference and this was originally posted there. I was asked to put a blog post together as a teaser for my talk.

Privacy is dead, or so the common wisdom says. But that can't be true. Centuries of philosophy tell us that it's vital for our development and existence as human beings. As a trite example, try imagine having a truly intimate conversation with your partner while knowing someone else was listening. But that's not what I want to talk about here. If you want to have that conversation, start with this paper.

It seems my work on privacy has garnered some attention of late. Whether earned or not, I will be presenting at the Computer Security Institute's Virtual Conference CSIVX on the 28th of September. I will be on hand to answer questions, even though it will be some silly hour ZA time. This is technically the first "international" event I've ever "presented (see pre-recorded video for)" at, and it includes the likes of Ira Winkler, Amit Klein and Jeff Williams.

I'll also be presenting on privacy at IS' Internetix2010 conference in both Jozi & Cape Town. Internetix is a rocking conference organised by IS, and I'm chuffed to have been invited. It will be a nice chance to test the privacy stuff with a large non-sec crowd.

Next up, I'll also be presenting a workshop on Threat Modelling off the back of quite a lot of work we (my employer SensePost, and I) have done on it recently. If you want to get an idea of the content, have a look at the last set of slides. It's hosted by the ISF and will be held in Jozi on the 28th.

Finally, I'll most likely be giving the SensePost training at BlackHat Abu Dhabi in Nov. If we get over around 15 people I can justify someone smarter than me from SensePost joining us, so if you're keen for some training, please sign-up :)