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.
4 comments:
There's a saying in Yiddish: "A Bi Gezunt"
;-)
Run with least-privilege and/or inside a sandbox.
For least-privilege be sure to read
http://www.matasano.com/log/589/the-least-privilege-delusion/
I haven't tried these sandboxes yet (nor PMIE) but here are some links anyways:
http://www.trustware.com/
http://www.greenborder.com/
http://www.getspyblock.com/
http://www.ecsl.cs.sunysb.edu/fvm/
At first I thought you were right. and than I read it once more, and abother, and now I think you got it all wrong.
You're confusing client side security with security boundaries.
when I browse my bank account it is the bank which uses the rule no client side security. I don't even have a say in the security architecture, I'm outside the security design.
when the bank trusts my home computer it's because they decided their security boundary ends there. client side security is a rule within the security design, whereas what you're refering to is beyond the security design (usually) it is not always the case though.
you do have a good point though. setting a boundary for your security design does not mean that the threats you don't deal with won't hit you.
Anonymous,
I was trying to write from the perspective of the website owner, rather than from the user. Your right, the user has little security choice when it comes to security and "trust". Sometimes reading and writing in this style gets confusing. :)
Post a Comment