Update to Single-Site-Browsers (SSBs)

I spent a lot more time thinking about SSBs over the last week or so and I’d like to use this blog to do a bit of a brain dump. A few days ago, Andrew Jaquith publicly posted the presentation that was sent me to privately. Here are links to his blog and to his presentation.

His presentation makes a number of claims about the security benefits of SSBs. It lists protection against phishing, CSRF, some types of XSS (likely all non-persistent varieties), and domain whitelisting as a future improvement to harden those protections.

I don’t think [current] SSBs completely provide those security benefits unless you do two things:

1. You block non-SSBs from accessing your website (blocking on user agent string would be enough)
2. You train users that an SSB is the only acceptable place to enter their password

Without those two requirements satisfied, it is my opinion that SSBs give little security benefit.

If you still allow non-SSBs to access citibank.com, then when a user clicks an XSS’d link to citibank.com, the citibank.com page will still load, and they will still be XSS’d. Similarly, CSRF continues to function as it is likely that the ’session cookie isolation’ benefit of SSBs are negated by the user likely having duplicate cookies in both their SSB and in Firefox (you must ensure the user never logs into citibank.com with their normal browser and obtain a session cookie there, hence the first requirement).

In order for the phishing protection to be effective, users must be aware that they are only supposed to encounter Citibank content in their SSB and not in their normal browser. For instance, if an SSB user encounters a Citibank phishing website in Firefox, will they close their browser and open their SSB instead? It might be the case that users will behave in this way, but I haven’t seen any verifiable proof either way.

[This hasn't been reported on ISIS Blogs yet, but next week marks the end of our first run of "The Psychology of Security/Social Engineering", a first-run research course here at Poly. I'm writing up a research proposal to test the above hypothesis with a group of students in the Fall.]

Lastly, if a bank starts deploying SSBs to their customers, I see this as a first step towards successfully forcing client-side requirements on users where the end-game is fully trusted computing and the open commercial web starts to disappear. This actually goes back to our “Refusing Insecure Customers” debate. It’s an evolution of the same (bad, according to readers) idea.

So, although I see where SSBs have some use and can positively affect your web security, let’s not kid ourselves, they don’t solve that much. To really be effective, they require major changes in the way you do business and [still] rely on an intelligent user. Rather, they look like avoidance of the base problem and an idealistic patch that isn’t going to work.

Oddly enough, I have been using a set of 4 Prism SSBs for the last 2 weeks and have actually grown fond of them, but not for security reasons at all. I like how they show up in my dock, that they rarely crash, and it seems natural to give such webapps “first-class” status as desktop applications. I’ll probably continue using them, but I don’t think I’ve gained any security from doing so.

That said, I think part of the problem here is that SSBs haven’t fully matured yet. I just heard about these things 2 weeks ago and I haven’t heard anyone else in the security community talking about them besides Andrew. They are a topic that deserves more attention and particularly more research from the security community as they embody a lot of attractive ideas. Despite my harsh words, I’m not ready to give up on them yet.

Let’s brainstorm: how could SSBs be more useful to security? Could we change the way they work or change how they are deployed to give us additional benefits? If you’re an InfoSec student with no good topic to research, this is without a doubt a good avenue to explore.