Web Application Incidents practice questions

SecDataDir

Why it fails: This defines the path for persistent storage, not security constraints.

SecRuleEngine DetectionOnly

Why it fails: This puts the engine in logging mode, providing no active mitigation.

SecResponseBodyLimit

Why it fails: This restricts the size of the server's response, not the incoming request.

Enable full packet capture on the database server

Why it fails: While useful, it is overkill compared to specific query timing logs and creates massive storage overhead.

Enable verbose SQL query logging with execution timestamps

Why it fails: Recording query duration allows responders to identify the time-delays used in blind SQL injection exploits.

Increase the log rotation frequency

Why it fails: This manages storage but does not improve visibility into the attack.

Referer

Why it fails: The Referer header shows the previous page visited, not the attacker's network identity.

User-Agent

Why it fails: User-Agent can be easily spoofed and does not indicate origin IP.

Host

Why it fails: The Host header indicates the target domain, not the attacker's IP.

grep -r "SELECT" /var/log/apache2/access.log

Why it fails: This is used for SQL injection, not directory traversal.

grep -r "<script>" /var/log/apache2/access.log

Why it fails: This is used for XSS, not directory traversal.

tail -f /var/log/auth.log

Why it fails: This monitors authentication logs, which are not relevant to directory traversal.

Enable IP reputation blocking

Why it fails: IP reputation is broad and does not address the specific payload injection.

Enable URL encoding normalization

Why it fails: This helps prevent bypasses but does not block the payload itself.

Set the WAF to block all POST requests

Why it fails: This would break application functionality entirely.

Request timestamp

Why it fails: Timestamps confirm when the activity occurred, not who performed it.

Remote IP address

Why it fails: IP addresses can change due to mobile networks, so they are not definitive proof of hijacking.

HTTP Referer

Why it fails: The Referer header changes based on navigation and does not indicate identity.

Application server error logs

Why it fails: Application server error logs may contain stack traces if the deserialization attempt caused an exception, but successful exploits often do not generate errors. Even if errors occur, they may not include the full serialized payload. These logs are useful for debugging but not the primary source for reconstructing the attack payload.

Database query logs

Why it fails: Database query logs record SQL statements executed against the database. While a deserialization exploit might lead to database interactions, these logs do not capture the serialized payload itself. They are relevant for detecting data manipulation but not for analyzing the initial exploit vector or the code execution path.

Web server access logs

Why it fails: Web server access logs record the HTTP requests but typically do not capture the full request body, especially for POST requests containing serialized data. They may show the endpoint and response code but lack the payload details needed to understand the deserialization exploit. Therefore, they are insufficient for analyzing the exact payload and execution path.

GET

Why it fails: GET requests can be vulnerable to HPP, but they are not the most commonly associated method because parameters are typically visible in the URL and often less critical for state-changing operations. HPP is more often exploited in POST requests where parameters are in the body and may bypass validation more easily.

PUT

Why it fails: PUT is used to update resources and is less commonly involved in HPP because it typically does not rely on multiple parameters in the same way as POST. HPP requires the application to process duplicate parameters, which is more typical in form submissions using POST.

DELETE

Why it fails: DELETE is used to remove resources and is not typically associated with HPP. HPP exploits parameter parsing discrepancies, which are more prevalent in POST requests where multiple parameters are common. DELETE requests usually target a specific resource and do not involve parameter pollution.

Disable all Java serialization in the application

Why it fails: Disabling all Java serialization is not a practical immediate mitigation because many applications rely on it for functionality. It could cause widespread outages. Instead, a more targeted approach like patching the library or implementing a deserialization filter is preferable to maintain availability while mitigating the risk.

Implement a WAF rule to block all requests containing serialized Java objects

Why it fails: A WAF rule blocking all serialized Java objects may cause false positives and break legitimate functionality, as some applications legitimately use serialization. It is a blunt instrument and may not cover all attack vectors. Patching the vulnerability is more effective and less disruptive.

Block all incoming traffic to the application until further notice

Why it fails: Blocking all traffic is a denial-of-service measure that prevents legitimate users from accessing the application. While it stops the attack, it is not a targeted mitigation and can cause significant business impact. A more precise approach like patching or filtering is preferred to maintain service availability.

Requests are sent using the GET method to state-changing endpoints

Why it fails: While CSRF can use GET requests, many applications use GET for state-changing operations, and this is not inherently indicative of CSRF. Legitimate GET requests to state-changing endpoints are a poor practice but not necessarily an attack. CSRF is more reliably detected by missing tokens or unusual referrers.

Requests are made from the same IP address as the victim's previous requests

Why it fails: CSRF requests originate from the victim's browser, so they will have the same IP address as the victim's legitimate requests. This is not an indicator of CSRF; it is expected behavior. The attack is possible because the browser automatically includes credentials, making the request appear to come from the victim.

Requests originate from a different domain than the application's domain

Why it fails: Requests from a different domain can be legitimate, such as API calls or CDN requests. While CSRF attacks often involve a malicious site, the Referer header may be absent or spoofed, and many legitimate cross-origin requests exist. Thus, this alone is not a strong indicator of CSRF.

'%20', '+', and '='

Why it fails: Percent-encoding, plus signs and equals signs indicate URL-encoded parameters and form data, not shell metacharacters. Searching these surfaces ordinary query strings; command injection requires characters such as semicolons, pipes, ampersands or backticks that a shell would interpret as command separators.

'{', '}', and '$'

Why it fails: Braces and dollar signs relate to template or variable expansion syntax, not shell command chaining. Detecting OS command injection requires shell metacharacters like ';', '|', '&&' or backticks, which separate or substitute commands; braces and '$' alone rarely indicate executed commands in Apache logs.

'<', '>', and '/'

Why it fails: Angle brackets and slashes point to HTML tags or path traversal attempts, not shell command execution. OS command injection needs metacharacters the shell interprets, such as ';', '|', '&', '`' or '$()', so these searches miss the actual injection payloads in the access logs.

Disable the entire XSS protection rule set

Why it fails: Disabling the XSS rule set removes detection of actual cross-site scripting attacks, leaving the application exposed. It is tempting as a quick fix because it instantly halts the false positives disrupting user sessions, but it is appropriate only when the rule set is confirmed entirely redundant due to upstream input validation.

Implement a negative security model

Why it fails: A negative security model blocks known-bad signatures, so novel or obfuscated XSS payloads bypass it entirely. It is tempting because it produces fewer false positives and suits environments with stable, well-known traffic, but here it weakens XSS coverage rather than refining the existing rules.

Switch the WAF from Blocking mode to Transparent mode

Why it fails: Transparent mode only logs and alerts without blocking, so the XSS payloads still reach users — protection is lost, not tuned. It is tempting because it immediately stops false positives and is useful during initial rule baselining, but the scenario demands maintained protection.

Application Event logs

Why it fails: Application Event logs record ASP.NET runtime and application-level errors, not raw HTTP request lines, so URL-encoded payload strings never appear there. It tempts because application logs do surface unhandled exceptions from malformed queries, which would be the right source if the question asked about application error details rather than the submitted payload.

HTTPERR logs

Why it fails: HTTPERR logs capture only requests IIS rejected before processing — timeouts, 400-level parse failures, queue overflows — so a payload that reached the application is absent. It tempts because HTTPERR does log malformed request data, making it correct when diagnosing requests IIS itself refused rather than inspecting submitted query strings.

Security Event logs

Why it fails: Security Event logs record Windows authentication, logon and audit events, not HTTP request bodies, so URL-encoded payloads are never written there. It tempts because Security logs are the default forensic source for host-level compromise evidence, and would be correct if the question concerned failed logons or privilege use rather than the submitted SQL payload.

The user session has expired

Why it fails: An expired session produces 401 Unauthorised or a redirect to login, not 403, because the server has not authenticated the request at all. It is tempting since both errors concern access denial, and session expiry would be the answer if logs showed 401 responses after a token timeout.

The requested file does not exist

Why it fails: A missing file yields 404 Not Found, since the server cannot locate the resource; 403 means the resource exists but the server refuses to authorise access. It is tempting because both are client-visible errors, and 404 would be correct if logs showed requests for paths that were never published.

The server is offline

Why it fails: A server that is offline cannot return any HTTP status; clients would see connection timeouts or refused connections, not a 403 generated by the web server. It is tempting because outages cause access failures, and it would be correct if monitoring showed the host unreachable rather than serving responses.

High volume of requests to the login page without POST data

Why it fails: Requests to the login page without POST data are ordinary GET retrievals, which reveal nothing about session fixation. It is tempting because fixation begins with the attacker obtaining a session ID from the application, but that ID is then forced onto the victim, so the log signature is a reused ID across authentication.

The same session ID is associated with two different IP addresses within a short timeframe

Why it fails: Session fixation keeps one attacker-chosen session ID valid across the victim's authentication, so the ID stays constant rather than appearing from two IP addresses. It is tempting because IP changes suggest hijacking, but that pattern fits session theft after the fact, not the pre-set-ID mechanism.

A sudden spike in failed login attempts

Why it fails: Failed login spikes indicate brute-force or credential-stuffing attempts, not session fixation, which succeeds without guessing credentials. It is tempting because login anomalies often signal authentication attacks, but session fixation requires the victim to authenticate successfully while retaining an attacker-supplied session ID.

Content-Type header inspection

Why it fails: Inspecting the Content-Type header only confirms the declared media type so the parser applies the right decoding rules; it does not transform Unicode-encoded characters into canonical form for signature matching. Header inspection is correct when attackers disguise payloads as an unexpected MIME type to dodge parsing.

SSL/TLS offloading

Why it fails: SSL/TLS offloading merely terminates encryption at the WAF so plaintext is visible; the Unicode-encoded payload remains encoded and still evades signatures. Offloading is the right choice when the appliance must inspect HTTPS traffic that would otherwise pass through encrypted and unreadable.

Request body buffering

Why it fails: Buffering the request body only reassembles fragmented payloads before the engine inspects them; it does not decode Unicode escape sequences into their canonical characters, so signature matching still misses the obfuscated attack. Buffering is the right control when attackers split payloads across TCP segments to evade inspection.

Nmap

Why it fails: Nmap maps hosts, ports and services via crafted probes; it does not reassemble or inspect HTTP request bodies, so malicious payloads pass unseen. It is tempting because Nmap can fingerprint web servers and run http-* NSE scripts, which suits port and service discovery, not real-time content inspection.

Netstat

Why it fails: Netstat lists local socket connections and listening ports; it does not decode HTTP payloads or inspect request content. It tempts because it reveals active network connections, which is correct when the task is identifying open ports and established sessions rather than analysing traffic.

Syslog

Why it fails: Syslog transports and stores event messages; it neither captures HTTP sessions nor parses payloads, so live inspection is impossible. It is tempting because syslog feeds centralised monitoring and alerting, which suits aggregating device and application logs rather than examining HTTP traffic content in real time.

Multiple POST requests without a corresponding GET request

Why it fails: Normal applications routinely issue POST requests without a preceding GET, such as API calls and form resubmissions, so this pattern is not diagnostic. CSRF is confirmed by a state-changing request bearing the victim's authenticated session that the user never initiated. This pattern would be correct for detecting automated scripting or crawler activity.

High volume of 401 Unauthorized errors

Why it fails: CSRF typically bypasses authentication, so 401 errors are unlikely.

A sudden change in the session cookie value

Why it fails: Session cookie values legitimately change on re-authentication, timeout or rotation, so this pattern indicates session handling rather than forgery. CSRF is confirmed by a state-changing request carrying the victim's valid session without the user initiating it. Cookie change would be the right indicator for session hijacking or fixation.

Storing database backups

Why it fails: A WAF inspects HTTP traffic to detect and block application-layer attacks; backup storage is a data protection function provided by backup systems or database replication. It tempts because WAFs log requests for forensic review, and would be correct if the requirement were recovering data after destructive incidents.

Encrypting all web traffic

Why it fails: A WAF inspects and filters HTTP requests to block attacks like SQL injection and cross-site scripting; TLS termination or encryption is performed by load balancers or reverse proxies. It tempts because WAFs sit inline with HTTPS traffic, and would be correct if the requirement were confidentiality of data in transit.

Providing user authentication services

Why it fails: A WAF filters malicious HTTP payloads; authentication is handled by identity providers such as Microsoft Entra ID or application login modules. It tempts because WAFs process session cookies and login requests, and would be correct if the requirement were verifying user identity rather than blocking application-layer attacks.

Firewall logs

Why it fails: Firewall logs show permitted and denied connections at the network layer, not application-layer HTTP responses, so a 500 error never appears there. They are correct for investigating blocked ports, intrusion attempts or egress filtering, not for diagnosing server-side application faults.

DNS logs

Why it fails: DNS logs record name resolution queries, not HTTP response codes, so they cannot confirm whether the 500 error is isolated or systemic. They suit diagnosing resolution failures or suspected DNS tunnelling. Application and web server logs are where 500 status codes and stack traces appear.

Access logs

Why it fails: Access logs capture request metadata such as IP, URL and status code, confirming the 500 occurred but not why. Determining incident scope needs application error logs with stack traces. Access logs are the right source for traffic analysis, abuse detection or confirming request volume.