Explore the 10 most critical OWASP vulnerabilities and how to mitigate them.
The Open Web Application Security Project, or OWASP, is a worldwide not-for-profit that attempts to educate business owners, developers, and users about the risk associated with web application vulnerabilities. OWASP is a community of professionals where everyone can volunteer to participate and work toward creating a knowledge base for application security. All materials are available under a free and open software license. One example of the organization’s work is its top 10 project, which produces its OWASP top 10 vulnerabilities reports.
Every few years, OWASP releases the list of the top 10 web application security vulnerabilities that are commonly exploited by hackers (ranked according to risk) and provides recommendations for dealing with these attacks. The list acts as an awareness document for security professionals and organizations to help them better understand their current security posture and become better equipped to find and mitigate these risks.
OWASP Top 10 Vulnerabilities
An open call for data goes out from OWASP to the industry and companies that perform secure code reviews, penetration testing, etc. send in their data anonymously. The data is then collated to produce the frequency of each risk, and each vulnerability is assigned a score based on its exploitability, prevalence, detectability, and technical impact.
Let us discuss the current OWASP top 10 vulnerabilities list (which is from 2017) and look at ways to remediate these risks.
From verbose error messages to sensitive information getting leaked, injection flaws can lead to undesirable and disastrous outcomes. Injection flaws include but are not limited to SQL injection, LDAP injections, or file system injections. Carried over from the 2013 OWASP list, injection flaws occur when the application takes in user-supplied data (in a form field or a search query) and passes it onto the backend database or server without proper input validation checks. A hacker could craft a string with the intention of exploiting the application, and without adequate input sanitization, the query gets executed on the server.
- Use a combination of parameterized queries, stored procedures, output escaping, and whitelists for server-side input validation.
- Use database controls like LIMIT to prevent mass disclosure in case of a successful injection attack.
2. Broken Authentication
Like injection, broken authentication has not changed position in the OWASP top 10 vulnerability list since 2013. A misconfigured authentication system could allow attackers to impersonate legitimate users by compromising passwords, session tokens, etc. The technical impact is severe. If you could log in as anybody else, you could potentially have access to all resources on their website or application.
Remediation Measures: Use a combination of tactics to mitigate your risks:
- Implement multi-factor authentication (MFA).
- Avoid using default credentials.
- Implement strong password policies.
- Use controls such as delayed failed logins, randomized session IDs, session timeouts, etc. as preventive measures.
- Be sure to log all failed login attempts.
3. Sensitive Data Exposure
In this vulnerability, sensitive data such as financial information, health records, user credentials, etc. that should typically be encrypted or kept hidden is visible as plaintext. This means hackers could gain access to such information by executing man-in-the-middle (MitM) attacks to steal data in transit. Sensitive data exposure has become increasingly common over the past several years. As such, it’s climbed up three positions from its previous list ranking in in 2013.
- Classify application data being processed, stored or transmitted by level of sensitivity, and apply controls accordingly.
- Enforce encryption and use proper key management and standard algorithms.
- Disable caching for responses containing sensitive data and avoid storing any data unnecessarily.
4. XML External Entities (XXE)
XXE takes advantage of the XML parsers in a web application that might process and execute some payload included as an external reference in the XML document. This vulnerability was added to the list based on the statistics returned by companies running static analysis tools. Over the last couple of years, they’ve observed this vulnerability in XML processing has steadily gained traction and has become a more serious risk to web applications.
If an attacker adds or modifies these entities in an XML file and points them to a malicious source, they can cause a denial of service (DoS) attack or an SSRF attack. They can also scan internal systems, run port scans, extract data, etc.
Here’s an attack scenario from OWASP that involves an attacker attempting to extract data from the server:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
- Implement server-side input validation, sanitization checks, etc. to prevent hostile data within XML documents.
- Disable XML external entity and DTD processing.
- Use timeouts, and test any place where uploads are made.
- Use less complicated formats like JSON, avoid serialization of sensitive data, and patch all XML processors and libraries.
5. Broken Access Control
Missing function level access control and insecure direct object references — two categories from the 2013 OWASP vulnerabilities list — merged into broken access control in the latest list published by OWASP. Broken access control refers to weakness in the access control system that allow attackers to bypass authorization and gain access as privileged users. For instance, an application could allow users to change which account they are logged into merely by modifying a part of the URL.
- With public resources being the exception, deny all other resources by default and maintain logs for access control failures and alert admins.
- Implement and re-use access control checks throughout the application, including minimizing cross-origin resource sharing (CORS) usage.
6. Security Misconfigurations
This category refers to the improper implementation of a wide variety of controls that keep application data safe. Misconfiguring security headers, ignoring verbose error messages leaking sensitive information, neglecting to patch or upgrade systems, and using default configurations can all give rise to this vulnerability. Dynamic application security testing (DAST) can be used to detect such misconfigurations.
- Implement a secure installation process, including a system hardening process. Remove (or do not install) any unnecessary, unused features or frameworks.
- Utilize a “segmented application architecture” that implements a zero-trust model and allows only the desired behavior while blocking the rest. This helps to provide a secure separation between components or tenants, with segmentation, containerization or ACLs.
- Also be sure to review all permissions, update configurations, and install patches.
7. Cross-Site Scripting (XSS)
Cross-site scripting has moved down the list of OWASP top 10 vulnerabilities from third place in 2013 to seventh in 2017 — not necessarily because it has gotten any better, but because the other vulnerabilities have gained precedence. It’s still a common vulnerability affecting more than two-thirds of the application vulnerabilities that were submitted to OWASP for the 2017 list. The attacker essentially injects a script into the page output of someone else’s web application. The browser gets duped into believing it is a part of the page and runs the script.
For example, an attacker could send an email with a malicious link to a victim and make it seem like it’s coming from a trusted source. Upon clicking the link, the code gets executed in the victim’s web browser and can be used to steal session cookies, user credentials, or deliver malware.
- Use frameworks such as the latest Ruby on Rails, which filters out XSS by design.
- Implement data escaping techniques, apply context-sensitive encoding, and enable content security policy (CSP) as mitigation measures.
8. Insecure Deserialization
The concept of serialization is taking an object from the application code and converting it into a stream of bytes or into a format where it can be used for other purposes such as sending it over the wire or storing it on a disk. Deserialization is the opposite — it refers to converting serialized data back into objects usable by the application. This attack refers to these data objects being tampered with so when it is deserialized at the other end it leads to serious consequences like a distributed denial of service (DDoS) attack or a remote code execution.
- Don’t accept serialized objects from untrusted sources.
- Implement integrity checks and enforce strict type constraints during deserialization.
- Log all deserialization exceptions and failures while monitoring deserialization, and restrict all network connectivity from containers or servers that deserialize.
9. Using Components with Known Vulnerabilities
This section of the OWASP top 10 vulnerabilities list refers to the widespread issue of using components such as libraries to implement a certain functionality without first verifying their legitimacy or without using updated versions of those components. The exploitability score is variable depending on what and where the vulnerability is. For example, if there is a bug in a public-facing web server that’s more exploitable than a vulnerability in a less visible component or library. Attackers look for security flaws in these components and because developers reuse them across websites, if a weakness is exploited, it could potentially leave hundreds of pages vulnerable.
- Use components from official sources only and maintain a current inventory of them. Remove unused dependencies, unnecessary features, components, etc.
- Monitor for version updates and patches for both client and server-side components along with their dependencies.
- Continuously monitor sources like CVE for vulnerabilities in the components.
10. Insufficient Logging & Monitoring
To detect data breaches, organizations need to log events that are of interest to them in the context of their web application. The average discovery time for a security breach is more than six months after it has happened, giving attackers plenty of time to wreak havoc. Logging refers to recording the occurrence of an event or security incidence in your web application such as repeated failed login attempts from the same IP. Monitoring, on the other hand, refers to continually keeping an eye on these logs to escalate to the incident response (IR) team for timely action.
- Ensure all suspicious activities (such as failed logins, access control failures, input validation failures, etc.) are logged to identify malicious accounts in a format that can be fed into a centralized log management solution.
- Maintain detailed audit trails for important transactions to prevent tampering or deletion.
- Establish an incident response and recovery plan.
Issues like injection, XSS, etc. continue to appear, year after year, in the list of OWASP vulnerabilities as a reflection of the mistakes we keep on making while writing code and testing. A security-driven mindset is required at the management level to avoid a preference for functionality at the cost of security while passing directives to developers. It’s high time that security stopped being an afterthought in the software development life cycle and is incorporated into the process right from the get-go.