Skip to main content

7 steps for building a secure web application

For years, security experts have warned of vulnerabilities in web applications., and these warnings are unfortunately coming to fruition. Today the headlines are dominated with news of a hacker successfully infiltrating one web application or another. Underground forums buzz with these criminals sharing vulnerability discoveries, success stories and research for their next target. We cannot hack or firewall our way to become impenetrable – hackers have proved that – so what can be done to secure these often critical applications?

Thankfully, it is possible. Here are seven steps to security-centric computer programming necessary to build low-risk web-based applications.

Step 1: Query parameterisation

There have been many high visibility attacks against web applications that can be traced back to a SQL injection attack successfully stealing passwords. Businesses, governments and social network sites have all fallen victim to this attack making it a universal issue. As testament to the size of the problem – WhiteHat’s recent Website Security Statistics Report found that seven per cent of all websites still contain SQL Injection. While many cite the problem as a vendor issue, ultimately it’s a developer programming issue.

A web form comments box, data field or another area of a form that allows free data entry, especially open string input, can lead to this vulnerability. SQL Injection attacks can even be transmitted via non-visible web elements like HTTP header values. The simple insertion of malicious SQL code – which is sometimes impractical to validate and protect – and the entire database could potentially be stolen, wiped, modified, or even used to run malicious operating system commands against your database.

To stop SQL injection, developers must prevent untrusted input from being interpreted as part of a SQL command. The best way to do this and stop SQL Injection is with the programming technique known as Query Parameterisation.

Step 2: Secure password storage

It stands to reason that, if SQL injections are being used to steal passwords, then you need to store them securely. So why isn’t this happening?

The worst method for storing passwords is, of course, in plain text; however, encryption isn’t much better. The reason: it’s reversible. Next on the list is MD5 or any other standard hashing algorithms, which are of course fallible. Hackers today have access to powerful computing resources that are inexpensive and allow them to create, or even buy, rainbow tables which allow modest strength passwords to be deciphered in real-time. And rainbow tables are not even in use these days, while high performance home computers can be used to conduct high speed dictionary attacks. Salting is the coding technique needed to help defeat rainbow table attacks and de-duplication of password hashes, but this alone is not enough.

With modest resources, attackers can create GPU cracking rigs that can execute 25 billion attempts or more per second against stored passwords – yes, that’s right - 25 billion attempts per second using inexpensive home computer equipment.

To store passwords today, I recommend combining three major techniques: use a one-way algorithm, use a salt, and use an algorithm that is purposely slow, in order to prevent GPU cracking rigs and similar resources from exposing your passwords. The algorithms SCRYPT and PBKDF2 are excellent examples of algorithms that can be used, safely, to store your passwords in this fashion.

Step 3: Contextual output encoding XSS defence

Cross Site Scripting (XSS) or, to give it its proper name, JavaScript injection, can be used for session hijacking, site defacement, network scanning, undermining CSRF defences, site redirection/phishing, load of remotely hosted scripts, data theft and keystroke logging. Attackers are also using XSS more and more frequently.

Contextual output encoding/escaping is a crucial programming technique needed to stop XSS. This is performed on output, when you’re building a user interface, at the last moment before untrusted data is dynamically added to HTML.

Step 4: Content security policy

Content Security Policy is an emerging browser standard. The idea is to create a standardised framework to provide browser-based protection that will stop XSS, with less developer involvement.

In order for content security policy to be effective, all JavaScript that’s embedded in HTML needs to be removed and deployed in a separate external JavaScript file. From this point, if a content security policy aware browser detects JavaScript embedded in a HTML document – for example if a hacker tries to insert it – the action is rejected. This really locks down the browser, preventing many forms of XSS attacks.

Step 5: Cross site request forgery

Once a user has logged into a secure site, if they were then to open another tab and inadvertently launch a malicious site, the site in question could host a forged request that could take advantage of the fact that the user is already logged in. The malicious site could then submit fake requests that could carry out great harm – such as tricking the user into transferring money from a banking website.

To prevent this type of attack, developers need to consider deploying cryptographic tokens and requiring users to re-authenticate to complete a transaction or event to prevent in-session hijacks.

Step 6: Multi factor authentication

Many would agree that passwords, as a single authentication factor, are dead. A better authentication solution is two-factor (2FA) or even multi-factor authentication (MFA). 2FA/MFA has struggled to gain in popularity in the past due to the impracticalities of always carrying a second device just to verify a user’s identity. However, mobile devices are quickly becoming the ‘what you have’ factor. While SMS and native apps for MFA are not perfect, they do heavily reduce risk versus password-only authentication. Many consumer websites and other online services now offer multi-factor authentication, such as Google, Apple, Facebook, Twitter, Blizzard and more.

Step 7: Forgotten password security design

Many sites allow for a user to request an existing, or even new, password be sent to a registered email address with little, if any, verification. A stronger process would be to:

- Validate identity with security questions- Send the user a randomly generated token via out-of-band method (i.e. SMS or token)- Verify code in the same web session and enforce a lockout policy- Change the password

For a hacker to circumvent this type of attack, they would need a lot of pieces to rebuild the system. It’s not unfathomable, but let’s not make it easy for them.

While these seven steps will not fully eradicate every vulnerability in existence - nor thwart all attack vectors – they will help strengthen online portals and applications significantly.

The long and short of it is, and I make no apologies for being so blunt, application programmers must learn to code in a secure fashion. It’s the only way organisations will stand any chance of installing proper defences for website security.

Jim Manico is the VP of Security Architecture at WhiteHat.