A couple of language-agnostic tips for web app security

[Adil]

Preamble
This little tutorial/reference serves as a reminder/checklist for securing your web apps. However, it is not the only guide out there and nor is it the only guide you should refer to. Rather, it should be one of many.

The list
Error Handling
This is a pretty obvious one. In most web frameworks (Play!, Rails, webapp2, etc), any errors are output using a http code and some text.
Let's take this scenario:
You have a blogging platform, and you've just rolled out a new feature. However, you have not catered for extreme edge cases. As a result, the blogging engine cannot save some data to a database.

// this is dummy code
var userId = request.get('user_id');
db.saveData('users', 'user_id', userId, function(err) {});

Here we see that some data (in this case, 'user_id') is being saved to the database. If there is an error in handling it, good practice suggests:

var errCode = 500;
response.write(utils.errFor(errCode));

That would give you a 500 error. This is vital. If you were to give the end user a stacktrace (that's not encrypted - Google encrypt Youtube errors), you'd be exposing yourself to a potential hacker gaining access to your system. This is the first point you must address.

Using HTTPS
This is pretty self explanatory. HTTPS adds a layer of security to your site, so attackers cannot perform man in the middle attacks (see wikipedia for more info). HTTPS should be enforced throughout the site, but especially on any areas handling sensitive data - this includes, but is not limited to:

• Billing areas
• User sign in/registration/account management

Extensive Logging
Logging is pretty much vital in any large application. Logging will allow you to inspect site stats - loading times, error codes, etc. Logging will also allow you to keep track of any suspicious activity. Many languages have a large collection of logging frameworks. Most web servers also log data.

Proper authentication handling
This is my last point. When a user is faced with a login screen and tries to login, they may be greeted with an error. Now, this is bad practice.
Why?
Well, if a hacker becomes aware of a user's email address, they may also have a vague idea of their password. So, when the hacker visits the login page, he/she will try to login and will be greeted with 'password incorrect'. This means the hackers now knows that the password they supplied is incorrect. Their job becomes a bit easier.
Example scenario:
User a
Hacker b
Password list: apples, oranges, pears, bananas, grapes, cucumber <(this is the password)
We have 6 potential passwords.

B gets a's email ([email protected]). B then goes to the login of site C. B tries to login with the password "apples". B does not succeed, but B now knows he/she has eliminated one password. From having a 1/6 chance of getting the password, they now have a 20% chance. They continue until they breach the system.

So, to conclude, here is a basic overview of the points I have just discussed.

• Do not send stack traces or any sort of specific error to the user (only send errors to trusted users - in a development or staging environment).
• Using SSL across your site
• Logging everything (Loggly and Logentries are two good log analysis tools)
• Redirecting the user to the login page rather than sending an error to them.

I hope you learnt something new!
~Adil