Regular Expression Policy pattern validation by SonarQube

[apiandintegr]

Hello All,

Our regular expression pattern declaration is getting flagged as an issue in sonarqube analysis. 

I am not sure why the issue is, but below is the line which is giving a trouble, 

[\s](?i)((delete)|(exec)|(drop\s*table)|(insert)|(shutdown)|(update)|(\bor\b)). 

How have you handled, regex policy with sonarqube code analysis ? Is there a way, we can declare these patterns outside code and fetch it regex policy to avoid this issue ? Or any other better way ?

Appreciate your help, thanks

[dchiesa1 · Accepted solution]

No, the Pattern element in the RegularExpressionProtection policy always takes a fixed (static) regular expression.  You cannot declare these patterns outside the API proxy and fetch it dynamically.  You could replace the RegularExpressionProtection policy with a JavaScript policy that performs a similar check. But that seems like the wrong approach: you'd be writing your own JavaScript to do the work that the builtin policy performs, potentially introducing bugs and vulnerabilities, and definitely introducing more maintenance load, and you'd do that only to avoid an erroneous flag by SonarQube. 

Maybe a better approach is to find a way to tell SonarQube to NOT flag this policy as a threat.

[dchiesa1 · Accepted solution]

No, the Pattern element in the RegularExpressionProtection policy always takes a fixed (static) regular expression.  You cannot declare these patterns outside the API proxy and fetch it dynamically.  You could replace the RegularExpressionProtection policy with a JavaScript policy that performs a similar check. But that seems like the wrong approach: you'd be writing your own JavaScript to do the work that the builtin policy performs, potentially introducing bugs and vulnerabilities, and definitely introducing more maintenance load, and you'd do that only to avoid an erroneous flag by SonarQube. 

Maybe a better approach is to find a way to tell SonarQube to NOT flag this policy as a threat.

[apiandintegr]

I managed to find the root cause. Regex sonarqube rule has been configured to  flag issue, if pattern contains "(?". We are using this to make match case insensitive.  Now, I am trying to see if this case insensitive is better practise, if yes, do we have any other option other than having (?.

Thanks for your time. 

[dchiesa1 · Accepted solution]

Case insensitivity is appropriate if you are scanning for SQL injection, (eg select, insert, drop table, etc).  SQL is generally case insensitive for those keywords.

I don't know of another way, in Apigee, to tell the regex match, "be case insensitive", other than using (?i). 

Conclusion: as far as I know, to do what you want, your regex needs to have the (?i).