Common Web Application Security Vulnerabilities and Mitigation
It's easy to avoid common vulnerabilities with little precaution
Oct. 12, 2011 06:00 AM
Web applications are vulnerable to a multitude of security attacks. This exposes the underlying businesses and the consumer data to public view. However it is a common observation that web developers hardly take any preventive steps to secure their web applications.
Most of the time web application developers focus only on authentication and authorization to secure the web applications. This may be a viable approach for designing an intranet application. However, for the Internet application, multiple programming practices need to be followed to prevent such attacks.
This article details in brief the various security vulnerabilities web applications face and how they can be mitigated.
Bypassing Input Validation
All input should be validated twice - first on the client side and then on the server side. Client-side validation is done using Java Script. The server-side validation is done using the respective server-side technology like Java, .NET or PHP
Use Prepared Statements to fire queries. Don't use string concatenation with the user input to create dynamic queries
The attacker can guess the URLs of unprotected resources. Such information can be divulged by reading the code comments or it could be guessed.
All web content must be protected by authentication. In the case of Java web application programming, keep all the unprotected and sensitive code under WEB-INF. A similar solution exists for PHP and other server-side technologies.
For rich client applications such as those using Java Applets, Adobe Flex, Microsoft Silverlight, etc., the entire byte code gets transmitted to the client side. An attacker can decompile the byte code and gain sensitive information.
The client-side code shouldn't contain any business logic. It also shouldn't contain business logic validation. The code should be obfuscated before sending to the client.
Many times attackers can gain access to a secure website by using common terms like ‘admin,' ‘test,' etc. Developers often use these user names and passwords for testing purposes and often forget to remove them from the production systems.
Developers should not be given access to a production database for testing purposes. All testing must happen in UAT and it should use real user names and passwords.
Cross-Site Scripting (XSS)
When you open two websites in two different browser tabs, you don't expect one website on a given tab to steal your passwords from another tab.
However, this is possible, if you are using an old version of the browser or if you're using an infected browser
Encourage users to upgrade to the latest version of the browsers. Also technologies that use secure sandboxing such as Java Applets and Adobe Flex and many others should be used for creating rich-client applications.
About 80% of all web security breaches can be prevented by addressing the above vulnerabilities. A regular code review is very much required to correct the oversight on the part of programmers.
There are also various tools available that will detect the common vulnerabilities for you. Many of these tools, however, generate false positives and need substantial time to separate false positives from real alerts.
Ultimately these tools can't fix the code. That has to be done by the developer. Thus, appropriate review procedures must be established and awareness should be propagated to educate developers on the vulnerabilities and their mitigation.