Application and Software Vulnerabilities

What the Exam Is Really Testing

Application vulnerabilities make up the largest chunk of the vulnerability questions on this exam. SQL injection, XSS, CSRF, buffer overflows, race conditions — you will see all of them, and you need to tell them apart under pressure.

Given a description of application behavior or a code-related scenario, identify the vulnerability category, understand why it exists, and select the correct mitigation.

You do not need to write exploit code. But you do need to read a scenario — "a user submits input that appears in another user's browser" or "the application crashes after receiving oversized input" — and immediately know which vulnerability that describes and how to fix it.

Memory and Process Vulnerabilities

Memory Injection

Memory injection attacks insert malicious code into a running process's memory space. The attacker exploits a legitimate process to execute unauthorized code, making the attack harder to detect because it runs within a trusted application.

DLL injection is a common example: the attacker forces a process to load a malicious dynamic link library, giving them control within the context of a legitimate application.

Buffer Overflow

A buffer overflow occurs when an application writes more data to a memory buffer than it was designed to hold. The excess data overwrites adjacent memory, which can corrupt data, crash the application, or allow the attacker to execute arbitrary code.

Buffer overflows exist because applications fail to validate the length of input before writing it to memory. The mitigation is input validation and bounds checking — verifying that data fits within the allocated buffer before processing it.

On the exam, buffer overflow questions often describe an application crash after receiving oversized input. The correct answer involves input validation or memory-safe programming practices.

Race Conditions

A race condition occurs when the outcome of a process depends on the timing or sequence of events, and an attacker can manipulate that timing. The system behaves correctly under normal conditions but produces unexpected results when operations overlap.

Time-of-Check to Time-of-Use (TOCTOU)

TOCTOU is a specific type of race condition. The system checks a condition (permissions, file existence, resource availability) and then acts on it, but an attacker changes the condition between the check and the use.

Example: A system verifies a user has permission to access a file, then opens the file. Between the check and the open, an attacker replaces the authorized file with a sensitive one. The system opens the replacement because the permission check already passed.

The exam tests whether you recognize TOCTOU as a timing-based vulnerability distinct from standard access control failures.

Software Supply Chain Vulnerabilities

Malicious Updates

Compromised software updates distribute malware through legitimate update channels. Because users and systems trust vendor updates, malicious updates bypass normal security controls entirely.

The defense involves verifying update integrity through code signing, hash verification, and monitoring vendor security practices.

Side Loading

Side loading installs applications from outside official distribution channels — bypassing app store review processes, security scanning, and integrity verification. On mobile devices, this means installing APK files directly rather than through the Google Play Store or Apple App Store.

Side-loaded applications may contain malware, lack security updates, or request excessive permissions without oversight.

Web Application Vulnerabilities

SQL Injection (SQLi)

SQL injection inserts malicious SQL commands into application input fields that interact with a database. If the application passes user input directly to SQL queries without sanitization, the attacker can read, modify, or delete database contents.

A login form vulnerable to SQL injection might accept ' OR '1'='1 as a username, causing the query to return all records and bypass authentication.

Mitigation: parameterized queries (prepared statements), input validation, and stored procedures. Never concatenate user input directly into SQL queries.

Cross-Site Scripting (XSS)

XSS injects malicious scripts into web pages viewed by other users. The script executes in the victim's browser within the context of the trusted website, allowing the attacker to steal session cookies, redirect users, or manipulate page content.

There are three types:

• Stored XSS — The malicious script is permanently stored on the target server (in a database, comment field, or forum post)
• Reflected XSS — The script is reflected off a web server in error messages, search results, or URL parameters
• DOM-based XSS — The vulnerability exists in client-side code rather than server-side code

Mitigation: output encoding, input validation, and Content Security Policy (CSP) headers.

Cross-Site Request Forgery (CSRF)

CSRF tricks an authenticated user into submitting a request they did not intend. The attacker crafts a malicious request and delivers it through a link or embedded content. When the victim clicks it, their browser sends the request with their existing authentication cookies.

Example: A user logged into their bank visits a malicious page that contains a hidden form submitting a transfer request to the bank's API. The bank processes it because the user's session cookie is attached.

Mitigation: anti-CSRF tokens, SameSite cookie attributes, and requiring re-authentication for sensitive operations.

Server-Side Request Forgery (SSRF)

SSRF tricks a server into making requests to internal resources that the attacker cannot reach directly. The attacker submits a URL to a server-side function, and the server fetches that URL using its own network access — potentially accessing internal APIs, metadata services, or private network resources.

SSRF is particularly dangerous in cloud environments where internal metadata services can expose credentials and configuration data.

Configuration and Coding Vulnerabilities

Improper Input Handling

Improper input handling is the root cause of most application vulnerabilities. When applications accept and process user input without validation, sanitization, or encoding, they become vulnerable to injection attacks, buffer overflows, and data corruption.

The principle: never trust user input. Validate type, length, format, and range before processing.

Improper Error Handling

Verbose error messages reveal internal architecture details: database types, file paths, stack traces, and API structures. Attackers use this information to craft targeted attacks.

Proper error handling shows generic messages to users while logging detailed errors internally for debugging.

Hard-Coded Credentials

Embedding usernames, passwords, API keys, or encryption keys directly in application source code creates permanent backdoors. These credentials cannot be rotated without modifying and redeploying the application, and they are often discoverable through reverse engineering or source code exposure.

Default Configurations

Default configurations ship with known credentials, unnecessary services enabled, and permissive security settings. Attackers maintain databases of default credentials for every major platform and device.

The first step after deploying any system is changing default credentials and hardening the configuration.

Pattern Recognition

When you see a vulnerability question, determine:

1. Is the vulnerability in the code, the configuration, or the process?
2. Does it involve user input being processed unsafely?
3. What type of data or system is being affected?
4. What is the correct mitigation category?

Pattern shortcuts:

• User input in a database query = SQL injection
• Script executing in another user's browser = XSS
• Authenticated action the user did not initiate = CSRF
• Server fetching an attacker-controlled URL = SSRF
• Application crash from oversized input = buffer overflow
• Timing-dependent security bypass = race condition / TOCTOU

Trap Patterns

Common exam traps:

• Confusing XSS with CSRF. XSS injects and executes scripts. CSRF tricks users into performing actions. Both involve web browsers, but the mechanisms are completely different.
• Confusing SQLi with XSS. SQLi targets the database through the server. XSS targets the user through the browser. The injection target determines the category.
• Assuming encryption fixes input handling. Encrypting malicious input does not neutralize it. The input must be validated and sanitized before processing.
• Overlooking SSRF. SSRF is newer to the exam but increasingly important. If a scenario describes a server making unexpected internal requests, think SSRF.

Scenario Practice

Question 1

A web application allows users to search for products. A security tester enters ' UNION SELECT username, password FROM users -- in the search box and receives a list of all user credentials from the database.

Which vulnerability is being exploited?

Question 2

An application checks whether a temporary file exists before writing to it. An attacker replaces the temporary file with a symbolic link to a sensitive system file between the existence check and the write operation. The application overwrites the system file.

Which vulnerability does this describe?

Question 3

A penetration tester discovers that a web application displays full stack traces, database connection strings, and internal file paths when an error occurs. Which vulnerability category does this represent?

Key Takeaway

If you remember one thing from this module, make it this:

Most application vulnerabilities trace back to one failure: trusting user input without validation.

Input validation stops injection attacks. Output encoding stops XSS. Anti-CSRF tokens stop forged requests. Atomic operations stop race conditions. And changing default credentials is the simplest fix that organizations still get wrong. Know the vulnerability, know the mitigation, and match them in the scenario — that is what the exam is testing.