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

Endpoints should not be vulnerable to reflected cross-site scripting (XSS) attacks

    Details

    • Message:
      Refactor this code to not reflect tainted, user-controlled data.
    • Highlighting:
      Hide

      "[varname]" is tainted (assignments and parameters)
      this argument is tainted (method invocations)
      the returned value is tainted (returns & method invocations results)

      Show
      " [varname] " is tainted (assignments and parameters) this argument is tainted (method invocations) the returned value is tainted (returns & method invocations results)
    • Default Severity:
      Blocker
    • Impact:
      High
    • Likelihood:
      High
    • Default Quality Profiles:
      Sonar way
    • Covered Languages:
      C#, Java, PHP
    • Remediation Function:
      Constant/Issue
    • Constant Cost:
      30min
    • Analysis Level:
      Abstract Interpretation
    • 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

      User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Endpoints reflecting back tainted data could allow attackers to inject code that would eventually be executed in the user's browser. This could enable a wide range of serious attacks like accessing/modifying sensitive information or impersonating other users.

      Typically, the solution is one of the following:

      • Validate user provided data based on a whitelist and reject input that's not whitelisted.
      • Sanitize user provided data from any characters that can be used for malicious purposes.
      • Encode user provided data being reflected as output. Adjust the encoding to the output context so that, for example, HTML encoding is used for HTML content, HTML attribute encoding is used for attribute values, and JavaScript encoding is used for server-generated JavaScript.

      When sanitizing or encoding data, it is recommended to only use libraries specifically designed for security purposes. Also, make sure that the library you are using is being actively maintained and is kept up-to-date with the latest discovered vulnerabilities.

      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.
        Java RSPEC-5132 Language-Specification Active Unassigned
        2.
        C# RSPEC-5133 Language-Specification Active Unassigned
        3.
        PHP RSPEC-5134 Language-Specification Active Unassigned

          Activity

            People

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

              Dates

              • Created:
                Updated: