Tip

Five common Web application vulnerabilities and how to avoid them

The Open Web Application Security Project (OWASP) is close to releasing this year's list of the Top 10 critical Web application security flaws. Sadly, the list is little changed from previous years, showing that those responsible for

    Requires Free Membership to View

application design and development are still failing to address known and well-documented errors. Many of the most common Web app vulnerabilities are so widespread that crimeware kits feature search-and-exploit tools targeting them, making it trivial for even novice attackers to exploit these flaws.

Many of the most common Web app vulnerabilities are so widespread that crimeware kits feature automated search and exploit tools for them.

In this tip, we'll look at the top five common Web application vulnerabilities and provide guidance on how enterprises can fix the original problems and combat attacks that try to exploit them.

Injection vulnerabilities and cross-site scripting

These are two of the most common and serious flaws that occur in Web applications. There are various forms of injection attacks, including SQL, operating system, email and LDAP injection, and they all work by sending malicious data to an application as part of a command or query. Carefully crafted data can trick an application into executing unintended commands or accessing unauthorized data. SQL injection occurs when attackers take advantage of sites that generate SQL queries using user-supplied data without first checking to make sure it is valid. This allows an attacker to submit malicious SQL queries and pass commands directly to a database. As an example of this kind of attack, it's thought that SQL injection was used to access Sony's PlayStation database and plant unauthorized code as part of the 2011 attacks on the PlayStation Network.

Cross-site scripting (XSS) attacks target an application's users by injecting code, usually a client-side script such as JavaScript, into a Web application's output. Whenever the compromised output or page is viewed, the browser executes the code, allowing an attacker to hijack user sessions, redirect the user to a malicious site or simply deface the page. XSS attacks are possible within the contents of a dynamically generated page whenever an application incorporates user-supplied data without properly validating or escaping it.

To prevent both injection and XSS attacks, an application should be configured to assume that all data, whether it's from a form, URL, cookie or even the application's database, has come from an untrusted source. Review every point where user-supplied data is handled and processed, and check to make sure it is validated. Validation functions need to clean any input of characters or strings that could possibly be used maliciously before passing it on to scripts and databases. Input must be checked for type, length, format and range. Developers should make use of existing security control libraries, such as OWASP's Enterprise Security API or Microsoft's Anti-Cross Site Scripting Library, instead of writing their own validation checks. Also, ensure that any values accepted from the client are checked, filtered and encoded before being passed back to the user.

Broken authentication and session management

Web applications have to handle user authentication and establish sessions to keep track of each user's requests as HTTP does not provide this capability. Unless all authentication credentials and session identifiers are protected with encryption at all times and protected against disclosure from other flaws such as XSS, an attacker can hijack an active session and assume the identity of a user. In case an attacker discovers a session where the original user has failed to log out (walk-by attacks), all account management functions and transactions should require re-authentication, even if the user has a valid session ID. Two-factor authentication should also be considered for high-value transactions.

To uncover authentication and session-management problems, enterprises can perform both code review and penetration tests. Developers can use automated code and vulnerability scanners to uncover potential security issues. Areas that often require more attention include how session identifiers are handled and the methods used for changing a user's credentials. If budgets don't stretch to cover commercial versions, there are plenty of open source and lite versions that highlight places where a closer inspection of code or processes is required.

Insecure direct object references

From the editors: More on Web application security

Learn about the latest Ruby on Rails security vulnerabilities and how enterprises should respond to them.

Avoid making common mistakes in the SSL certificate management process.

This is another flaw that stems from poor application design based on the false assumption that users will always follow the application rules. For example, if a user's account ID is shown in the page URL or in a hidden field, a malicious user may be able to guess another user's ID and resubmit the request to access their data, particularly if the ID is a predictable value. The best ways to prevent this vulnerability are to use random, unpredictable IDs and file and object names, and to never expose the actual names of objects. Common places where this data is incorrectly exposed are URLs and links, hidden form fields, the unprotected view state in ASP.NET, drop-down list boxes, JavaScript code and client-side objects like Java applets. Each time sensitive files or content are accessed, verify the user is authorized to access them.

Security misconfiguration

The infrastructure that supports a Web application comprises a complex variety of devices and software, including servers, firewalls, databases and OS and application software. All these elements need to be securely configured and maintained, with the application running with the least privileges necessary, yet many systems are never fully hardened. A primary cause of poor system administration is that those responsible for managing Web applications and the infrastructure that supports them have never undergone the necessary training.

Providing adequate training and resources for those tasked with day-to-day network and application management is as essential as making security and privacy a priority throughout all phases of the development process. Finally, schedule a penetration test for Web applications that handle sensitive data of any kind. This is a proactive method of assessing its ability to withstand an attack and finding vulnerabilities before a hacker does.

Conclusion

These five common Web application vulnerabilities have been a thorn in the side of IT security for years. They are not new and neither are the fixes for them, but until the security of Web apps is prioritized, attackers seeking to commit theft, fraud and cyberespionage will all continue to take advantage of these flaws.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is founder and managing director of Cobweb Applications Ltd., a consultancy that helps companies secure their networks and websites, and also helps them achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Michael is also a Microsoft Certified Database Administrator and a Microsoft Certified Professional.

This was first published in May 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.