By: Patrick Toomey
The vast majority of the applications we assess are web based. Sure, we look at our fair share of client-server applications, but I would say the ratio is probably on the order of 10 to 1. For whatever reason, we had a string of more traditional client-server applications on our plate in the last few weeks. Looking at the types of vulnerabilities identified in these applications, as well as other similar applications we have reviewed in the past, it seems as though there is fundamental gap in how a fair percentage of these developers are approaching security. To illustrate, let’s listen in on a couple of web developers discussing a few pieces of their security architecture for a new web app they are about to deploy.
Web Dev 1: So, we need to check to make sure only authenticated and authorized users are allowed to access our app.
Web Dev 2: Yeah, it seems like this whole username password thing is pretty popular. I vote we go with that.
Web Dev 1: Ok, yeah, no need to reinvent the wheel here. So, how should we go about validating the user’s username and password?
Web Dev 1: Yeah, that is awesome; with a little more effort we almost don’t need an application server. We can do everything client-side.
Web Dev 2: Hmmm, yeah, it sounds pretty great, but we are putting a lot of our eggs into one basket. What if someone figures out how view or manipulate traffic as it traverses the network. They might be able to do bad stuff.
Web Dev 1: Yeah, true, there must be some way to prevent our users from mucking around with the network traffic.
Web Dev 2: I got it!! We can use SSL. That uses top notch cryptography that nobody can break.
Web Dev 1: I think we have it. But, I thought I remember reading about some sort of tool that lets user’s man in the middle their own SSL traffic, something to do with proxies and self-signed certificates or something?
Web Dev 2: Hmmmm….that could be a problem, but it sounds like it would be really hard for users to do.
Web Dev 1: Yeah, nobody will figure it out. I think we are good to go.
Ok, the above conversation is obviously hyperbolic for effect, but can you get what I am saying here? The above conversation just wouldn’t happen in a web app world. Almost every sentence is filled with principles that are antithetical to the web security model. Validating passwords on the client-side in the browser, connecting directly to the database from the browser (thankfully this doesn’t exist…I googled it just to make sure there wasn’t some inept RFC I wasn’t aware of), or treating SSL like it is some sort of magic crypto juju you can sprinkle over your application to protect yourself against users that have full control of the execution environment.
I have seen some web applications in a pretty sad state of disrepair, but I have never seen a web application that was architected with all of the above fundamental flaws. Sadly, on the client-server side of things I have seen each of the above approaches used with regularity. Applications that validate passwords by requesting them from the server, applications that treat the server simply as an ODBC connection, and applications that depend on SSL as their sole security control for preventing malicious user input and/or the disclosure of highly sensitive information (ex. those passwords being send back to the client from the server). So, in short, if you are writing a client-server application, think of your client as the browser, and treat it with the same degree of trepidation. The client cannot be trusted to enforce your security policy, and any expectation that it will do so is likely to result in an architectural flaw that may very well subvert the entirety of your security model.