DEV Community: Sunfire

What I’ve learned from the Web Application Security Beginner’s Guide

Sunfire — Sun, 03 Feb 2019 22:14:42 +0000

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.

Expanding the Snake game to include a Global Scoreboard - Part 1

Sunfire — Fri, 01 Feb 2019 01:12:50 +0000

As you may have seen in my post Feed the Snake game, I'm trying to learn more about web dev by improving something I built from a tutorial.

The game as is uses the browser's localStorage to keep track of the user's high score. But trying to beat your own score isn't as fun as trying to beat someone else's high score.

Now, I have to admit, since I want to focus on secure coding practices and learning how to best build secure apps from the start, this felt really daunting, and I've been putting it off for a while now. But as I've been reminded, the best way to learn is get in, do it, fail, and figure out the right way...

So, while I know this version isn't secure yet, it took me a couple days just to get it to the point of pulling the score (which is added to the page with JS) and combining it with a name (that the user enters at the end of the game), and sending all of that to my tiny little db through PHP.

While it felt monumental just to get that working, what really struck me after the fact was that I had forgotten some of the core principles of web dev, namely remembering the order of processing of different files to produce the site as viewed in the browser. I had to be away from home, freezing my ears off at the bus stop, to remember that once PHP has processed, it's gone, and if I want to take something that's been generated by JS after the page was loaded and send it to PHP, it has to go through an AJAX call. Order of operations.

Like I said, I know it's probably vulnerable to things like tampering and maybe even XSS, but since I don't quite understand how those attacks work yet, I can't quite write my code better to prevent it. I've contemplated a variety of ways to handle the issues that could arise from accepting user input, but it seemed to me that I first needed to make sure my data was getting into the db, and then the top scores being displayed for everyone to see. Because if I can't do that much, then I can't test the security of other methods, right?

I'm not ready to have you help me by poking at it just yet, so I won't share the link. But if you have any tips, suggestions, guidance that could help me as I learn the best way to write my apps more securely, please share. Thanks.

Tic Tac Toe – another browser game

Sunfire — Thu, 17 Jan 2019 23:50:18 +0000

** Disclaimer: I’m not an affiliate for anything here, just sharing my honest opinion. **

In an effort to keep working on code, I found another browser game to play with. It’s not as entertaining as my Feed the Snake game, but it’s good practice for looking over code and trying to figure out a different (maybe better) way to write it.

As before, I’m taking my starting point from a Udemy course, Projects in JavaScript & jQuery. The idea is fairly simple – click a square to change it to X or O (they alternate based on turn number), and when there are 3 in a row with the same mark, a winner is declared. It also has the ability to detect a tie game, and provides reset functionality if you want to start over before the game officially ends.

Where did I come from?

For reference, here’s what the JavaScript looked like after I followed along with the videos: First commit to bitbucket

There were a LOT of If statements with AND and OR, and a few lines were repeated. It felt clumsy and quick. So I asked myself, how could I change this?

First, since the original was written in 2014, and had more folders than I felt necessary, I cleaned up the paths and updated the jQuery CDN link.

Then I said let’s get rid of the anonymous functions and set up some actual reusable functions. I also defined what a winning row looks like and made a list of matching variables. From there I was able to create the shell of the check4win() function.

I also did some rearranging. The original had almost everything set within the single click handler. As I created functions and defined variables, I moved them to the level that made sense – some at the very top, even before the page is loaded, and others deeper within. This took a little while, because I had to make sure everything in the function was being accessed at the right time. You see, the tricky thing about JavaScript is the DOM (document object model – aka the elements of the page being loaded and accessible). If you try to access an element of the DOM that you haven’t actually created yet, or before the page is completely loaded, you’ll get an error. So I had to keep testing until I had everything in the right order.

Finally I was ready to do some testing. Played through once, then started a new game only to realize that the winning condition had not been cleared at the end of the last game, so as soon as I clicked the first square on a new game, it gave me the same winning popup. Had to fix that…

Where am I going?

Then, before stopping for the day, I thought I would see how it plays on the phone. So I quickly added the files to my webhost and pulled up hitsaru.com/tictactoe from my phone, only to realize the board was much too small. Easy fix: just make sure meta name="viewport" content="width=device-width, initial-scale=1.0" is set in a <meta> tag in the <head> of the index file. I don’t know too much about improving sites for mobile (YET), but from what I can tell, it plays just fine as is.

On top of it all, I used this as a chance to practice using git to publish changes. If you’re interested, the full repo is available on my Bitbucket.

There you have it – my fun little project for this afternoon. Like I said, I know Tic Tac Toe is way less fun than Feed the Snake, but I’d appreciate if you took a look at it and let me know what you think. Suggestions on improvements are absolutely welcomed.

Feed the Snake game

Sunfire — Sat, 05 Jan 2019 01:18:42 +0000

Disclaimer: I’m not an affiliate for anything here, just sharing my honest opinion.

A few years back, after graduating college with my degree, I decided it was important to keep learning and exploring in my field of study. One of the first things I did was look into Udemy, a site full of online courses that were mostly free (at the time – they’ve since moved to a slightly different model, with most courses going on sale for about $10 fairly often). And on that site, I came across a lot of project-based courses, where the instructor codes the project and explains what’s going on. My favorite thing about these types of courses is that now, with some experience under my belt, the first thing I do is pull down the final project file, review it as the video rolls on, and make notes/comments on how I might change/improve it. Sometimes I even go back to those projects and try to do just that.

One such project is a fun little game I’ve always enjoyed playing some version of since I was a kid – Snake. The concept is to tell the ‘snake’ which direction to move in order to ‘eat’ the piece of ‘food’ that randomly appears on on the gameboard. In the Eduonix course “Projects in HTML5”, we worked with the ‘new’ <canvas> element, and some JavaScript and jQuery to paint and animate it. The result was a version of the game where the snake started moving as soon as the page finished loading, and the user had to refresh the page to start over. One of the other cool features it included was getting and settling a localStorage value in order to keep track of the user’s high score.

Well, me being me, and wanting to learn and explore, I started thinking of ways to improve it. First, I added Start/Pause functionality, because no one likes a game that starts automatically, that you can’t put on hold for a quick bio break, right? Right. That didn’t take too much work:

Figure out what the number for a spacebar keypress is [hint: it’s 32]
Create a function to house everything that would be tied to pausing the game
Identify when the game is still being played (using spacebar to pause), or if the game has ended or the page is newly loaded (use spacebar to start a new game), and therefore what should be displayed on the overlay
Ensure any elements relating to the pause/start functionality are included throughout the rest of the javascript and html

It was one of those things that, until I knew what I was doing, felt a little daunting, so it was a while before I started on these upgrades. But by May of 2017, I had it up and functioning and entertaining myself and some friends.

And then it sat there again. Life got busy/crazy, and pursuing side projects was pressed down the totem pole of importance….

In the past few months, I took down the site where my snake game was originally published, and just yesterday I put it back up on the internet for you to play with my version and enjoy. If you’re interested, take a look at my Bitbucket repo for the code so far. I’m even practicing my git skills by creating a branch there…

In the coming months, my plan is to further develop this game to be a bit more interesting: I want to add a global scoreboard. While trying to beat your own personal best can be okay for a while, it’s even more fun to try and beat someone else’s best score.

One of the things I will have to focus on with that version, though, is security. Because while I will be testing my skills with a database and AJAX, I also want to make sure I am developing with security in mind from the beginning. And the first thing I learned about security is “if there’s anywhere a user can input data, it’s a weakness”. Developing a global scoreboard that minimizes the chances of hackers faking their scores will be a fun test, but something I am looking forward to exploring.

For now, just go play. If you like it, share it with others. Just know that this was NOT designed to be played on a small mobile device – the layout of the design expects a screen of at least 650px wide, and it expects keyboard arrows and spacebar for the input. That’s a whole other set of changes/improvements I could explore someday…