Over the past couple of weeks, I’ve been reading through “Web Application Security – a Beginner’s Guide” from Bryan Sullivan and Vincent Liu (2012, McGraw Hill) with a highlighter in hand. Now that I’ve finished reading through it, I wanted to record some of my thoughts on what I’ve learned, and what I need to explore further.
Summary Points
- Never Trust the User!
- Whitelist > Blacklist
- set access control based on user role and least privilege
- use parameterized stored procedures for SQL queries
- use SSL for the whole app, not just the sensitive parts
- bake security in, from start to finish
Let’s dig deeper
1. Never Trust The User
The most important thing I learned here is that the “user” is not just the person on the other side of the screen/keyboard. It is also the browser and any other website or application that might be calling on the resources in my website/app. Anything that has left my server can be manipulated before reaching the end user. Anything coming to my server could have been manipulated between my end user and me. And so, there is a need to validate, sanitize, and verify access/authz before handling input server-side.
2. Whitelist is better than Blacklist
It makes more sense to clearly define only what is acceptable, explicitly stating what IS allowed to happen, instead of depending on an ever-growing list of what IS NOT allowed, because inevitably, someone somewhere will come up with a way to circumvent your blacklist while still not doing what you want/expect. Specifying “no this, no that, and definitely none of these” will still leave openings, while stating “only this, that, and those” doesn’t leave much wiggle room.
3. Set access control based on user role and least privilege
If the app only needs read access to the DB, set up a specific user role in the DB with only Read permissions. Do not use the admin level for everything. This is something I have to get used to, as I don’t work with database users very often.
4. Use parameterized stored procedures for SQL queries
This is something totally new to me, but it seems like it’s something anyone who ever learned working with SQL in a formal setting should have been exposed to. Needless to say, I have to dig much deeper into this one, as I’m not sure I quite understand the syntax or process yet.
5. Use SSL for the whole app, not just the sensitive parts
It only makes sense, and is becoming the standard across the internet. If you want the users to trust you, you have to prove you are trustworthy. Even if you don’t openly collect data from your visitors, they probably wouldn’t want to give you any more information than necessary with the big ugly “Not Secure” in the browser URL bar, right? I will need to remember this as I develop even the smallest apps and sites, to reinforce the good habit.
6. Bake security in, from start to finish
Take a holistic approach to security. It’s not just about the code itself – security needs to be in mind when scoping out requirements and working on the design. Threat modeling should become second-nature when considering all features (“How could this be broken?” and “How should the app respond to such issues?”). Include testing at various points throughout the project. And have a plan to handle an incident, should one occur. And while I want to learn about all of these things, for now I need to focus on the code part – what libraries and tools should I be using, and how do I use them (syntax, location, etc).
That’s not all!
This was just my way of cementing a few aspects of what I read, but there is a LOT more covered in the book. For those of you like myself that aren’t quite security-minded by default, this is a great intro to thinking like the bad guys so you can develop good habits that should prevent the bad guys from targeting your products. I look forward to putting this stuff into practice – in fact, I’m already making a list for what I need to do when upgrading my Feed the Snake game to include a global scoreboard, but I’ll save that for another post.