Recently I gave a talk on web application security to a group of new developers, and in a twist from how I normally live-code & improvise, I used a slide deck. I realized that no matter how entertaining it might be to see some live exploitation and run through some code, it's probably not the best way to approach the subject for people entering development roles. With that in mind (and 30 hours or so before I had to present), I completely scrapped what I originally planned on doing and instead chose some of the biggest threats I think an average programmer needs to be aware of.
Stupidly I also promised a comprehensive writeup, of which this is an introduction & teaser. Take a look at the slides to get an idea of what subjects I'll be covering the next few weeks and months. Infosec professionals shouldn't be expecting to learn anything new here, though I welcome your input, but anyone who's starting to work as a software developer in any field, looking at creating a startup, or just wanting to be aware of real-world security concerns will find plenty of new, useful information here.
Why I do stress startups and new developers especially? In my experience, security gets treated like car maintenance or flossing - everyone knows it's helpful and important, but will avoid actually doing it til a deadline comes up. The other side of the coin, especially with developers, is that they think writing secure code is "hard" or have had limited enough exposure they don't even know where to start. There's a few reasons this is wrong, if not dangerous:
- Cyber attacks are prevalent and increasing - there's proven money in it
- Black markets for credentials and 0-days[1] are thriving
- Many common security flaws are pretty easy to avoid
- Making a habit out of secure behavior means it becomes effortless
- Deadlines in security are potentially business-ending if not met
- Reactive security means you're already a victim
Those last two points are particularly relevant to you as a business owner, and something you should ask new hires or cofounders if you're the non-technical part of the operation. Even at a large company that has its own security team, new devs, you should be aware that you'll have to meet their standards - regularly failing security reviews means your code doesn't make it to production and costs everyone time & money.
Time & money being the key things you have to weigh when you consider security concerns. At its core, security is about risk management. You as a developer can negate a lot of risk with minimal effort; it's downright irresponsible not to spend an hour or two making sure some script kiddy can't steal your customers' data.
Like I said, this is just a teaser: Keep an eye out for the next post in this series, discussing rules of thumb and common classes of vulnerabilities.
0-day refers to a vulnerability that was released 0 days ago, ie: is unknown and usable on most systems ↩