WebApp Security and Lock Picking: Things Aren’t That Different by Matt
Woah, application security and picking locks- sounds like the topic of lunchtime conversation at DEFCON. When it comes to exploitation, attacks, vulnerabilities, and mitigation techniques, security in any field is really all the same. Sometimes explaining web application security is difficult, but it seems when we match it with something more tangible, like the hard steel of locks, some sense comes to life. Lets start with a “hypothesis”, and then look at some worthy comparisons between 1′s & 0′s, and padlocks & handcuffs.
Before we try to explain that, lets talk a little about how a lock works. A lock has a set number of pins inside (anywhere between 5-7 pins for a normal lock), each cut to a specific height. When a key with the correct pattern is inserted all the pins line up straight and allow the lock mechanism to rotate (see more at How Stuff Works). The problem for someone without a key is that they need to manually manipulate each pin to the correct height in order to get the lock to rotate/open.
So lets start with a simple comparison, we can easily see that the more pins in a lock, the harder it is to pick. Along with this, the more random the pin-heights, the harder the lock will be to pick. Sound familiar? In web application security we use bit-length (each bit is a technically “layer” of security) and randomness all the time. Consider how we encode passwords to save in a database, the most common hash’s are MD5, and SHA1, which are as a standard are a 128-bit vs. 160-bit encryption (respectively). Quick Tip: Anything encoded for the US Government must be at least as secure as the SHA1 encryption, MD5 is unacceptable. Lets see an example:
Well, indeed MD5 is a shorter encryption, and in turn less secure if we were to try to break it using “brute force”- having server upon server running automated scripts using good ole’ trial and error. Lock pickers use brute force all the time, one method uses these nifty “jiggler keys”:
These keys are made for car door locks. As you can see there is some randomness between each key, and the idea is that when you put that into the door lock, “jiggle and twist”, but the time you give each pattern a couple minutes you find one that works- brute force at it’s finest!
Handcuffs are a well-known lock that display some layers of security. Instead of six or seven pins, handcuffs have one simple lever- yes, society trusts that if you are dumb enough to get arrested, you are not smart enough to bypass a single-lever mechanism. However, consider the more transparent layers of security related to handcuffs:
Be pro-active, strip and clean anything that could damage the application. Give as little information about the way the application is built as possible; hide file extensions and handle all errors. Lastly, watch and react; if you get 100 requests from an IP address in China in 3 minutes, block it. As developers we must try our best to put the attacker at a disadvantage by using layers, remember some of these when building a web application:
Layers, The Future, and You.
We believe one large part in the evolution of web security is summed up in agreat quote from an OWASP Podcast we recently listened to, “If someone was throwing rocks at your house window, you wouldn’t just sit there and be happy your windows are strong, you would call the police or go after the person. We don’t do this in web application security yet.” One idea we are currently piloting at Prime Studios is a “that’s weird” database; we add a simple line to our XSS (Cross Site Scripting) filtering, our CRSF (Cross Site Request Forgery) filters, and authentication systems to monitor for anything that we would say “that’s weird” to. It doesn’t sound like much, but if we see a lot of login failures or broken form tokens over a certain time period, we can take action on a particular user, IP address, User Agent, or a mix of all of them.
Everyone likes elegant solutions, but unfortunately with web application security we can’t just rely on a single [Godly] plugin or framework to handle all our security needs. The first step is knowing what to look for (education), and then you can start building your own methods for a strong security policy throughout your applications (implementation). Hit up the following links for some more great web application security tips:
Improving Web Application Security
July 6, 2010
Comments