Automation, Dog Food and a Security State of Mind
Something unusual happened recently: I found an XSS problem in the web application controlling our security scans.
Let’s set the stage; I started using the Internet before it was called the Internet. I had some informal security training in college and graduate school, but when I started my first job my boss said “I’m going to make you a security expert.” I’ve used that security training, and kept learning more, in the jobs I’ve had in the thirty years since then.
With my coding background and the Internet’s booming growth my career like many others took a turn towards web development. My first professional web development experience started around 2000, but I’d been dabbling in web development for a few years at that point. Due to my security interest I’ve kept learning about the new attack vectors being developed as websites and web browsers became more complicated.
With my strong security background it would seem obvious that I am constantly aware of security as I develop code and never produce less than secure web applications. Now it’s true that I’ve found various security flaws over the years, but I don’t remember finding any security flaws in Veracode software before this XSS issue, and I know I’ve placed several security flaws in Veracode software.
The reason I’ve messed up and created security flaws is the standard reason: I’m not focusing on security.
When my task is to add a new configuration parameter for Veracode scans:
- I think about the user experience: Where in the configuration does it make sense to ask for the information? Should we only allow one value, or allow many? How should we frame the question to the user? How to ensure the customer enters an appropriate value? After it is entered, how do we display it in our reports in a context the user will understand?
- I think about how to store the data: Do I put in an existing database record or create new records for the information? What data type to use?
- I think about how to send the saved information to our scan engines.
What I don’t focus on is security. I usually get the security correct, but my main goal is making all the parts work together well. And that’s true of most developers most of the time.
So why was this XSS flaw the first security flaw I found?
Simple, we eat our own dog food.
Our coders are human, so we regularly run the code we develop through our own scanners. The security problems I created in the past were found by these scans, and the XSS problem would have been found by another scan. It just happened in this case that I found it first. I wasn’t even looking for security issues. I noticed a new feature had some bugs, and while investigating the scope of the problems I realized there was a security flaw.
I’m glad to know I can still find security flaws, but don’t count on any person thinking about all the details of correct security all the time.
Teach your web developers about web application security so they can fix discovered flaws, but have them focus on their main job–the overall user experience. Have the security checks done separately, and the least expensive method to find most of the problems (and the most commonly exploited security problems) is an automated scan.
And before you get worried: The flaw I found was on a test system, and the code was fixed (and related code checked) before that feature was ever on our production web server.