Web Applications Security – Introduction

As a matter of fact we all make mistakes. Some of us learn from them and others just ignore. But when it comes to the web applications that we develop, there should be no point of making mistakes, because our mistakes can cause a huge loss of business and in some cases loss of life! Here mistakes refer to architectural mistakes, UX mistakes and many others. But the most prominent one is mistakes made in security, leaving the loop-holes, that can be used by others to harm your application. Being on web means open for everyone, leaving open-gates there means you are inviting everyone.

When I started writing this blog I wanted to cover overview of web-applications security in a single blog-post but as you know security is a vast subject and can’t be covered in a single blog post, i decided to divide this in a blog series. So, here comes the first.

For the upcoming posts you can subscribe to our blog. I know you are a social animal, that’s why we are on Facebook, like us there and stay connected. For the tweeples a bonus : @sopantech

So you as a developer think that you need to develop things that work. Better think this from now – “I develop things that work only in certain conditions”. Okay enough said, now think your web-application is being hacked. What to do next, you have something in backup? No.. Now here comes rule 1:

Have a backup plan Whether or not you have a backup plan. Have one now. Who knows your application may just sink when you test different vulnerabilities against your application, that we are going to discuss in upcoming days. I have three type of user in my web-application one can do this another can do that….but one can do this also….wait a minute. Look rule 2:

Least Privilege Give user not more than what they actually need. If a user is meant for only data entry whats the use of giving him/her privileges for viewing past data. They may get all past data and misuse it. Data is valuable.

Minimum Exposure Yes, Data is valuable don’t show it all, important information like Credit Card Numbers, Passwords must be given a due care. Saving hashed password with md5 algorithm with a salt added gives another layer of security when peoples with wrong intention compromise your database.

Trade-off between usability and security A trade-off between space and time is well known but when it comes to security, smart decisions are to be taken to keep usability at good levels.

Don’t correct any data If user is passing data, force them to provide correct data rather than correcting it. For example you don’t want to give access to parent directory for any user. So, you replaced “..” with “.” , but what if someday hacker put in “…” ?

Its all about connections Most of the security breaches are found where exists some ‘connection’ between two entities. These entities can be client-server , database and application, API and its accessing clients. Let’s have an example for these. Suppose you have a form:

<form action="deliverGift" method="GET" name="myform">
<select name="gift">
<option value="watch">Watch</option>
<option value="popcorns">Popcorns</option>
<option value="sandwitch">Sandwitch</option>
</select>
<input type="hidden" name="address" size="25" value="heaven on earth" />
</form>

… and somewhere in deliverGift you wrote: performDelivery( “gift”,”address”); but the story doesn’t end here. What if the user makes a spoofed HTTP GET requested in the form:

 /deliverGift?gift=keyboard&address=usa 

In such case your application will end up in delivering a keyboard to usa, that’s you certainly don’t want! A cure to this problem is:

// updated code
if(gift==watch) {
performDelivery("gift","address"); 
} 
if(gift==popcorn) { 
performDelivery("gift","address"); 
}
if(gift==sandwitch) { 
performDelivery("gift","address"); 
}

or you can go with some switch case construct.

That would work fine. But better use following code:

if(gift==watch OR gift==popcorn OR gift==sandwitch){ 
performDelivery("gift","address");
}

But it’s not over, you are leaving a loop-hole for wrong address!

Please try to solve out by yourself and post your solution in comment. Solution will be included in next blog post.