Web Application and Injection Attacks practice questions

Directory Traversal

Why wrong: 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 wrong: 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 wrong: 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.

HTTP request smuggling

Why wrong: Incorrect. HTTP request smuggling exploits discrepancies in how front-end and back-end servers parse HTTP headers to cause request misrouting, not IP spoofing via X-Forwarded-For.

IDOR (Insecure Direct Object Reference)

Why wrong: Incorrect. IDOR involves accessing unauthorized resources by manipulating direct object references (e.g., IDs, filenames), not by spoofing IP addresses via headers.

Clickjacking

Why wrong: Incorrect. Clickjacking tricks users into clicking hidden elements via transparent overlays; it does not involve header manipulation.

Successful logins from unusual geographic locations

Why wrong: 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.

CAPTCHA

Why wrong: CAPTCHA can slow down automated attacks but is often bypassed using CAPTCHA-solving services. It is less robust than rate limiting and degrades user experience, so it is not the best.

Complex password policy

Why wrong: Complex password policy makes passwords harder to guess but does not prevent repeated attempts. It is a passive defense and not the best against brute-force.

Account lockout after 5 failed attempts

Why wrong: Account lockout after 5 failed attempts can be circumvented by distributed attacks from many IPs. It is reactive and may cause denial of service for legitimate users, so it is not the best.

Command injection

Why wrong: 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 wrong: 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 wrong: 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.

Secure - Cookie is sent only over HTTPS

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Password spraying uses a few passwords against many accounts, not many passwords against one account.

File inclusion (LFI)

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Implementing Multi-Factor Authentication (MFA)

Why wrong: 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 wrong: 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.

Reflected XSS

Why wrong: Reflected XSS (Cross-Site Scripting) is incorrect because it involves injecting malicious client-side scripts (typically JavaScript) into a web application, which are then immediately 'reflected' back to the user's browser, often via an error message, search result, or other response that includes user-supplied data. The attack relies on the victim's browser executing the script, leading to actions like session hijacking or defacement. It does not involve inferring server-side information through database delays or timing differences in the application's response.

Blind boolean-based SQL injection

Why wrong: Blind boolean-based SQL injection is incorrect because, while it is a form of blind SQL injection, it relies on observing *differences in the application's response content or HTTP status codes* rather than timing. Attackers inject SQL queries that evaluate to true or false, and the application responds differently based on the outcome (e.g., showing a generic error page for false, or a slightly altered layout for true) without directly revealing database errors or data. This method does not involve deliberate delays to exfiltrate information; instead, it analyzes the structure or presence of elements in the HTTP response.

CSRF

Why wrong: Cross-Site Request Forgery (CSRF) is incorrect because it is an attack that tricks authenticated users into unknowingly submitting malicious requests to a web application where they are currently logged in. The attacker crafts a forged request, often embedded in an image tag or a hidden form on a malicious website, and relies on the victim's browser automatically including their session cookies. This attack focuses on unauthorized actions performed by the victim through their browser, not on exploiting database vulnerabilities or inferring information through response timing differences from the server.

Metasploit

Why wrong: Metasploit Framework is a powerful penetration testing platform primarily used for developing, testing, and executing exploit code against remote target machines and for post-exploitation activities. While it contains some modules that can interact with databases or exploit certain database-related vulnerabilities, it is not specifically engineered for the automated detection and comprehensive exploitation of diverse SQL injection vulnerabilities within web applications. Its strength lies in general system compromise and payload delivery, rather than specialized web application SQLi scanning.

Nmap

Why wrong: Nmap (Network Mapper) is a free and open-source utility fundamentally designed for network discovery and security auditing. Its core functionalities include host discovery, port scanning, service detection, and operating system fingerprinting across network infrastructures. Although the Nmap Scripting Engine (NSE) allows for some vulnerability checks, Nmap is a network-level scanner and lacks the specialized HTTP interaction logic, payload generation capabilities, and response analysis required to automate the detection and exploitation of SQL injection vulnerabilities within web applications.

Burp Suite

Why wrong: Burp Suite is an integrated platform for performing security testing of web applications, primarily functioning as an intercepting proxy to analyze and manipulate HTTP traffic. While its Intruder module can be leveraged to craft and automate custom payloads for SQL injection testing, and its Scanner module can identify some SQL injection patterns, it is not a dedicated, fully automated SQL injection exploitation tool like SQLMap. Burp Suite typically requires more manual interaction and configuration for comprehensive SQLi exploitation compared to SQLMap's specialized, end-to-end automation.

SameSite=Strict

Why wrong: SameSite=Strict is a cookie attribute designed to mitigate CSRF by preventing the browser from sending the cookie with cross-site requests. This means if a user is logged into example.com and then visits malicious.com, any request initiated by malicious.com to example.com will not include the session cookie. While highly effective against many CSRF scenarios, it can sometimes break legitimate cross-site functionality and doesn't protect against same-site request forgery or if the state-changing action doesn't strictly require the session cookie.

HTTPOnly flag

Why wrong: The HTTPOnly flag prevents client-side scripts, such as JavaScript, from accessing the cookie via document.cookie. Its primary purpose is to mitigate the impact of Cross-Site Scripting (XSS) attacks, where an attacker might inject malicious script to steal session cookies. However, HTTPOnly does not prevent the browser from automatically sending the cookie with requests to the server, which is the fundamental mechanism exploited by CSRF attacks. Therefore, it offers no direct protection against CSRF.

Secure flag

Why wrong: The Secure flag ensures that a cookie is only sent by the browser over encrypted HTTPS connections, never over unencrypted HTTP. This protects the cookie from passive network eavesdropping and man-in-the-middle attacks that attempt to steal session information. While essential for overall application security and maintaining session integrity, the Secure flag does not prevent a malicious site from tricking a user's browser into sending an authenticated request to a legitimate HTTPS endpoint. The browser will still include the Secure cookie if the destination is HTTPS, regardless of the request's origin.

Directory traversal

Why wrong: Directory traversal vulnerabilities allow an attacker to read or write files to arbitrary locations on the server's file system by manipulating file paths, typically using sequences like "../". However, this attack vector does not inherently provide a mechanism for uploading a new, arbitrary malicious file from the client to the server for execution. The scenario explicitly describes an upload leading to server-side code execution, which is distinct from path manipulation for existing files.

Command injection

Why wrong: Command injection occurs when an application executes operating system commands constructed with unsanitized user input, allowing an attacker to inject and execute arbitrary system commands directly. While highly severe, this vulnerability is distinct from the scenario where a malicious file is uploaded to the server and subsequently executed by the web server itself. The attack vector here is the file upload mechanism, not the manipulation of command-line arguments passed to a shell.

Stored XSS

Why wrong: Stored Cross-Site Scripting (XSS) involves injecting persistent client-side scripts, typically JavaScript, into a web application's data store, which are then served to other users' browsers. When a victim's browser renders the compromised content, the malicious script executes within their browser context, allowing for session hijacking, defacement, or redirection. This attack targets the client-side and does not involve uploading server-side executable files or achieving remote code execution on the web server itself.

SSRF

Why wrong: 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 wrong: 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 wrong: 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.

Stored XSS

Why wrong: Stored XSS, also known as persistent XSS, involves the attacker injecting a malicious script that is permanently saved on the target server, typically within a database or file system. This stored payload is then delivered to all subsequent users who access the affected web page or resource, leading to widespread compromise without further attacker interaction. Because the script persists on the server, it can affect numerous victims over an extended period, making it a highly dangerous form of XSS.

DOM-based XSS

Why wrong: This attack occurs entirely on the client-side, where the malicious payload is executed due to a client-side script modifying the Document Object Model (DOM) environment. Unlike other XSS types, the server does not process the malicious input in a way that leads to its reflection or storage; instead, the vulnerability arises from client-side code dynamically writing unsanitized data, often from the URL (e.g., "location.hash"), directly into the page. The server's response itself is not inherently malicious.

Self-XSS

Why wrong: Self-XSS is a type of cross-site scripting where the victim themselves must manually inject and execute the malicious script, typically by pasting it into their browser's developer console or an input field that is only processed client-side. This vulnerability cannot be exploited by an attacker to target other users or even the victim without significant social engineering to convince the victim to actively run the code. It primarily relies on tricking users into compromising their own session rather than a server-side vulnerability.