We all use web applications everyday whether we consciously know it or not. That is, all of us who browse the web. Now a days we have seen a significant surge in the amount of web application specific vulnerabilities that are disclosed to the public. No web application technology has shown itself invulnerable, and discoveries are made every day that affect both owners and users security and privacy.
Security professionals have traditionally focused on network and operating system security. Assessment services have relied heavily on automated tools to help find holes in those layers,so we need some guideline to build secure web application apart from networking and operating system concept.
Software is generally created with functionality first in mind and with security as a distant second or third. This is an unfortunate reality in many development shops. Designing a web application is an exercise in designing a system that meets a business need and not an exercise in building a system that is just secure for the sake of it. However, the application design and development stage is the ideal time to determine security needs and build assurance into the application. Prevention is better than cure, after all!
In this blog we will learn some guidelines to build secure web application. The following high-level security principles are useful as reference points when build web application.
- Validate Input and Output
User input and output to and from the system is the route for malicious payloads into or out of the system. All user input and user output should be checked to ensure it is both appropriate and expected. The correct strategy for dealing with system input and output is to allow only explicitly defined characteristics and drop all other data. For the example, If an input field is for a Social Security Number, then any data that is not a string of nine digits is not valid.
- Fail Securely (Closed)
Any security mechanism should be designed in such a way that when it fails, it fails closed. That is to say, it should fail to a state that rejects all subsequent security requests rather than allows them. An example would be a user authentication system. If it is not able to process a request to authenticate a user or entity and the process crashes, further authentication requests should not return negative or null authentication criteria.
- Keep it Simple
While it is tempting to build elaborate and complex security controls, the reality is that if a security system is too complex for its user base, it will either not be used or users will try to find measures to bypass it. Often the most effective security is the simplest security. Do not expect users to enter 12 passwords and let the system ask for a random number password for instance! This message applies equally to tasks that an administrator must perform in order to secure an application. The application developer should create a security mechanism as simple as possible for users and perform complex security function at behind the scene.
- Use and Reuse Trusted Components
We should use third parties components from trusted source and it’s stable version, because in many cases they will have improved components through an iterative process and learned from common mistakes along the way. Using and reusing trusted components makes sense both from a resource stance and from a security stance. When someone else has proven they got it right, take advantage of it.
- Defense in Depth
Relying on one component to perform its function 100% of the time is unrealistic.While we hope to build software and hardware that works as planned, predicting the unexpected is difficult. Good systems don’t predict the unexpected, but plan for it. If one component fails to catch a security event, a second one should catch it.
- Only as Secure as the Weakest Link
We’ve all seen it, “This system is 100% secure, it uses 128bit SSL”. While it may be true that the data in transit from the user’s browser to the web server has appropriate security controls, more often than not the focus of security mechanisms is at the wrong place. As in the real world where there is no point in placing all of one’s locks on one’s front door to leave the back door swinging in its hinges, careful thought must be given to what one is securing. Attackers are lazy and will find the weakest point and attempt to exploit it.
- Least Privilege
Systems should be designed in such a way that they run with the least amount of system privilege they need to do their job. This is the “need to know” approach. If a user account doesn’t need root privileges to operate, don’t assign them in the anticipation they may need them. Giving the pool man an unlimited bank account to buy the chemicals for your pool while you’re on vacation is unlikely to be a positive experience.
- Compartmentalization (Separation of Privileges)
Similarly,compartmentalizing users, processes and data helps contain problems if they do occur. Compartmentalization is an important concept widely adopted in the information security realm. Imagine the same pool man scenario. Giving the pool man the keys to the house while you are away so he can get to the pool house, may not be a wise move. Granting him access only to the pool house limits the types of problems he could cause.
- Security By Obscurity Won’t Work
It’s naive to think that hiding things from prying eyes doesn’t buy some amount of time. Let’s face it, some of the biggest exploits unveiled in software have been obscured for years. But obscuring information is very different from protecting it.You are relying on the premise that no one will stumble onto your obfuscation, because hiding things does not mean that it is fully secure . This strategy doesn’t work in the long term and has no guarantee of working in the short term.
In Next blog we will see security checklist and its related security stuff.
You can find out more about web Application security here OWASP