Application security - 5 things you don't waana do

Let me start by saying and I quote it, “in today’s world everything which is necessary is not secure”.

Now-a-days, everyone knows the significance of application security but very few take it seriously and try to implement safe guards to avoid any breach. For rest, it is more desirable than imperative.

Let’s face it; we have stories in backlog not security. We accept a reduced security or vulnerable flow just because we know a proper secured communication will take more time & money either of which are usually in shortfall. But what we can do at least is not to make things to easy for a hacker by leaving backdoors open which are mere programming errors and not a security flawed design.

When it comes to security, there are too many things to worry about.  Input validation, broken authentication, lack of authorization, misconfiguration of security, insecure direct object reference, improper error handling leaving sensitive information exposed, open redirects anywhere and the list goes on. Almost all hacking techniques are designed to exploit these loopholes and gain access in your application/servers/communication.

I am not targeting any specific programming language because the 5 things I have mentioned below are implemented in all. So let’s start.

Input validation

By very nature of this business or technical requirements, I believe the code should always be defensive. It helps you to deal with both kinds of people, extreme stupid and very clever ones. You really don’t want anyone breaking your application by just entering something in the input fields which nowhere in the world belongs there. You can’t help it; common sense is not really common anymore. But this category is also not our main problem. The problem is the ones who are very clever and know from where the validation is missing and how it can be exploited.

Common input validation hacks include SQL injection, HTML injection, Cross Site Scripting (XSS), buffer overflows, application content identification, phishing etc. A hacker can inject html, JavaScript or unlimited data into your application’s input fields until either it breaks or does something on the server which it never suppose to do.

This all can be avoided by taking few simple measures. First, always expect the unexpected and put validations on everything. Second, implement validation both on client & server side. The web browser is an untrusted, uncontrolled environment because all data coming from and going to the web browser can be modified in transit regardless of input validation routines.

Authentication & Authorization

Well, nothing to say here. These are the bouncers or gate keepers of your application. Any flaw here will results in unwanted guests inside your application.  Just implementing the login in the application doesn’t make it secure. There are more security hacks then security solutions available now-a-days. You have to implement the security in a way that no one can guess and mimic it.

Common issues with authentication implementations are:-

1. Transmitting credentials in header over HTTP
2. Passing tokens, sessionIds as url parameters
3. No session management, timeout implemented
4. Unsecured/open form submission without Captcha
5. Open redirects post authentication without validation
6. Permissions not checked before execution

Above are just few things but if not implemented properly can lead to things like Denial of Service (DDos) attack, Man in middle attack, Session hijacking etc.

It is really easy to implement above properly. Most of the programming languages come with an out of the box functionality to implement above correctly. All you have to do is use them and make sure you are not leaving something which someone can exploit.

Error Handling

A good quality error handling not only ensures security but a better application and enhanced end user experience. Who likes an application which gives you a yellow screen of death (at least developers will understand what yellow screen of death is).

For now let’s just see how an improper error handling can lead to security flaws. See below and tell me how many things this error exposes of this application.

You might think, this is just an error. Not really exposing much details but for a 

hacker even this much information is enough to fire much closer hits to your application. And remember, you need the luck always but hackers only need it once.

So always make sure that you handle all errors inside your application and even if something is unhandled, user should only see an unknown error message and not a broken screen as above. 

Security Misconfiguration

This is another area where you don’t even require coding to screw it up. Application configurations are critical aspect of security and if something is deployed in production with local environment’s configuration is as good as giving you application to a hacker in silver plate with ribbon on it.

Below are some examples which can lead a leakage of your application information:-

1. Deploying application with default username/passwords of third party components
2. Deploying application in debug mode
3. Keeping directory listing enabled
4. Deploying application with security disabled for certain areas of application. 
5.  Running outdated software or operating system

The best solution to overcome above issues is to automate the entire build process. Most of the deployment errors happen because the process is manual. Remember the quote “If there is an error, it’s human” perfectly fits here.

An automated process will keep the environments consistent and reduce the number of human/manual errors.

Understand the technology & understand the business

And finally, understand before you implement. I have seen people (majority in big organizations) where they only care about the module they are developing without the understanding of the entire end to end flow and the organization rules.  Developers are too removed from the business, especially if they do not work for the company whose website they are creating.  A developer will not be able to accurately model threats unless the developer is keenly aware of what the business objectives are and which critical information assets have to be protected by the application.

Same goes for technology. Web applications are changing rapidly and the tools to build those are changing even more quickly. Everybody involved in the web development process has to live up to the challenge to understand the security aspects of particular frameworks and development environments. This process is made harder if organizations try to chase the latest fad in web technology just to keep up with the industry.

Technology owners are trying hard to keep their products upto date with all latest threats and various programming languages are updating their modules to fight against these threats as well. If you understand the threat and the technology then all you have to do is to implement an out of the box solution to deal with those threats. Believe me, it require much less time than it sounds. All you need to know is what you are up against and what you have to fight it. 

Summary

Hopefully I gave you some idea about how implementing even small things in your application can save you from major hacks. Also, just to set the expectation right, we have't even scratched the surface of application security here. If you really wish to build a secure application then I am afraid there are no shortcuts. You will always have to be top of your game, stay up to date with various security threats and mitigations.