Uploaded image for project: 'Rules Repository'
  1. Rules Repository
  2. RSPEC-5247

Disabling or bypassing HTML output escaping is security-sensitive

    Details

    • Default Severity:
      Blocker
    • Impact:
      High
    • Likelihood:
      High
    • Default Quality Profiles:
      Sonar way
    • Targeted languages:
      HTML, Java, JavaScript, PHP, Python, XML
    • Analysis Level:
      Syntactic Analysis
    • Analysis Scope:
      Main Sources
    • Common Rule:
      Yes
    • CWE:
      CWE-79, CWE-80, CWE-81, CWE-82, CWE-83, CWE-84, CWE-85, CWE-86, CWE-87
    • OWASP:
      A7
    • SANS Top 25:
      Insecure Interaction Between Components

      Description

      Disabling or bypassing HTML output escaping is security-sensitive. It has led in the past to the following vulnerabilities:

      To mitigate the risk of exposing users to cross-site scripting attacks, user data provided to web applications should always be sanitized, validated or escaped before rendered in a web browser.

      Here are some examples of what HTML escaping looks like:

      & --> &
      < --> &lt;
      > --> &gt;
      " --> &quot;
      ' --> &#x27;
      

      Output escaping can be achieved through various methods. One convenient, and usually safe, way is to rely on built-in mechanisms in web frameworks to automatically handle this for all output sent from the application.

      However, most web frameworks allow developers to disable or bypass the built-in escaping mechanism. This makes sense when the data is already escaped, otherwise it would be escaped twice.

      Whenever the built-in escaping is not used, it is important that there is another mechanism in place to handle either sanitization, validation or escaping of user provided data.

      This rule flags code that disables or bypasses output escaping. The goal is to guide manual security code reviews.

      Ask Yourself Whether

      • user data provided to the application is at some point sent back to the user with the purpose of being rendered in a browser.
      • there is no mechanism to sanitize, validate or escape the data being sent from the application.

      You may be at risk if you answered yes to the above questions.

      Recommended Secure Coding Practices

      • wherever an application is sending data meant to be rendered in a browser, make sure that any data influenced by the user is either sanitized, validated or escaped.
      • use an appropriate encoding method for the context. For example, use HTML escaping for HTML element contexts, use attribute escaping for HTML attribute contexts, and so on. Read up to understand if the web framework you are using has automatic support for this or if it has to be achieved manually.

      In addition to escaping dangerous strings, it is always a good idea to protect clients from third-party scripts:

      • set the HttpOnly flag on any security-sensitive cookies to mitigate the risk of these cookies being stolen through cross-site scripting attacks.
      • set a Content Security Policy (CSP) header to prevent many cross-site scripting attacks. For more information on how to set a CSP header, see this site.

      See

      • OWASP Cheat Sheet - XSS Prevention Cheat Sheet
      • OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
      • MITRE, CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
      • MITRE, CWE-80 - Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
      • MITRE, CWE-81 - Improper Neutralization of Script in an Error Message Web Page
      • MITRE, CWE-82 - Improper Neutralization of Script in Attributes of IMG Tags in a Web Page
      • MITRE, CWE-83 - Improper Neutralization of Script in Attributes in a Web Page
      • MITRE, CWE-84 - Improper Neutralization of Encoded URI Schemes in a Web Page
      • MITRE, CWE-85 - Doubled Character XSS Manipulations
      • MITRE, CWE-86 - Improper Neutralization of Invalid Characters in Identifiers in Web Pages
      • MITRE, CWE-87 - Improper Neutralization of Alternate XSS Syntax
      • SANS Top 25 - Insecure Interaction Between Components

        Attachments

        1.
        JavaScript RSPEC-5248 Language-Specification Active Unassigned
        2.
        XML RSPEC-5249 Language-Specification Active Unassigned
        3.
        PHP RSPEC-5252 Language-Specification Active Unassigned
        4.
        HTML RSPEC-5347 Language-Specification Active Unassigned

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              lars.svensson Lars Svensson
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: