Skip to content

Latest commit

 

History

History
231 lines (164 loc) · 14.6 KB

mitigations.md

File metadata and controls

231 lines (164 loc) · 14.6 KB

Mitigation Strategies Analysis for ampproject/amphtml

Mitigation Strategy: Subresource Integrity (SRI) for AMP Runtime and Components

  • Description:

    1. Identify AMP Runtime and Component URLs: Locate the <script> tags in your AMP HTML that load the AMP runtime (v0.js) and any AMP components (e.g., amp-carousel-0.1.js). These URLs are typically from CDN providers like cdn.ampproject.org.
    2. Generate SRI Hashes: For each of these JavaScript files, generate an SRI hash using tools like openssl or shasum after downloading the files locally from the CDN URLs.
    3. Add integrity and crossorigin Attributes: Modify the <script> tags in your AMP HTML to include the integrity attribute with the generated hash and crossorigin="anonymous" attribute.
    4. Update Hashes on AMP Runtime/Component Updates: When updating AMP versions, regenerate SRI hashes and update the integrity attributes in your HTML.

    • List of Threats Mitigated:

      • Compromised AMP Cache Serving Malicious Runtime/Components (High Severity): Prevents execution of tampered AMP runtime or component files served from a compromised AMP cache, mitigating potential XSS or other attacks.
      • Man-in-the-Middle (MITM) Attacks Modifying AMP Files (Medium Severity): Prevents execution of AMP files modified during transit by MITM attacks.

    • Impact:

      • Compromised AMP Cache: Significant risk reduction.
      • MITM Attacks: Moderate risk reduction.

    • Currently Implemented: Implemented for the core AMP runtime (v0.js) in the main website layout template (/templates/base.html).

    • Missing Implementation: SRI is not yet implemented for individual AMP components (e.g., amp-carousel, amp-analytics). Needs to be implemented for all used AMP components across all AMP pages.

Mitigation Strategy: Regularly Update AMP Runtime and Components

  • Description:

    1. Monitor AMP Project Releases: Subscribe to AMP project release notes and security channels.
    2. Establish Update Schedule: Create a schedule for regularly checking and applying AMP updates (quarterly or more frequently for security updates).
    3. Test Updates in Staging Environment: Test updates in a staging environment before production deployment.
    4. Update CDN URLs: Update CDN URLs in your AMP HTML to point to new versions of the runtime and components.

    • List of Threats Mitigated:

      • Exploitation of Known AMP Vulnerabilities (High Severity): Prevents exploitation of known security vulnerabilities in outdated AMP runtime and components.

    • Impact:

      • Known Vulnerabilities: Significant risk reduction.

    • Currently Implemented: Annual checks for major AMP runtime updates, but component updates are not regularly tracked.

    • Missing Implementation:

      • Implement more frequent checks for both runtime and component updates (quarterly or more).
      • Automated notifications for new AMP releases.
      • Documented procedure for testing and deploying AMP updates.

Mitigation Strategy: Monitor AMP Project Security Advisories

  • Description:

    1. Identify Official AMP Security Channels: Find official AMP project security advisory channels (GitHub, mailing lists, blog).
    2. Subscribe to Security Channels: Subscribe to receive notifications about new security advisories.
    3. Establish Review Process: Set up a process for regularly reviewing security advisories.
    4. Act on Advisories Promptly: Prioritize understanding and implementing mitigation steps for relevant advisories.

    • List of Threats Mitigated:

      • Zero-Day and Newly Discovered AMP Vulnerabilities (High Severity): Allows for rapid response to emerging AMP vulnerabilities.

    • Impact:

      • Zero-Day/New Vulnerabilities: Significant risk reduction.

    • Currently Implemented: Occasional checks of AMP project's GitHub, but not a formalized process.

    • Missing Implementation:

      • Formalize the process of monitoring AMP security advisories.
      • Subscribe to official AMP security channels.
      • Document a procedure for responding to security advisories.

Mitigation Strategy: Be Mindful of Data Cached in AMP Pages

  • Description:

    1. Data Sensitivity Audit: Review data in AMP pages and identify sensitive data.
    2. Minimize Sensitive Data in AMP: Reduce or eliminate sensitive data in cached AMP pages.
    3. Alternative Data Handling: Explore alternatives for handling sensitive data outside of cached AMP content (e.g., AJAX, server-side rendering).

    • List of Threats Mitigated:

      • Unintended Exposure of Sensitive Data via AMP Cache (Medium to High Severity): Prevents unintended exposure of sensitive data cached in AMP pages.

    • Impact:

      • Data Exposure: Moderate to Significant risk reduction.

    • Currently Implemented: General awareness, but no specific audit for AMP pages.

    • Missing Implementation:

      • Conduct a specific audit of AMP pages for sensitive data.
      • Develop guidelines for handling sensitive data in AMP contexts.

Mitigation Strategy: Strictly Adhere to AMP Validation

  • Description:

    1. Integrate AMP Validation in Development Workflow: Make AMP validation a mandatory step in development.
    2. Use AMP Validator Tools: Utilize AMP validator browser extension, CLI, or online validator.
    3. Treat Validation Errors as Critical: Resolve validation errors before deployment; fail builds on errors.
    4. Regular Validation: Run AMP validation regularly, especially after changes.

    • List of Threats Mitigated:

      • Cross-Site Scripting (XSS) due to Malformed AMP HTML (Medium to High Severity): Prevents XSS vulnerabilities by enforcing strict AMP HTML structure.
      • Unexpected Behavior and Security Issues from Non-Standard AMP (Medium Severity): Ensures AMP pages are processed correctly by caches and runtimes, reducing unexpected behavior and security issues.

    • Impact:

      • XSS and Non-Standard AMP Issues: Significant risk reduction.

    • Currently Implemented: Developers aware of validation and use browser extension ad-hoc.

    • Missing Implementation:

      • Integrate AMP validator CLI into CI/CD pipeline.
      • Formal policy for AMP validation before deployment.
      • Developer training on AMP validation errors.

Mitigation Strategy: Use Only Trusted and Necessary AMP Components

  • Description:

    1. Component Necessity Review: Evaluate the necessity of each AMP component before adding it.
    2. Prioritize Core and Well-Established Components: Favor core and widely used AMP components.
    3. Research Component Security History: Research security history of less common components.
    4. Minimize Component Count: Keep the number of AMP components to a minimum.

    • List of Threats Mitigated:

      • Vulnerabilities in Less Common or Newer AMP Components (Medium to High Severity): Reduces risk from potential vulnerabilities in less vetted components.

    • Impact:

      • Component Vulnerabilities: Moderate risk reduction.

    • Currently Implemented: Developers generally use common components, but no formal review process.

    • Missing Implementation:

      • Guideline for component selection emphasizing necessity and trust.
      • Review process for new component additions.
      • Periodic review of used components.

Mitigation Strategy: Regularly Review and Audit AMP Component Usage

  • Description:

    1. Component Inventory: Maintain an inventory of used AMP components.
    2. Regular Review Schedule: Schedule periodic reviews of the component inventory.
    3. Check for Updates and Advisories: Check for component updates and security advisories during reviews.
    4. Assess Component Necessity: Re-evaluate component necessity and remove unnecessary ones.
    5. Update Components as Needed: Update components based on reviews and advisories.

    • List of Threats Mitigated:

      • Accumulation of Outdated and Vulnerable AMP Components (Medium to High Severity): Prevents accumulation of outdated and potentially vulnerable components.

    • Impact:

      • Outdated Components: Moderate risk reduction.

    • Currently Implemented: No formal process for reviewing AMP component usage.

    • Missing Implementation:

      • Create a component inventory document.
      • Establish a schedule for regular component reviews.
      • Document the review process.

Mitigation Strategy: Utilize amp-iframe with sandbox Attribute and Restrictive allow Attributes

  • Description:

    1. Use amp-iframe for Third-Party Content: Embed third-party content using <amp-iframe>.
    2. Always Include sandbox Attribute: Always include the sandbox attribute in <amp-iframe> tags.
    3. Configure allow Attribute Restrictively: Configure the allow attribute to grant only minimum necessary permissions. Avoid allow-same-origin unless necessary.
    4. Regularly Review allow Attributes: Periodically review allow attributes for appropriate restrictions.

    • List of Threats Mitigated:

      • Compromised Third-Party Iframe Content Exploiting Browser Features (Medium to High Severity): Limits capabilities of compromised iframe content, preventing access to sensitive resources or malicious actions.

    • Impact:

      • Iframe Compromise: Significant risk reduction.

    • Currently Implemented: amp-iframe used with sandbox, but allow attributes not always restrictively configured or regularly reviewed.

    • Missing Implementation:

      • Policy that sandbox must always be used with amp-iframe.
      • Guidelines for restrictive allow attribute configuration.
      • Process for regular review of amp-iframe usage and allow attributes.

Mitigation Strategy: Be Cautious with amp-script (if used)

  • Description:

    1. Minimize amp-script Usage: Avoid <amp-script> unless absolutely necessary.
    2. Strict Code Review: Rigorous security code reviews for custom JavaScript in <amp-script>.
    3. Limit Script Capabilities: Be mindful of limited amp-script APIs and capabilities.
    4. Regular Security Audits: Regular security audits of custom JavaScript code in <amp-script>.

    • List of Threats Mitigated:

      • Cross-Site Scripting (XSS) through Custom JavaScript in amp-script (High Severity): Prevents XSS vulnerabilities from custom JavaScript in amp-script.
      • Security Issues from Unintended or Malicious Custom JavaScript Behavior (Medium Severity): Reduces security issues from poorly written custom JavaScript.

    • Impact:

      • XSS and Custom Script Issues: Moderate to Significant risk reduction.

    • Currently Implemented: <amp-script> is currently not used in the project.

    • Missing Implementation:

      • Policy to avoid <amp-script> unless necessary and with security review.
      • Detailed security review process for <amp-script> code if used in future.

Mitigation Strategy: Educate Users About AMP URLs and Cached Origins (Indirect Mitigation)

  • Description:

    1. Create User Education Content: Develop content explaining AMP URLs and cached origins (help articles, FAQs).
    2. Explain AMP Cache URLs: Explain that AMP pages are often served from caches for performance.
    3. Highlight Origin Verification: Emphasize content origin from the original publisher despite cache URLs.
    4. Address Phishing Concerns: Address user concerns about phishing related to AMP cache URLs.

    • List of Threats Mitigated:

      • User Confusion and Phishing Susceptibility due to Unfamiliar AMP Cache URLs (Low to Medium Severity): Reduces user confusion and potential phishing susceptibility related to AMP cache URLs.

    • Impact:

      • User Confusion/Phishing: Minor risk reduction.

    • Currently Implemented: No specific user education about AMP URLs.

    • Missing Implementation:

      • Create user-facing documentation explaining AMP URLs.
      • Consider visual cues or tooltips on AMP pages to reinforce origin.

Mitigation Strategy: Consider Signed Exchanges (SXG) for Origin Clarity (Advanced)

  • Description:

    1. Implement Signed Exchanges (SXG) Generation: Set up server infrastructure to generate SXG for AMP pages.
    2. Configure Web Server to Serve SXG: Configure the web server to serve SXG responses for AMP pages.
    3. Test SXG Implementation: Thoroughly test SXG implementation.
    4. Monitor SXG Adoption and Support: Monitor browser support for SXG.

    • List of Threats Mitigated:

      • User Confusion and Phishing Susceptibility due to Unclear Origin in AMP Cache URLs (Low to Medium Severity): Improves origin clarity and reduces user confusion/phishing risks related to AMP cache URLs.

    • Impact:

      • User Confusion/Phishing (Improved Origin Clarity): Minor risk reduction, but potentially more impactful than basic user education.

    • Currently Implemented: Signed Exchanges (SXG) are not currently implemented.

    • Missing Implementation:

      • Investigate feasibility and benefits of SXG for AMP pages.
      • Plan and implement SXG generation and serving infrastructure if beneficial.
      • Monitor browser support for SXG.