Idiots Guide to….Web Application Security

June 15, 2011

Below is my recommended list of web application security must-haves. Whilst I wouldnt call myself a security expert, I do have over 10 years IT experience, much of which has been spent in development. These are all fundamentals, but often missed – Either due to lack of knowledge or time – Yes, security does often take a hit over functionality when a project is running late (Unfortunately)!
  • Don’t rely on client side validation
    Ok, so you use client side scripting (Probably javascript) to ensure your users can’t send you a SQL injection attack and shut down your SQL box. Great! Are you sure there browser supports javascript? Yep? Sure they haven’t switched scripting off? Sure they are not accessing your site via a proxy that lets them change post/get data on-the-fly?

  • This script does just what I need….Great!
    Alright, so your projects running late, you have some tough code to write. As luck would have it your also low on Red-Bull/Coffee/Jelly Babies. You find some code that suits the job perfectly! Whats next…Download, modify to suit, test a little… Job done! Only problem is, any security flaws that were in that script are now sat in your application, waiting to be exploited. Worse still is the scenario when you use a well known script which has flaws – You then have an application where anyone who knows about Google can find out how to hack your site.

  • Just more stuff to go wrong…
    Generally speaking, things that are simple work better and for longer. Do you really need all them extra features and roles on your web server? Are you using Perl? Webdav? FTP? SMTP? Perhaps you installed them out of the box – Surely its easier to install and configure now, whilst your on the server build project? Perhaps not – The more you have installed, the higher the chances are that your server will have a vulneralbility of some kind, making your server a more attractive play-ground to hackers. Indeed the approach by Microsoft since Windows server 2003 is to have a minimal server foot print. This is approach in general with the O/S on Windows 2008. This method has the positive side effect of reducing processing, which means less power usage – So you can save the planet too!The same applies for the code you write – The more functionality a system has, the more likely it is to have bugs, which of course increases the risk of security flaws. As a general rule, if the Business doesn’t need the functionality, don’t add it. The responsibility for keeping an application lean in this sense comes down to the designer/architect, customer and developer – All of these project roles have scope for adding/introducing functionality that is not needed/wanted.
  • Don’t put up a welcome sign
    Easy one – If you have an admin interface on a website, dont make it obvious where it is! Can you host it on another site? Do you really have to store it at /admin? Is it password protected? (If not, forget reading this page….give up, go home!). Is it reachable and/or indexible by search engines? (Lets hope not). What username/password did you decide upon? Users are aweful at remembering account details, but this is no excuse for weak credentials (Although in my experience, a decent username/password combo often encourages users to write the details down…sometimes in the most unbelievable places!)

  • If you need to hide it, hide it well!
    Many web developers have made the mistake of using hidden form variables to ‘hide’ data from the user, these can easily be modified in transit, using a proxy software, or using an even simpler method – Downloading the HTML, changing the hidden form field values and submitting the form data from the local machine to the script on the remote web server. The same goes for querystring variables, which are potentially even more of a problem – They are immediately visible to the user (in the browser address bar), so even a casual browser, let alone a hacker may try to change these, perhaps just for fun, maybe for personal gain or perhaps just to wreck your web app!The results of course depend on the criticality of the application – Imagine an online banking application that relied on hidden form fields or querystring variables to carry transaction amounts around! Ok, that’s an extreme example, but you get the point!? I have actually seen a live e-commerce site using hidden form variables to carry the product prices…a quick experiment proved that changing these resulted in a very heavily discounted shopping cart! (No, I didn’t actually check out – I emailed the site owner informing them of the issue).

  • Broken Biscuits
    Cookies can be broken apart, changed and put back together again. Its also possible (and easy) to view the ingredients. So – Dont use cookies to store any critical information! By critical, I mean anything that will change, or has the potential to change the functionality of your application – Consider the way your site works, what the user is offered and howits secured – e.g. Store the users account name in a cookie, OK, they wont have to enter it every time but – You have just given away one half of the users credentials to anyone who uses their computer.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: