Skip to content

Latest commit

 

History

History
105 lines (78 loc) · 5.99 KB

File metadata and controls

105 lines (78 loc) · 5.99 KB

Mitigation Strategies Analysis for intervention/image

Description:

  1. Retrieve Uploaded File: Obtain the uploaded file object.
  2. Initial Checks (Optional but Recommended): Perform basic checks before creating an intervention/image instance: file upload success, preliminary MIME type check (from the browser, but don't trust it fully), and a preliminary file size check.
  3. Create Image Instance: Use Image::make($uploadedFile) to create an intervention/image instance. Wrap this in a try...catch block.
  4. Verify MIME Type: Use $img->mime() to get the actual MIME type detected by the library. Compare this against a whitelist of allowed types (e.g., ['image/jpeg', 'image/png', 'image/gif', 'image/webp']).
  5. Verify Dimensions: Use $img->width() and $img->height() to get the image dimensions. Compare these against maximum allowed width and height values.
  6. Handle Invalid Images: If invalid, throw an exception or return an error. Do not proceed. Log the error.
  7. Destroy Image Instance: Use $img->destroy() to free resources after validation.

List of Threats Mitigated:

  • Image Parsing Vulnerabilities: Severity: Critical. Reduces the chance of triggering vulnerabilities by rejecting malformed or unexpected image types.
  • Denial of Service (DoS) via Resource Exhaustion: Severity: High. Prevents processing of excessively large images.
  • File Inclusion Vulnerabilities (Indirectly): Severity: Medium. Helps prevent processing of non-image files.

Impact:

  • Image Parsing Vulnerabilities: Risk reduction: Medium. Important defense, but vulnerabilities can still exist in supported formats.
  • DoS via Resource Exhaustion: Risk reduction: High. Effectively prevents processing of overly large images.
  • File Inclusion Vulnerabilities: Risk reduction: Medium.

Currently Implemented:

  • MIME type and dimension validation is implemented in the ImageUploadController class, in the store method.

Missing Implementation:

  • Validation logic is not consistent across all image upload endpoints (e.g., "profile picture" upload lacks checks).
  • Error handling could be improved (more specific messages and logging).

Description:

  1. Intervention/Image Resize: Use $img->resize() or $img->fit() early in the processing pipeline to enforce maximum dimensions. Use the $constraint->upsize() callback to prevent upscaling beyond the original dimensions. This is the image-specific part of resource limiting, as it directly interacts with the image data.
    $img = Image::make($uploadedFile)->resize(1024, 1024, function ($constraint) {
        $constraint->aspectRatio();
        $constraint->upsize();
    });

List of Threats Mitigated:

  • Denial of Service (DoS) via Resource Exhaustion: Severity: High. Directly limits the resources an image processing operation can consume by modifying the image itself.

Impact:

  • DoS via Resource Exhaustion: Risk reduction: High. Very effective at preventing resource exhaustion by reducing image size.

Currently Implemented:

  • resize() is used in the main image processing function.

Missing Implementation:

  • The upsize() constraint is not consistently used in all resizing operations.

Mitigation Strategy: Strip Metadata

Description:

  1. After Image Creation: After creating the intervention/image instance and processing, call $img->strip() to remove all EXIF and other metadata.
  2. Alternative (Selective Metadata): If you need some metadata, use a separate library (e.g., exiftool or a PHP EXIF library) for fine-grained control, as intervention/image doesn't offer this.

List of Threats Mitigated:

  • Information Disclosure (EXIF Data): Severity: Medium. Prevents leakage of potentially sensitive information.

Impact:

  • Information Disclosure: Risk reduction: High. Effectively removes all metadata.

Currently Implemented:

  • $img->strip() is called in the main image processing function, after resizing.

Missing Implementation:

  • None. The current implementation is sufficient.

Description:

  1. Disable External Entities (libxml): Ensure external entity loading is disabled in libxml2 (used by Imagick). This is usually done via a configuration file or environment variable.
  2. Use a Sanitizer Library: Before passing an SVG to Image::make(), use a dedicated SVG sanitization library (e.g., enshrined/svg-sanitize in PHP) to clean and validate the input.
    use enshrined\svgSanitize\Sanitizer;
    
    $sanitizer = new Sanitizer();
    $cleanSvg = $sanitizer->sanitize($dirtySvgString);
    
    if ($cleanSvg !== false) {
        $img = Image::make($cleanSvg);
        // ...
    } else {
        // Handle invalid SVG
    }
  3. Configure Sanitizer: Configure the sanitizer to allow only necessary SVG elements and attributes. Be restrictive.

List of Threats Mitigated:

  • XXE (XML External Entity) Attacks: Severity: Critical. Can lead to information disclosure, SSRF, and potentially RCE.
  • Cross-Site Scripting (XSS) (via SVG): Severity: High. Malicious SVGs can contain JavaScript.

Impact:

  • XXE: Risk reduction: Very High. Disabling external entities and sanitizing are essential.
  • XSS: Risk reduction: High.

Currently Implemented:

  • Not applicable. The project does not support SVG uploads.

Missing Implementation:

  • If SVG support is added, this must be implemented.