Web App Injection Attacks practice questions

The query returns all rows from the users table.

Why it fails: This result occurs only when using string concatenation in SQL queries. In parameterized queries, the database driver ensures the input is treated as a literal value. Therefore, the database engine searches for a user whose actual name is 'OR 1=1' instead of evaluating the command.

The database engine throws a syntax error.

Why it fails: The syntax is valid for a parameterized query because the placeholder handles the input safely. The database engine does not interpret the input as SQL keywords, so no syntax error is triggered. The request completes successfully but fails to match any records in the table.

The application crashes due to an unhandled exception.

Why it fails: Modern database drivers and ORMs are designed to handle special characters in input fields gracefully. Providing SQL keywords in an input field does not cause an application crash unless the backend logic is improperly configured to handle empty result sets or specific database exceptions.

Escape input using a generic blacklist.

Why it fails: Blacklisting characters is notoriously ineffective because attackers constantly discover new bypasses and alternative ways to encode payloads. It is impossible to anticipate every dangerous character or sequence. Defense-in-depth requires positive security models, like allow-listing, rather than attempting to filter out known bad input, which is always incomplete.

Run the application with root privileges.

Why it fails: Running applications with root privileges is a security anti-pattern. If a command injection occurs, the attacker gains full control of the entire server. Applications should always adhere to the principle of least privilege, running with the minimum permissions necessary to perform their required tasks to limit potential blast radii.

Cross-Site Scripting via injected JavaScript payloads in the SKU search field

Why it fails: Cross-Site Scripting executes malicious scripts in the victim browser rather than interacting directly with database execution logic. While dangerous, XSS does not natively dump internal database table structures or reveal underlying schema definitions directly onto application response pages.

Remote Code Execution via insecure deserialization of serialized PHP objects

Why it fails: Insecure deserialization exploits flaws in how application objects are reconstructed from serialized data strings. This vulnerability typically yields arbitrary code execution or system command access rather than structured database schema information exposed directly in standard search results.

XML External Entity injection via malformed search queries processed by an XML parser

Why it fails: XML External Entity vulnerabilities occur when parsers process malicious external entity definitions within uploaded or submitted XML documents. This leads to local file disclosure or server-side request forgery rather than direct relational database schema error exposure.

Enabling client-side JavaScript validation to strip out single quotes and semicolons

Why it fails: Relying on client-side input validation provides zero security assurance because attackers can easily bypass browser restrictions using intercepting proxies like Burp Suite. Security controls must always be enforced on the server side to protect backend assets.

Relying exclusively on Web Application Firewall signature blocking rules

Why it fails: Signature rules only match known attack patterns, so they miss novel or obfuscated injection payloads that parameterised queries would neutralise at the database layer. WAFs are tempting as a compensating control for legacy code that cannot be changed, where patching the application itself is not feasible.

Encoding all database query outputs using HTML entity encoding before rendering

Why it fails: HTML entity encoding protects the rendering context against cross-site scripting; it does not alter how the database parses SQL syntax, so injected statements still execute. Output encoding is the right control when untrusted data is reflected into HTML pages rather than passed to a query.

Server-Side Template Injection via malicious expressions evaluated by template engines

Why it fails: Server-Side Template Injection occurs when user input is embedded unsafely into template engines like Jinja2 or Twig. This differs fundamentally from XML parsing flaws, as template injection evaluates server-side code constructs directly within view rendering logic.

Cross-Site Scripting via injected script tags within CDATA sections

Why it fails: While XML documents can contain CDATA sections holding script content, rendering them improperly in a web browser leads to Cross-Site Scripting. Server-side command execution requires flaws in server processing logic rather than client-side script rendering issues.

LDAP injection through improper attribute filtering in directory search queries

Why it fails: LDAP injection targets directory search filters, not XML parsers, so it cannot explain external entity resolution or command execution here. It is tempting because both involve unsanitised input reaching an interpreter, but LDAP injection would be correct against a directory service querying attributes, not an XML parser.

Database error logs displaying syntax violations from unmatched table column counts

Why it fails: Unmatched column counts produce SQL syntax errors, evidencing SQL injection or faulty queries, not command injection. It is tempting because both flaws stem from unsanitised input, and would be the correct indicator where the payload manipulates database statements rather than spawning shell commands on the host.

Application configuration files storing plaintext database connection passwords

Why it fails: Plaintext database credentials in configuration files indicate poor secret management, not command injection. It is tempting because exposed credentials often accompany compromised web applications, and would be relevant where the finding concerns credential storage or lateral movement rather than operating-system command execution through application input.

Client-side DOM manipulation errors logged within browser developer console windows

Why it fails: DOM manipulation errors occur in the browser, so they evidence client-side scripting flaws such as XSS, not server-side command injection. It is tempting because both involve injected input, and would be correct where the requirement is to show malicious script executing in a victim's browser rather than commands running on the web server.

Server-Side Request Forgery via unvalidated webhook URLs

Why it fails: SSRF exploits server-side URL fetching to reach internal services, not token forgery. The forged JWTs stem from the server accepting the 'none' algorithm or failing to verify signatures, letting attackers alter claims without the secret. SSRF would be correct when an application fetches attacker-supplied URLs, enabling access to cloud metadata endpoints.

SQL injection within the session lookup table query

Why it fails: SQL injection manipulates database queries, not JWT integrity. The forgery arises because the server trusts the token's algorithm header or skips signature verification, accepting unsigned or 'none'-algorithm tokens. SQL injection would be correct where unsanitised input reaches a session-lookup query, allowing attackers to bypass authentication via crafted SQL.

Cross-Site Scripting enabling session identifier theft from local storage

Why it fails: While Cross-Site Scripting can steal tokens stored in local storage, the scenario specifically describes forging and modifying token payloads without possessing the secret key. This points directly to algorithm enforcement flaws rather than client-side script theft.

Enforcing HTTPS for all application traffic.

Why it fails: HTTPS encrypts data in transit, protecting against man-in-the-middle attacks, but it does not prevent XSS. An attacker can still inject malicious scripts into a page served over HTTPS. XSS is a flaw in the application's input or output logic, which encryption alone cannot resolve or mitigate.

Disabling JavaScript in the web browser.

Why it fails: While disabling JavaScript prevents XSS, it is not a feasible defense for modern web applications that rely on client-side functionality. Security controls should be implemented on the server or via browser policies, not by requiring end users to degrade their browsing experience by turning off essential features.

Using basic regex to filter out script tags.

Why it fails: Regex-based filtering is notoriously ineffective because attackers can bypass it using alternative payloads, character encoding, or DOM-based vectors. Relying on blacklisting patterns is inherently fragile. Robust defense requires properly escaping data at the output point rather than attempting to filter out specific dangerous tags or characters.

SQL Injection

Why it fails: The exhibit displays a web page source code, not a database interaction. While the input payload looks like SQL, the vulnerability context is the browser's rendering of HTML. SQL injection occurs on the server side during database queries, whereas this is a client-side execution vulnerability occurring within the browser.

Command Injection

Why it fails: Command injection occurs when user input is used to execute operating system commands on the server. The exhibit depicts HTML rendering, which is a presentation layer issue. There is no evidence of the input being passed to shell-level execution functions or backend system processes in this specific scenario.

Insecure Direct Object Reference (IDOR)

Why it fails: IDOR involves an attacker accessing resources by manipulating identifiers such as database keys. The exhibit shows a clear XSS vector where the application reflects user input. While both are web vulnerabilities, IDOR focuses on broken access control, whereas the exhibit highlights a failure in input-to-output data handling protocols.

The vulnerability enables unauthorized database password decryption.

Why it fails: Deserialization is concerned with object structure and logic, not cryptographic key storage. While an attacker might gain system access, the vulnerability is not inherently tied to the decryption of static database passwords, but rather the execution of logic flow via the reconstructed object during the deserialization process.

It allows attackers to inject malicious code into the database.

Why it fails: This is a description of SQL injection. Insecure deserialization is specifically about the process of converting a serialized byte stream back into an object in memory. The risk is that the resulting object's state or behavior is manipulated by the attacker to perform unauthorized actions or execute code.

It causes the application to leak internal memory structures.

Why it fails: While memory corruption can occur, the primary danger is the manipulation of application logic. Leaking memory is generally a secondary symptom or related to information disclosure vulnerabilities. The main exploit objective in deserialization attacks is achieving remote code execution through the application's own built-in functionality and classes.

Stored XSS uses server-side scripts, whereas Reflected XSS uses client-side scripts.

Why it fails: Both forms of XSS utilize client-side scripting (usually JavaScript) to execute within the victim's browser. The distinction is not in the type of script used, but in the storage location of the malicious payload. Stored XSS exists in the server database, while Reflected XSS exists only in the request.

Reflected XSS is stored on the server, while Stored XSS is delivered via URLs.

Why it fails: This statement is the exact opposite of the truth. Reflected XSS payloads are delivered in real-time through URLs or request parameters, while Stored XSS payloads are permanently saved in the application's persistent storage like a database, comment section, or profile page before being served to other users.

Reflected XSS is more dangerous because it bypasses CSRF tokens.

Why it fails: The danger levels depend on the context, not CSRF tokens, which are separate security controls. Stored XSS is generally considered more dangerous because it can affect all users without individual interaction. CSRF is an entirely different class of vulnerability that focuses on forcing unwanted actions rather than script injection.

The script executes successfully.

Why it fails: The CSP header restricts script execution to 'self' and 'https://trusted.cdn.com'. Since the injected script is inline, it fails the policy constraints. Browsers will refuse to execute it and will typically report a CSP violation in the developer console, neutralizing the XSS attempt immediately upon page rendering.

The browser executes the script only if the user is an admin.

Why it fails: CSP is a security policy enforced by the browser for all users, regardless of their role or permission level. It does not contain logic for user roles. If the script violates the policy, the browser will block it for everyone, ensuring consistent security posture across the entire application user base.

The browser automatically strips the script tags.

Why it fails: The browser does not modify the HTML content to remove script tags. Instead, it enforces the policy by refusing to execute the code contained within those tags. The DOM may still contain the tags, but the security engine prevents the JavaScript engine from interpreting or running the injected code.

The application uses a relational database management system.

Why it fails: Relational databases themselves are not inherently vulnerable. The vulnerability resides in how the application constructs queries before sending them to the database. Using a relational database is a standard design choice and provides no indication of security quality or susceptibility to SQL injection without reviewing the code.

The database contains sensitive user data.

Why it fails: The existence of sensitive data is a risk factor for the impact of an exploit, but it is not an indicator of the vulnerability itself. An application can have highly sensitive data and be perfectly secure against SQL injection if it uses properly parameterized queries or safe database abstraction layers.

The application is written in an interpreted language.

Why it fails: The programming language choice is irrelevant to SQL injection risk. Both compiled and interpreted languages are susceptible to injection if they interact with databases improperly. The issue is about input handling and query building practices, which are independent of the underlying runtime environment or language characteristics used by the developer.

Implement client-side JavaScript regex validation to strip SQL keywords from input parameters before transmission.

Why it fails: Client-side validation offers zero security against determined attackers who bypass browser controls completely using intercepting proxies like Burp Suite. Attackers can submit raw HTTP requests directly to the application server, making client-side checks entirely ineffective for preventing server-side database injection attacks.

Wrap all user inputs inside custom string-escaping functions designed to neutralize single quotes and semicolons.

Why it fails: Manual escaping routines are notoriously fragile and frequently fail when facing complex character encodings, second-order injections, or database-specific nuances. Modern database drivers and frameworks provide robust built-in parameterization mechanisms that completely eliminate the human error inherent in custom escaping functions.

Deploy a traditional network firewall configured with signature rules to block incoming HTTP GET requests containing UNION.

Why it fails: Network firewalls struggle with web application attacks because traffic is often encrypted via HTTPS, hiding the payload from inspection. Attackers can also easily evade simple signature rules using URL encoding, case manipulation, or chunked transfer coding to bypass perimeter defenses entirely.

Require strict TLS 1.3 encryption for all incoming and outgoing web traffic sessions.

Why it fails: TLS encryption secures confidentiality and integrity while data traverses the network channel between client and server. However, it provides absolutely no defense against Cross-Site Scripting because the malicious script executes locally within the browser after decryption has already occurred.

Store user session tokens inside local storage rather than standard browser cookies.

Why it fails: Local storage is directly accessible to any JavaScript running on the page, making it significantly more vulnerable to theft via XSS than HttpOnly cookies. Moving tokens to local storage actually increases exposure because the browser offers no attribute equivalent to HttpOnly for web storage APIs.

Encode all dynamic output using generic HTML entity encoding routines on the server side.

Why it fails: While HTML body encoding helps prevent standard reflected XSS, it is insufficient on its own for complete mitigation across complex contexts like attributes or script blocks. Furthermore, it does not protect session tokens directly if scripts manage to execute via other bypass vectors or missing flags.

Apply strict input validation blacklists to filter out dangerous shell operators such as semicolons, pipes, and ampersands.

Why it fails: Blacklists of shell metacharacters are bypassable through encoding, alternate separators, and shell-specific syntax, so they cannot provide robust defence. It is tempting because blocking obvious operators appears to neutralise injection, but blacklisting suits low-risk legacy hardening only; the correct strategies avoid invoking a shell entirely and validate against a strict allowlist.

Configure the web server process to run with elevated root privileges to ensure access to system binaries.

Why it fails: Running web server processes with elevated privileges is an extreme security anti-pattern that magnifies the impact of any successful compromise. If command injection occurs under root privileges, attackers gain immediate administrative control over the entire underlying host operating system.

Encode all user inputs using URL encoding standards before passing parameters into system shell execution functions.

Why it fails: URL encoding is designed for safe transport across HTTP and is automatically decoded by receiving web frameworks before reaching execution functions. It provides zero protection against command injection because the shell interprets the decoded characters normally.

Implement client-side JavaScript validation checks to strip dangerous SQL characters before submission.

Why it fails: Client-side validation runs in the attacker's browser and is bypassed entirely by intercepting the request or disabling JavaScript, so the server still concatenates untrusted input into SQL. It is tempting because it improves user experience by catching malformed input early, but it is not a security boundary.

Configure the web application firewall to block requests containing common SQL keywords like UNION and SELECT.

Why it fails: Keyword blocklists are trivially bypassed via comment insertion, encoding, or case variation, and cannot stop injection through parameters that never contain those tokens. A WAF is a compensating control for legacy code that cannot be changed; parameterised queries fix the root cause by separating code from data.

Disable verbose database error messages globally to prevent attackers from viewing schema details.

Why it fails: Suppressing error output hides schema leakage but leaves the injection flaw exploitable for data extraction, authentication bypass, and blind inference. Error suppression is a hardening measure for production deployments, not a fix; parameterised queries eliminate the concatenation that lets input alter statement structure.

HTTP response splitting through CRLF injection in the Host header

Why it fails: HTTP response splitting requires injecting CRLF sequences to manipulate response headers or body. The logs show a modified Host header but no evidence of CRLF injection or response splitting. The attack leverages the Host header value directly in a generated URL, not through header injection into the response.

Cross-Site Request Forgery (CSRF) against the password reset endpoint

Why it fails: CSRF forces an authenticated user's browser to submit a state-changing request without their knowledge. Here, the attacker is not tricking a victim's browser into sending an authenticated request; instead, the attacker is directly manipulating the Host header to poison the reset link. CSRF does not explain the attacker-controlled Host header in the logs.

Server-Side Request Forgery (SSRF) via the password reset functionality

Why it fails: SSRF occurs when the server is tricked into making requests to internal or external resources. In this scenario, the server is not making outbound requests; it is generating a link based on the attacker-supplied Host header. The observed behavior is link poisoning, not server-side request forgery.

SQL injection using MongoDB's SQL compatibility layer

Why it fails: MongoDB is a NoSQL database and does not use SQL by default. While some tools provide SQL-like interfaces, the payload uses MongoDB-specific operators like $ne, which are not part of SQL syntax. This is a NoSQL injection, not SQL injection.

Cross-Site Scripting (XSS) through unsanitized input in the login form

Why it fails: XSS involves injecting client-side scripts that execute in a victim's browser. The observed attack manipulated database query operators to bypass authentication, which is a server-side injection flaw. XSS would not grant administrative access by itself, and the payload uses MongoDB operators, not JavaScript.

LDAP injection exploiting the authentication backend

Why it fails: LDAP injection targets directory services using LDAP filters. The payload here uses MongoDB operators ($ne) which are specific to NoSQL databases. There is no indication that LDAP is involved. The attack exploits the application's MongoDB query construction, not an LDAP directory.

XML External Entity (XXE) injection

Why it fails: XXE abuses XML parsers that resolve external entities, often using file:// or http:// URIs inside a DOCTYPE declaration. The log entries show query-string parameters with ../ sequences, not XML payloads. There is no evidence of XML parsing or entity expansion, so XXE is unrelated to this incident.

Local File Inclusion (LFI)

Why it fails: LFI typically abuses include/require constructs in scripting languages to execute or embed local files into a page. This Java servlet uses new File() and reads content directly; it is not including the file as code. While LFI and Path Traversal overlap conceptually, the mechanism here is direct file read via path manipulation, so Path Traversal is the more precise classification.

Server-Side Request Forgery (SSRF)

Why it fails: SSRF involves the server making an outbound network request to an attacker-chosen URL, such as http://169.254.169.254/latest/meta-data. Here the server is reading local files from disk via a File object, not fetching remote resources. No outbound HTTP request or URL manipulation is present in the log evidence, so SSRF does not fit the observed behavior.