Network and Web Application Attacks practice questions

Cookie headers

Why it fails: SQL injection is not typically carried out via cookie headers, as cookies are primarily used for session management, user tracking, and storing client-side state, not for direct database query parameters. While it's theoretically possible for a poorly designed application to directly incorporate cookie values into a SQL query without proper sanitization, this is an uncommon and highly specific vulnerability. Most applications process cookies separately from user-supplied data intended for database interaction, making them a less frequent vector for SQL injection compared to direct input fields.

User-Agent header

Why it fails: The User-Agent header, which identifies the client's browser and operating system, is generally not a typical vector for SQL injection. Its primary purpose is informational for server-side logging and content negotiation, not as a parameter for database queries. For a User-Agent header to be exploitable via SQL injection, the application would need to be exceptionally misconfigured, directly embedding this header's value into a database query without any sanitization. This scenario is highly unusual and represents a severe architectural flaw rather than a common attack surface.

Brute Force

Why it fails: While a common web application attack, brute force is primarily an authentication mechanism attack focused on guessing credentials (passwords, PINs, keys) through exhaustive trial and error. It does not involve injecting malicious code or commands into the application's data processing or execution flow, which is the defining characteristic of "injection" vulnerabilities.

Path Traversal

Why it fails: Path Traversal, also known as Directory Traversal, is a vulnerability that allows an attacker to access files and directories stored outside the intended web root directory by manipulating file paths. While it enables unauthorized access to sensitive data or system files, it does not involve injecting executable code or commands into the application's processing logic or underlying database, distinguishing it from injection-based attacks.

Cross-Site Request Forgery (CSRF)

Why it fails: Cross-Site Request Forgery (CSRF) is an attack that tricks a victim into submitting a malicious request to a web application in which they are authenticated. Unlike injection attacks, CSRF does not involve inserting malicious code into the application's data streams or execution environment. Instead, it leverages the victim's existing authentication session to perform unauthorized actions on their behalf.

Use a single DNS server for all queries

Why it fails: Relying on a single DNS server for all queries creates a critical single point of failure. If this server becomes unavailable due to a DDoS attack, hardware malfunction, or misconfiguration, all DNS resolution for the organization will cease, leading to a complete service outage. This approach severely compromises availability and resilience, making it an ineffective countermeasure against various threats.

Disable DNS caching

Why it fails: Disabling DNS caching is a detrimental practice that significantly degrades network performance and does not effectively prevent DNS poisoning. Caching reduces the load on DNS servers and speeds up resolution for clients by storing frequently requested records. Without caching, every query requires a full resolution path, increasing latency and bandwidth usage, while still remaining vulnerable to poisoning attempts during the initial resolution phase.

The server redirects to a login page (302)

Why it fails: A 302 Found status code indicates a temporary redirect, often used for session management or post-authentication navigation. While a SQL injection might bypass authentication, a direct redirect to a login page typically signifies that the application's authentication mechanism was triggered by an invalid or unauthenticated request, rather than a successful data extraction or manipulation via SQLi. This outcome usually implies the injection attempt itself did not yield the desired database interaction.

The server returns a 200 OK status code

Why it fails: A 200 OK status code, indicating a successful HTTP request, can indeed signify a successful SQL injection, especially in scenarios like blind SQL injection or when using UNION queries. If the injected query executes successfully without causing a server error and the application processes the database's response, the server will often return a 200 OK. The success is then confirmed by subtle changes in the page content (e.g., altered logic, presence/absence of specific elements) or by the direct display of injected data within the page.

The client receives no response (timeout)

Why it fails: A timeout, where the client receives no response from the server within a specified period, typically suggests that the injected query caused a critical server-side issue. This could be an infinite loop, a resource exhaustion, a database deadlock, or a complete application crash. While some advanced time-based blind SQL injection techniques intentionally induce delays, a general timeout without specific timing patterns usually indicates a failure to execute the intended query successfully, preventing the server from generating any valid response.

Boot from Linux USB, mount Windows partition, navigate to System32\config, replace sethc.exe with cmd.exe, reboot into Windows and press Shift five times.

Why it fails: This is the correct order because you need to boot from the USB first to access the system, then mount the Windows drive to see its files, navigate to the configuration directory, replace the accessibility tool with a command prompt, and finally reboot to trigger the exploit.

Mount Windows partition, boot from Linux USB, navigate to System32\config, replace sethc.exe with cmd.exe, reboot into Windows and press Shift five times.

Why it fails: This sequence is fundamentally flawed because mounting a partition is an operating system function that cannot be performed without an active operating system. The Linux USB must first be booted to provide the necessary kernel and utilities to execute the `mount` command. Attempting to mount the Windows partition before the Linux environment is active makes the initial step procedurally impossible.

Boot from Linux USB, navigate to System32\config, mount Windows partition, replace sethc.exe with cmd.exe, reboot into Windows and press Shift five times.

Why it fails: While booting from the Linux USB is the correct first step, attempting to navigate to `System32\config` on the Windows partition before it is mounted is a critical error. The Windows file system remains inaccessible to the live Linux environment until it has been explicitly mounted to a directory within the Linux file system hierarchy. Without mounting, the `System32\config` path does not exist within the accessible file system, preventing any navigation or file operations.

Boot from Linux USB, mount Windows partition, navigate to System32\config, reboot into Windows and press Shift five times, replace sethc.exe with cmd.exe.

Why it fails: This option incorrectly places the file replacement step after rebooting into Windows. The core of this exploit relies on Windows executing the *modified* `sethc.exe` (which is actually `cmd.exe`) when Sticky Keys is invoked. If the system is rebooted before the `sethc.exe` file is replaced, the original, legitimate `sethc.exe` will still be in place, and pressing Shift five times will only activate Sticky Keys, not an elevated command prompt.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting (XSS) is a client-side code injection attack where malicious scripts are injected into trusted websites. Unlike the observed attack, XSS does not involve traversing server-side file systems or accessing local files like `/etc/passwd`. Instead, XSS aims to execute arbitrary JavaScript in a victim's browser, typically to steal session cookies, deface websites, or redirect users.

Remote file inclusion (RFI)

Why it fails: Remote File Inclusion (RFI) vulnerabilities allow an attacker to include a remote file, usually via a URL, on the vulnerable server. This typically involves injecting a URL into a parameter that the web application uses to include files, leading to the execution of arbitrary code from an external source. The requests in the exhibit, however, are specifically targeting *local* files on the server's file system using relative path manipulation, not external resources.

SQL injection

Why it fails: SQL injection is a code injection technique used to attack data-driven applications, where malicious SQL statements are inserted into an entry field for execution. This attack primarily targets the backend database, allowing an attacker to bypass authentication, retrieve sensitive data, or even modify database content. The observed attack, conversely, focuses on manipulating file paths to access operating system files directly, which is distinct from injecting database commands.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting (XSS) involves injecting malicious client-side scripts into a *trusted* website, which are then executed by other users' browsers when they view the compromised page. The attack described, where a malicious site auto-submits a form, does not involve injecting code into the legitimate bank site itself but rather leverages the user's browser to send an unauthorized request *from* the malicious site. This fundamental difference makes XSS an incorrect classification for the scenario.

Session hijacking

Why it fails: Session hijacking typically involves an attacker gaining unauthorized access to a user's active session by stealing or predicting session identifiers, such as cookies. While it allows an attacker to perform actions as the user, the scenario explicitly states the attack uses auto-submission from a malicious site, not direct cookie theft. This is particularly true when cookies are HttpOnly and Secure, which prevent client-side script access, meaning the user's session is *used* by the browser, not *stolen* by the attacker.

Phishing attack

Why it fails: Phishing is a social engineering technique where attackers deceive users into revealing sensitive information or performing actions by impersonating a trustworthy entity. This usually involves fake websites, emails, or messages designed to solicit direct user input, such as login credentials, or to trick them into clicking malicious links. The described attack, involving a silent auto-submission from a malicious site, does not rely on user deception to input data but rather on the browser's automatic handling of authenticated requests.

ARP spoofing attack

Why it fails: ARP spoofing operates at Layer 2 (Data Link Layer) by manipulating MAC address tables and ARP caches, not establishing or managing TCP/IP connections. `netstat` primarily displays active TCP and UDP connections, listening ports, and routing information, which are Layer 3 and Layer 4 phenomena. Therefore, an ARP spoofing attack, which alters the local ARP cache to redirect traffic, would not be directly observable through `netstat` output showing established network sessions.

DNS amplification attack

Why it fails: A DNS amplification attack is a reflection-based Distributed Denial of Service (DDoS) technique that leverages open DNS resolvers to flood a target with large volumes of UDP traffic. This attack specifically utilizes UDP port 53 for DNS queries and responses. The `netstat` output in the exhibit, however, shows an established TCP connection on port 80, which is used for HTTP, making it inconsistent with the characteristics of a DNS amplification attack.

SYN flood attack

Why it fails: A SYN flood attack is a classic denial-of-service technique that exploits the TCP three-way handshake by sending numerous SYN requests to a target server without completing the final ACK. This leaves a large number of half-open connections on the server, typically in a `SYN_RECEIVED` state, exhausting its connection table. The `netstat` output, however, indicates an `ESTABLISHED` connection, signifying a completed handshake and an active, fully open session, which is not characteristic of a SYN flood.

Stored XSS

Why it fails: Stored Cross-Site Scripting (XSS) involves injecting a malicious script into a web application's persistent storage, such as a database, comment section, or forum post. This script is then retrieved and executed by any user who later accesses the compromised data, making it a persistent threat. The exhibit, however, depicts an immediate, non-persistent reflection of the script in the server's response, not its retrieval from a stored location.

DOM-based XSS

Why it fails: DOM-based Cross-Site Scripting (XSS) occurs entirely on the client-side, where a malicious script manipulates the Document Object Model (DOM) of a web page without the server ever processing or reflecting the payload. The vulnerability arises from client-side scripts that incorporate user-supplied data into the DOM without proper sanitization. The provided exhibit, however, clearly shows the script being injected and returned directly within the server's HTTP response, indicating a server-side reflection rather than a client-side DOM manipulation.

SQL injection

Why it fails: SQL injection is a web security vulnerability that allows an attacker to interfere with the queries an application makes to its database. Attackers typically insert malicious SQL statements into input fields to execute arbitrary database commands, retrieve sensitive data, or modify database contents. The exhibit, however, clearly shows the injection of a `<script>` tag containing JavaScript, which targets the client's browser for execution, not the backend database.

The IP address 192.168.2.10 is not in the allowed subnet.

Why it fails: While the client's IP address 192.168.2.10 is indeed outside the allowed subnet `192.168.1.0/24`, this is not the primary reason for the 401 status code. If IP denial were the sole issue, and no authentication was attempted or failed, Nginx would typically return a 403 Forbidden error. The 401 specifically signifies that the authentication process was engaged, but the provided credentials failed validation, indicating an issue beyond just the IP address.

The 'deny all' directive overrides the 'allow' directive.

Why it fails: The `deny all` directive does not unconditionally override the `allow` directive when `satisfy any` is configured. The `satisfy any` directive explicitly states that if *any* of the defined `allow` or `auth_basic` conditions are met, access is granted. Therefore, if the client's IP had been within `192.168.1.0/24`, access would have been granted despite the `deny all` directive, demonstrating that `deny all` is evaluated in conjunction with `allow` and `auth_basic` under the `satisfy any` logic.

The .htpasswd file is missing or misconfigured.

Why it fails: If the `.htpasswd` file specified by `auth_basic_user_file` were missing, inaccessible, or severely misconfigured to the point of being unreadable, Nginx would typically return a 500 Internal Server Error. This error indicates that the server encountered an unexpected condition preventing it from fulfilling the request, such as a critical configuration file being unavailable. A 401 Unauthorized error, conversely, confirms that the authentication mechanism was active and attempted to validate credentials, but they were found to be incorrect.

1 column

Why it fails: If the original query were selecting only one column, the UNION SELECT 1,2,3 payload would inevitably fail with a SQL error indicating a column count mismatch. The UNION operator strictly enforces that all participating SELECT statements must return the same number of columns. Providing three values (1, 2, 3) in the injected query when the original only has one would prevent successful execution and data retrieval.

2 columns

Why it fails: While the application's front-end might only render two output fields (e.g., "User" and "Email"), the successful execution of UNION SELECT 1,2,3 confirms that the underlying SQL query is selecting three columns. The UNION operator demands an exact match in column count between the original query and the injected SELECT statement. The appearance of '2' and '3' in the displayed fields further indicates that these correspond to the second and third columns selected by the query, with the first column likely being an ID that is not displayed.

4 columns

Why it fails: The UNION SELECT 1,2,3 statement explicitly attempts to select three columns. If the original query were selecting four columns, the UNION operation would fail due to a column count mismatch error. The UNION operator requires that the number of columns in the injected SELECT statement precisely matches the number of columns in the initial query for the combined result set to be valid. Therefore, a successful UNION with three values rules out four columns.

Slowloris

Why it fails: Slowloris is a denial-of-service attack that works by opening many connections and sending partial HTTP requests, keeping them alive. It is not specific to HTTP/2 and primarily targets HTTP/1.1 servers by exhausting connection limits. While it can affect HTTP/2 servers, it does not manipulate HTTP/2 frames, so it is not a valid HTTP/2-specific technique in this context.

SYN flood

Why it fails: A SYN flood is a network-layer attack that exploits the TCP handshake by sending many SYN packets without completing the connection. It is not specific to HTTP/2 and operates at a lower layer. While it can cause denial of service, it does not involve manipulating HTTP/2 frames, so it is not a valid HTTP/2-specific DoS technique.

HTTP/2 CONTINUATION flood

Why it fails: The CONTINUATION flood is a theoretical attack that involves sending many CONTINUATION frames without the END_HEADERS flag, causing the server to buffer headers indefinitely. While it is HTTP/2-specific, it is less commonly exploited and not as widely recognized as HPACK bomb or Rapid Reset. In this scenario, the question asks for two valid techniques; Rapid Reset and HPACK bomb are the primary ones, so this option is not selected.

SQL Injection

Why it fails: SQL Injection exploits vulnerabilities in an application's database queries, allowing an attacker to insert or manipulate SQL commands. This typically affects the backend database server, enabling data exfiltration, modification, or even complete database compromise, rather than directly manipulating content displayed in the user's browser. The attack targets the data layer, not the client-side rendering.

Cross-Site Request Forgery (CSRF)

Why it fails: Cross-Site Request Forgery (CSRF) tricks a victim's browser into sending an authenticated request to a vulnerable web application, leveraging the victim's existing session. The attack does not involve injecting malicious scripts into the application's output; instead, it exploits trust in the user's browser to perform unauthorized actions on their behalf, such as changing passwords or transferring funds, without the user's explicit consent.

Command Injection

Why it fails: Command Injection vulnerabilities arise when an application executes user-supplied input as part of an operating system command without sufficient sanitization. This allows an attacker to inject arbitrary shell commands, which are then executed on the server hosting the web application. The impact is server-side command execution, not client-side manipulation of browser output or user interface elements.

UDP flood

Why it fails: UDP flood transmits connectionless datagrams, which never initiate a three-way handshake, so no incomplete handshakes would appear. It is tempting as another high-volume denial-of-service attack, and would be correct if the target received a flood of UDP packets to closed ports.

ARP spoofing

Why it fails: ARP spoofing sends forged ARP replies to poison local MAC-to-IP mappings, generating no TCP SYN segments to internal hosts. It is tempting as a man-in-the-middle technique, and would be correct if the evidence were duplicated IP-to-MAC bindings rather than half-open connections.

ICMP flood

Why it fails: ICMP flood sends echo request packets, generating no TCP handshake state at all, so it cannot produce half-open connections. It is tempting as a volumetric denial-of-service technique, and would be correct if the traffic consisted of high-rate ping requests rather than SYN segments.

Directory traversal

Why it fails: Directory traversal, also known as path traversal, exploits vulnerabilities to access files and directories stored outside the intended web root directory. This attack manipulates file paths in input parameters to read sensitive files like configuration files or password files, but it does not directly modify the values of form parameters submitted by a user, such as a product price. Its focus is on file system access, not data manipulation within an application's business logic.

Cross-Site Scripting (XSS)

Why it fails: Cross-Site Scripting (XSS) is a client-side code injection attack where malicious scripts are injected into legitimate websites. When a user visits the compromised page, the malicious script executes in their browser, potentially stealing cookies, session tokens, or redirecting them to malicious sites. While XSS can manipulate the DOM, its primary purpose is script execution within the victim's browser context, not directly altering server-side form parameter values like a product price during submission.

Cross-Site Request Forgery (CSRF)

Why it fails: Cross-Site Request Forgery (CSRF) tricks a victim's browser into sending an authenticated request to a vulnerable web application without the user's knowledge. The attacker crafts a malicious request (e.g., a money transfer) and embeds it into a page the victim visits. While CSRF can initiate actions like changing a password or making a purchase, it does so by forcing the browser to send a *pre-defined* request, not by allowing the attacker to *modify* specific parameters like a product price within an existing form submission.

SNMP

Why it fails: Simple Network Management Protocol (SNMP) is primarily used for monitoring and managing network devices, such as routers, switches, and servers, by collecting and organizing information about them. It operates at the application layer and typically uses UDP ports 161/162. While crucial for network operations, SNMP does not provide encryption or secure communication for web application traffic, making it unsuitable for protecting user data exchanged over HTTP/HTTPS. Therefore, it cannot prevent an attacker from intercepting web-based communications.

FTP

Why it fails: File Transfer Protocol (FTP) is an application-layer protocol designed for transferring files between a client and a server on a computer network. By default, FTP transmits both data and authentication credentials, such as usernames and passwords, in cleartext, meaning they are unencrypted and easily readable by anyone performing network sniffing. This inherent lack of encryption makes standard FTP highly vulnerable to eavesdropping and man-in-the-middle attacks, rendering it ineffective for securing web traffic or preventing data interception.

HTTP

Why it fails: Hypertext Transfer Protocol (HTTP) is the foundational protocol for data communication on the World Wide Web, enabling clients to request and servers to deliver web pages and other resources. However, HTTP transmits all data, including sensitive information like login credentials and form submissions, in cleartext across the network. This lack of encryption means that an attacker performing packet sniffing can easily intercept and read the entire communication, making HTTP inherently insecure for any traffic requiring confidentiality or integrity protection.

Cross-Site Request Forgery (CSRF)

Why it fails: Cross-Site Request Forgery (CSRF) attacks involve coercing an authenticated user's browser to send an unintended request to a trusted web application. This typically occurs when a victim visits a malicious site that contains a hidden request targeting another site where they are logged in. The provided HTTP exhibit does not show a request originating from a different domain or any mechanism designed to trick a user's browser into making an unwanted, authenticated request to the server.

SQL Injection

Why it fails: SQL Injection is a code injection technique used to attack data-driven applications, where malicious SQL statements are inserted into an entry field for execution. An exhibit demonstrating SQL injection would typically show user input containing specific SQL syntax, such as single quotes, comments (`--`), or keywords like `UNION` or `SELECT`, aimed at manipulating backend database queries. The captured HTTP request and response in the exhibit contain no such database-specific syntax or indicators of backend query manipulation.

Directory Traversal

Why it fails: Directory Traversal, also known as Path Traversal, is an attack that allows an attacker to access files and directories stored outside the web root folder by manipulating file paths in user-supplied input. This vulnerability typically involves using sequences like `../` or `..\` to navigate the server's file system. The provided HTTP request and response do not contain any attempts to modify file paths or access system files beyond the intended application scope, which would be indicative of a directory traversal attempt.

Configure the firewall to block all incoming traffic from the IPs that appear most frequently in logs.

Why it fails: While blocking frequently appearing IPs might seem like a direct response, it is a reactive measure that fails to confirm the specific attack type causing high CPU and 503 errors. Such an approach risks blocking legitimate users if the attack employs IP spoofing or a large, distributed botnet. More critically, it does not provide insight into the attack's nature (e.g., Layer 7 vs. Layer 4 DDoS, or other attack vectors), which is essential for developing a precise and effective mitigation strategy.

Increase the number of application servers to handle the load.

Why it fails: Increasing the number of application servers might temporarily alleviate the symptoms of high CPU utilization and 503 errors by distributing the load across more resources. However, this is a reactive scaling measure, not a diagnostic one. It consumes additional resources without identifying the root cause or specific nature of the attack (e.g., whether it's a volumetric DDoS, resource exhaustion, or a legitimate traffic surge). Without understanding the attack type, scaling can be inefficient, costly, and ultimately overwhelmed by a persistent, targeted attack.

Run a SQL injection scanner on the application.

Why it fails: SQL injection is a code injection technique primarily used to exploit vulnerabilities in data-driven applications, typically aiming for data exfiltration, manipulation, or unauthorized access to databases. While successful SQL injection can lead to severe data breaches, it does not directly manifest as widespread high CPU utilization across servers or 503 "Service Unavailable" errors, which are indicative of resource exhaustion or service overload. Running a scanner for this vulnerability is irrelevant to diagnosing the observed symptoms and diverts resources from the actual problem.

The attacker successfully performed a blind SQL injection to enumerate the database structure

Why it fails: The attacker did not perform a blind SQL injection, which relies on inferring data through true/false responses or time delays without direct output. Instead, the exhibit demonstrates a successful UNION-based SQL injection where the attacker directly received the database's response containing enumerated data. This direct data exfiltration method is fundamentally different from the indirect, inferential nature of blind SQL injection techniques.

The attacker caused a denial of service by sending an invalid query

Why it fails: The query executed successfully, evidenced by the HTTP 200 OK status code and the return of actual data from the database. A denial of service attack would typically manifest as a server error, timeout, or an inability to process legitimate requests, none of which occurred here. The system remained operational and responsive, fulfilling the attacker's data retrieval request without interruption.

The attacker modified the database records to update user passwords

Why it fails: The SQL payload utilized in the exhibit, specifically `UNION SELECT`, is designed for data retrieval, not for modifying database records. To update user passwords, the attacker would need to employ a DML (Data Manipulation Language) statement such as `UPDATE` along with appropriate `SET` and `WHERE` clauses. The current query merely extracts existing information without altering the database's state or content.

Implement rate limiting on the /product endpoint

Why it fails: Implementing rate limiting on the /product endpoint would indeed reduce the volume of requests processed per unit of time, thereby mitigating the *impact* of the resource exhaustion attack. However, it does not *immediately stop* the attacker's ability to consume resources entirely. The malicious actor could still continue sending requests, albeit at a throttled rate, potentially prolonging the attack and still exhausting resources over a longer period, failing to provide the immediate cessation required.

Install a web application firewall (WAF) to detect and block malicious requests

Why it fails: While installing a Web Application Firewall (WAF) is an excellent strategic measure for enhancing application security and detecting various types of malicious requests, it is not an immediate solution for an active, ongoing resource exhaustion attack. Deploying and properly configuring a WAF, including defining rules specific to the current attack pattern, requires significant time and expertise. This delay means the attack would likely continue to impact services during the WAF's setup phase, rendering it unsuitable for immediate incident response.

Apply input validation to ensure product IDs are positive integers

Why it fails: Applying input validation to ensure product IDs are positive integers is a fundamental security best practice that helps prevent various injection attacks and ensures data integrity. However, this measure is primarily preventive and does not address the core issue of an ongoing resource exhaustion attack where the attacker is sending a high volume of *valid* requests. The attacker can simply continue to send numerous requests with perfectly valid product IDs, still overwhelming the server and exhausting its resources, making it ineffective for immediate attack cessation.