Cyber Security Quiz: Secure File Upload And Storage
10 questions · exam conditions
0:00
Secure File Upload And StorageQuestion 1 of 10

An image-sharing service verifies that an upload begins with a valid JPEG signature and then uses a native image library to create thumbnails. An attacker submits a structurally complex JPEG that exploits a memory-corruption defect during thumbnail generation.

Which additional design MOST effectively reduces the impact of this class of attack?

Require filenames to end in ".jpg", reject images whose client-supplied dimensions exceed a configured maximum, and log all oversized requests.
Verify the JPEG signature a second time immediately before thumbnail generation and abort processing if the re-check fails.
Run a patched decoder in a low-privilege sandbox with resource limits, then publish only newly re-encoded output rather than the original file.
Encrypt the original JPEG at rest and decrypt it only within an isolated thumbnail generation process to limit key exposure.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Secure File Upload And Storage

Practice Secure File Upload And Storage 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 Secure File Upload And Storage, 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

An image-sharing service verifies that an upload begins with a valid JPEG signature and then uses a native image library to create thumbnails. An attacker submits a structurally complex JPEG that exploits a memory-corruption defect during thumbnail generation.

Which additional design MOST effectively reduces the impact of this class of attack?

  1. Require filenames to end in ".jpg", reject images whose client-supplied dimensions exceed a configured maximum, and log all oversized requests.
  2. Verify the JPEG signature a second time immediately before thumbnail generation and abort processing if the re-check fails.
  3. Run a patched decoder in a low-privilege sandbox with resource limits, then publish only newly re-encoded output rather than the original file. (correct answer)
  4. Encrypt the original JPEG at rest and decrypt it only within an isolated thumbnail generation process to limit key exposure.
Explanation: When evaluating defenses against memory-corruption attacks in media processing, think in terms of blast radius: if the vulnerability will be exploited, what limits the damage? Signature checks and input validation help at the gate, but a sufficiently complex, valid-looking JPEG can still trigger a heap overflow inside a native library. The real question is what happens after that. Option C addresses this directly. Running a patched decoder inside a low-privilege sandbox with resource limits means that even a successful exploit is confined — the attacker can't pivot to the broader system because the process has no meaningful permissions or resources to abuse. Crucially, publishing only freshly re-encoded output (not the original file) eliminates polyglot or embedded-payload risks entirely, since the output is generated fresh from parsed image data. Option A focuses on filename extensions and dimension checks. These are trivially bypassed — a malicious JPEG can have a valid filename and legal dimensions while still containing a corrupt internal structure that triggers the library bug. Logging oversized requests catches nothing here. Option B re-verifying the JPEG signature before thumbnail generation is redundant. The attack isn't hiding from signature checks; it passes them. The exploit lives in the parsing complexity of a structurally valid but malicious file. Option D encrypts the file at rest, which protects stored data confidentiality — a separate concern entirely. Decryption inside an isolated process doesn't prevent the decoder from being exploited; it just moves where the vulnerability fires. Your study tip: when a question involves native code processing untrusted input, sandboxing + re-encoding is the gold-standard defense. Containment beats prevention when vulnerabilities are assumed inevitable.

Question 2

A support portal accepts compressed diagnostic bundles. It limits each uploaded archive's compressed size and scans extracted files for malware. During testing, a small archive expands until the extraction host exhausts its disk space, so the malware scan never completes.

Which control set BEST addresses this denial-of-service condition?

  1. Increase extraction disk capacity and reject archives whose compressed size exceeds the existing upload limit.
  2. Stream extraction while enforcing cumulative expanded-size, entry-count, nesting-depth, and resource limits in an isolated workspace. (correct answer)
  3. Require a recognized archive extension and compare the request Content-Type with the extension before extracting the bundle.
  4. Scan the compressed archive before extraction and delete its expanded files immediately after the later scan finishes.
Explanation: When you see a question about file upload vulnerabilities causing resource exhaustion, you're being tested on zip bomb (or archive bomb) defenses — attacks where a tiny compressed file expands into enormous data, overwhelming disk, memory, or CPU before any security scan can run. The scenario describes exactly this: a malicious archive defeats malware scanning by exhausting disk space during extraction. The fix must prevent runaway expansion during extraction, not after. Answer B addresses this directly by streaming extraction while simultaneously enforcing multiple resource limits — expanded size cap, entry count, nesting depth, and overall resource usage — inside an isolated workspace. This multi-layered approach stops the expansion mid-process before damage occurs, so the malware scan can actually complete. Answer A is tempting but fundamentally misses the threat. Adding disk capacity just raises the ceiling — a sophisticated zip bomb can still exhaust any fixed capacity. Rejecting archives by compressed size doesn't help because the attack's danger is in the expanded size, not the compressed size. Answer C addresses file-type validation (extension and Content-Type matching), which guards against disguised file types but does nothing to limit how much an archive expands. A valid .zip file can still be a zip bomb. Answer D scans before extraction, which sounds logical, but the attack already demonstrates that extraction itself causes the denial-of-service — scanning the compressed form doesn't detect the expansion risk, and deleting files afterward is too late. Study tip: When evaluating defenses against archive-based attacks, always ask whether the control acts during extraction with enforced limits, not merely before or after — attackers exploit the extraction process itself.

Question 3

A document repository encrypts all objects at rest and uses unpredictable object identifiers. Its download endpoint verifies that a requester is logged in, reads the identifier from the URL, and returns the corresponding object. It does not check which tenant owns that identifier.

Which correction is MOST important for preventing cross-tenant disclosure?

  1. Validate the downloaded object's extension and Content-Type before sending its encrypted bytes to the requesting user.
  2. Use longer unpredictable identifiers so authenticated users are less likely to discover another tenant's stored objects.
  3. Rotate the storage encryption key more frequently so objects from different tenants are protected under newer keys.
  4. Perform object-level authorization against the tenant and user on every retrieval before issuing or streaming the object. (correct answer)
Explanation: When you see a question about multi-tenant systems leaking data between customers, you're being tested on access control — specifically, whether authorization checks are scoped correctly. The key question to ask is: "Even if a user is authenticated, are they authorized to access this specific resource?" The flaw described is a classic Insecure Direct Object Reference (IDOR): the system confirms a user is logged in but never verifies that the requested object belongs to their tenant. Any authenticated user from Tenant A can simply request an identifier belonging to Tenant B and receive that object. The fix is D — enforcing object-level authorization on every retrieval, confirming the requesting user's tenant matches the object's owner before returning anything. This closes the logical gap directly. The distractors each address real security concerns, but none of them fix the core authorization flaw. A validates file type and Content-Type, which guards against malicious uploads or content-sniffing attacks — it does nothing to stop a legitimate user from reading another tenant's data. B suggests longer, harder-to-guess identifiers, which reduces discoverability but doesn't eliminate the risk — a determined attacker or even an accidental collision still results in unauthorized disclosure, and "hard to guess" is not the same as "access controlled." C rotates encryption keys more frequently, which is a good key-management practice but irrelevant here — the system already decrypts and returns the plaintext object on request, so key rotation protects nothing against this attack. For the exam, remember: obscurity and encryption are not substitutes for authorization. If a question describes missing ownership checks, the answer almost always involves enforcing them explicitly.

Question 4

A content-management system allows an editor to replace an existing downloadable file. The replacement is uploaded, scanned, and written over the same object-storage key. A content delivery network may continue serving an older cached version, while concurrent readers may observe different content under the same URL.

Which storage strategy BEST provides a clear security boundary for replacements?

  1. Write the replacement to the existing key first, then restore the prior version if the subsequent scan fails.
  2. Overwrite the existing key after scanning and rely on a cache purge request to make all readers observe the replacement.
  3. Preserve the existing key but append the upload timestamp to the filename returned in the download response.
  4. Store each approved replacement under a new immutable key and atomically update the authorized metadata pointer after validation. (correct answer)
Explanation: When evaluating file-replacement security in storage systems, you should focus on atomicity, immutability, and validation boundaries — the core properties that prevent readers from ever observing an unvalidated or partially-replaced file. The safest design, and the reasoning behind answer D, is to treat each approved file as immutable. By writing the replacement to a brand-new key and only updating the authoritative metadata pointer after validation succeeds, you create a hard security boundary: no reader can access the new content until it has been fully approved. The swap is atomic — either the pointer updates completely or it doesn't — eliminating race conditions and ensuring consistent, validated content under the canonical URL at all times. A is dangerous precisely because it inverts the validation order. Writing to the live key before the scan passes means real users could download malicious content during the window between upload and scan completion. A "restore if scan fails" approach is reactive, not preventive — and restores may themselves fail. B improves on A by scanning first, but overwriting a live key still creates a brief inconsistency window. Cache purge requests are not instantaneous or guaranteed; during propagation, different CDN edge nodes serve different file versions, breaking integrity guarantees. C is a cosmetic workaround, not a security control. Appending a timestamp to the filename changes what the user sees in the response but doesn't establish any validated state boundary or prevent access to unvalidated content on the server side. Study tip: Watch for questions that distinguish reactive security (fix problems after they occur) from preventive security (design systems so problems can't occur). Immutable keys with atomic pointer swaps are the classic preventive pattern for safe content replacement.

Question 5

A document service saves each upload using the path "/srv/files/" followed by the user-supplied filename. Developers propose removing occurrences of "../" and then using the cleaned value as the stored filename. The service runs on multiple operating systems and may normalize encoded or Unicode characters differently.

Which approach BEST prevents path traversal and filename-collision problems?

  1. Decode the filename once, remove parent-directory sequences, and reject it if the remaining name contains a slash character.
  2. Apply an allowlist of common filename characters and preserve the resulting name as the physical storage key.
  3. Generate an opaque server-side storage identifier and retain the submitted filename only as separately encoded display metadata. (correct answer)
  4. Canonicalize the destination path and accept it whenever the original filename does not begin with a directory separator.
Explanation: When a question asks about sanitizing user-supplied filenames, you should immediately think about two separate problems: input validation and storage architecture. The most robust defenses eliminate the attack surface entirely rather than trying to filter every possible malicious input. The core insight here is that any sanitization strategy applied to a user-controlled filename is playing catch-up against an attacker. Encoded slashes (%2F), Unicode normalization quirks, null bytes, and OS-specific path separators all create edge cases where "cleaned" filenames can still escape the intended directory. Option C sidesteps this entirely — by generating an opaque server-side identifier (like a UUID) as the actual storage key, the user's input never touches the filesystem path. The original filename is stored separately as metadata, safely encoded for display. This eliminates both path traversal and filename-collision risks in one architectural decision. Option A is a trap because it assumes one decode pass is sufficient. Attackers can double-encode sequences (e.g., %252F decodes first to %2F, then to /), and cross-OS normalization differences mean your strip-then-check logic may behave differently on Windows versus Linux. Option B sounds appealing — allowlists are generally better than denylists — but preserving a user-supplied name as the physical storage key still risks collisions (two users uploading report.pdf) and subtle bypass techniques if the allowlist misses an edge case. Option D is arguably the worst: canonicalizing the path after the fact is exactly what path traversal attacks exploit, and checking only the original filename's first character ignores everything that happens during normalization. Your study tip: when you see "sanitize user input before using it in a filesystem path," the gold-standard answer almost always involves not using that input as the path at all — generate your own identifier instead.

Question 6

A collaboration platform permits users to exchange HTML files. Uploaded objects are stored in cloud storage and displayed from "files.example.com". That host receives the parent domain's broadly scoped authentication cookies. The application sets the submitted Content-Type when returning each object.

Which change MOST effectively limits the consequences of a malicious uploaded HTML file while preserving downloads?

  1. Serve uploads from a dedicated cookieless origin, use attachment disposition, and send a no-sniff response header. (correct answer)
  2. Continue using the current origin, but replace each uploaded filename with a cryptographically random object identifier.
  3. Continue using the current origin, but require the uploader to declare the file's Content-Type before storage.
  4. Serve uploads over HTTPS from the parent domain and apply short cache lifetimes to every HTML response.
Explanation: When a platform serves user-uploaded files from the same origin as authenticated sessions, you're dealing with a stored Cross-Site Scripting (XSS) / content injection threat. The core question becomes: how do you neutralize a malicious HTML file without breaking legitimate downloads? Think in terms of three independent defenses — origin isolation, disposition control, and MIME enforcement — and recognize that the strongest answer layers all three. Option A does exactly that. Serving uploads from a dedicated cookieless origin (e.g., uploads.example-cdn.com) ensures that even if an attacker's HTML executes JavaScript, it has no access to authentication cookies scoped to the parent domain. The Content-Disposition: attachment header forces browsers to download rather than render files. And X-Content-Type-Options: nosniff prevents browsers from ignoring the declared MIME type and speculatively rendering HTML. Together, these three controls eliminate the attack at the cookie theft, execution, and rendering layers simultaneously. Option B is a trap — randomizing filenames obscures the URL but doesn't prevent rendering. An attacker who receives a share link still gets a browsable, cookie-accessible HTML page. Option C is equally flawed. Letting the uploader declare the Content-Type means the attacker simply declares text/html themselves. This adds zero protection. Option D actually worsens the situation. Serving from the parent domain over HTTPS still exposes authentication cookies to any executed script. Short cache lifetimes address availability, not security. The study tip here: when evaluating upload-handling scenarios, always check whether the file can execute (rendering vs. download), what credentials are exposed (same-origin cookies), and whether MIME sniffing is suppressed — layered controls beat any single fix.

Question 7

A benefits portal accepts PDF evidence documents. It requires a filename ending in ".pdf" and a client-supplied Content-Type of "application/pdf". Files are renamed and stored outside the web root, but employees later open them with a PDF viewer.

Which additional control would MOST directly address the remaining file-type validation risk?

  1. Verify the file signature and parse the document with a maintained PDF parser, rejecting malformed or prohibited PDF features. (correct answer)
  2. Scan the file with one antivirus engine and accept it whenever the engine reports that no known malware was found.
  3. Replace the original filename with a longer random value while retaining the submitted extension and Content-Type information.
  4. Reject files containing executable extensions in their names, including strings such as ".exe", ".js", and ".cmd".
Explanation: When a question asks about file upload validation, think in layers: client-supplied metadata (filename, Content-Type) is completely attacker-controlled and proves nothing about what's actually inside the file. The real risk here is that a malicious file disguised as a PDF could be stored and later opened by an employee — a classic polyglot or malicious document attack. The strongest control is A: verifying the file's magic bytes (its internal signature) and parsing it with a hardened PDF library. This confirms the file is actually a PDF at a structural level, not just labeled as one. Rejecting malformed content or dangerous embedded features (like JavaScript or embedded executables within the PDF) addresses the root threat — that an attacker uploads a crafted file that survives surface checks but executes malicious behavior when opened. B is dangerously weak because a single antivirus engine misses novel, zero-day, or cleverly obfuscated malware routinely. A clean scan is not a guarantee of safety, and this creates false confidence. C doesn't help at all with file-type validation. Randomizing the filename is a good practice to prevent path traversal and enumeration, but it does nothing to verify the file's actual content or structure — the internal threat remains unchanged. D is a blocklist approach targeting executable extensions within the filename, but a skilled attacker simply avoids those strings. Blocklists are inherently incomplete; they can't anticipate every evasion technique and don't examine file contents. Study tip: On security exams, always favor controls that validate content over controls that validate labels. Attackers control labels — only structural inspection reveals the truth.

Question 8

An application stores uploaded profile images under "/var/www/uploads" and serves them through Nginx. The intended uploads location is static-only, but a later configuration change applies the server's PHP handler to every file ending in ".php". The application already checks image extensions and generates random filenames.

Which design change would provide the STRONGEST protection against an uploaded file becoming server-side executable content after a configuration error?

  1. Store uploads outside the document root and return them through a download service that never invokes application-language handlers. (correct answer)
  2. Keep uploads under the document root but remove execute permission from files immediately after each successful upload.
  3. Continue using random filenames and append the validated image extension after any extension supplied by the user.
  4. Place a web-server configuration file in the uploads directory that disables PHP execution for that directory only.
Explanation: When evaluating file upload security, the key question isn't just "how do we block bad uploads?" but rather "what happens if every other control fails?" Defense-in-depth thinking means identifying which control eliminates the root cause of the threat rather than just mitigating symptoms. The real danger here is that uploaded files sit inside a directory where the web server can execute them. Option A eliminates this threat at its root: if uploads live outside the document root entirely and are returned through a controlled download service, the web server never has the opportunity to execute them — regardless of filename, extension, permissions, or future configuration mistakes. No configuration error can accidentally make those files executable because they're structurally unreachable by the web server's request handler. That's the strongest possible guarantee. Option B (removing execute permissions) sounds reasonable, but file execution on modern web servers is controlled by the server process owner, not filesystem execute bits. PHP files are typically executed by Nginx invoking PHP-FPM, which reads the file as data — execute permission bits don't stop this. Option C (appending a validated extension) only addresses naming, not location. A file named shell.php.jpg could still become dangerous if a misconfigured handler matches on any .php occurrence in the path, which is a real-world attack pattern. Option D (directory-level config disabling PHP) is a configuration-based control — exactly the kind of thing a later configuration change can override or undo, which is the very scenario the question describes. A useful rule of thumb: when a question asks for the strongest protection, look for the answer that removes the attacker's capability entirely rather than adding another rule layer that can be misconfigured away.

Question 9

A media site uploads files directly into its normal object-storage bucket and immediately returns a public URL. A background worker scans each object for malware several minutes later. If malware is found, the worker deletes the object.

Which redesign BEST closes the security gap in this workflow?

  1. Keep objects private in a quarantine state, scan them, and atomically publish only objects that pass all required checks. (correct answer)
  2. Return the public URL immediately but shorten its expiration so most users cannot retrieve the object after several minutes.
  3. Publish each object immediately after calculating its checksum, then compare that checksum again during the background scan.
  4. Store new objects in the public location but rely on clients to wait until the scanning worker reports completion.
Explanation: When you see a workflow where files are publicly accessible before a security check completes, you're looking at a race condition vulnerability — specifically, a Time-of-Check to Time-of-Use (TOCTOU) gap. The fix is always to restrict access until validation passes, not to patch around the exposure window. Option A is correct because it eliminates the gap entirely using a quarantine-then-publish pattern. Objects stay private and inaccessible until they pass all security checks, at which point they're atomically moved to public availability. No malicious file ever has a live public URL, so there's no window for a user to download malware — even briefly. Option B is a trap. Shortening the URL's expiration reduces the exposure window but doesn't eliminate it. A fast attacker (or an automated script) can still retrieve and spread the malware within those few minutes. Security gaps measured in seconds are still gaps. Option C confuses integrity with security. Checksums verify that a file hasn't been corrupted or altered, but a malware-laden file will pass a checksum comparison perfectly — because the checksum matches the original malicious content. This catches tampering, not malware. Option D is wishful thinking. Relying on clients to voluntarily wait is not a security control — it's an honor system. Any client ignoring that suggestion gets the unscanned file immediately. Study tip: On security exam questions, whenever you see a "scan after publish" workflow, your instinct should be "quarantine first." Legitimate content tolerates a short delay; malware exploits every second of public exposure. Default-deny is always stronger than default-allow-then-remediate.

Question 10

A multi-tenant application issues presigned object-storage URLs so browsers can upload large files without passing them through the application server. The application records the object as available as soon as it issues the URL. The client selects the object key and declares the file size and media type.

Which workflow provides the STRONGEST control over direct uploads?

  1. Allow the client to select any unused key, but restrict each presigned upload URL to a short validity window and log all upload attempts.
  2. Sign a server-generated, tenant-scoped key with upload constraints, then verify object attributes and security scan status before marking it available. (correct answer)
  3. Accept the client's declared media type and file size because the object-storage service cryptographically authenticates every request that carries a valid signature.
  4. Mark the object available immediately upon issuing the presigned URL, then remove its record and revoke access if object storage later reports an upload failure.
Explanation: When securing direct-upload workflows, think beyond the presigned URL itself. The real threat model includes malicious clients who control the key name, declare false metadata, and exploit the window between URL issuance and object availability. Strong control means the server owns every security-sensitive decision, not the client. Answer B is correct because it chains multiple enforcement layers together. The server generates a tenant-scoped key, eliminating path traversal or key-collision attacks a client could craft by choosing their own key. Upload constraints baked into the signature (size limits, allowed content types) are cryptographically enforced by the storage service. Critically, the object is only marked available after attribute verification and a security scan — meaning malware or policy-violating files never become accessible to other tenants, even briefly. Answer A sounds reasonable, but a short validity window and logging are detective controls at best. Logging tells you an attack happened; it doesn't prevent a valid-but-malicious payload from being uploaded and immediately accessed before anyone reviews the logs. Answer C is the most dangerous misconception. A valid signature proves the request was authenticated, not that the content is safe or accurately described. A client can carry a valid signature while uploading a 10 GB executable labeled as a 10 KB JPEG. Answer D is the scenario described as the problem in the passage — marking objects available immediately and cleaning up afterward creates a race-condition window where malicious content is briefly live and accessible. Your takeaway: whenever you see presigned URL questions, look for "server-generated keys + pre-availability verification." If the client controls metadata or the object is marked available before scanning, that's a red flag.