After what seems like 900 years in security I just traveled again, and even after all this time, landing in a new role gives me a fresh perspective on another aspect of the problem of IT security. I was fortunate to have the opportunity to join Security Innovation to focus on the problem of making applications secure in the first place after several years of focusing on the problem of finding their security holes. Both are important, but going from the 'attack' side to the application doctor side has been eye opening.
Like any product manager, my first step in the new role was to know my product, in this case, take the classes myself. It’s not like I didn’t know, having been a developer way, way back, but there’s having a concept, and then there’s actually traveling through time and space to be hit with reality. Consider this simple scenario – you are a freshly minted engineer out of college, and your first assignment is a simple page that starts a user registration. You create an input field to ask for the user’s first name, and the echo back: “OK, <first name>, let's get started with registration…”. BANG! ...your first security rift. Easy cross site scripting for a cyberman, just create a scenario with a script tag and a little script in the name field and he owns your user’s browser. They didn’t teach you that in college? Right, exactly the problem.
Looking at the small blue box of your application’s outside, what does it take a hacker to find the problem? Just play with the input field and enter the usual suspects – long input, script tags, special characters, etc. You don’t even have to do it by hand, if you have something like CORE IMPACT you have a sonic screwdriver which will find and open just about any security hole for you by running a couple of wizards.
Opening up the blue box, you find it is much bigger on the inside. What has to be done to make these two lines of code secure? Well about a half a dozen things depending on the language, environment and architecture – constrain the input, strip the output, catch exceptions, make sure you allocated a sufficient buffer and don’t allow it to overrun, be careful with integer/pointer arithmetic, don’t use format string functions for the output, and defintely don't allow the application to go back on its own time line. That’s a big inside for one little field.
Fortunately, it isn’t as bad as it sounds. With the right knowledge and reference to it when you need it, writing the code securely from the beginning becomes just part of the process. This also improves the code overall making testing and deployment go much more smoothly, reducing security bugs as well as functional and performance bugs, resulting in less work and time spent overall. How’s that for fixing time and space, Doctor?
