Developers and website owners aren’t cybersecurity experts, so how do you know that your web application is secure? If you aren’t familiar with web vulnerabilities, how do you know what to search for? The Open Web Application Security Project (OWASP) provides guidelines for site owners and developers to help them properly review code and application procedures.
These guidelines are a roadmap of top vulnerabilities that put an application at risk. When an application is penetration tested (pen tested), pen testers use this list to go through code and procedures to find any vulnerabilities that could lead to a data breach, malware installation or account takeover attacks. Here are the top 10 OWASP categories and a brief explanation of each one.
1. Injection
Injection flaws are created from poorly designed commands built within the application usually from user input. These commands could be Structured Query Language (SQL) sent to a database or local commands that allow remote code execution. When these commands are built within the application without filtering out malicious characters, injection flaws are introduced. These flaws could be one of the worst to overlook in an application, because an attacker could potentially use privilege escalation and remote code execution to take over the web or database server.
2. Broken Authentication
Every application that stores sensitive data should have authentication procedures to protect from data breaches, but mistakes in authentication procedures can lead to account takeover. For instance, if sessions are not expired or destroyed after a user logs out of the application, a user’s session could be used by an attacker who can then impersonate the user within the application. Any permissions the user has will also be granted to an attacker with the session token.
3. Sensitive Data Exposure
Every application owner wants to protect sensitive data, but mistakes in the way data is transferred or stored could lead to a breach. For instance, developers that upload code to Github without redacting access keys, client keys, secrets or passwords would expose this sensitive data to the public. Another mistake that falls under this section is the use of cryptographically insecure algorithms to transfer data across the Internet, leading to vulnerabilities such as brute-force attacks on data.
4. XML External Entities (XXE)
This section mainly affects older applications where XML has not been replaced with JSON. This issue exposes data using malicious XML sent to parsers. For instance, the “billion laughs attack” (also known as an XML bomb) will cause a denial of service (DoS) should developers allow entities to repeat without memory limitations.
5. Broken Access Controls
Authentication requires users to authenticate into the application using proper credentials, but access controls determine the resources a user can read. Users should only have access to the data needed to perform a job function. With broken access controls, attackers can use privilege escalation attacks to gain access to data, and the first step is obtaining user credentials using phishing or malware.
Stolen credentials can also be found on lists sold on darknet markets. Forcing users to change their passwords every 30-60 days will help defend against broken access controls. Limiting access to only the data necessary to perform a function reduces the severity of a data breach should it happen.
6. Security Misconfigurations
Both developers and operation people should ensure that configurations are set properly to avoid attacker access. Leaving infrastructure configured with default credentials, misconfiguring cloud storage bucket access controls, having the wrong HTTP security headers, or leaving verbose error messages available in a web application are all examples of security misconfigurations.
To avoid security misconfigurations, the organization should have a professional review settings and scan for any vulnerabilities. For instance, if an organization leverages cloud virtualization and hosting from Amazon Web Services (AWS), a third-party penetration tester can review settings to avoid data breaches in the future due to mistakes in security configurations.
7. Cross-Site Scripting (XSS)
XSS is one of the hardest cybersecurity issues for a web developer to identify. XSS can be reflective or persistent. Reflective XSS occurs when an attacker can send malicious code to a web application, and the web application returns (reflects) malicious content to a user. It can lead to users falling victim to stolen credentials or sessions. It usually occurs when the application returns information using a GET request with invalidated user input.
Persistent XSS happens when the application does not properly encode user input, and malicious input is stored in a database and returned to users later in application processing. For instance, an attacker can send malicious content to an application form submission procedure. The content is stored in the database, and then a user opens a page with the malicious content, which results in execution of unwanted code.
8. Insecure Deserialization
When JSON or querystring values are parsed, user-controlled input should be whitelisted with validated data. If developers do not ensure that deserialized data from users is validated, it can lead to injection flaws. Injection flaws lead to possible remote code execution, SQL injection or privilege escalation attacks.
9. Components with Known Vulnerabilities
Developers often use dependencies in their code, which are libraries that perform a function without requiring a developer to code a component from scratch. These libraries can save a developer several hours of time and speed up the development process. It can also eliminate bugginess and make it easier for quality assurance people to test software.
Reducing development time is an advantage, but the disadvantage is relying on a third-party to properly code a library with no vulnerabilities. Vulnerabilities are made public so that developers know to upgrade to the latest version. However, many developers leave old outdated dependencies in their code, so the vulnerabilities persist. All dependencies should be properly monitored for vulnerabilities and updated when appropriate.
10. Insufficient Logging and Monitoring
Applications should always have logging and monitoring integrated, but this component takes time. To speed up development time, web application owners skip proper logging and monitoring integration, and this allows an attacker to potentially spend months to exfiltrate data after the initial compromise. Without logging, server managers and developers are unaware of the breach. Logging makes it easier to audit an application should a data breach occur, and monitoring lets administrators know that suspicious activity should be further reviewed.
Conclusion
With these ten OWASP categories, a website owner or developer can at least get started with a cybersecurity review of an application. There are several scanners on the market that can help find low-level vulnerabilities that an attacker’s scanner would find. However, to properly secure an application, the owner should have a cybersecurity expert review the code for issues and perform a penetration test that covers server configurations, HTTP headers, and code processing and output.
