The server code we scanned has regular expressions that are not prepared for DoS, as you can see in the attached image.
However, when I look at the results in the SonarQube dashboard after the scan, it doesn’t say that a vulnerability was found for the security rule ‘Regular expressions should not be vulnerable to Denial of Service attacks’.
Why is the SonarQube scanner not catching vulnerabilities in my code? This is a very serious issue for us.
We are using the developer edition of SonarQube and our code is written in Typescript.
Could you please explain why you think this regular expression should raise an issue for ‘Regular expressions should not be vulnerable to Denial of Service attacks’? It is not obvious to me from the screenshot.
The file where the regex code I attached in the screenshot is located is the resUtil.ts file, which defines the custom middleware functionality.
The description of the security rule ‘Regular expressions should not be vulnerable to Denial of Service attacks’ in the above link says that validation should be done on the server side for regular expressions, using escape functions, etc.
However, we don’t have anything like an escape function in our code.
We want to know if regular expressions in our middleware that will be used by express.js are independent of the ‘Regular expressions should not be vulnerable to Denial of Service attacks’ security rule, and if that’s why the scan says it’s okay.
We also want to know how the scan results for the ‘Regular expressions should not be vulnerable to Denial of Service attacks’ security rule would be if there are no regular expressions in the code we want to scan. In other words, we want to know what the results would be if we scanned code unrelated to any security rule against that security rule.
This rule is an injection rule, meaning it looks for user input that is used to construct regular expressions (the pattern, not the subject that the regular expression is applied to). In such a case you should escape the user input to prevent attackers from specifying “bad” regular expressions. In your case, the regular expression is a hard-coded string, so there is nothing to escape.
In theory, you can also be vulnerable to ReDOS with a hard-coded pattern but this is covered by a different rule that is not yet available for TypeScript. And your regular expression is safe, there is nothing to worry about.
