Secure Coding Guideline for Hack-proof Web Development
We have seen a massive growth in the number of web applications in recent years. Most of us use online shopping portals. Many Government offices are also offering various e-governance services using different web technologies. Web services are affecting our lives in many daily activities. They cover various areas such as e-banking, e-transaction, e-education, e-commerce, e-governance, etc. The more we are getting dependent on these web technologies and started taking benefits of these easy to use services, the more our personal information and identity is getting stored online. So the need of web application security is growing along with the number of web application. A compromised web application can lower the security of a web server and databases despite having all security measures like Firewall, IPS, etc. According to SANS study report, more than 60% of the attacks are on web applications among the total attack attempts observed over the Internet. Developing a secure web application or service is not an easy task but still it is cost effective to build a secure web application then to rectify errors after the application has been compromised. The process of secure web application development needs one or more guidelines on secure coding practice and in-depth knowledge of recent attacks on web application. Requirements related to security issues need to be identified in the early phase of software development life cycle. Though practically it is not possible to mitigate all the vulnerabilities in the development phase, but still, secure coding guidelines can be used as a checklist for the developers to achieve minimum required security. A web developer should always keep in mind that there are ‘n’ numbers of Hacker, Crackers, Spammers and Script Kiddies are waiting to tear apart your coding skill, as you are developing something which will be online and browsed by the world wide community. Once a web service is online you cannot limit users from playing with it and trying to make it perform what your web service is actually not intended to do. There is a difference between the thinking of a developer and an attacker. Developers mostly concentrate on what the application is intended to perform based on clients requirement. But an attacker will not bother about what your application is intended to do; rather he will focus on what the application can be made to do. He will try to allow denied actions by finding the less securely programmed portion of your code. Therefore, it is advisable to follow some secure coding guidelines. Below are mentioned a few basic rules, a developer should follow to minimize the security issues –
- Client Inputs should be validated properly. Do not allow any data (parameters, URLs, HTTP Header) to reach server without performing input validation check.
- Client Side input validation can be easily circumvented using client side web proxies and custom built data can be submitted bypassing the interface. Therefore along with client side input validation input data should always be sanitized using server side functions, so that hazardous characters are not allowed as input.
- Indentify all source of input and classify them as trusted and not trusted.
- Do not store login credentials as simple text in database. Password should always be encrypted with cryptographically strong one way hashing algorithms using strong salt values. MD5 is no more a good choice.
- Authentication failure should not indicate which part of authentication data is incorrect. Same error message should be displayed for both username and password mismatch.
- Login credentials and critical data should be submitted using POST method. While using GET method data should be encrypted before submitting along with URL.
- Captcha validation should be enforced or user account should be blocked for few hours if there is more than 3 attempt of failed login.
- Session variables should not store user-name or password. Random and unique session ID should be generated for each user and destroyed once the user sign outs.
- All login attempts should be stored in database along with the IP address of the client.
- Passwords should be checked for its length and strength. Password containing special character and both alphanumeric is more secure. It should be more than 8 characters long.
- Password reset process should send email to the previously registered email id. The link for password reset must have short expiration time.
- An inactive session should be logged out automatically after a specified time.
- Logout functionality should be implemented properly and it should clear all session related data. Logout option should be accessible from all secured pages.
- Do not disclose any sensitive information like system details, session identifier in error messages.
- Avoid the use of known vulnerable functions. Properly free allocated memory and close database connection after the completion of functions and at all exit points.