Skip to content

Latest commit

 

History

History
68 lines (49 loc) · 5.02 KB

File metadata and controls

68 lines (49 loc) · 5.02 KB

Mitigation Strategies Analysis for square/picasso

  • Description:

    1. Determine Maximum Dimensions: Based on your UI and performance needs, determine the maximum width and height for images.
    2. Use resize(width, height): Always use Picasso's resize() method when loading images. Provide the maximum dimensions. This forces Picasso to scale down images.
    3. Use onlyScaleDown(): Use onlyScaleDown() with resize(). This prevents Picasso from upscaling smaller images, saving resources.
    4. Avoid Sole fit() Reliance: fit() is convenient but doesn't set hard limits. Use resize() for explicit control, then optionally fit() to fit the target view.
    5. Choose centerCrop() or centerInside(): Select the appropriate scaling option based on how you want the image displayed.
  • Threats Mitigated:

    • Denial of Service (DoS) (High): Prevents loading huge images that consume excessive memory (OutOfMemoryError crashes) or CPU time (slowing the app).
    • Performance Degradation (Medium): Improves responsiveness by preventing the loading and processing of unnecessarily large images.
  • Impact:

    • DoS: Significantly reduces memory-based DoS attack risk.
    • Performance Degradation: Improves performance and reduces resource use.
  • Currently Implemented: [Example: Partially - resize() is used in some places, but not consistently. onlyScaleDown() is not used.]

  • Missing Implementation: [Example: Apply resize() and onlyScaleDown() to all image loading calls. Review and adjust maximum dimensions based on testing.]

  • Description:

    1. Assess Caching Needs: Determine if caching is essential. For sensitive images, disable it.
    2. Disable Caching: Use noCache() and noStore(): Picasso.get().load(url).noCache().noStore().into(imageView);
      • noCache(): Bypasses the memory cache.
      • noStore(): Prevents storing the image in the disk cache.
  • Threats Mitigated:

    • Data Leakage (Medium to High): Prevents sensitive images from being stored in the cache, accessible to other apps or attackers with device access.
    • Data Tampering (Low): Reduces the risk of cached images being modified.
  • Impact:

    • Data Leakage: Significantly reduces risk if caching is disabled.
    • Data Tampering: Minor risk reduction.
  • Currently Implemented: [Example: Partially - Default caching is used. No explicit noCache() or noStore() calls.]

  • Missing Implementation: [Example: Evaluate caching needs for each image. Use noCache() and noStore() where appropriate.]

Mitigation Strategy: Use a Custom RequestHandler

  • Description:

    1. Create a RequestHandler: Extend com.squareup.picasso.RequestHandler.
    2. Override canHandleRequest(): Implement canHandleRequest(Request data). This is called before loading. Perform security checks here:
      • URL Validation (within Picasso's context): Although ideally done before calling Picasso, you can re-validate the URL here for defense-in-depth. Return true only if valid, false otherwise. This is crucial if you cannot fully control the inputs to Picasso.
      • Header Inspection (Optional): Inspect headers and reject based on values.
      • Other Checks (Optional): Implement any other custom security checks.
    3. Override load() (Optional): Override load(Request request, int networkPolicy) for actions before or after loading:
      • Modify Headers: Add custom headers.
      • Post-Processing: Security checks on loaded data (complex, e.g., format checks).
      • Custom Error Handling: Handle errors specifically.
    4. Register the RequestHandler: Use Picasso.Builder: .addRequestHandler(new YourCustomRequestHandler()).
  • Threats Mitigated:

    • Untrusted Image Sources (RCE, XSS, SSRF, Information Disclosure, Phishing) (Critical to Medium): Centralized, robust mechanism for enforcing security policies on all image requests handled by this Picasso instance. Crucially, this allows you to intercept requests even if the calling code doesn't perform proper validation.
    • Flexibility for Future Threats: Easily add new checks without modifying multiple code areas.
  • Impact:

    • Untrusted Source Threats: Significantly reduces risk; strong defense layer.
  • Currently Implemented: [Example: No - No custom RequestHandler is used.]

  • Missing Implementation: [Example: Create a RequestHandler implementing URL validation (as a fallback) and other needed checks.]