What constitues validation of the header in the context of S5167

SonarQube Server / Community Build
, ,
1

Must-share information (formatted with Markdown):

  • which versions are you using

Version 8.9.3 (build 48735)
sonar-maven-plugin:3.9.1.2184

  • what are you trying to achieve

Resolve a vulnerability identified by SQ.

  • what have you tried so far to achieve this

Various validation patterns.

Hi there, currently trying to find a way to resolve S5167.

It appears that I am able to satisfy SQ by providing validation inside the given method - but when calling another method to perform the validation - the issue remains. For example:

String headerValue = RequestContext.getHeader("X_HEADER");
if(headerValue != null && headerValue.matches("[a-zA-Z0-9]*")){
   ResponseContext.setHeader("X_HEADER", headerValue);
}

Is NOT marked as vulnerable, while in :

public void blah(){
String headerValue = RequestContext.getHeader("X_HEADER");
if(validateHeader(headerValue)){
   ResponseContext.setHeader("X_HEADER", headerValue);
}
}

public boolean validateHeader(String headerValue){
  return headerValue != null && headerValue.matches("[a-zA-Z0-9]*";
}

SQ is not able to detect that headerValue is properly validated.

I am trying to understand what exactly is missing in the second example that makes it still flag as vulnerability. Is there a list of patterns documented somewhere that outlines what valid SQ friendly validators look like?

2

Hey @shockdm

You’re running against a known limitation of our security analyzer (which persists in recent versions) where validators in separate methods (user-defined validators) are not supported. Unfortunately, for a number of reasons that folks much smarter than me have outlined internally, this isn’t trivial to fix, but it’s definitely on our list.

I would recommend marking the issue as a false-positive.

4

Thank you for a quick response!

5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.