=== on 9 Oct 2013, 16:00:40 Freddy Mallet wrote:
Is implemented by \http://jira.codehaus.org/browse/SONARJAVA-343

=== on 12 Dec 2014, 21:41:55 Sébastien Gioria wrote:
Could this be an extension to \http://jira.sonarsource.com/browse/RSPEC-2068

=== on 15 Dec 2014, 10:17:45 Freddy Mallet wrote:
I think it's better to have to distinct rules [~sebastien.gioria].

=== on 2 Feb 2015, 20:12:43 Sébastien Gioria wrote:
Could be Tag : CERT Secure coding MSC03-J


And sometime : OWASP top10 A2 or OWASP Top10 A5

=== on 3 Feb 2015, 20:02:37 Ann Campbell wrote:
\[~sebastien.gioria] I've added the CERT link, but I don't quite understand how this ties to the top 10. Can you point me in the right direction, please?

=== on 4 Jun 2018, 10:20:10 Patrik Lundin wrote:
I had some code flagged because I use "127.0.0.1" as the default value when no other address had been supplied in a configuration file. Does it make sense to have this check treat the use of hard coded loopback addresses like 127.0.0.1 or ::1 a special case? From a information disclosure perspective I don't think those addresses provide much information to anyone, and the ability to be able to use them as a sane default for networked services without a config file makes sense to me.


Here is how I think this idea stands up to the effects this check hopes to have as defined in this ticket:


* a recompile is required if the address changes
This assumes that the value is not a default that can be overriden by a config file. Requiring a user to write a configuration file when listening on loopback for networked processes seems cumbersome to me (I would assume that a "default" config file example would use a loopback address such as 127.0.0.1 anyway).


* it forces the same address to be used in every environment (dev, sys, qa, prod)
See above.


* it places the responsibility of setting the value to use in production on the shoulders of the developer
See above.


* it allows attackers to decompile the code and thereby discover a potentially sensitive address
I do not think loopback addresses should be counted as sensitive information since there is no way to utilize them unless you already have local access to a machine of interest. The linked CERT page even uses the hostname "localhost" in the compliant solution regarding hard coded names and passwords (and the example regarding hard coded IP addresses uses a non-loopback address).


With this said I think using something like \https://docs.oracle.com/javase/10/docs/api/java/net/InetAddress.html#isLoopbackAddress() and skipping the warning if it comes out true is reasonable.

=== on 7 Jun 2018, 16:43:11 Alexandre Gigleux wrote:
Rule removed from "Sonar Way" as this is more a Security Hotspot than a real Vulnerability.

=== on 20 Jul 2018, 09:22:05 Tibor Blenessy wrote:
I removed the compliant section because this is now security hotspot

=== on 16 Aug 2018, 15:09:07 Ann Campbell wrote:
\[~nicolas.harraudeau] it would be nice to give a little context/background for the Object Identifiers link, since the linked page offers none itself.

=== on 16 Aug 2018, 16:17:27 Nicolas Harraudeau wrote:
Thanks [~ann.campbell.2]. I didn't see that there was no link to the parent page. I updated the link and it now points to the OID description.

