On the Lambda

Programming, Technology, and Systems Administration

On the Lambda

Four basic security lessons for undergrad CS Students

February 17th, 2014 · 2 Comments · development

Security is a huge problem in the IT industry. It seems like we hear almost weekly about a new systems breach resulting in the leak of millions of user accounts. The recent breaches at Target and Kickstarter come to mind, and those are just the ones that made news. Often this is actually more of a people problem than a technology problem: of convincing non-technical employees the importance of following correct security procedures, and of convincing non-technical managers to allow developers to make the proper security investments. But many of these are the result of easily-correctable technical issues.

When looking at student work, I don’t expect them to be hardcore security experts. But I do expect that students have learned four basic lessons by the time they finish their undergrad work. Those lessons are, in no particular order:

1. A general idea of the correct way to store passwords.
Probably this general idea will be slightly wrong, but that’s okay. A recent grad is unlikely to be asked to build a new authentication system from the ground up. However, they should know enough to raise red flags if they see something done horribly wrong, and they should know enough to follow what’s going on if asked to fix a bug in an existing system. Getting down to nuts and bolts, the student should understand the difference between encrypting and hashing, they should know to use bcrypt or scrypt (or least not to use md5), and they should know they need a per-user salt.

2. How to avoid Sql Injection Attacks
Or, put another way, how to use sql query parameters in their platform of choice. This assumes, of course, that students have at least some exposure to databases as part of their degree (they should). Sql Injection should be part of that exposure.

I also take issue with that standard comic on the subject (see here). The problem is that it talks about sanitizing database inputs, and that’s just the wrong approach. If you’re thinking, “sanitize”, you’ve already lost; it implies you should write code that examines user input and removes bad things, which is the wrong approach. Real sql injection security lies in quarantining unsafe data. And, yes, I do think undergrad students should know the difference.

Quarantined data does not need to be sanitized. There can be all kings of attempted bad things in the data, but if the programmer used a mechanism that transmits this data to the database in a completely separate data block from the sql query, the chances of that data being executed as code drop to 0%. On the other hand, the chances of a bug, logical flaw, or ignorance of a potential exploit creeping into sanitizing code? Significantly higher.

3. How to avoid Cross-site Scripting / Cross-site Request Forgery Issues
If you work with the web (and today, who doesn’t?) you need to understand XSS/CSRF issues and how to mitigate them. This is definitely an issue for students, because often they’ll go straight from college to working on a web property, and may even do some web work before graduating. Simply put, they’re at risk for this from day one. The solution to this issue is to be diligent about escaping data. Better if your web platform helps you do this in the appropriate ways.

4. Don’t write your own security code
Perhaps the most important lesson. Security code is one of those areas that has hidden complexity. It’s easy to write security code that seems to work just fine — it may even pass an exhaustive suite of unit tests — but is still flawed in subtle ways such that you don’t catch it until six months after you get hacked. The solution here is to lean as much as possible on security code provided by the platform of your choice. This code will be written by people who understand the security issues in play. It will be battle-tested and designed in such a way that it helps you get the details right. Most of all, it’s backed and serviced by a vendor such that when (not if) flaws are discovered you are generally able to patch them without having to re-write code yourself.

Bonus Resources:
I have two resources that I recommend that students at least be aware of. The idea is not to have a complete grasp of everything they cover, but to know where to look to get more information. The first is OWASP, especially their Top 10 list. The second is this Stack Exchange question: What technical details should a programmer of a web application consider before making the site public?


2 Comments so far ↓

Leave a Comment