Skip to content

Latest commit

 

History

History
116 lines (91 loc) · 8.83 KB

File metadata and controls

116 lines (91 loc) · 8.83 KB

Mitigation Strategies Analysis for hakimel/reveal.js

  1. Disable Unnecessary Features: In your reveal.js initialization code (usually in your HTML or JavaScript), disable any features you don't need. This includes plugins, configuration options, and potentially even Markdown support if it's not essential. For example:

    Reveal.initialize({
      // ... other options ...
      markdown: false, // Disable Markdown if not needed
      plugins: [ /* Only include necessary plugins */ ],
      // Disable features you don't use:
      controls: false, // If you don't need navigation controls
      progress: false, // If you don't need the progress bar
      history: false,  // If you don't need browser history support
    });
  2. Configure Markdown (If Used): If you do use Markdown, configure reveal.js's Markdown plugin (RevealMarkdown) carefully. Specifically, consider:

    • smartypants: This option controls automatic conversion of quotes and dashes. While generally safe, disable it if you have concerns.
    • pedantic: This option enforces stricter Markdown parsing. Enable it for increased security.
    • breaks: This option controls how line breaks are handled. Consider disabling it if you don't need it.
  3. Server-Side Markdown Sanitization: Even with careful reveal.js configuration, always sanitize the Markdown output on the server-side using a dedicated HTML sanitization library (e.g., sanitize-html, bleach). This is crucial because vulnerabilities can exist in the Markdown parser itself, or in how reveal.js handles the parsed output. Do not rely solely on client-side sanitization.

  4. Disable allowHTML: If you are using the Markdown plugin, ensure that the allowHTML option is set to false (which is the default). This prevents raw HTML from being interpreted within your Markdown.

    • Threats Mitigated:

      • Cross-Site Scripting (XSS) via Markdown Injection: (Severity: High) - Prevents attackers from injecting malicious JavaScript through crafted Markdown.
      • HTML Injection (via Markdown): (Severity: High) - Prevents attackers from injecting arbitrary HTML through Markdown.
      • reveal.js-Specific Configuration Exploits: (Severity: Medium) - Reduces the attack surface by disabling unused features and configuring options securely.
    • Impact:

      • XSS: Significant risk reduction (especially when combined with server-side sanitization).
      • HTML Injection: Significant risk reduction.
      • reveal.js Exploits: Moderate risk reduction.
    • Currently Implemented:

      • Basic reveal.js configuration is in place.
    • Missing Implementation:

      • Markdown is enabled, but smartypants, pedantic, and breaks are not explicitly configured.
      • Server-side Markdown sanitization is not implemented. We rely solely on the reveal.js Markdown plugin's built-in (potentially insufficient) sanitization.
      • allowHTML is not explicitly set to false.

Mitigation Strategy: Lazy Loading of Media

  1. Enable Lazy Loading: In your reveal.js configuration, enable lazy loading for images and iframes. This is done using the data-src attribute instead of src for images and iframes. reveal.js will then only load these resources when they are about to become visible.

    <section>
      <img data-src="large-image.jpg">
      <iframe data-src="external-content.html"></iframe>
    </section>
  2. Configure Preload (Optional): You can optionally configure reveal.js to preload nearby slides using the preloadIframes and related options. This can improve performance, but be mindful of the potential for increased initial load if you have many media-heavy slides.

    • Threats Mitigated:

      • Denial of Service (DoS) via Resource Exhaustion: (Severity: Medium) - Reduces the initial load of the presentation, making it less susceptible to DoS attacks that attempt to overwhelm the server or client browser with large resource requests.
    • Impact:

      • DoS: Moderate risk reduction.
    • Currently Implemented:

      • Lazy loading for images is enabled using data-src.
    • Missing Implementation:

      • Lazy loading is not consistently used for all iframes.
  1. Inventory: Create and maintain a list of all reveal.js plugins used in your project. This list should include the plugin name, version, source, and a brief description of its purpose.

  2. Vetting: Before adding a new plugin, carefully vet it:

    • Source: Prefer plugins from reputable sources (e.g., the official reveal.js repository, well-known developers).
    • Code Review (If Possible): If the plugin's source code is available, review it for potential security issues (e.g., improper input handling, use of eval, DOM manipulation vulnerabilities).
    • Maintenance: Check if the plugin is actively maintained. Avoid plugins that haven't been updated in a long time.
    • Dependencies: Examine the plugin's dependencies. Avoid plugins with many dependencies or dependencies with known vulnerabilities.
  3. Updates: Regularly update all plugins to their latest versions. Use a dependency management tool (e.g., npm, yarn) to track and update plugins.

  4. Disable Unused Plugins: Remove or disable any plugins that are not actively being used. This reduces the attack surface. This can be done in the reveal.js initialization:

    Reveal.initialize({
      plugins: [ RevealMarkdown, /* ... other *needed* plugins ... */ ]
    });
  5. Vulnerability Scanning: Use tools to scan for known vulnerabilities in your dependencies, including reveal.js plugins.

    • Threats Mitigated:

      • Plugin-Specific Vulnerabilities: (Severity: Variable, depends on the plugin) - Reduces the risk of vulnerabilities in third-party reveal.js plugins being exploited.
    • Impact:

      • Plugin Vulnerabilities: Moderate to significant risk reduction, depending on the number and nature of plugins used.
    • Currently Implemented:

      • We use a small number of well-known reveal.js plugins.
    • Missing Implementation:

      • We do not have a formal inventory of plugins.
      • We do not have a regular process for updating plugins.
      • We have not reviewed the code of the plugins we are using.
      • Vulnerability scanning is not performed.
  1. Configuration: If your application does not require speaker notes or hidden slides, disable these features in the reveal.js configuration. This reduces the risk of accidental information disclosure. There isn't a direct configuration option to completely disable them, but you can effectively disable them by:

    • Not Using Them: Simply don't use the speaker notes feature (don't add <aside class="notes"> elements) and don't use the data-visibility="hidden" attribute on slides.
    • Removing the Speaker Plugin: If you're absolutely sure you don't need speaker notes, you can avoid including the RevealNotes plugin in your plugins array during initialization.
  2. Server-Side Prevention: Even if you don't use these features in your presentation authoring, ensure that your server-side code does not serve speaker notes or hidden slide content to unauthorized users. This is a crucial defense-in-depth measure.

    • Threats Mitigated:

      • Information Disclosure via Speaker Notes: (Severity: Medium) - Prevents accidental exposure of sensitive information in speaker notes.
      • Information Disclosure via Hidden Slides: (Severity: Medium) - Prevents accidental exposure of hidden slides.
    • Impact:

      • Information Disclosure: Risk eliminated if the features are not used and server-side controls are in place.
    • Currently Implemented:

      • We do not actively use hidden slides.
    • Missing Implementation:

      • We do use speaker notes, and they are served through the same endpoint as the main presentation content (which is a vulnerability). We need to address the server-side handling of speaker notes (separate endpoint, authentication). We should also consider whether we need speaker notes at all.