Skip to content

Latest commit

 

History

History
85 lines (77 loc) · 9.43 KB

mitigations.md

File metadata and controls

85 lines (77 loc) · 9.43 KB

Mitigation Strategies Analysis for markedjs/marked

Mitigation Strategy: Strict Input Sanitization with marked

  • Mitigation Strategy: Strict Input Sanitization with marked
  • Description:
    1. Choose Sanitization Approach: Decide between using marked's built-in sanitizer option or integrating a dedicated HTML sanitization library to be used with marked. Dedicated libraries are generally recommended for more robust protection and are configured within marked's options.
    2. Implement Custom marked Sanitizer (if using marked's option): Define a JavaScript function and configure it as the sanitizer option within marked.use({}). This function will receive the raw HTML output from marked and must return sanitized HTML. The sanitizer should:
      • Remove or escape potentially harmful HTML tags such as <script>, <iframe>, <object>, <embed>, <style>, <link>, <meta>, etc.
      • Remove or escape dangerous HTML attributes like onload, onerror, onmouseover, href (for javascript: URLs), src (for potentially malicious URLs), etc.
      • Whitelist allowed tags and attributes only if absolutely necessary and with extreme caution.
    3. Integrate Sanitization Library with marked (if using a dedicated library):
      • Install the chosen library (e.g., npm install dompurify).
      • Import the library.
      • Configure marked to use the library's sanitization function as its sanitizer option within marked.use({}). For example, with DOMPurify: 
        const marked = require('marked');
const DOMPurify = require('dompurify');

marked.use({
    sanitizer: (html) => DOMPurify.sanitize(html)
});
      • Configure the sanitization library itself for stricter rules if needed, ensuring it's applied via marked's sanitizer option.
    4. Apply Sanitization via marked: Ensure the chosen sanitization method is correctly configured within marked so that it is applied to the HTML output after marked parses the markdown and before the output is used in the application.
    5. Regularly Review and Update Sanitizer: Keep your marked sanitizer function or integrated library configuration updated, especially as new XSS vectors are discovered. Test your sanitization regularly with known XSS payloads in the context of marked processing.
  • Threats Mitigated:
    • Cross-Site Scripting (XSS) - High Severity: Prevents injection of malicious JavaScript code into the application through markdown processed by marked, protecting users from account compromise, data theft, and website defacement.
  • Impact:
    • XSS - High: Significantly reduces the risk of XSS attacks originating from markdown input processed by marked by removing or neutralizing malicious HTML and JavaScript within the marked output.
  • Currently Implemented:
    • Basic marked sanitizer is implemented in the frontend comment section to remove <script> tags, configured directly within the marked processing for comments.
  • Missing Implementation:
    • More comprehensive sanitization using a dedicated library like DOMPurify integrated with marked is missing across the entire application, including:
      • Backend markdown processing for blog posts and articles using marked.
      • Admin panel markdown input for content management processed by marked.
      • User profile descriptions that allow markdown processed by marked.
      • Any other areas where markdown input from users or less trusted sources is processed by marked.

Mitigation Strategy: Regularly Update marked Library

  • Mitigation Strategy: Regularly Update marked Library
  • Description:
    1. Monitor marked Releases: Regularly check for new releases of markedjs/marked on GitHub or npm. Pay attention to security advisories and release notes specifically mentioning security fixes in marked.
    2. Review marked Release Notes for Security: When updates are available, carefully review the release notes to identify security patches, bug fixes, and especially any mentions of XSS or ReDoS vulnerabilities addressed in marked.
    3. Update marked Dependency: Use your package manager (e.g., npm, yarn) to update the marked dependency in your project to the latest version. This directly updates the marked library used in your application.
    4. Test Application with Updated marked: After updating marked, thoroughly test your application, focusing on areas that use marked to ensure the update hasn't introduced regressions or broken functionality related to markdown rendering.
    5. Automate marked Updates (Consider): Explore using dependency update tools (e.g., Dependabot, Renovate) to automate the process of checking for and proposing updates specifically for marked and other dependencies.
  • Threats Mitigated:
    • Cross-Site Scripting (XSS) - Variable Severity: Addresses potential XSS vulnerabilities that might be discovered and patched within the marked library itself. Severity depends on the specific vulnerability patched in marked.
    • Regular Expression Denial of Service (ReDoS) - Variable Severity: Addresses potential ReDoS vulnerabilities that might be fixed within marked's regular expressions. Severity depends on the specific ReDoS vulnerability in marked.
    • Other marked Parser Bugs - Variable Severity: Fixes general bugs and potential security issues within the marked parser.
  • Impact:
    • XSS - Variable: Can significantly reduce XSS risk if the update patches an XSS vulnerability in marked.
    • ReDoS - Variable: Can significantly reduce ReDoS risk if the update patches a ReDoS vulnerability in marked.
    • Other marked Parser Bugs - Variable: Improves overall security and stability of markdown processing by addressing bugs in marked.
  • Currently Implemented:
    • marked dependency is manually updated approximately every 6 months.
  • Missing Implementation:
    • Automated dependency update monitoring and alerts specifically for marked are not implemented.
    • Updates of marked are not performed frequently enough. Aim for more frequent checks and updates, ideally monthly or even more often for security-sensitive libraries like marked.

Mitigation Strategy: Principle of Least Privilege for marked Features

  • Mitigation Strategy: Principle of Least Privilege for marked Features
  • Description:
    1. Review marked Features and Extensions: Identify all marked features and extensions that are currently enabled or potentially enabled in your application's marked configuration. This includes core features and any extensions you might be using (e.g., GFM tables, task lists, breaks, etc.).
    2. Disable Unnecessary Features: For each feature and extension, evaluate if it is truly necessary for your application's functionality. If a feature or extension is not actively used or provides only marginal benefit, disable it in your marked configuration. This reduces the complexity of the marked parser.
    3. Configure marked.use({}) for Minimal Features: Explicitly configure marked.use({}) to only enable the features and extensions that are absolutely required. For example, if you don't need GFM tables, ensure they are not enabled.
    4. Regularly Re-evaluate Feature Usage: Periodically review your application's markdown processing requirements and re-evaluate if all enabled marked features are still necessary. Disable any features that are no longer needed to maintain a minimal configuration.
  • Threats Mitigated:
    • Cross-Site Scripting (XSS) - Low Severity (Indirect): Reducing parser complexity in marked can potentially reduce the attack surface and the likelihood of undiscovered XSS vulnerabilities within less commonly used features.
    • Regular Expression Denial of Service (ReDoS) - Low Severity (Indirect): Disabling complex features in marked might indirectly reduce the risk of ReDoS vulnerabilities associated with those specific features' regular expressions.
    • General Parser Bugs - Low Severity (Indirect): Simplifying the parser configuration of marked can potentially reduce the overall risk of encountering bugs in less used features.
  • Impact:
    • XSS - Low: Marginally reduces XSS risk by simplifying the marked parser.
    • ReDoS - Low: Marginally reduces ReDoS risk by simplifying the marked parser.
    • General Parser Bugs - Low: Marginally improves stability by using a less complex marked configuration.
  • Currently Implemented:
    • Default marked configuration is used, which enables a set of core features. No explicit disabling of features is currently done.
  • Missing Implementation:
    • A review of enabled marked features and extensions is needed to identify and disable any unnecessary ones.
    • Explicit configuration of marked.use({}) to enable only required features should be implemented.
    • This configuration should be applied consistently across all areas where marked is used.