Module four study material VAEE
Client-side attacks: A client-side attack refers to a type of attack that targets the systems of
unsuspecting victims by exploiting vulnerabilities in client-side applications such as web browsers,
media players, email clients, and office suites. It is a common and increasingly dangerous threat that
organizations face, and it allows attackers to gain information without having to target heavily
defended server-side applications. Users become easy prey for client-side attacks due to a lack of or
poorly maintained security measures such as anti-virus, firewall, or antispyware.
Role of browsers in combatting client-side attacks
A detailed comparison of Internet Explorer (IE) security versus modern browsers (like Chrome,
Firefox, Edge, and Safari) in preventing client-side attacks such as XSS, CSRF, drive-by downloads,
and malicious scripts
Aspect Internet Explorer Modern Browsers
Process Limited. IE used a single process for tabs Strong sandboxing per tab/process;
Isolation (except in IE8+ with Loosely Coupled IE). isolates browser, renderer, and
plugins to prevent attacks from
affecting the system.
Memory Susceptible to buffer overflows due to older Modern browsers implement ASLR,
Safety codebase in IE. DEP, and sandboxing to mitigate
memory-based attacks.
Address Space Layout Randomization (ASLR)
Data Execution Prevention (DEP)
Aspect Internet Explorer Modern Browsers
Update Manual or via Windows Update; slower Auto-updates; security patches
Mechanism response to zero-day exploits. delivered rapidly; continuous
vulnerability management.
Aspect Internet Explorer Modern Browsers
HTTPS/TLS Supported, but older Enforce modern TLS 1.2/1.3; deprecated weak
versions (SSL 2.0/3.0) were ciphers; HSTS (HTTP Strict Transport Security)
insecure. support.
Certificate Less strict; allowed Strict certificate validation; warnings for
Validation invalid/self-signed certs with invalid/mismatched certificates; automatic
warnings. revocation checks.
What is source code analysis & Binary analysis?
Source Code Analysis (SCA): Definition:
Source code analysis is the process of examining the human-readable code of a program (like C, Java,
Python) to identify vulnerabilities, bugs, or insecure coding patterns before the program is compiled
or deployed.
Advantages:
• Detects issues early in development.
• Provides precise location of vulnerabilities in code.
Disadvantages:
If the source code is unavailable (third-party software, legacy apps), analysis cannot be performed.
Binary Analysis
Definition:
Binary analysis examines the compiled program (machine code or executable) rather than the
source code. This is also called reverse engineering or executable analysis.
Advantages:
• Works even if source code is unavailable.
• Detects vulnerabilities introduced during compilation.
Disadvantages:
Binary code is low-level; understanding the logic is harder without debugging/reverse engineering
skills.
A short note on Cross-site scripting:
Cross-Site Scripting (XSS) XSS is a web security vulnerability that allows an attacker to inject
malicious scripts (usually JavaScript) into web pages viewed by other users. These scripts can steal
cookies, session tokens, or perform actions on behalf of the victim.
Impact on users:
Reputation Damage
• Attackers can post content or messages under the user’s session, harming trust or credibility.
Tracking / Fingerprinting
• Collects detailed user behavior and browsing data for surveillance or profiling.
Malware Distribution / Drive-By Downloads
• Injected code can redirect users to malicious websites or force downloads of malware.
Reflected XSS (Non-Persistent XSS)
Reflected XSS occurs when the malicious script is immediately reflected by the web server in its
response to the user, often via URL parameters or form inputs. The server does not store the
script—it just echoes it back.
Stored XSS (Persistent XSS)
Stored XSS happens when the malicious script is stored on the server, such as in a database,
message forum, comment section, or user profile. Every user who accesses the stored data will
execute the script.
Feature Reflected XSS Stored XSS
Storage on server No Yes
Requires user action Yes (click link) No
Impact Usually targets one user Can target multiple users
Common places URL parameters, search, forms Comments, forums, profiles, databases
Description on OWASP (Introduction & Purpose)
OWASP stands for Open Web Application Security Project.
• It is a global non-profit organization dedicated to improving the security of software.
• OWASP provides free resources, tools, guidelines, and best practices for web and
application security.
• It is community-driven, with contributions from security experts worldwide.
Purpose of OWASP
• To educate developers, testers, and organizations about application security risks.
• To provide standardized guidelines for identifying and mitigating vulnerabilities.
• To promote secure coding practices and awareness of common threats.
A list of the most critical web application security risks. Updated periodically; the latest version
(2021) includes:
1. Broken Access Control
2. Cryptographic Failures
3. Injection (SQL, OS, etc.)
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)
Refer this: OWASP Top Ten | OWASP Foundation note that OWASP 2025 is likely to be announced in
November 2025.
Importance of OWASP
A. Provides awareness of threats to web applications.
B. Helps organizations prioritize security fixes.
C. Acts as a benchmark for compliance in security audits.
D. Encourages developers to build secure applications by design.
A concise/precise one-line definition for each of the OWASP Top 10 Web Application Security Risks
2021:
A01: Broken Access Control – Users can access unauthorized functions or data due to improper
access restrictions.
A02: Cryptographic Failures – Sensitive data is exposed because of weak or missing encryption.
A03: Injection – Malicious input is interpreted by the application, allowing attacks like SQL, OS, or
LDAP injection.
A04: Insecure Design – Flaws in the application’s design enable security vulnerabilities.
A05: Security Misconfiguration – Default settings, incomplete configurations, or exposed debug
features create security risks.
A06: Vulnerable and Outdated Components – Using unpatched libraries or frameworks introduces
known security weaknesses.
A07: Identification and Authentication Failures – Weak authentication allows attackers to
impersonate users.
A08: Software and Data Integrity Failures – Applications fail to verify the integrity of code or data,
leading to unauthorized modifications.
A09: Security Logging and Monitoring Failures – Insufficient logging and monitoring prevent
detection of attacks.
A10: Server-Side Request Forgery (SSRF) – Attackers can make the server send requests to
unintended internal or external resources.
How do you address the above while testing web applications?
While testing web applications, all the above mentioned web application vulnerabilities should be
thoroughly tested.
A01 — Broken Access Control
Test the unauthorized access to pages/APIs, horizontal/vertical privilege escalation, forced
browsing.
A02 — Cryptographic Failures
Test data-in-transit and at-rest encryption, weak ciphers, insecure key/storage, sensitive data in
cleartext.
A03 — Injection
Test SQL, NoSQL, OS, LDAP, command injection via input fields, headers, cookies, JSON.
A04 — Insecure Design
Test business-logic abuses, missing threat model controls
A05 — Security Misconfiguration
Test default credentials, verbose errors, open directories, unnecessary services, insecure headers.
A06 — Vulnerable & Outdated Components
Test third-party libs, frameworks, server components for known CVEs.
A07 — Identification & Authentication Failures
Test weak passwords, broken MFA, session fixation, insecure password reset
A08 — Software & Data Integrity Failures
Test tampered uploaded files.
A09 — Security Logging & Monitoring Failures
Test important events that are logged
A10 — Server-Side Request Forgery (SSRF)
Test inputs that cause server to fetch external/internal resources ([Link])
Potential Risks wrt OWASP top 10 2021
OWASP 2021 Risk Potential Risk in This Scenario Explanation
A01: Broken Access Users may access other users’ Misconfigured role checks or
Control sensitive data or admin direct object references could
functions. allow privilege escalation.
A02: Cryptographic Sensitive data (PII, passwords, Weak encryption, missing TLS
Failures tokens) may be transmitted or
stored insecurely.
A03: Injection SQL, NoSQL, or command Malicious input could manipulate
injection in user input fields. database queries or execute
commands.
A04: Insecure Design Logic flaws could allow bypass E.g., price manipulation,
of validation or workflows. bypassing multi-step approvals.
A05: Security Default credentials Could be introduced by third-
Misconfiguration party components or server
settings.
A06: Vulnerable & Third-party libraries may contain Unpatched dependencies can be
Outdated Components known vulnerabilities. exploited remotely.
A07: Identification & Weak authentication May allow account takeover or
Authentication Failures mechanisms or password credential stuffing.
policies.
A08: Software & Data Unsigned updates or tampered Could lead to code execution or
Integrity Failures third-party code. altered behavior.
A09: Security Logging & Malicious activity may go Lack of proper logging or alerting
Monitoring Failures undetected. reduces incident response
capabilities.
A10: Server-Side User-controlled URLs or API calls Could allow attackers to access
Request Forgery (SSRF) to internal services. internal network resources.
How should we mitigate ?
Risk Recommended Mitigation
Broken Access Control Implement server-side role-based access control
Cryptographic Failures Enforce HTTPS/TLS 1.2+; use strong encryption (AES-256) for
sensitive data at rest
Injection Use parameterized queries. validate and sanitize all user input;
implement WAF rules.
Insecure Design Conduct threat modeling and security review
Security Misconfiguration configure secure headers; remove default accounts.
Vulnerable & Outdated Apply patches promptly.
Components
Identification & Enforce strong password policies; implement MFA; limit login
Authentication Failures attempts;
Software & Data Integrity Validate signatures for third-party libraries or updates; use
Failures integrity checks (hashes, digital signatures);
Security Logging & Enable detailed logging for authentication, authorization, and
Monitoring Failures sensitive operations; integrate alerts; monitor anomalies.
Server-Side Request Validate and whitelist allowed URLs; restrict internal network
Forgery (SSRF) access; sanitize input for URL requests.
****************************************************************************
A note on insecure deserialization:
Insecure deserialization occurs when an application accepts serialized data from an untrusted
source and deserializes it (turns it back into an object) without proper validation or integrity
checks. This can allow attackers to manipulate the serialized data to:
• Bypass authentication or access controls
• Tamper with application logic or data
In short: the application blindly trusts external serialized input, which can be exploited.
Example for a serialized data in JSON format
"username": "John",
"age": 25,
"roles": ["user", "admin"]
Deserialization:
Deserialization is the process of converting serialized data (a stored or transmitted object in a
string or binary format) back into a usable in-memory object. Deserialized data is the result of this
process — the object that the program can now use like any normal variable, array, or class
instance.
Example:
# Serialized data (JSON string)
serialized_data = '{"username": "John", "age": 25, "roles": ["user","admin"]}'
# Deserialization
deserialized_data = [Link](serialized_data)
print(deserialized_data)
Consequences of Insecure Deserialization
1. Remote Code Execution (RCE)
o Attackers can craft serialized objects that execute arbitrary code when deserialized.
o Often the most severe consequence, allowing full system compromise.
2. Privilege Escalation
o Malicious objects can manipulate roles, permissions, or session data to gain higher
privileges.
o Example: a normal user becomes an admin.