Systems and Application Security →mediumMultiple Select

SSCP Systems and Application Security Practice Question

A security analyst is hardening a web application that stores user-uploaded images. The application currently writes uploads to a directory served directly by the web server. Which TWO controls BEST reduce the risk of a malicious upload leading to remote code execution? (Choose two.)

⚠ Common exam trap

The trap here is treating operational hygiene such as filename randomization or logging as sufficient prevention, when the decisive controls are content validation and removing the file from any executable path.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Validate the file's magic bytes and extension against an allowlist of permitted image formats.

Preventing upload-based remote code execution requires both validating that the content is genuinely an allowed image type and ensuring stored files can never be interpreted as executable code. Content inspection and an extension allowlist establish the first barrier, while storing files outside the web root with safe response headers removes the execution path entirely.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Validate the file's magic bytes and extension against an allowlist of permitted image formats.
Why this is correct
Checking magic bytes and enforcing an extension allowlist ensures the file's actual content matches an expected image type, blocking polyglot files and scripts disguised with image extensions. This directly prevents a PHP or JSP payload from being accepted as a JPEG, which is a prerequisite for the upload-to-RCE chain described in the scenario.
✗
Log every upload event with the client IP address and user agent for later review.
Why it's wrong here
Logging provides detection and forensic value after an incident, but it is a detective control that does not stop a malicious upload from being written or executed. In this scenario the analyst needs preventive controls that break the execution path, so audit logging, while recommended, does not satisfy the requirement.
✓
Store uploaded files outside the web root and serve them through a handler that sets Content-Type and Content-Disposition.
Why this is correct
Placing uploads outside the document root means the web server will never interpret them as executable scripts, and forcing safe Content-Type and Content-Disposition headers prevents browsers from rendering or executing content inline. Together these break the path from a stored file to code execution, which is the core risk in this scenario.
✗
Increase the PHP upload_max_filesize directive to accommodate large images.
Why it's wrong here
The upload_max_filesize directive controls how large a request body PHP will accept. Raising it only permits larger files and does not inspect or constrain content, so a malicious script uploaded as an image would still be accepted and could still be executed if stored in a web-accessible path. This is a capacity tuning setting, not a security control.
✗
Rename each uploaded file to a random UUID while keeping the original extension.
Why it's wrong here
Randomizing filenames prevents predictable-path attacks and overwrites, which is useful hygiene, but retaining the original extension means a file named .php remains executable if the storage location is web-accessible. Because the scenario's primary risk is code execution from a stored script, name randomization alone does not close that gap.

Go deeper

SSCP Systems and Application Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question