Cyber Security Quiz: Ssrf And Deserialization Risks
10 questions · exam conditions
0:00
Ssrf And Deserialization RisksQuestion 1 of 10

A service receives encrypted serialized session objects from clients. It decrypts each object and immediately passes the plaintext to a native deserializer. The encryption mode provides confidentiality but does not authenticate the ciphertext.

Which redesign best addresses the primary security concern?

Use authenticated encryption, verify authenticity before parsing, and replace native objects with a constrained schema where practical.
Retain the encryption mode, base64-encode the ciphertext, and reject plaintext containing known class names.
Decrypt and deserialize inside a separate thread, then verify a checksum after the resulting object is created.
Compress each serialized object before encryption and require a longer client-side session identifier.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Ssrf And Deserialization Risks

Practice Ssrf And Deserialization Risks in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Ssrf And Deserialization Risks, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A service receives encrypted serialized session objects from clients. It decrypts each object and immediately passes the plaintext to a native deserializer. The encryption mode provides confidentiality but does not authenticate the ciphertext.

Which redesign best addresses the primary security concern?

  1. Use authenticated encryption, verify authenticity before parsing, and replace native objects with a constrained schema where practical. (correct answer)
  2. Retain the encryption mode, base64-encode the ciphertext, and reject plaintext containing known class names.
  3. Decrypt and deserialize inside a separate thread, then verify a checksum after the resulting object is created.
  4. Compress each serialized object before encryption and require a longer client-side session identifier.
Explanation: When you see a question pairing unauthenticated encryption with deserialization, recognize that two distinct vulnerabilities are stacked: a malleable ciphertext an attacker can manipulate, and a dangerous parser that will blindly execute whatever data it receives. The fix must address both layers — not just one. Option A is correct because it closes both attack surfaces systematically. Authenticated encryption (e.g., AES-GCM) ensures the ciphertext cannot be tampered with undetected — if an attacker modifies the ciphertext, the authentication tag fails and you reject it before decryption even completes. Verifying authenticity before parsing means a malicious payload never reaches the deserializer. Replacing native deserialization with a constrained schema (like JSON with strict type validation) eliminates the arbitrary code execution risk that native deserializers carry. Option B is a cosmetic fix — base64 encoding provides zero security, and blocklisting known class names is a well-documented arms race that attackers consistently win with novel gadget chains. The fundamental ciphertext malleability remains untouched. Option C is dangerously backwards. Deserializing first and then verifying a checksum means malicious code can execute during deserialization before your check ever runs. Thread isolation adds no meaningful protection against in-process exploit payloads. Option D is entirely off-target. Compression and longer session identifiers address neither the unauthenticated ciphertext problem nor the unsafe deserialization — they're irrelevant performance and identity management concerns. Your study tip: whenever a question mentions unauthenticated encryption + deserialization, remember the mantra authenticate-then-parse, constrain the schema. Defense-in-depth means fixing every layer, not patching just one end.

Question 2

An internal administration service performs sensitive actions without authenticating callers because firewall rules permit connections only from the web-application subnet. The public web application contains a URL-fetch feature that can be induced to send requests to the administration service.

Which control most directly corrects the failed security assumption?

  1. Add a CAPTCHA to the URL-fetch form so automated clients cannot submit internal destinations repeatedly.
  2. Enable TLS on the public web application so external users cannot inspect URL-fetch requests in transit.
  3. Require strong authentication and authorization on the administration service instead of trusting network origin alone. (correct answer)
  4. Move administration service logs to a separate subnet so the web application cannot alter audit records.
Explanation: When you see a question describing a service that trusts network location instead of verifying who is asking, you're being tested on a foundational security principle: authentication must be enforced at the resource itself, not delegated entirely to perimeter controls. The scenario describes a classic Server-Side Request Forgery (SSRF) vulnerability. The administration service assumes that any request arriving from the web-application subnet is legitimate. But the web application's URL-fetch feature lets attackers weaponize the web server itself as a proxy — it is on the trusted subnet, so the firewall rule is satisfied. The root cause is that the administration service never verifies the identity or permissions of the caller. C directly fixes this: by requiring strong authentication and authorization at the service layer, it eliminates the bad assumption that network origin equals trustworthiness, regardless of how a request arrives. A is a surface-level distraction. A CAPTCHA slows automated abuse of the URL-fetch form but does nothing to secure the administration service — a determined attacker simply needs one successful request, manually submitted. B is irrelevant to this attack; TLS protects data in transit from external eavesdroppers, but the attacker isn't intercepting traffic — they're manipulating the server into making internal calls. D addresses log integrity, which is a secondary concern; protecting audit records doesn't prevent the administration service from being exploited in the first place. A useful pattern: when a question describes a control that assumes safety based on context (network, location, timing), the correct fix almost always moves authentication and authorization directly onto the sensitive resource. Perimeter trust is never a substitute for explicit access control.

Question 3

A server-side fetch feature permits a URL when its raw text contains partner.example. Security testing finds that differently formatted URLs can pass this test even though the HTTP client interprets their actual destination as another host.

Which validation strategy best addresses this parser-confusion weakness?

  1. Search the decoded URL for the approved name twice and reject any value containing a private-address string.
  2. Hash the submitted URL before logging it and compare the hash after the outbound request completes.
  3. Require the URL to end with the approved name and let the HTTP client normalize credentials and redirects.
  4. Parse and canonicalize once, require approved scheme, host, and port values, then validate the resolved destination. (correct answer)
Explanation: When a server accepts user-supplied URLs and fetches them on behalf of a user, you're in Server-Side Request Forgery (SSRF) territory. The core danger is parser confusion: an attacker submits a URL that passes a string-matching check but gets interpreted differently by the HTTP client — using tricks like embedded credentials (http://partner.example@evil.com), fragment abuse, or URL encoding. The fix must eliminate any gap between "what validation sees" and "what the HTTP client does." Option D is correct because it closes that gap systematically. By canonicalizing the URL first (normalizing encoding, stripping credentials, resolving redirects), you ensure validation and execution operate on the same representation. Then you enforce an allowlist of scheme, host, and port — and verify the resolved destination after DNS lookup, preventing DNS rebinding attacks as well. No raw string tricks survive canonicalization. Option A fails because searching raw text for an approved string is exactly the vulnerable pattern described. An attacker can still embed partner.example as a credential (http://partner.example@evil.com) or in a subdomain path (evil.com/partner.example) and bypass the check. Blocking private addresses via string matching is similarly bypassable. Option B is a red herring — hashing a URL before logging has no bearing on whether the destination is safe. It addresses log integrity, not request validation. Option C is close but dangerous: letting the HTTP client "normalize credentials and redirects" after validation means the client may follow a redirect to a disallowed host that the validator never saw. Study tip: On SSRF questions, always favor answers that canonicalize before validating and verify the final resolved destination — any answer that validates raw input or delegates normalization to the requester is a trap.

Question 4

A web application stores client state in a native object-serialization format. It appends an HMAC to each serialized value and verifies the HMAC before deserializing it. The HMAC key is well protected, but the application has a large dependency set containing classes with potentially dangerous deserialization behavior.

Which assessment and recommendation are most appropriate?

  1. The HMAC makes native deserialization safe, so only stronger encryption is needed to protect confidential state.
  2. The HMAC prevents object-graph complexity attacks, so the application should primarily add replay timestamps.
  3. The HMAC reduces tampering risk, but replacing native objects with schema-validated data further reduces attack surface. (correct answer)
  4. The HMAC should be checked after deserialization so malformed values can first be classified and logged.
Explanation: When evaluating security controls around deserialization, the key question isn't just "does this control prevent tampering?" but rather "does this control eliminate the attack surface entirely?" HMAC verification is a strong integrity check — it ensures an attacker can't modify a serialized payload. However, it does nothing to address what happens during the deserialization process itself. This is the critical insight that makes C correct. Native deserialization in languages like Java, Python, or PHP can trigger dangerous side effects — constructors, finalizers, and magic methods may execute simply by deserializing an object, even a legitimate, HMAC-verified one. If the classpath contains gadget classes (e.g., from libraries like Commons Collections), a valid-but-malicious payload could theoretically be constructed by someone who obtained the HMAC key, or the existing codebase may contain logic bugs triggered by edge-case objects. Replacing native serialization with schema-validated formats (JSON with strict validation, Protocol Buffers, etc.) fundamentally shrinks the attack surface by eliminating executable object graphs entirely. A is wrong because HMAC is not encryption and addresses authenticity, not confidentiality — and more importantly, it conflates "tamper-evident" with "safe to deserialize." B is wrong because HMAC does not prevent object-graph complexity attacks (e.g., billion-laughs-style deeply nested structures); replay timestamps are also an incomplete substitute for the real problem. D is dangerously wrong — verifying HMAC after deserialization means the dangerous code execution has already occurred, defeating the entire purpose. Remember this pattern: integrity controls reduce one risk but don't sanitize processing. On security exams, always ask whether a control prevents the vulnerability or just guards around it.

Question 5

A development team replaces a native binary serialization format with JSON. The new JSON library is configured to honor a client-provided type discriminator and automatically instantiate any application class matching that value.

Which statement best evaluates the change?

  1. The risk is eliminated because text formats cannot invoke constructors or type-specific behavior during parsing.
  2. The risk is limited to disclosure because readable JSON exposes field names but cannot affect application control flow.
  3. The risk changes entirely to SSRF because JSON type names are interpreted as remote network locations.
  4. The risk remains because unrestricted polymorphic binding can recreate dangerous object-instantiation behavior in JSON. (correct answer)
Explanation: When evaluating serialization security, the critical question isn't what format is used — it's what the parser does with untrusted input. The danger in binary serialization (like Java's native serializer or pickle) has never been the binary encoding itself; it's the automatic object instantiation that happens during deserialization. Keep that distinction sharp as you read this question. The passage tells you the JSON library honors a client-provided type discriminator and automatically instantiates any matching class. That's the smoking gun. An attacker can supply a type name like com.example.ProcessBuilder or any gadget class, and the library will call its constructor with attacker-controlled data — recreating exactly the same dangerous behavior as unsafe binary deserialization. The format changed; the vulnerability didn't. D is correct. A is wrong because it assumes text formats are inherently safe. The format is irrelevant; what matters is whether the parser invokes constructors or executes type-specific logic. JSON absolutely can trigger object instantiation if the library is configured to do so. B is wrong because it conflates readability with safety. Yes, JSON field names are visible, but that's a disclosure concern at most. The real risk here isn't confidentiality — it's arbitrary code execution through polymorphic binding, which is a control-flow issue, not just a disclosure issue. C is wrong because it confuses type discriminators (class names resolved within the application's JVM or runtime) with URL-based SSRF vectors. These are distinct mechanisms; type names aren't network locations. The study tip: whenever a question mentions "automatic instantiation," "polymorphic deserialization," or "type discriminators," think deserialization gadget chains — the format is irrelevant if the behavior is the same.

Question 6

An API accepts a webhook URL and immediately returns a generic success response. During testing, a unique hostname supplied as the webhook destination later receives a DNS lookup from the API's network, but the tester receives no fetched content or status details.

What is the most accurate interpretation of this observation?

  1. It proves exploitable reflected SSRF because the remote response must have been returned through the API.
  2. It indicates possible blind SSRF, but additional evidence is needed to determine what protocols or destinations are reachable. (correct answer)
  3. It demonstrates unsafe deserialization because the API interpreted the hostname as a runtime object reference.
  4. It confirms DNS cache poisoning because the API resolved a hostname controlled by an external tester.
Explanation: When evaluating API behavior during security testing, pay close attention to what evidence you actually have versus what you're inferring. A DNS lookup appearing at your controlled server is meaningful, but it's a narrow data point — not a complete picture of exploitability. In this scenario, the API resolves a hostname you supplied, which tells you the server made an outbound network request to an external destination you controlled. That's the hallmark signal of blind SSRF — the server-side request happens, but the response isn't reflected back to you. However, you only know DNS resolution occurred; you don't yet know whether the API can reach internal services, which protocols it supports (HTTP, FTP, file://, etc.), or whether you can extract meaningful data. More testing is required, which makes B the most accurate interpretation: possible blind SSRF with insufficient evidence to draw stronger conclusions. A is wrong because reflected SSRF requires the server's response to be returned to you — no content was returned here, so calling it "exploitable reflected SSRF" overstates the evidence entirely. C is wrong because unsafe deserialization involves parsing serialized object data and reconstructing runtime objects from it — a DNS lookup to a webhook URL has nothing to do with that attack class. D is wrong because DNS cache poisoning is an attack you perform against a resolver to corrupt its cache; the API resolving your hostname is normal DNS behavior, not evidence of poisoning. A useful exam strategy: watch for answer choices that use confident language ("proves," "confirms") when the evidence is indirect. In security testing, partial signals like DNS callbacks require follow-up — never assume maximum impact from minimal evidence.

Question 7

A deserialization endpoint checks that the top-level object is an allowed PurchaseOrder class. The class contains several generic collection and interface-typed fields. The deserializer may instantiate concrete nested types based on metadata in the incoming payload.

Why is the top-level class check insufficient?

  1. A permitted root object can contain attacker-selected nested types, so constraints must cover the complete object graph. (correct answer)
  2. A permitted root object is safe only when its serialized bytes are also hidden with transport-layer encryption.
  3. A permitted root object prevents code execution but cannot prevent SSRF through an external reverse proxy.
  4. A permitted root object becomes unsafe only if the endpoint accepts more than one serialization format.
Explanation: When you see a question about deserialization vulnerabilities, think about the object graph — the full tree of objects that gets instantiated when a payload is processed, not just the root. Deserializers that support polymorphism or interface types will eagerly instantiate nested concrete classes based on metadata embedded in the payload itself. This means an attacker doesn't need to replace your PurchaseOrder root; they just need to smuggle a dangerous class inside it. This is exactly why A is correct. Even though the endpoint validates that the top-level type is PurchaseOrder, the fields inside that class are typed as generic collections or interfaces. The deserializer resolves those to concrete implementations at runtime using attacker-supplied type hints in the payload. A single gadget class buried three levels deep in the object tree can trigger arbitrary code execution — the root-level check never even saw it. B is a red herring. Transport-layer encryption (TLS) protects data in transit from eavesdropping, but it does nothing to constrain which types a deserializer will instantiate. The server decrypts before deserializing, so the attacker-controlled payload arrives intact. C confuses the threat model. SSRF is a distinct vulnerability class, and the concern here is code execution via gadget chains, not server-side request forgery through a proxy. Don't conflate unrelated attack categories. D is false because the multi-format condition is irrelevant. A single-format endpoint is equally exploitable if nested types are unrestricted. As a study tip: whenever deserialization is mentioned with interfaces or generics, immediately think "full object graph whitelisting" — validating only the root type is a well-known, exploitable gap.

Question 8

A document-processing service accepts an HTTPS URL, resolves the hostname, rejects the request if the resulting address is private or loopback, and then downloads the document. The HTTP client automatically follows redirects. Security testing shows that an approved public URL can redirect the service to an internal management endpoint.

Which change most directly addresses the weakness while preserving the URL-download feature?

  1. Validate the original hostname against an allowlist and permit all redirects from an approved starting URL.
  2. Revalidate every redirect destination, control DNS resolution, and enforce outbound network restrictions on the downloader. (correct answer)
  3. Require HTTPS for the initial request and reject responses whose certificates use an untrusted issuer.
  4. Encode user-supplied URLs before passing them to the HTTP client and increase redirect logging.
Explanation: When you see a question about Server-Side Request Forgery (SSRF), focus on where validation happens and how many times it runs. A classic SSRF bypass exploits the gap between when a URL is checked and when it's actually used — and redirect-following widens that gap significantly. The weakness here is a time-of-check to time-of-use (TOCTOU) flaw: the service validates the initial hostname but never re-checks where redirects lead. An attacker registers a public domain, passes the initial validation, then redirects the downloader to an internal endpoint like http://169.254.169.254/ (a common cloud metadata service). Option B closes this loop by revalidating every redirect destination — not just the first URL — ensuring no hop in the chain can land on a private address. Controlling DNS resolution prevents DNS rebinding attacks (where a domain resolves differently on the second lookup), and outbound network restrictions add a defense-in-depth layer at the infrastructure level. Together, these address the root cause without removing the download feature. Option A is the trap most students fall for — allowlisting the original URL explicitly ignores where redirects go, which is exactly the attack path being exploited. Option C focuses on TLS certificate trust, which is a transport-layer concern entirely unrelated to SSRF; a valid HTTPS cert doesn't prevent a redirect to an internal address. Option D encodes URLs and adds logging — encoding doesn't affect how an HTTP client follows redirects, and logging detects attacks after the fact rather than preventing them. The study tip: whenever SSRF appears, ask yourself "is validation applied at every step of the request lifecycle, or only at entry?" If it's only at entry, the control is bypassable.

Question 9

A security review finds no known code-execution gadget chain in a service's deserialization libraries. However, the service accepts unauthenticated serialized messages and reconstructs arbitrarily deep object graphs with large collections before applying business validation.

Which risk and mitigation should receive the highest priority despite the absence of a known gadget chain?

  1. Cross-site scripting; HTML-encode every collection element after the complete graph has been reconstructed.
  2. Resource-exhaustion denial of service; limit input size, nesting depth, collection counts, and processing resources. (correct answer)
  3. Credential replay; encrypt the serialized message so intermediaries cannot observe repeated object graphs.
  4. DNS rebinding; pin the service's public hostname to one address before accepting serialized messages.
Explanation: When you see deserialization questions on a security exam, train yourself to think beyond code execution. The classic deserialization threat is a gadget chain — a sequence of existing classes that, when deserialized, triggers arbitrary code execution. But the passage explicitly tells you no known gadget chain exists, which is a deliberate misdirection. The real question becomes: what else can go wrong? The answer is resource exhaustion. Even without a gadget chain, a service that reconstructs arbitrarily deep object graphs with large, nested collections is wide open to a Billion Laughs-style or deeply recursive attack. An attacker sends a carefully crafted payload that forces the server to allocate gigabytes of memory or spin the CPU for minutes before any business logic even runs. This is a denial-of-service condition that requires zero exploit sophistication. Option B correctly identifies this risk and prescribes the right controls: cap input size, enforce maximum nesting depth and collection counts, and throttle processing resources like CPU time and heap allocation. Option A describes XSS, which is a client-side rendering vulnerability — it has nothing to do with server-side deserialization of object graphs. Option C addresses credential replay and proposes encryption, but encryption protects confidentiality, not availability, and doesn't prevent a valid (or forged) oversized message from exhausting resources. Option D introduces DNS rebinding, which is an origin-boundary attack completely unrelated to the scenario's threat model. The study tip here: when a question removes the "obvious" vulnerability (gadget chains), look for the structural risk the service still exposes. Deserialization without depth/size limits is always a DoS candidate, gadget chain or not.

Question 10

A cloud-hosted application retrieves previews for user-supplied links. A vulnerability allows the application to send requests to arbitrary destinations, including services reachable only from its workload network. The application currently runs with a broadly privileged cloud identity.

Which defense-in-depth plan best limits both SSRF reachability and the impact of a successful request?

  1. Place outbound requests behind a destination-restricted proxy and reduce the workload identity to its minimum permissions. (correct answer)
  2. Require all submitted links to use TLS and rotate the workload's broadly privileged credentials more frequently.
  3. Hide internal service names from public DNS and require users to submit URLs in an encoded form.
  4. Deploy a web application firewall for inbound traffic and increase audit retention for cloud API calls.
Explanation: When a question describes both an SSRF vulnerability and an overprivileged identity, it's signaling a defense-in-depth scenario — meaning you need controls that address multiple attack layers simultaneously. Ask yourself: what limits where malicious requests can reach, and what limits the damage if one gets through? Answer A does exactly this two-layer job. A destination-restricted egress proxy acts as a network-level control, allowing the application to fetch only whitelisted external URLs and blocking requests to internal services — directly curtailing SSRF reachability. Reducing the workload identity to least privilege is the blast-radius control: even if an attacker successfully reaches the cloud metadata service or an internal API, the stolen credentials authorize almost nothing. Together, these address the root vulnerability and its consequence. Answer B fails on both fronts. TLS requirements only enforce encryption in transit — they say nothing about where requests are sent. Rotating broadly privileged credentials more frequently still leaves a dangerous window of exposure and doesn't reduce the scope of those credentials at all. Answer C relies on security through obscurity. Hiding internal DNS names won't stop an attacker who can enumerate services by IP range, and encoding URLs client-side provides zero server-side validation — the server still ultimately resolves the destination. Answer D addresses inbound traffic with a WAF, but SSRF is an outbound threat originating from the server itself. Increased audit retention helps with forensics after an incident but prevents nothing. The study tip here: defense-in-depth questions reward pairing a preventive control (restrict the attack surface) with a limiting control (minimize impact if prevention fails). Watch for answer choices that address only one dimension.