Welcome!

Security Authors: Yeshim Deniz, Peter Silva, Liz McMillan, Pat Romanski, Hollis Tibbetts

Related Topics: SOA & WOA, Security

SOA & WOA: Article

Common Web Application Security Vulnerabilities and Mitigation

It's easy to avoid common vulnerabilities with little precaution

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
Generally developers validate the user input using JavaScript validations. Once the information is sent to the server side, developers do not validate again, since they assume that JavaScript validations can block all invalid data.

Hackers, however, can simply save the page to their local hard disk and modify the JavaScript to not do the validation. They can then submit the page.

Mitigation
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

SQL Injection
An attacker can submit input that would pass the JavaScript and server-side validation. However, the input is actually an SQL query. Since the input is used to construct the SQL queries, such an input would alter the SQL query and give unauthorized information back to the attacker.

Mitigation
Use Prepared Statements to fire queries. Don't use string concatenation with the user input to create dynamic queries

Unprotected Resources
The attacker can guess the URLs of unprotected resources. Such information can be divulged by reading the code comments or it could be guessed.

Mitigation
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.

Reverse Engineering
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.

Mitigation
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.

Weak Authentication
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.

Mitigation
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

Mitigation
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.

Conclusion
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.

More Stories By Mahesh K Punjabi

Mahesh K Punjabi is a senior technology architect with Infosys Technologies Ltd. He has extensive experience designing enterprise applications using Java and multitude of RIA technologies including Flex and GWT. His other passions include photography and speaking with Toastmasters' clubs.