False positives from S1313 (with PR)

[magnus...@gmail.com]

Hi all!

The rule S1313 (https://dev.eclipse.org/sonar/rules/show/squid:S1313) gives false positives for 0.0.0.0 and 127.0.0.1. For 0.0.0.0, it's a special value that is used /instead of/ an IP address in some contexts, e.g. in a bind() call to specify the intention to bind to all interfaces, and in routing to specify the default gateway. The 127.0.0.1 address is the conventional address for the loopback interface. While it's common to configure the name "localhost" to resolve to that address, an it's better form to simply use the intended address instead of going via a configuration layer that at best can do nothing.

Neither of these addresses fulfill any of the criteria in the documentation for the rule

 - the values are stable and standardized, so there is no risk of them requiring recompiles,

 - they are global, and do not change between environments,

 - being special values, they are rightly specified as part of the implementation, and

 - they are not sensitive information.

I've prepared a PR for white-listing 0.0.0.0 and 127.0.0.1 in S1313 on https://github.com/SonarSource/sonar-java/pull/1081 . Please consider merging it.

BR

Magnus Reftel

[Michael Gumowski]

Hey Magnus,

Sorry for the delay answering you. First, thanks a lot for the feedback and the quality of your PR, it's really appreciated. We discussed the subject internally, but we are not going to follow you on your statements. Indeed, those IPs are standard and widely used / known. However allowing them may imply too much side effects for us.

Allowing 127.0.0.1 implies that the desire will always be to go to the loopback in implementation. The whole point is that you might be testing your application on localhost, but need a different IP in production in those specific places. For 0.0.0.0, it seems that it's not always used to declare "any IP address". For instance, in interface configuration, it may be used to remove a given address. It's usage has to be consequently well studied, and raising a (security) issue when used sounds not a bad idea.

So indeed, these both addresses are global, and usually well-known special values, but the risks their usage imply can still be problematic. From our point of view, raising an issue on them seems consequently legit. Of course, when raised, it's the responsibility of the dev team to flag the issue as "Won't Fix" or "False Positive", depending of the context.

Cheers,

Michael 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/596cd29e-73ce-4145-a6fa-02a379fd8379%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael GUMOWSKI | SonarSource

Software Developer @ Language Team
http://sonarsource.com