Add web application security testing and life’s sweet

Big Thoughts

29 April 2013 • Written by Barret Chin

You can’t have your cake and eat it when it comes to web applications, explains Barret Chin

Cake is like a web application

Cakes come in many different forms, all of which are delicious. Some contain chocolate and others fruit, but each has something that makes it distinct from the next. The same can be said for web applications – they come in many different forms and can contain various features worth getting your teeth into. However, just like cakes, not all of these features are necessarily good for you – and even contain some nasty security surprises. This is where web application security testing comes into play.


Culprits (vulnerabilities)

These nasty surprises are about as common as the amount of butter or sugar in a cake. They’re ingredients you’ll find in every cake, but you don’t realise until you stop and start thinking about what makes the cake so delicious! Equally, web applications share similar underlying gotchas. Here are the top three to watch out for!

The first thing to look for in a web application is the text box. Text boxes can’t be trusted. As the window to the code, you can pretty much put anything in and the code behind it will most likely process it. Not so bad you might think… but what if it’s some Javascript?

The second thing to look for is a long URL. Long URLs concern us as they may contain more information than just the web address, such as information that identifies you or someone else.

The third thing to look for is an informational error page or pages. These pages are a veritable goldmine of information on how the application runs, revealing almost everything from the technologies used and the capability of the code. The secret on how the application works may even be revealed in these pages!


The harm (common attacks)

Now we move on to why these are bad which highlights why web application security testing is so important. After all, how can lots of sugar be so bad when it tastes so good? Like a nutritionist, we’ll talk about what these culprits can do.


The most common form of attack is the SQL injection. This nasty attack is the use of SQL input to target the web application’s databases to extract the information stored, including names, addresses and credit card numbers. This can be entered anywhere where code will execute SQL, such as the aforementioned text box or in the long URL. SQL can, of course, vary depending on the technology used, but the error pages will let the malicious user know which one if the SQL fail.

Another common form of attack is cross-site scripting. This attack is very similar to SQL injection but, instead of SQL, the malicious user uses a scripting language to target the web application instead. The objective is to manipulate the web application to perform unintended actions, like getting the application to tell the malicious user another user’s session ID.

This leads us onto our next common form of attack, which is to identify and manipulate broken authentication and session management. One example would be if the login page reports a different error when different information is provided for the user name and password. A malicious user could use this to discover valid user names. Or, if he realises URLs can be accessed without logging on, he could try to guess secure page names and attempt to access something that they shouldn’t be.

So, just like a piece of cake and its many enticing features, a web application’s features can contain some nasty security surprises – hence the need for web application security testing. Just like the cake’s abundance of sugar or butter, the many features of a web application might make it moreish, but will also increase the risk of potential security dangers. We need to take a leaf out of the nutritionist’s book and ask ourselves if it’s really necessary and if we’ve thought about the negative consequences of this feature.


Search the Assurity website (Hit ESC to cancel)