Do we trust client-side security?

Many respected experts prior to me, including Bruce Schneier, have explained the faults of trusting client-side software. Not trusting the client has been widely accepted for a long time. And in kind I’ve repeated the mantra “never ever ever ever trust the client (or user-supplied content)” many times when it comes to web application security. Then I found myself reading one of RSnake’s posts and something he wrote caused me think about client-side security in a new way. It occurred to me that maybe we’re wrong. Maybe we already do trust the client, or in our case here the web browser. And maybe we have no choice but to continue doing so.

RSnake:
"I guess we have pretty much completely broken the same domain policies of yesterday. If I can scan your Intranet application from an HTML page without JavaScript or Java or any DHTML content whatsoever I think it’s time to start revisiting the entire DOM security model. That might just be my opinion but come on. What else do we have to do to prove it’s not working?"

He’s right of course. In the past 18 months it seems everything web browser related has been hacked. The same-origin policy, cookie security policy, history protection, the intranet boundary, extension models, flash security, location bar trust, and other sensitive areas have all been exposed. Web security models are completely broken and heck it’s spooky to even click on links these days. If we didn’t/don’t rely on client-side (browser) security, none of these discoveries would have mattered and none of us would have cared. But we do! Why is that?

You see when a user logs-in to a website, the first thing they must have is a reasonable assurance that the web page their visiting is from whom it claims to be. It could easily be a phishing site. Without a visually trustable location bar, SSL/TLS lock symbol, or HTML hyperlink display the user could be tricked into handing over their username/password to an attacker. Which of course could in-turn be used to illegally access our websites. Website security depends on the user not being *easily* tricked, but this does happen hundreds or maybe thousands of times a day.

This moves us to transport security. We don’t want sensitive data compromised by an attacker sniffing the web-browser-web server connection. If for some reason the browser has a faulty implementation of SSL/TLS (it happens) the crypto can be cracked and any sensitive data our website collects could fall into the wrong hands. Our website may remain safe and sound, but the data isn’t and that’s really the whole idea. Websites are relying on the browser to have a solid SSL/TLS implementation otherwise back to plaintext we go.

In exchange for a correct username/password combination the user’s browser receives for a cookie storing their session ID. The browser is the protector of this important key because if it’s stolen, then likely the user account and their data go with it. The website is trusting that the same-origin and cookie security policies imposed by the browser will keep the session ID (cookies) safe. But anyone familiar with XSS, using some JavaScript and Flash Malware, know that is hardly the case. And besides browser vulnerabilities routinely exposed this information through exploits. No joy here.

Another example is websites rely on web browsers to safeguard history/cache/bookmarks/passwords and everything else containing sensitive information or granting access to it. And as we well know, all of these areas are again routinely exposed through browser vulnerability exploits or clever JavaScript Malware hacks. Inside the browser walls is everything an attacker needs to hack our websites. Websites become highly dependent on web browsers keeping this data safe. Unfortunately they rarely do.

So maybe we are already trusting client-side (web browser) security. And with the web security models being set-up the way they are, we probably have to keep doing so for years to come.