Example-driven Insecurity Illustrates Need for WAF

Learning online is big. Especially for those who self-identify as a developer. If you take a peek at Stack Overflow’s annual developer survey (in which they get tens of thousands of responses) you’ll find a good portion of developers that are not formally trained:

• Among current professional developers globally, 76.5% of respondents said they had a bachelor’s degree or higher, such as a Master’s degree or equivalent.
• 20.9% said they had majored in other fields such as business, the social sciences, natural sciences, non-computer engineering, or the arts.
• Of current professional developers, 32% said their formal education was not very important or not important at all to their career success. This is not entirely surprising given that 90% of developers overall consider themselves at least somewhat self-taught: a formal degree is only one aspect of their education, and so much of their practical day-to-day work depends on their company’s individual tech stack decisions.

Note the highlighted portion from the survey results. I could write a thesis on why this is true, but suffice to say that when I was studying for my bachelor’s, I wrote in Pascal, C++, and LISP. My first real dev job required C/C++, so I was good there. But later I was required to learn Java. And SQL. I didn’t go back to school to do that. I turned to books and help files and whatever other documentation I could get my hands on. Self-taught is the norm whether you’re formally educated or not, because technology changes and professionals don’t have the time to go back to school just to learn a new language or framework.

This is not uncommon at all, for any of us, I suspect. We don’t go back to school to learn a new CLI or API. We don’t sign up for a new degree just to learn Python or Node.js. We turn to books and content on the Internet, to communities, and we rely heavily on “example code.”

I still rely on blogs and documentation, not just from our own engineers and architects, but other folks, too. Because signing up for a Ph.D now isn’t really going to help learn me* the ins and outs of the Express framework or JQuery.

It’s no surprise then that network engineers and operations (who, being the party of the first part of the second wave of DevOps, shall henceforth be known as NetOps) are also likely to turn to the same types of materials to obtain those skills they need to be proficient with the tools and technologies required. That’s scripting languages and APIs, for those just tuning in. And they, too, will no doubt copy and paste their hearts out as they become familiar with the language and systems beginning to automate the production pipeline.

And so we come to the reason I write today. Example code.

There’s a lot of it. And it’s good code, don’t walk away thinking I am unappreciative or don’t value example code. It’s an invaluable resource for anyone trying to learn new languages and APIs. What I am going to growl about is that there’s a disconnect between the example code and security that needs to be addressed. Because as we’re teaching new folks to code, we should also be instilling in them at least an awareness of security, rather than blatantly ignoring it.

I say this because app security is not – repeat NOT – optional. I could throw stat after stat after stat but I hope at this point I’m preaching to the choir. App security is not optional, and it is important to promulgate that attitude until it’s viewed as part and parcel to development. Not just apps, mind you, but the scripts and systems driving automation at the fingertips of DevOps and NetOps.

I present as the source of my angst this example. 

The code itself is beautiful. Really. Well formatted, nice spacing. Readable. I love this code. Except the part that completely violates Security Rule Zero.

THOU SHALT NOT TRUST USER INPUT. EVER.

I’m disappointed that there’s not even a head nod to the need to sanitize the input. Not in the comments nor in the article’s text. The code just passes on “username” to another function with nary a concern that it might contain malicious content.

But Lori, obviously this code is meant to illustrate implementation of some thing that isn’t designed to actually go into production. It’s not a risk.

That is not the point. The point is that if we continue to teach folks to code we ought to at least make an attempt to teach them to do it securely. To mention it as routinely as one points out to developers new to C/C++ that if you don’t allocate memory to a pointer before accessing it, it’s going to crash.

I could fill blog after blog with examples of how security and the SDLC is given lip-service but when it comes down to brass-tacks and teaching folks to code, it’s suddenly alone in a corner with an SEP (somebody else’s problem) field around it.

This is just another reason why web application firewalls are a critical component to any app security strategy. Organizations need a fire break between user input and the apps that blindly accept it as legitimate to avoid becoming the latest victim of a lengthy list of app security holes.

Because as much as we like to talk about securing code, when we actually teach it to others we don’t walk the walk. We need to be more aware of this lack of attention to security – even in example code, because that’s where developers (and increasingly NetOps) learn – but until we start doing it, we need security solutions like WAF to fill in the gaps left by insecure code.
 

* Or English, apparently. Oh come on, I do that on purpose. Because sometimes it’s fun to say it wrong.