Web Communication Security practice questions

Cross-Site Request Forgery; remediated by implementing unpredictable anti-CSRF tokens in all state-changing form submissions.

Why it fails: Cross-Site Request Forgery targets unauthorized state modifications executed on behalf of authenticated users. While critical, CSRF does not directly address the interception of cleartext session tokens transmitted over unencrypted HTTP channels during early redirection stages.

Sensitive Data Exposure; remediated by disabling cookies entirely and relying solely on URL parameter-based session management.

Why it fails: Relying on URL parameters for session management drastically increases vulnerability to session fixation and leakage through browser history logs. This approach exacerbates data exposure risks rather than resolving the fundamental transport layer security deficiency.

Insecure Deserialization; remediated by validating object types during the deserialization phase of incoming HTTP requests.

Why it fails: Insecure deserialization flaws occur when untrusted user data is parsed to instantiate objects without adequate type constraints. This vulnerability category is unrelated to session token transmission protocols and transport layer encryption mechanisms.

Deploy a restrictive Content Security Policy header that disables inline script execution and restricts trusted script sources.

Why it fails: While a restrictive Content Security Policy mitigates cross-site scripting risks effectively, it serves as a defense-in-depth mechanism rather than the primary fix. Context-aware output encoding remains the essential foundational control required to neutralize untrusted input directly at the sink.

Implement robust server-side input validation using regular expressions to strip out all angle brackets and quotation marks.

Why it fails: Relying strictly on input filtering to block specific characters is notoriously fragile and frequently bypassed using alternative encoding schemes. Context-aware output encoding is mathematically proven to be far more reliable for preventing injection vulnerabilities.

Store all user-supplied input inside encrypted database tables to ensure confidentiality before rendering it in the browser.

Why it fails: Database encryption protects data at rest against unauthorized physical or logical extraction but offers zero protection against injection attacks. When retrieved data is rendered unsanitized into a browser context, the application remains vulnerable to script execution.

Store the secret signing key directly within client-side local storage to simplify authentication retrieval logic.

Why it fails: Storing secret signing keys in client-side storage exposes them to immediate extraction via cross-site scripting vulnerabilities. Secret keys must remain securely on the server side to maintain cryptographic trust and token integrity.

Encode all user session payloads in plain Base64 format inside the token body for maximum read performance.

Why it fails: Base64 encoding provides zero confidentiality or encryption; anyone can decode token payloads instantly. Sensitive data should never be placed in JSON Web Tokens unless properly encrypted using JSON Web Encryption standards.

Strict-Transport-Security

Why it fails: Strict-Transport-Security (HSTS) informs the browser that the site must only be accessed using HTTPS. While this is critical for preventing protocol downgrade attacks and ensuring transport encryption, it does not directly prevent clickjacking or XSS, which are application-layer vulnerabilities executed within the browser's rendering engine.

X-Content-Type-Options

Why it fails: X-Content-Type-Options: nosniff prevents the browser from MIME-type sniffing a response away from the declared Content-Type. While this is an important security header to prevent drive-by downloads or style-sheet injection, it is not the primary defense mechanism against clickjacking or XSS execution vectors.

Access-Control-Allow-Origin

Why it fails: This header is part of Cross-Origin Resource Sharing (CORS). It determines which origins are permitted to access resources on the server. While it manages cross-origin data access permissions, it is not designed to mitigate XSS or clickjacking, which operate differently within the browser security model.

The server is misconfigured and is not enforcing HTTPS for the login page, but the Secure attribute will still protect the cookie after authentication.

Why it fails: While the server may not enforce HTTPS, the Secure attribute does protect the cookie after it is set, but the initial login credentials are still exposed. The question asks for the most likely explanation for the cookie being sent over HTTP during initial login. The cookie is not sent because it hasn't been set yet; the credentials are sent. This option misstates the cookie behavior.

The Secure attribute is not supported by the browser being used, so the cookie is sent over both HTTP and HTTPS.

Why it fails: Modern browsers widely support the Secure attribute. If it were unsupported, the cookie would be sent over both, but the scenario states the cookie is set with Secure, implying browser support. The issue is not lack of support but the initial HTTP request before the cookie is set. Therefore, this explanation is incorrect.

The Secure attribute only applies to cookies with the HttpOnly flag, so without HttpOnly, the cookie is sent over HTTP.

Why it fails: The Secure and HttpOnly flags are independent. Secure controls transmission over HTTPS, while HttpOnly prevents JavaScript access. The absence of HttpOnly does not cause the cookie to be sent over HTTP. This option incorrectly links the two attributes and misrepresents their functions, making it an invalid explanation for the observed behavior.

Require re-authentication for every state-changing request.

Why it fails: Requiring re-authentication for every state-changing action would indeed prevent CSRF, as the attacker cannot provide the user's credentials. However, this severely impacts usability, as users would need to constantly re-enter passwords, leading to poor user experience and potential workarounds. It is not a practical or standard solution for CSRF protection in most web applications.

Set the 'SameSite' attribute of session cookies to 'Strict'.

Why it fails: Setting SameSite to Strict prevents the cookie from being sent on cross-site requests, which blocks CSRF. However, it also prevents the cookie from being sent when a user follows a link from an external site, potentially breaking legitimate functionality. While it offers strong protection, it may not maintain usability for applications that rely on cross-site navigation, making it less ideal than a synchronized token approach in some contexts.

Validate the 'Origin' header on all incoming requests.

Why it fails: Validating the Origin header can help detect cross-site requests, but it is not a complete solution because the Origin header can be absent in some requests (e.g., from older browsers or certain privacy settings) and can be spoofed in non-browser contexts. Relying solely on it may leave gaps, especially if the application also accepts requests from non-browser clients. It is a useful additional layer but not the strongest standalone protection.

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Why it fails: This cipher suite uses Diffie-Hellman Ephemeral (DHE), which does provide forward secrecy. However, it is not the best choice here because it uses CBC mode, which has known vulnerabilities like padding oracle attacks, and it is less efficient than ECDHE. While it meets the forward secrecy requirement, the ECDHE option is more modern and secure.

TLS_RSA_WITH_AES_128_GCM_SHA256

Why it fails: This suite uses RSA key exchange, which lacks forward secrecy. Even though it uses GCM for authenticated encryption, the lack of ephemeral key exchange means that a compromised private key can decrypt all past sessions. It does not satisfy the forward secrecy requirement, so it should not be selected.

TLS_RSA_WITH_AES_256_CBC_SHA

Why it fails: This cipher suite uses RSA key exchange, which does not provide forward secrecy. If the server's private key is compromised, an attacker can decrypt all recorded sessions because the session key is encrypted with the server's long-term key. It fails the requirement for forward secrecy, making it unsuitable despite using strong symmetric encryption.

Set the cookie's Path attribute to / and the Domain attribute to the exact hostname.

Why it fails: Path and Domain scope where the cookie is sent, but they do not enforce transport security. Even with a narrow scope, the cookie is still sent over the unencrypted HTTP request in this scenario, allowing the attacker to capture it.

Enable HTTP Public Key Pinning (HPKP) on the web server.

Why it fails: HPKP pins a site's public key to detect certificate mis-issuance, but it does not upgrade HTTP requests to HTTPS. It also does not prevent the browser from making an initial cleartext request, so the session cookie would still be exposed on the network.

Add the SameSite=Strict attribute to the session cookie.

Why it fails: SameSite=Strict controls whether the cookie is sent on cross-site requests to mitigate CSRF; it does not force the browser to use HTTPS for the initial request. The cookie would still be transmitted over the plain HTTP URL in this scenario, so the attacker could capture it.

The server certificate has expired, triggering a validity date error in the browser.

Why it fails: Expiration errors specifically indicate that the current date is outside the Not Before and Not After range of the certificate. This is distinct from a chain of trust issue, which is caused by missing root certificates rather than the timing of the certificate lifecycle management process.

The web server failed to send the intermediate certificate in the handshake process.

Why it fails: While missing intermediates cause chain issues, the primary issue with internal CAs usually stems from the client not trusting the root itself. If the root CA is not in the local trust store, the chain cannot be completed, regardless of intermediate certificate inclusion in the handshake.

The web application is utilizing an outdated TLS version that browsers no longer support.

Why it fails: TLS version incompatibility results in a connection failure or a protocol error, not a certificate chain warning. Browser warnings specifically related to certificates denote an issue with the identity verification process, whereas protocol errors relate to the secure channel negotiation between the client and the server.

HttpOnly

Why it fails: The HttpOnly attribute prevents client-side scripts from accessing cookies via the Document.cookie API. While this is an essential defense against Cross-Site Scripting (XSS) attacks, it does not mandate encryption of the transport layer, which is the specific requirement for preventing cleartext interception over the network.

SameSite=Strict

Why it fails: The SameSite attribute is used to mitigate Cross-Site Request Forgery (CSRF) by controlling whether cookies are sent with cross-site requests. Setting it to Strict ensures the cookie is only sent in a first-party context, but this does not govern the encryption requirements of the underlying transport protocol.

Path=/secure

Why it fails: The Path attribute restricts the scope of the cookie to a specific URL directory on the server. While this limits where the cookie is sent within an application, it provides no protection regarding the transport protocol and does not force the use of encrypted connections for transmission.

Cross-Site Request Forgery (CSRF)

Why it fails: CSRF attacks rely on the browser automatically including cookies in cross-site requests. HttpOnly does not stop this behavior. To prevent CSRF, developers should use anti-CSRF tokens or the SameSite cookie attribute, as these mechanisms specifically target the request context rather than script-based access to stored cookies.

Man-in-the-Middle (MitM) interception

Why it fails: MitM interception is prevented by transport encryption, such as TLS/HTTPS. The Secure flag handles the requirement for encryption. The HttpOnly flag is strictly concerned with preventing client-side script access to cookie data and has no effect on network-level visibility or interception of data during transit.

SQL Injection (SQLi)

Why it fails: SQL injection occurs when untrusted user input is directly processed by a database query. This is a server-side vulnerability unrelated to how a browser stores or manages cookies. HttpOnly is a browser-side protection mechanism and provides no mitigation for database-level input validation or command execution vulnerabilities.

Complete server crash due to memory corruption

Why it fails: A server crash suggests an exploit targeting a buffer overflow or a critical software fault. Slowloris does not typically cause the process to crash; instead, it consumes server resources such as thread slots or connection pools, causing the server to stop responding to new legitimate requests.

Database downtime caused by excessive query volume

Why it fails: Database-centric attacks involve overwhelming the backend data store with complex or voluminous queries. Slowloris is strictly an HTTP-level attack that targets the web server's connection handling capabilities. It does not interact with the database tier, so it would not cause the database itself to go offline.

Unauthorized access to the application root directory

Why it fails: Unauthorized access, such as directory traversal or privilege escalation, involves gaining access to files or functions that should be restricted. A DoS attack like Slowloris focuses on service availability and does not provide the attacker with any ability to read files or execute unauthorized code.

It uses AES in CBC mode, which is vulnerable to padding oracle attacks such as POODLE.

Why it fails: While AES-CBC can be susceptible to padding oracle attacks like Lucky Thirteen, POODLE specifically targets SSLv3's CBC padding and is not applicable to TLS 1.0+ implementations that correctly handle padding. The cipher suite name indicates TLS, not SSLv3, and the primary weakness here is the key exchange, not the block cipher mode. CBC mode itself is not inherently broken when implemented properly.

It uses SHA-1 for integrity, which is considered cryptographically broken for MACs.

Why it fails: SHA-1 is used in the HMAC construction for message authentication, and while SHA-1 has known collision weaknesses, HMAC-SHA1 remains secure for integrity protection in TLS because collisions do not directly translate to MAC forgeries. The real issue with this cipher suite is the lack of forward secrecy due to RSA key exchange. SHA-1 in HMAC is not the primary concern for this configuration.

It allows downgrade to export-grade cryptography because of the RSA key exchange.

Why it fails: Export-grade cryptography (e.g., EXPORT ciphers) is a separate class of weak cipher suites that were historically used for export compliance. TLS_RSA_WITH_AES_128_CBC_SHA is not an export cipher; it uses 128-bit AES, which is strong. The RSA key exchange itself does not enable downgrade to export ciphers unless the server explicitly supports them. The main flaw is the lack of forward secrecy, not export-grade weakness.

Ensure the HSTS header is sent with a max-age of at least six months and includes the 'preload' directive, then submit the domain to the preload list.

Why it fails: The minimum max-age for preload eligibility is one year (31536000 seconds), not six months. While six months is a common starting point for HSTS, it does not meet the preload requirements. Additionally, the header must include 'includeSubDomains' to be eligible. Submitting with a shorter max-age or without 'includeSubDomains' will result in rejection. This option is a near-miss that highlights the specific thresholds required.

Configure the server to redirect all HTTP requests to HTTPS with a 301 status code and include the HSTS header in the redirect response.

Why it fails: Redirecting HTTP to HTTPS is a recommended practice, but HSTS headers are ignored by browsers when sent over HTTP; they are only processed over secure connections. Including the HSTS header in a redirect response over HTTP does not contribute to preload eligibility. The preload requirement focuses on the header sent over HTTPS and the submission process, not on redirect behavior. While redirects are good, they are not the specific additional measure needed for preloading.

Add the 'preload' directive to the HSTS header and wait for browsers to automatically discover and add the domain to their preload lists.

Why it fails: Browsers do not automatically discover and add domains to their preload lists; inclusion is a manual process that requires submission to a central list. The 'preload' directive alone does not trigger automatic inclusion. Without submission, the domain will never be preloaded, even if the header is correct. This option reflects a common misconception that the directive itself is sufficient, but it is only a declaration of intent.

Implement a strict Content Security Policy (CSP) that disallows inline scripts.

Why it fails: A Content Security Policy restricts which scripts can execute in the browser, but it does not prevent the server from executing an uploaded file. In this scenario, the attacker uploads a file that the server interprets as PHP, leading to server-side code execution. CSP operates on the client side and would not stop the server from processing the malicious file, so it fails to address the root cause.

Enforce HTTPS for all upload and download requests to prevent man-in-the-middle attacks.

Why it fails: HTTPS encrypts data in transit and protects against interception, but it does not affect how the server handles uploaded files. The attack described involves the server executing a malicious file after it has been uploaded, which can occur even over HTTPS. Therefore, enforcing HTTPS does not prevent this server-side code execution vulnerability.

Set the 'secure' attribute on session cookies to ensure they are only sent over encrypted connections.

Why it fails: The 'secure' attribute ensures cookies are transmitted only over HTTPS, protecting session tokens from interception. However, it has no bearing on file upload handling or server-side execution of uploaded files. This control addresses session security, not the vulnerability of executing user-supplied files, so it would not prevent the attack.

SameSite

Why it fails: The SameSite attribute controls when cookies are sent with cross-site requests, helping to prevent CSRF attacks. It does not restrict JavaScript access to the cookie. While important for security, it does not address the specific risk of XSS reading the cookie. Thus, it is not the correct choice for preventing JavaScript access.

Domain

Why it fails: The Domain attribute specifies which hosts can receive the cookie. It does not affect JavaScript accessibility. Setting the Domain attribute can broaden or narrow the scope of the cookie, but it does not prevent XSS from reading it. Therefore, it does not meet the requirement of blocking JavaScript access to the session cookie.

Secure

Why it fails: The Secure attribute ensures the cookie is only sent over HTTPS, protecting it from interception over unencrypted channels. However, it does not prevent JavaScript from accessing the cookie. An XSS attack could still read the cookie via document.cookie if the Secure attribute is the only protection. Therefore, Secure alone does not mitigate the risk described.

The policy is insecure because it lacks a report-uri directive, so violations cannot be monitored.

Why it fails: The absence of a report-uri directive means CSP violations are not reported, but this does not directly affect the policy's ability to mitigate XSS. The primary issue is the 'unsafe-inline' allowance. While reporting is useful for monitoring, it is not the main security flaw here. The policy's XSS protection is weakened by allowing inline scripts.

The policy is secure because default-src 'self' prevents loading scripts from external domains, mitigating XSS.

Why it fails: While default-src 'self' restricts scripts to the same origin, the script-src directive overrides default-src for scripts and includes 'unsafe-inline'. The ability to execute inline scripts is a major XSS vector. Even if external scripts are blocked, inline script injection can still occur. Therefore, the policy is not fully secure against XSS.

The policy is secure because it restricts scripts to the same origin and disallows inline scripts.

Why it fails: The policy includes 'unsafe-inline' in script-src, which permits inline scripts. This weakens the protection against XSS because inline scripts can be injected. The default-src 'self' restricts other resource types, but the script-src directive explicitly allows inline scripts. Therefore, the policy is not secure against XSS as described.

The HSTS header must include the includeSubDomains directive to protect all subdomains.

Why it fails: The includeSubDomains directive extends HSTS protection to subdomains, but it is optional. HSTS can be effective for the primary domain without it. The question asks for required conditions for HSTS to be effective, not for maximum coverage. Therefore, includeSubDomains is not a strict requirement for basic HSTS functionality.

The server must be configured to support TLS 1.2 or higher for HSTS to function.

Why it fails: HSTS does not mandate a specific TLS version. It works with any HTTPS connection that the browser trusts. While using strong TLS versions is good practice, it is not a prerequisite for HSTS. The browser will enforce HTTPS as long as the initial connection is secure. Thus, this is not a required condition for HSTS effectiveness.

The server must redirect all HTTP requests to HTTPS before the HSTS header is processed.

Why it fails: While redirecting HTTP to HTTPS is a common practice, it is not a requirement for HSTS to be effective. HSTS works by instructing the browser to automatically use HTTPS for future requests, bypassing HTTP. The initial redirect is not necessary once HSTS is established; in fact, HSTS prevents the browser from even attempting HTTP. Thus, this is not a required condition.

The token uses a weak signing algorithm that can be brute-forced to recover the secret key.

Why it fails: The "none" algorithm is not a weak signing algorithm; it is the absence of any signature. Brute-forcing is irrelevant because there is no signature to crack. The risk is not about recovering a key but about the lack of integrity protection. Therefore, this option incorrectly describes the nature of the vulnerability.

The token is vulnerable to replay attacks because it lacks an expiration claim.

Why it fails: The "alg": "none" header does not inherently relate to expiration claims. While JWTs should include an exp claim to mitigate replay attacks, the absence of a signature is a more severe and immediate risk. The token could have an expiration claim, but without a signature, an attacker could modify it to extend the expiration. Thus, this option does not address the primary risk.

The token is encrypted, so the contents cannot be read by an attacker.

Why it fails: The "alg": "none" algorithm indicates that the token is unsecured, not encrypted. In fact, JWTs with "none" have no signature, and their payload is base64url-encoded, which is easily decoded. Encryption would require a different algorithm like RSA or ECDSA for signing, or JWE for encryption. Thus, this option mischaracterizes the token's security properties.

Deploy a Web Application Firewall (WAF) with SQL injection signatures.

Why it fails: A WAF can block known SQL injection patterns, but it is a reactive measure that can be bypassed with obfuscation or new techniques. It does not fix the underlying vulnerability in the application code. While it adds a layer of defense, it should not be the primary mitigation. The most effective solution is to address the root cause by using parameterized queries.

Implement strict input validation to allow only alphanumeric characters.

Why it fails: Strict input validation can reduce the attack surface, but it is not foolproof and can break legitimate functionality if not carefully designed. Attackers can sometimes bypass validation using encoding or alternative characters. Moreover, it does not address the root cause if the application still concatenates input into SQL queries. Parameterized queries are a more robust solution.

Encode all user input using HTML entity encoding before storing in the database.

Why it fails: HTML entity encoding is used to prevent cross-site scripting (XSS) when outputting data to HTML contexts, not to prevent SQL injection. Applying it before database storage would not stop SQL injection because the database interprets encoded characters as part of the SQL syntax. It is the wrong layer of defense for this attack type.