Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-1569

[Java, C#] SonarSecurity: 5 Additional Rules (XSS, Response Splitting, SSRF, Log Forging, Open Redirect) and Sanitizers/Validators per Rule


    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:



      SonarSecurity is currently supporting 6 injection rules for Java and C# "only". PHP support is coming soon but still that won't be enough.

      We should increase the number of supported rules to maximize our chance to find 0-days vulnerabilities.


      SonarSecurity should detect these 5 vulnerabilities:

      • RSPEC-5131 Endpoints should not be vulnerable to reflected cross-site scripting (XSS) attacks
      • RSPEC-5144 Server-side requests should not be vulnerable to forging attacks
      • RSPEC-5145 Logging should not be vulnerable to injection attacks
      • RSPEC-5146 HTTP request redirections should not be open to forging attacks
      • RSPEC-5167 HTTP response headers should not be vulnerable to injection attacks

      These 5 rules will be implemented in three phases. Two of them are covered by this MMF.

      Java configuration:

      C# configuration:

      Basic Version

      Using the current SonarSecurity technology, all RSPECs will be implemented with a common list of sanitizers.

      RSPEC-5144, RSPEC-5145, RSPEC-5146, RSPEC-5167 will be implemented with the specified sinks.

      RSPEC-5131 will be implemented with specified sinks for C# but in Java we will simplify the implementation to comply with the current limitation of how we can define sinks in SonarSecurity. Specifically, PrintWriter will be defined as a sink, without regard to how the object is created. These limitations imply that we allow for a potentially large number of False-Negatives and False-Positives.

      Less False-Negatives through Sanitizers per Rule Config

      To reduce the number of False-Negatives, and to make sure that True-Positive results disappear only when vulnerabilities are actually fixed, separate lists of sanitizers will be used for all SonarSecurity rules.

      SonarSecurity will be enhanced to cover this use case.

      Here is an example where an SQL-sanitizer is used for mitigating XSS, still leaving the vulnerability exploitable.

      Sanitizers specified per rule can be found in the above linked configuration sheets.

      Separate Sanitizers and Validators

      To prepare for future functionality that will make specific use of Validators, we will separate the current configuration of Sanitizers into two different lists, one for Sanitizers and one for Validators.

      • A Sanitizer is defined as a method, function, language construct or annotation that is leading a tainted value to be sanitized after its use.
      • A Validator is a method, function, language construct or annotation that checks if a tainted value is safe and generally returns a boolean value. A call to a Validator method makes the path from a source to a sink safe.

      Out Of Scope

      For S5131 (XSS), it is accepted to generate FPs that we will tackle in another MMF (MMF-1596).

      For example S5131 should not raise an issue when PrintWriter is used to write to anything else than a HttpServletResponse. To achieve this we need to change SonarSecurity to allow for sinks to be defined as a list of criteria that need to be fulfilled; for example that the PrintWriter object is created from a call to HttpServletResponse.getWriter().




            • Assignee:
              lars.svensson Lars Svensson (Inactive)
              alexandre.gigleux Alexandre Gigleux
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: