How to Get Into Application Security

It’s been more than 20 years since I began my career. I started out working on updating Windows 95 client software, managing the BNC network cabling and getting Windows NT VPN working with partners in other countries. The Internet was just emerging, and I also built my first webpage for this company: grey background; nice little moving gifs; horizontal bars; and all the crazy stuff you did to webpages back then.

When Security Wasn’t a Thought

A few years later, I found myself working for a “new market” company building web applications using PHP, MySQL, Linux and Apache. At that time, PHP was seen as well-suited to building “complex” web applications.

I was focused on building dynamic content from a database or template system, and was solely concerned with performance, not with security at all. Back then, all you had to take care of was performance, building web apps that were able to provide the right amount of data in a reasonable time, as well as keeping in mind that personal Internet connections were still at a speed of maybe two line ISDN 128 kilo bit. My company at that time had an amazingly fast 2 mega bit fixed line!

As my career progressed, I continued building more applications. And I say “building” here -- as at that time nobody was thinking about a software development life cycle! Yes, there was a test server to do some internal tests, but most of the time, changes were done directly in production.

Security Emerges

The application that first introduced me to application security was a community, á la Facebook. With this app, users were required to register, were able to use a set of features and, of course, could delete their profiles. As the number of registered users grew, I learned the hard way what application security is about.

We started receiving emails from users in our support mailbox letting us know that their account wasn’t available anymore, and asking why it was purged without any notification. The first few emails were mainly ignored, as we believed the user mistakenly clicked a button, or something similar. But as we got more and more emails, we noticed a significant reduction in registered users within a two-day timeframe. No wanting to risk losing even more users, we put up the infamous “under construction” page while an investigation took place.

Logfile analysis was a mess, consisting of manually crawling the logfiles and searching for certain keywords and user IDs. Finally the issue was found. As I said before, a user profile could easily be deleted by clicking a simple button. The page/script was called with a very simple http request:

https://www.ace.com/deleteUser.php?id=12345.

Never questioning our users’ honesty and, of course, not thinking about security at all, this script simply did a SQL query like “delete from users where ID=$user_ID”. Basically, every web site visitor could simply open this page and delete users by providing a valid user ID!

Ok, lesson learned -- “never trust user supplied input”!

A pretty easy check was implemented to verify that the supplied user ID belonged to the user requesting this page. In addition, another check was implemented to redirect all non-authenticated users to the start page.

We relaunched the full application only after maybe a day, yes I know a full day, but a day out of service for a consumer-only application wasn’t a big deal 20 years ago! Everybody was happy leaving the company in the evening, only to be shocked the next morning again. When I arrived in the office, the CEO was at my desk telling me that there is not a single registered user in our community anymore! He wasn’t amused.

The same process as before was put in place, and the logfile grabbing started again. Luckily it was just a few hours of logfiles, and we identified the issue. There were really strange SQL commands in my logfile. At first, I thought it was a programming mistake on our side related to the integration of the two new user checks. As it turned out, I had just seen my very first, in the wild SQL injection attack!

Luckily, I had a database backup available, and the app was up and running after a few hours again. But that SQL injection attack made me want to learn more about application security and how to avoid those types of attacks.

Pursuing Security

Not surprisingly, the next step in my professional career was getting into IT security. I spent quite a lot of time working for an IT security consulting company responsible for antivirus. I slowly moved into statefull inspection firewalls, IDS/IPS systems, and built the first penetration testing offering for that company.

Still, I was looking for a solution to secure applications like the community app that was breached. There was a relatively new way of doing so, Web Application Firewalls. As you can guess, this was the next step for me, and I moved into the WAF business. I stayed there quite a long time, but always with the thought that modern WAFs are still not really able to secure web applications as they should. They are very prone to false positives and false negatives. And performance is always a problem.

Enter AppSec

And that long path has led me here at Veracode, where I have finally found what I consider the best and most effective way to secure web applications and prevent SQL injection attacks, like the one I was subject to so many years ago. I strongly believe that a comprehensive program that features application security testing, full integration into the SDLC, along with continuous learning for developers, is the answer to the application security problem. Application security has a long way to go, but I think we’re on the right path and look forward to continuing the journey.

Have you ever introduced a vulnerability? Do tell! Share your security horror stories (and laugh at others') at the Veracode Community.