5 common web application vulnerabilities and how to avoid them
Common web application vulnerabilities continue to confound enterprises. Here's how to defend against them and stop enabling exploits.
Editor's note: In 2013, Michael Cobb wrote how sad it was that the same handful of web application vulnerabilities still vexed information security professionals. It's even sadder that, six years later, these same flaws continue to stymie efforts to educate developers and mitigate vulnerabilities in web applications.
OWASP revised its list of vulnerabilities in 2017. But the five common web application vulnerabilities listed below are still causing havoc, and all of them remain on the OWASP Top 10 list. This article has been updated for the next generation of web application developers, who should finally take to heart the techniques to prevent common web app exploits.
The Open Web Application Security Project last revised its OWASP Top 10 list of critical web application security flaws in 2017. Sadly, the list has changed little from previous years, showing that those responsible for application design and development are still failing to address well-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.
In this tip, we'll look at five of the most 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
Topping the OWASP Top 10 list since 2010, injection flaws are among the most common -- and most serious -- web application vulnerabilities. There are various forms of injection attacks, including SQL, operating system, email and Lightweight Directory Access Protocol 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 enables 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) vulnerabilities
Cross-site scripting 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 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 reauthentication, 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
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 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.
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.
