Web Application and Injection Attacks practice questions

SSRF

Why it fails: Server-Side Request Forgery (SSRF) occurs when a web application is tricked into making requests to an arbitrary domain specified by the attacker, often targeting internal systems or other external services. The observed log entry, which shows an attempt to access a local file path using '../', does not involve the server initiating an outbound network request to another server or internal service. Instead, it's a direct manipulation of a local file path within the server's own file system, fundamentally different from an SSRF attack.

LFI

Why it fails: Local File Inclusion (LFI) vulnerabilities allow an attacker to include a file from the local server into the web application's response, often by manipulating a parameter that specifies a file path to be processed by a script. While LFI can sometimes utilize directory traversal sequences ('../'), the primary characteristic is the *inclusion* of the file's content into the rendered page or script execution context. The log entry, by contrast, indicates a direct attempt to *access* a file path, not necessarily to include its content within a server-side script's execution flow, making it a direct path traversal attempt.

Command injection

Why it fails: Command injection vulnerabilities allow an attacker to execute arbitrary operating system commands on the host server by injecting them into input fields that are subsequently passed to a system shell. This attack aims to run commands like 'ls', 'cat', or 'whoami'. The log entry, however, shows an attempt to manipulate a file path using '../' to access a specific file, which is a file system navigation operation, not the execution of an arbitrary OS command. Therefore, it does not align with the characteristics of command injection.

RFI and command injection

Why it fails: RFI (Remote File Inclusion) is incorrect because the provided PHP `include` statement does not process user input as a remote URL, which would typically begin with schemes like `http://` or `ftp://`. Command injection is also not indicated, as there is no function present (e.g., `exec()`, `shell_exec()`, `system()`, or backticks) that would execute operating system commands based on user input. The `include` function is designed for file system operations, not direct command execution.

SQL injection and XSS

Why it fails: SQL injection is not applicable because the PHP code snippet does not interact with a database; there are no SQL queries being constructed or executed based on user input. Similarly, XSS (Cross-Site Scripting) is irrelevant as the `include` function processes file paths on the server-side and does not output user-controlled data directly into a web page in a client-side executable context. The vulnerability lies in file inclusion, not in manipulating database queries or injecting client-side scripts into a browser.

Directory traversal and IDOR

Why it fails: While directory traversal is a *component* of exploiting Local File Inclusion to reach files outside the intended directory, it is not the overarching vulnerability type itself in this context; LFI is the more precise classification. IDOR (Insecure Direct Object Reference) is entirely unrelated to this scenario. IDOR involves accessing unauthorized resources by manipulating an object's identifier (e.g., `user_id=123`), whereas this code deals with file path manipulation and inclusion.

Dictionary attack

Why it fails: Dictionary attack tries many passwords from a list on a single account.

Credential stuffing

Why it fails: Credential stuffing uses known username/password pairs from breaches.

Brute force attack

Why it fails: Brute force would try many passwords on a single account.

Error-based

Why it fails: Error-based SQL injection is an in-band technique where an attacker intentionally crafts malicious queries that force the database to generate error messages containing sensitive information. These error messages, which might include details like table names, column names, or even query results, are then displayed directly within the web application's response. Since the data is retrieved through the same channel as the legitimate application output, it is not considered a blind SQL injection method.

Union-based

Why it fails: Union-based SQL injection is an in-band technique that uses the `UNION` operator to combine the results of an attacker's malicious query with the results of the original legitimate query. This allows the attacker to retrieve data from other tables or databases and display it directly within the web application's standard response. As the extracted data is returned within the normal application output, it is not classified as a blind SQL injection method.

Directory Traversal

Why it fails: Directory Traversal, also known as path traversal, is a specific attack technique where an attacker manipulates file paths in an application's input to access files and directories stored outside the intended root directory. By injecting sequences like ../ (dot-dot-slash), an attacker can move up the directory hierarchy and read sensitive server files, such as configuration files or password files, which the application then attempts to "include" or process, fitting the scenario of "a parameter file to include server" resources.

Command Injection

Why it fails: Command Injection is a distinct vulnerability that allows an attacker to execute arbitrary operating system commands on the host server through a vulnerable application. This occurs when an application passes unsanitized user input directly to a system shell or a function that executes commands, such as system() or exec(). The scenario described involves accessing and including files by manipulating paths, which is fundamentally different from directly executing system-level commands.

Remote File Inclusion (RFI)

Why it fails: Remote File Inclusion (RFI) is a vulnerability where a web application is tricked into including a remote file, typically hosted on an attacker-controlled server, via a URL provided in user input. This often leads to remote code execution as the server fetches and executes the malicious script from an external source. The question describes accessing "server" files, implying local resources, and the mechanism of path manipulation, which is distinct from fetching files from a remote URL.

Successful logins from unusual geographic locations

Why it fails: Successful logins from unusual geographic locations are a primary indicator of a successful account compromise or account takeover, not an ongoing brute-force attack. A brute-force attack is characterized by failed attempts to guess credentials. Once an attacker has successfully logged in, the brute-force phase is over; the subsequent activity is exploitation of the compromised account, which might include logging in from various locations.

Error-based injection

Why it fails: Error-based SQL injection leverages database error messages, such as those generated by functions like `updatexml()` or `extractvalue()`, to reveal information from the database. By crafting malicious queries that intentionally cause specific errors, an attacker can embed query results within the error output returned to the application. This technique is fundamentally designed for data exfiltration by displaying data, not for directly writing files to the server's filesystem, as its output mechanism is limited to error strings.

Blind boolean-based injection

Why it fails: Blind boolean-based SQL injection infers data by observing true/false responses from the application, typically by monitoring HTTP response codes or subtle content changes. The attacker crafts queries that return a boolean result, then iterates through characters or conditions to deduce information one bit at a time without direct output. This method relies entirely on indirect observation and does not provide a mechanism for direct data output or file manipulation, making it unsuitable for writing files to the server.

Union-based injection

Why it fails: Union-based SQL injection leverages the `UNION SELECT` operator to combine the results of a malicious query with the results of the original legitimate query. This allows an attacker to retrieve data from other tables or even read local files (e.g., using `LOAD_FILE()`) by injecting a `SELECT` statement into the union. While highly effective for data exfiltration and reading files, the `UNION` operator's primary function is data retrieval, and it does not inherently provide a mechanism to write arbitrary files to the server's filesystem.

Security Misconfiguration (A05:2021)

Why it fails: Security Misconfiguration (A05:2021) encompasses vulnerabilities arising from insecure default configurations, incomplete or unpatched systems, unnecessary features enabled, or misconfigured HTTP headers. It specifically pertains to the improper setup and hardening of the application stack, rather than how user-supplied input directly manipulates application logic or interpreters. This is distinct from injection, which exploits input processing.

Broken Access Control (A01:2021)

Why it fails: Broken Access Control (A01:2021) describes vulnerabilities where an application fails to properly enforce restrictions on what authenticated users are authorized to do. It involves issues like horizontal privilege escalation, allowing users to access other users' data, or vertical privilege escalation, enabling standard users to perform administrative functions. The problem lies in inadequate authorization checks, not in the processing of malicious input by an interpreter.

Cryptographic Failures (A02:2021)

Why it fails: Cryptographic Failures (A02:2021) arise when sensitive data is not adequately protected, either in transit or at rest, due to weak or absent encryption, poor key management, or outdated cryptographic algorithms. This can lead to the exposure of confidential information. The core issue is the inadequate application of cryptographic controls to safeguard data, which is fundamentally different from exploiting input parsing.

Command injection

Why it fails: Command injection occurs when an application executes user-supplied input as part of a system command, leading to arbitrary command execution on the host operating system. This vulnerability typically involves manipulating shell commands, such as `ping` or `ls`, to run unintended instructions. The described scenario, however, focuses on reading files via directory navigation, not executing system commands.

Directory traversal

Why it fails: Directory traversal, also known as path traversal, is a web security vulnerability that allows an attacker to read arbitrary files on the server running an application. It exploits insufficient security validation of user-supplied input filenames, enabling the attacker to manipulate file paths using sequences like `../` to access directories outside the intended web root. This technique specifically aims to access and read sensitive files like configuration files or password files, making it the precise description for navigating the file system to read files.

Remote File Inclusion (RFI)

Why it fails: Remote File Inclusion (RFI) is a vulnerability where an application includes a remote file, typically from an external URL controlled by an attacker, into its execution context. This often results in remote code execution, as the included remote script is processed by the vulnerable server. The scenario, however, describes accessing and reading a *local* file on the server through path manipulation, not fetching and including a file from a distant, external source.

Set the User-Agent to: <img src=x onerror=alert(1)>

Why it fails: This payload uses an image tag with an onerror event, which could also trigger XSS if the image fails to load. However, it is not the most straightforward proof-of-concept; a simple <script> tag is more direct and reliable for demonstrating reflected XSS in a single request.

Set the User-Agent to: ' OR '1'='1

Why it fails: This payload, ' OR '1'='1, is a classic SQL injection attempt designed to manipulate backend database queries. If the User-Agent string were directly concatenated into a SQL query without proper sanitization, this could allow an attacker to bypass authentication or extract sensitive data by forcing a true condition. However, this is a server-side attack targeting the database and would not cause a web browser to execute client-side JavaScript, which is the defining characteristic of a Cross-Site Scripting (XSS) vulnerability.

Set the User-Agent to: ../../../../etc/passwd

Why it fails: The payload ../../../../etc/passwd represents a path traversal (or directory traversal) attack, aiming to access arbitrary files on the server's filesystem. If the application processes the User-Agent string in a way that constructs a file path without proper validation or sanitization, this could allow an attacker to read sensitive system files like the Unix password file. This is a server-side vulnerability focused on unauthorized file system access, fundamentally distinct from XSS, which involves client-side script execution in the user's browser.

Secure - Cookie is sent only over HTTPS

Why it fails: The Secure attribute is a distinct cookie flag, not a value for the SameSite attribute. Its purpose is to ensure that a cookie is only sent over encrypted HTTPS connections, preventing interception by attackers on unencrypted networks. This attribute provides transport-level security for the cookie's transmission, independent of its same-site or cross-site behavior.

HttpOnly - Cookie is inaccessible to JavaScript

Why it fails: The HttpOnly attribute is a separate, independent cookie flag, not a valid setting for the SameSite attribute. Its primary function is to prevent client-side scripts, such as JavaScript, from accessing the cookie's value. This significantly mitigates the risk of session hijacking via Cross-Site Scripting (XSS) attacks, as even if an XSS vulnerability exists, the attacker cannot read the cookie.

The application reflects user input in the page without encoding

Why it fails: When an application reflects user input directly back into a web page without proper encoding, it primarily indicates a Cross-Site Scripting (XSS) vulnerability. This allows an attacker to inject malicious client-side scripts, such as JavaScript, into the user's browser, potentially leading to session hijacking or defacement. Command injection, conversely, targets the server's operating system to execute commands, not the client's browser rendering.

The application returns database error messages

Why it fails: The display of verbose database error messages, such as SQL syntax errors or schema details, is a classic symptom of a potential SQL injection vulnerability. These errors occur when an attacker manipulates database queries, causing the database server to respond with diagnostic information. Command injection, however, exploits vulnerabilities in the execution of operating system commands, and its indicators would typically involve shell-level errors or unexpected command output, not database-specific diagnostics.

The application uses parameterized queries for database access

Why it fails: Parameterized queries are a fundamental security practice specifically designed to prevent SQL injection by separating SQL code from user-supplied data. By treating all input as literal values, they eliminate the possibility of an attacker injecting malicious SQL commands into a database query. While highly effective against SQL injection, this technique provides no defense whatsoever against command injection, which targets the execution of operating system commands rather than database interactions.

Input validation and output encoding

Why it fails: Input validation and output encoding primarily defend against injection attacks, such as SQL injection or Cross-Site Scripting (XSS), by sanitizing user-supplied data or safely rendering server responses. CSRF, however, exploits the trust a web application has in a user's browser to trick the user into performing an unintended action, rather than injecting malicious data into the application's logic or the browser's rendering engine. Therefore, these mechanisms do not directly prevent a forged request from being processed.

Enforcing CAPTCHA on all forms

Why it fails: Enforcing CAPTCHA on all forms is designed to differentiate human users from automated bots, primarily to prevent large-scale automated attacks like brute-forcing or spam. In a CSRF attack, the legitimate, authenticated user's browser is tricked into sending the request, and the user can still solve any CAPTCHA presented. Since the attack leverages the user's active session and browser, CAPTCHA does not prevent the forged request from being initiated and processed by the server.

SQLMap

Why it fails: SQLMap is a powerful open-source penetration testing tool that fully automates the process of detecting and exploiting SQL injection flaws. It is highly effective at identifying various types of SQLi, including boolean-based blind, time-based blind, error-based, UNION query, and stacked queries. Once a vulnerability is confirmed, SQLMap can automatically enumerate database schemas, tables, columns, and even dump data from the affected database, significantly streamlining the exploitation phase.

Nikto

Why it fails: Nikto is a web server scanner that focuses on identifying server misconfigurations, outdated software versions, and known vulnerabilities in web server components. It scans for common files, directories, server-side issues, and insecure configurations, but it does not interact with web application parameters to probe for input validation flaws like SQL injection. Nikto operates at a higher level, assessing the server's posture rather than application-layer injection points.

Nmap

Why it fails: Nmap (Network Mapper) is a robust network discovery and security auditing tool primarily used for port scanning and service detection. It operates at the network layer, identifying active hosts, open ports, services running on those ports, and operating systems. Nmap is not designed to interact with web application parameters or analyze application-layer vulnerabilities such as SQL injection; its scope is limited to network topology and service enumeration.

Out-of-band SQL injection

Why it fails: Out-of-band SQL injection is a valid, but less common, type of SQL injection that relies on the database server's ability to make external network requests. This technique is employed when an attacker cannot use the same channel to retrieve data, forcing the database to send data to an attacker-controlled server via protocols like DNS or HTTP. While powerful in specific scenarios, its reliance on specific database configurations and network egress capabilities makes it less frequently encountered than in-band or blind methods for general data exfiltration.

Heap-based SQL injection

Why it fails: Heap-based SQL injection is not a recognized or standard classification of SQL injection vulnerability. SQL injection fundamentally exploits flaws in how an application constructs SQL queries, leading to unintended execution of attacker-supplied code within the database context. Heap-based vulnerabilities, conversely, typically refer to memory corruption issues within the application's process memory (the heap), often related to buffer overflows or use-after-free bugs, which are distinct from database query manipulation.

NoSQL injection

Why it fails: NoSQL injection is a distinct category of vulnerability that targets NoSQL databases (e.g., MongoDB, Cassandra, Redis), not traditional relational SQL databases. While conceptually similar in exploiting improper input validation, NoSQL injection leverages the unique query languages and data models of NoSQL systems, such as JSON-based queries or document structures, to bypass authentication or manipulate data. It is fundamentally different from SQL injection, which specifically targets the Structured Query Language.

Credential stuffing

Why it fails: Credential stuffing uses known username/password pairs from data breaches. The scenario only provides a password list, not paired credentials, so this is incorrect.

Brute force attack

Why it fails: Brute force typically tries every possible combination, not just a list of common passwords. This is more specific to a dictionary attack.

Password spraying

Why it fails: Password spraying uses a few passwords against many accounts, not many passwords against one account.

File inclusion (LFI)

Why it fails: Local File Inclusion (LFI) vulnerabilities allow an attacker to include existing files from the server's file system by manipulating input parameters, often leading to information disclosure or, in some cases, remote code execution if combined with other vulnerabilities like log poisoning. However, LFI itself does not inherently involve uploading a malicious file to the server for execution. The scenario explicitly describes an attacker uploading a file, which is a distinct initial vector from LFI's typical mechanism of including already present files.

XSS

Why it fails: Cross-Site Scripting (XSS) is a client-side vulnerability where an attacker injects malicious scripts, typically JavaScript, into web pages viewed by other users. These scripts execute within the victim's web browser, enabling actions like session hijacking, defacement, or redirection. XSS fundamentally targets the client-side browser environment and does not involve executing arbitrary commands directly on the server or exploiting server-side file uploads for remote code execution.

Directory traversal

Why it fails: Directory traversal, also known as path traversal, allows an attacker to access files and directories stored outside the intended web root by manipulating file paths with sequences like "../" or similar encoding. While it can lead to unauthorized reading of sensitive files or even overwriting them, its primary purpose is file system navigation and access, not direct execution of arbitrary code on the server. The vulnerability described involves an uploaded file leading to execution, which is distinct from merely traversing directories to access existing files.

Reviewing the robots.txt file for hidden directories

Why it fails: Reviewing the robots.txt file primarily serves to identify paths and directories that webmasters prefer search engine crawlers to avoid. While it can reveal potentially interesting application endpoints, this file itself does not contain logic or mechanisms to detect SQL injection vulnerabilities. Its purpose is informational for crawlers and directory enumeration, not for dynamic vulnerability assessment or error-based SQLi discovery.

Scanning with a vulnerability scanner like Nikto

Why it fails: Nikto is a web server scanner designed to identify outdated server software, common configuration errors, and known vulnerabilities in web server components and CGI files. While it's valuable for initial reconnaissance and identifying potential weaknesses, Nikto's primary function is not to perform deep, logic-based SQL injection testing by crafting and analyzing database responses. Dedicated web application scanners or manual techniques are required for thorough SQLi detection.

Checking for XSS payloads in input fields

Why it fails: Checking for Cross-Site Scripting (XSS) payloads, such as <script>alert(1)</script>, in input fields aims to test if the application improperly renders user-supplied data in the client's browser, leading to arbitrary JavaScript execution. This method targets client-side vulnerabilities and browser behavior, which is fundamentally distinct from SQL injection, where the goal is to manipulate server-side database queries. XSS detection does not reveal database interaction flaws.

Sniper

Why it fails: Sniper is incorrect for a multi-parameter brute-force because it uses a single payload set and iterates through each defined payload position sequentially. It tests one position at a time while holding all other positions constant (usually to their original base value). This mode is primarily designed for fuzzing individual parameters to identify vulnerabilities like SQL injection or XSS, not for simultaneously brute-forcing combinations across multiple distinct input fields.

Direct

Why it fails: The "Direct" attack type is not a standard or recognized option within Burp Suite's Intruder module. Intruder offers specific attack modes like Sniper, Battering Ram, Pitchfork, and Cluster Bomb, each designed for distinct payload injection strategies. Therefore, attempting to select or utilize a "Direct" attack type would be invalid, as it simply does not exist in the tool's functionality for payload delivery.

Battering ram

Why it fails: Battering ram is incorrect because it employs a single payload set and inserts the same payload value into all defined payload positions simultaneously for each request. While it iterates through the payload set, every marked position receives the identical payload at any given time. This method is useful for testing vulnerabilities where a single value needs to be reflected across multiple input fields, but it is unsuitable for brute-forcing distinct combinations of different parameters.

Implementing Multi-Factor Authentication (MFA)

Why it fails: Implementing Multi-Factor Authentication (MFA) primarily enhances security by requiring multiple verification factors during the *authentication* process, protecting against unauthorized access due to compromised credentials. However, CSRF attacks exploit a user's *existing, active session* with a legitimate web application, where the user is already authenticated. MFA does not prevent an attacker from tricking an already logged-in user's browser into sending an unauthorized request to the vulnerable application, as the session token is already present.

Using HTTP GET requests for state-changing operations

Why it fails: Using HTTP GET requests for state-changing operations significantly increases vulnerability to CSRF attacks. GET requests are designed to retrieve data and should be idempotent; however, when used for actions like changing passwords or transferring funds, they can be easily triggered by an attacker. A malicious website can embed a simple `<img>` tag or `<a>` tag with the malicious GET request URL, causing the victim's browser to execute the request automatically when the page loads or is clicked, exploiting their active session.