Unofficial Guide to OWASP Top 10:2021

The OWASP Top 10 plays a versatile role in the security industry. On one hand, it serves as a reference model for categorizing security flaws in different segments. On the other hand, it is used as an analytics tool to determine the prevalence of specific vulnerability groups. The OWASP Top 10 is utilized by almost all professionals, regardless of their roles and responsibilities in the industry. This is because the OWASP Top 10 discusses the current threat landscape, risk factors, and detection and remediation of trending bugs. The OWASP Top 10 frames its datasets based on surveys and assessments participated by individuals and organizations. Thus, OWASP Top 10 has become the most reliable and industry-leading guide for application security. Today I will discuss it in the way I understood it. This will enlighten your AppSec career for sure. Don’t forget to read until the end, as there’s a bonus in the last part!

OWASP Top 10 is undoubtedly the most popular project by OWASP. It guides developers and security professionals to take necessary action against vulnerabilities enlisted there. OWASP Top 10 is the entry of the 10 most common web app security risks. Here the summary, impact, and mitigation are described for each bug class. It is updated after 4 years consecutively with a new version. OWASP conducts surveys from different personnel types and collaborates with companies to produce this list. From here you can know the in-depth analysis of the procedure. Regardless of your role, you should keep OWASP Top 10 in mind. Following everything from SDLC, secure code review, and security testing, OWASP Top 10 is almost necessary.

A01: Broken Access Control

This type of flaw allows an attacker to perform actions beyond their regular privileges. In short, authorization is violated here. Broken access control is the most versatile vulnerability class in the OWASP Top 10. It can have any severity of impact depending on the functionality. I’ve already written a thorough write-up on this. So won’t say much more about this category.

A02: Cryptographic Failures

When application/API uses no/weak encryption mechanism to protect data in transit or at rest. Deprecated SSL/TLS certificate, backdated hashing, hardcoded cryptographic key, automated database encryption/decryption, and decipherable UUID/access token allow attackers to craft endpoints to access/tamper others’ accounts or confidential information. Burp Suite’s Decoder, Sequencer, and CrackStation are good tools for cryptanalysis. Wireshark and tcpdump are used for packet interception and analysis.

A03: Injection

Abusing input fields to insert out-of-context data instead/alongside regular input. It occurs when input validation is missing or weak, allowing invalid inputs to be executed by the interpreter. Thus, malicious data are executed as commands, code, or queries. There are different types of injection attacks. Such as SQL injection, LDAP injection, Command injection, CRLF injection, PHP Object Injection, Host Header Injection, CSS injection, Template injection, XSS, iframe injection, SMTP injection, XPath injection, and Text Based Injection. Although XSS was in a distinct category in the previous list. However, it is now merged with ‘Injection’ because it injects arbitrary javascript into the web app. To exploit injection flaws, see how the input(request) is being parsed and producing result(response) from the back-end server. Observe how WAF and filters are handling inputs. Craft the payloads or polyglots accordingly to reach the destination and get them executed. There are many open-source and commercial scanners to detect and exploit injection attacks.

A04: Insecure Design

The absence of SSDLC (Secure Software Development Lifecycle) results in a vulnerable application layer that attackers can exploit. Business logic flaws typically fall under this category. These implementation flaws can vary from application to application because the design is not the same everywhere. Unlike SQLi, XSS, SSRF, or XXE, these are non-technical flaws that pose risks from a business logic perspective. Imagine a scenario where a malicious gamer can bypass one level to access another without having to play. It doesn’t hamper the application but violates the product policy. Typically no tools can identify insecure design flaws. The tester needs to use the application from an end-user’s perspective and examine its functions and features in different ways. He attempts to produce unexpected outcomes by tampering with, skipping, or removing certain values or parts of the application. I find this category quite similar to A01: Broken Access Control.

A05: Security Misconfiguration

Not configuring security settings properly can lead to malicious exploitation. Reading documentation greatly assists in uncovering such vulnerabilities. Additionally, it’s important to consider which best practices may be overlooked by developers or administrators. Such as incorrect permissions on cloud instances, verbose errors leaking too much data, misconfigured/lack of security headers, developer forgetting to disable debugging/testing mode, use of default credentials, and the directory or path containing sensitive data has not been disabled. Brute-forcing with default/weak values in dedicated areas(e.g. login, URL path) is quite effective in testing security misconfiguration.

A06: Vulnerable and Outdated Components

Web application simultaneously functions with components like frameworks, CMS, dependencies, libraries, and third-party integrations. If the presence and vulnerabilities of any of these components are known to the attacker then boom! It occurs when the customer uses a vulnerable product from any vendor. Attackers search with the label(title and version number) in the public domain where the known vulnerabilities are enlisted. They can also employ vulnerability scanners to identify previously discovered vulnerabilities in those components or modules. Testing A6 bugs is quite easy since pre-made exploits already exist. Identify the technology stack by automated tools like Wappalyzer, Censys and SecurityTrails. Or manually by reviewing job description of technical roles, verbose errors, website footer, response header, favicon hash, OSINT, and Google hacking. Easy to find in a White Box but challenging in a Black Box environment. If the identification is completed, then go to Exploit-DB, National Vulnerability Database (NVD), PacketStorm Security, vulmon, Rapid7 DB, sploitus for the exploit. You can also check the security bulletin/advisories of the vendor to see publicly disclosed vulnerabilities. SCA(Software Composition Analysis) test is also helpful in discovering such vulnerabilities.

A07: Identification and Authentication Failures

Weak authentication and session management are the root cause of such flaws. Allows attackers to circumvent authentication mechanisms to access others’ accounts. Common techniques include brute-force attacks, abusing broken password reset systems, and uncovering weak session IDs to infiltrate accounts. First, identify what type of authentication schema (e.g., basic HTTP authentication, OAuth, SSO, OTP, JWT) is implemented in the application. Then run test cases against that endpoint. Check for the type of rate-limiting, CAPTCHA, IP blockage, or account lockout in place. Evasion techniques and tools are already available for them if you search wisely. Employ suitable and heavy wordlists if you run brute-force attacks. Also don’t forget to analyze session tokens to determine if they can be exploited in some way. Burp Sequencer is quite effective in doing it.

A08: Software and Data Integrity Failures

Similar to the A6 category. Applications relying on insecure third parties like CDN, repositories, dependency, external JavaScripts, plugins, themes, and CI/CD pipelines without integrity verification can produce such risks. In such a case, an attacker can push malicious changes when the developer installs/pulls any updates or downloads. The attacker needs to compromise a particular module of a software supply chain to achieve this. Some of the vulnerabilities are found in black box, while others are discovered in white box testing.

A09: Security Logging and Monitoring Failures

Security logging and monitoring failures are almost essential to record any potential incident. Consecutive failed login attempts, unusual traffic from numerous/suspicious clients, unrecognized sign-in alerts, unwanted cash withdrawals, malicious inputs, unrecognized files in the back-end, and so on. A lack of efficient logging and monitoring allows attackers to remove footprints or successfully breach security systems. Every action done by each role should be recorded into dedicated log files in a formatted manner. These include HTTP status codes, IP addresses, timestamps, usernames, endpoints, files, and monetary transactions. It’s not a specific vulnerability that gets exploited. This group represents a set of weaknesses. If not aligned, the attacker can remain undetected, and potential/actual incidents may go untracked. It goes under white box testing because the log monitoring system is accessible to the stakeholders of an enterprise.

A10: Server Side Request Forgery

SSRF occurs when the attacker forces the server to send arbitrary requests to unintended areas for malicious purposes. Such as RCE, DoS, Information Disclosure, etc.

I believe that OWASP Top 10 is a vague documentation for many people. Because there are many instances of glitches that are difficult to categorize. Professional pen-testers, researchers, and bug hunters can highly relate to what I mean to say. Also, this guide doesn’t say what’s the scope of a particular issue. Some bugs can only be discovered in a white-box environment, while others are found in black-box environments. So a tester has to be well aware of such scenarios. I also mentioned a few if you have read above. Now let’s come to the bonus part. I have curated a checklist for you guys on this topic. Here you go.

https://www.notion.so/OWASP-Top-10-2021-Checklist-30f4b7362b904f129c9b9c094dd6fd9d