Skip to content

Commit 6bbe2f5

Browse files
SONARJAVA-6244 Update rule metadata (#5583)
Co-authored-by: tomasz-tylenda-sonarsource <tomasz-tylenda-sonarsource@users.noreply.github.com> Co-authored-by: Tomasz Tylenda <tomasz.tylenda@sonarsource.com>
1 parent bcf32c8 commit 6bbe2f5

38 files changed

Lines changed: 810 additions & 752 deletions
Lines changed: 33 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -1,42 +1,23 @@
1-
<p>Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:</p>
1+
<p>IP addresses hardcoded in source code couple the application to a specific infrastructure configuration. Today’s services have an ever-changing
2+
architecture due to their scaling and redundancy needs. When an IP address changes, every hardcoded occurrence must be found and updated, which has an
3+
impact on development, delivery, and deployment:</p>
24
<ul>
3-
<li><a href="https://www.cve.org/CVERecord?id=CVE-2006-5901">CVE-2006-5901</a></li>
4-
<li><a href="https://www.cve.org/CVERecord?id=CVE-2005-3725">CVE-2005-3725</a></li>
5+
<li>Developers must fix the code every time the address changes, instead of having an operations team update a configuration file.</li>
6+
<li>It leads to using the same address in every environment (dev, staging, QA, production).</li>
57
</ul>
6-
<p>Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always
7-
have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development,
8-
delivery, and deployment:</p>
9-
<ul>
10-
<li>The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.</li>
11-
<li>It misleads to use the same address in every environment (dev, sys, qa, prod).</li>
12-
</ul>
13-
<p>Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially
14-
sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to
15-
bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which
16-
will increase an attack’s impact.</p>
17-
<h2>Ask Yourself Whether</h2>
18-
<p>The disclosed IP address is sensitive, e.g.:</p>
19-
<ul>
20-
<li>Can give information to an attacker about the network topology.</li>
21-
<li>It’s a personal (assigned to an identifiable person) IP address.</li>
22-
</ul>
23-
<p>There is a risk if you answered yes to any of these questions.</p>
24-
<h2>Recommended Secure Coding Practices</h2>
25-
<p>Don’t hard-code the IP address in the source code, instead make it configurable with environment variables, configuration files, or a similar
26-
approach. Alternatively, if confidentially is not required a domain name can be used since it allows to change the destination quickly without having
27-
to rebuild the software.</p>
28-
<h2>Sensitive Code Example</h2>
29-
<pre>
30-
String ip = "192.168.12.42"; // Sensitive
31-
Socket socket = new Socket(ip, 6667);
32-
</pre>
33-
<h2>Compliant Solution</h2>
34-
<pre>
35-
String ip = System.getenv("IP_ADDRESS"); // Compliant
36-
Socket socket = new Socket(ip, 6667);
37-
</pre>
38-
<h2>Exceptions</h2>
39-
<p>No issue is reported for the following cases because they are not considered sensitive:</p>
8+
<h2>Why is this an issue?</h2>
9+
<p>Hardcoding an IP address embeds infrastructure configuration directly into the application. This means any change to the network environment—such
10+
as moving a service to a different host or scaling horizontally—requires a code modification and a full redeployment. Unlike a domain name, a
11+
hardcoded address also makes it harder to use different values across environments such as development, staging, and production.</p>
12+
<h3>What is the potential impact?</h3>
13+
<h4>Environment coupling</h4>
14+
<p>A hardcoded IP address is the same in every environment the application runs in. This makes it difficult to point development, staging, and
15+
production builds at different infrastructure without modifying the source code.</p>
16+
<h4>Increased deployment friction</h4>
17+
<p>Any change to the target host—such as migrating a service, scaling out, or rotating infrastructure—requires a code change and a full redeployment
18+
cycle. This prevents operational teams from making infrastructure adjustments independently and slows down incident response.</p>
19+
<h3>Exceptions</h3>
20+
<p>No issue is reported for the following well-known, special-purpose addresses, as they do not represent configurable infrastructure endpoints:</p>
4021
<ul>
4122
<li>Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255)</li>
4223
<li>Broadcast address 255.255.255.255</li>
@@ -48,11 +29,24 @@ <h2>Exceptions</h2>
4829
<li>Addresses in the range 2001:db8::/32, reserved for documentation purposes by <a href="https://datatracker.ietf.org/doc/html/rfc3849">RFC
4930
3849</a></li>
5031
</ul>
51-
<h2>See</h2>
32+
<h2>How to fix it</h2>
33+
<h3>Code examples</h3>
34+
<p>The following code contains a hardcoded IP address instead of reading it from configuration or environment variables.</p>
35+
<h4>Noncompliant code example</h4>
36+
<pre data-diff-id="1" data-diff-type="noncompliant">
37+
String ip = "192.168.12.42"; // Noncompliant
38+
Socket socket = new Socket(ip, 6667);
39+
</pre>
40+
<h4>Compliant solution</h4>
41+
<pre data-diff-id="1" data-diff-type="compliant">
42+
String ip = System.getenv("IP_ADDRESS");
43+
Socket socket = new Socket(ip, 6667);
44+
</pre>
45+
<h2>Resources</h2>
46+
<h3>Standards</h3>
5247
<ul>
5348
<li>OWASP - <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">Top 10 2021 Category A1 - Broken Access Control</a></li>
5449
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
5550
Exposure</a></li>
56-
<li><a href="https://wiki.sei.cmu.edu/confluence/x/OjdGBQ">CERT, MSC03-J.</a> - Never hard code sensitive information</li>
5751
</ul>
5852

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1313.json

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
2-
"title": "Using hardcoded IP addresses is security-sensitive",
3-
"type": "SECURITY_HOTSPOT",
2+
"title": "IP addresses should not be hardcoded",
3+
"type": "CODE_SMELL",
44
"code": {
55
"impacts": {
66
"SECURITY": "LOW"
@@ -16,6 +16,7 @@
1616
"cert"
1717
],
1818
"defaultSeverity": "Minor",
19+
"quickfix": "unknown",
1920
"ruleSpecification": "RSPEC-1313",
2021
"sqKey": "S1313",
2122
"scope": "Main",
@@ -32,6 +33,5 @@
3233
"CWE": [
3334
547
3435
]
35-
},
36-
"quickfix": "unknown"
36+
}
3737
}
Lines changed: 24 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,27 +1,37 @@
1-
<p>The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has
2-
been protected. Standard algorithms like <code>SHA-256</code>, <code>SHA-384</code>, <code>SHA-512</code>, …​ should be used instead.</p>
3-
<p>This rule tracks creation of <code>java.security.MessageDigest</code> subclasses.</p>
4-
<h2>Recommended Secure Coding Practices</h2>
5-
<ul>
6-
<li>Use a standard algorithm instead of creating a custom one.</li>
7-
</ul>
8-
<h2>Sensitive Code Example</h2>
9-
<pre>
1+
<p>Cryptographic operations should use proven, standard algorithms rather than custom implementations.</p>
2+
<h2>Why is this an issue?</h2>
3+
<p>Non-standard cryptographic algorithms are those that have not been publicly vetted by the security community or that implement cryptographic
4+
primitives in a custom way. Creating a custom cryptographic algorithm by subclassing standard cryptographic base classes bypasses the rigorous testing
5+
and peer review that established algorithms undergo. Custom implementations are likely to contain subtle flaws that could be exploited to break the
6+
protection the algorithm is supposed to provide.</p>
7+
<h3>What is the potential impact?</h3>
8+
<h4>Data compromise</h4>
9+
<p>When an attacker discovers a flaw in a custom cryptographic algorithm, they may be able to decrypt any data protected by it. Depending on the
10+
application, this could expose passwords, personal data, financial records, or other sensitive information.</p>
11+
<h2>How to fix it</h2>
12+
<p>This rule detects custom implementations of <code>java.security.MessageDigest</code>.</p>
13+
<h3>Code examples</h3>
14+
<h4>Noncompliant code example</h4>
15+
<pre data-diff-id="1" data-diff-type="noncompliant">
1016
public class MyCryptographicAlgorithm extends MessageDigest {
1117
...
1218
}
1319
</pre>
14-
<h2>Compliant Solution</h2>
15-
<pre>
20+
<h4>Compliant solution</h4>
21+
<pre data-diff-id="1" data-diff-type="compliant">
1622
MessageDigest digest = MessageDigest.getInstance("SHA-256");
1723
</pre>
18-
<h2>See</h2>
24+
<h2>Resources</h2>
25+
<h3>Documentation</h3>
26+
<ul>
27+
<li>Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#CUSTOM_MESSAGE_DIGEST">MessageDigest is
28+
Custom</a></li>
29+
</ul>
30+
<h3>Standards</h3>
1931
<ul>
2032
<li>OWASP - <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">Top 10 2021 Category A2 - Cryptographic Failures</a></li>
2133
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
2234
Exposure</a></li>
2335
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/327">CWE-327 - Use of a Broken or Risky Cryptographic Algorithm</a></li>
24-
<li>Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#CUSTOM_MESSAGE_DIGEST">MessageDigest is
25-
Custom</a></li>
2636
</ul>
2737

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2257.json

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
2-
"title": "Using non-standard cryptographic algorithms is security-sensitive",
3-
"type": "SECURITY_HOTSPOT",
2+
"title": "Custom cryptographic algorithms should not be used",
3+
"type": "VULNERABILITY",
44
"code": {
55
"impacts": {
66
"SECURITY": "HIGH"
@@ -12,8 +12,10 @@
1212
"func": "Constant\/Issue",
1313
"constantCost": "1d"
1414
},
15+
"quickfix": "unknown",
1516
"tags": [
16-
"cwe"
17+
"cwe",
18+
"former-hotspot"
1719
],
1820
"defaultSeverity": "Critical",
1921
"ruleSpecification": "RSPEC-2257",
@@ -34,6 +36,5 @@
3436
"6.2.2",
3537
"8.3.7"
3638
]
37-
},
38-
"quickfix": "unknown"
39+
}
3940
}
Lines changed: 27 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1,40 +1,47 @@
11
<p>JNDI supports the deserialization of objects from LDAP directories, which can lead to remote code execution.</p>
2-
<p>This rule raises an issue when an LDAP search query is executed with <code>SearchControls</code> configured to allow deserialization.</p>
3-
<h2>Ask Yourself Whether</h2>
4-
<ul>
5-
<li>The application connects to an untrusted LDAP directory.</li>
6-
<li>User-controlled objects can be stored in the LDAP directory.</li>
7-
</ul>
8-
<p>There is a risk if you answered yes to any of those questions.</p>
9-
<h2>Recommended Secure Coding Practices</h2>
10-
<p>It is recommended to disable deserialization of LDAP objects.</p>
11-
<h2>Sensitive Code Example</h2>
12-
<pre>
2+
<h2>Why is this an issue?</h2>
3+
<p>JNDI can deserialize Java objects returned by an LDAP directory when <code>SearchControls</code> is configured with the
4+
<code>returningObjFlag</code> parameter set to <code>true</code>. If the LDAP directory is untrusted or has been compromised, an attacker can inject a
5+
malicious serialized object that executes arbitrary code on the server when deserialized.</p>
6+
<h3>What is the potential impact?</h3>
7+
<p>If successfully exploited, an attacker who can control the content of the LDAP directory can craft a malicious serialized object that, when
8+
deserialized, executes arbitrary code on the server. This can lead to full system compromise, including data exfiltration, malware installation, or
9+
lateral movement within the network.</p>
10+
<h2>How to fix it</h2>
11+
<p>Set the <code>returningObjFlag</code> parameter to <code>false</code> when constructing <code>SearchControls</code> to prevent JNDI from
12+
deserializing objects returned by the LDAP directory.</p>
13+
<h3>Code examples</h3>
14+
<h4>Noncompliant code example</h4>
15+
<pre data-diff-id="1" data-diff-type="noncompliant">
1316
DirContext ctx = new InitialDirContext();
1417
// ...
1518
ctx.search(query, filter,
1619
new SearchControls(scope, countLimit, timeLimit, attributes,
17-
true, // Noncompliant; allows deserialization
20+
true, // Noncompliant: allows deserialization
1821
deref));
1922
</pre>
20-
<h2>Compliant Solution</h2>
21-
<pre>
23+
<h4>Compliant solution</h4>
24+
<pre data-diff-id="1" data-diff-type="compliant">
2225
DirContext ctx = new InitialDirContext();
2326
// ...
2427
ctx.search(query, filter,
2528
new SearchControls(scope, countLimit, timeLimit, attributes,
26-
false, // Compliant
29+
false,
2730
deref));
2831
</pre>
29-
<h2>See</h2>
32+
<h2>Resources</h2>
33+
<h3>Articles &amp; blog posts</h3>
34+
<ul>
35+
<li><a href="https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf">BlackHat USA 2016 - A
36+
Journey From JNDI/LDAP Manipulation to RCE</a></li>
37+
<li><a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ENTRY_POISONING">FindSecBugs - LDAP_ENTRY_POISONING</a></li>
38+
</ul>
39+
<h3>Standards</h3>
3040
<ul>
41+
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/502">CWE-502 - Deserialization of Untrusted Data</a></li>
3142
<li>OWASP - <a href="https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/">Top 10 2021 Category A8 - Software and Data Integrity
3243
Failures</a></li>
33-
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/502">CWE-502 - Deserialization of Untrusted Data</a></li>
3444
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A8_2017-Insecure_Deserialization">Top 10 2017 Category A8 - Insecure
3545
Deserialization</a></li>
36-
<li><a href="https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf">BlackHat
37-
presentation</a></li>
38-
<li>Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ENTRY_POISONING">LDAP_ENTRY_POISONING</a></li>
3946
</ul>
4047

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4434.json

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
2-
"title": "Allowing deserialization of LDAP objects is security-sensitive",
3-
"type": "SECURITY_HOTSPOT",
2+
"title": "Deserialization of Java objects from LDAP should be disabled",
3+
"type": "VULNERABILITY",
44
"code": {
55
"impacts": {
66
"SECURITY": "MEDIUM"
@@ -13,7 +13,8 @@
1313
"constantCost": "2min"
1414
},
1515
"tags": [
16-
"cwe"
16+
"cwe",
17+
"former-hotspot"
1718
],
1819
"defaultSeverity": "Major",
1920
"ruleSpecification": "RSPEC-4434",
Lines changed: 32 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -1,53 +1,53 @@
1-
<p>Using unsafe Jackson deserialization configuration is security-sensitive. It has led in the past to the following vulnerabilities:</p>
2-
<ul>
3-
<li><a href="https://www.cve.org/CVERecord?id=CVE-2017-4995">CVE-2017-4995</a></li>
4-
<li><a href="https://www.cve.org/CVERecord?id=CVE-2018-19362">CVE-2018-19362</a></li>
5-
</ul>
1+
<p>Jackson can be configured to allow Polymorphic Type Handling, which may expose the application to deserialization attacks.</p>
2+
<h2>Why is this an issue?</h2>
63
<p>When Jackson is configured to allow Polymorphic Type Handling (aka PTH), formerly known as Polymorphic Deserialization, "deserialization gadgets"
74
may allow an attacker to perform remote code execution.</p>
85
<p>This rule raises an issue when:</p>
96
<ul>
107
<li><code>enableDefaultTyping()</code> is called on an instance of <code>com.fasterxml.jackson.databind.ObjectMapper</code> or
118
<code>org.codehaus.jackson.map.ObjectMapper</code>.</li>
12-
<li>or when the annotation <code>@JsonTypeInfo</code> is set at class, interface or field levels and configured with <code>use =
9+
<li>The annotation <code>@JsonTypeInfo</code> is set at class, interface or field levels and configured with <code>use =
1310
JsonTypeInfo.Id.CLASS</code> or <code>use = Id.MINIMAL_CLASS</code>.</li>
1411
</ul>
15-
<h2>Ask Yourself Whether</h2>
16-
<ul>
17-
<li>You configured the Jackson deserializer as mentioned above.</li>
18-
<li>The serialized data might come from an untrusted source.</li>
19-
</ul>
20-
<p>There is a risk if you answered yes to any of those questions.</p>
21-
<h2>Recommended Secure Coding Practices</h2>
22-
<ul>
23-
<li>Use the latest patch versions of <code>jackson-databind</code> blocking the already discovered "deserialization gadgets".</li>
24-
<li>Avoid using the default typing configuration: <code>ObjectMapper.enableDefaultTyping()</code>.</li>
25-
<li>If possible, use <code>@JsonTypeInfo(use = Id.NAME)</code> instead of <code>@JsonTypeInfo(use = Id.CLASS)</code> or <code>@JsonTypeInfo(use =
26-
Id. MINIMAL_CLASS)</code> and so rely on <code>@JsonTypeName</code> and <code>@JsonSubTypes</code>.</li>
27-
</ul>
28-
<h2>Sensitive Code Example</h2>
29-
<pre>
12+
<h3>What is the potential impact?</h3>
13+
<p>If an attacker can control the serialized data, they can craft malicious payloads that exploit deserialization gadgets present on the classpath.
14+
This can lead to remote code execution, allowing the attacker to run arbitrary commands on the server.</p>
15+
<h2>How to fix it</h2>
16+
<h3>Code examples</h3>
17+
<h4>Noncompliant code example</h4>
18+
<pre data-diff-id="1" data-diff-type="noncompliant">
3019
ObjectMapper mapper = new ObjectMapper();
31-
mapper.enableDefaultTyping(); // Sensitive
20+
mapper.enableDefaultTyping(); // Noncompliant
21+
22+
@JsonTypeInfo(use = Id.CLASS) // Noncompliant
23+
abstract class PhoneNumber {
24+
}
3225
</pre>
33-
<pre>
34-
@JsonTypeInfo(use = Id.CLASS) // Sensitive
26+
<h4>Compliant solution</h4>
27+
<pre data-diff-id="1" data-diff-type="compliant">
28+
ObjectMapper mapper = new ObjectMapper();
29+
30+
@JsonTypeInfo(use = Id.NAME)
3531
abstract class PhoneNumber {
3632
}
3733
</pre>
38-
<h2>See</h2>
34+
<h2>Resources</h2>
35+
<h3>Documentation</h3>
36+
<ul>
37+
<li>OWASP - <a href="https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data">Deserialization of untrusted data</a></li>
38+
<li><a href="https://find-sec-bugs.github.io/bugs.htm#JACKSON_UNSAFE_DESERIALIZATION">FindSecBugs - JACKSON_UNSAFE_DESERIALIZATION</a></li>
39+
</ul>
40+
<h3>Articles &amp; blog posts</h3>
41+
<ul>
42+
<li><a href="https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062">On Jackson CVEs: Don’t
43+
Panic</a></li>
44+
</ul>
45+
<h3>Standards</h3>
3946
<ul>
4047
<li>OWASP - <a href="https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/">Top 10 2021 Category A8 - Software and Data Integrity
4148
Failures</a></li>
4249
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A8_2017-Insecure_Deserialization">Top 10 2017 Category A8 - Insecure
4350
Deserialization</a></li>
44-
<li>OWASP - <a href="https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data">Deserialization of untrusted data</a></li>
4551
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/502">CWE-502 - Deserialization of Untrusted Data</a></li>
46-
<li><a href="https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062">On Jackson CVEs: Don’t
47-
Panic</a></li>
48-
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-15095">CVE-2017-1509</a></li>
49-
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-7525">CVE-2017-7525</a></li>
50-
<li>Derived from FindSecBugs rule <a
51-
href="https://find-sec-bugs.github.io/bugs.htm#JACKSON_UNSAFE_DESERIALIZATION">JACKSON_UNSAFE_DESERIALIZATION</a></li>
5252
</ul>
5353

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4544.json

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,11 @@
11
{
2-
"title": "Using unsafe Jackson deserialization configuration is security-sensitive",
3-
"type": "SECURITY_HOTSPOT",
2+
"title": "Jackson deserialization should not use unsafe configuration",
3+
"type": "VULNERABILITY",
4+
"quickfix": "unknown",
5+
"tags": [
6+
"cwe",
7+
"former-hotspot"
8+
],
49
"code": {
510
"impacts": {
611
"SECURITY": "HIGH"
@@ -12,9 +17,6 @@
1217
"func": "Constant\/Issue",
1318
"constantCost": "15min"
1419
},
15-
"tags": [
16-
"cwe"
17-
],
1820
"defaultSeverity": "Critical",
1921
"ruleSpecification": "RSPEC-4544",
2022
"sqKey": "S4544",
@@ -40,6 +42,5 @@
4042
"5.5.1",
4143
"5.5.3"
4244
]
43-
},
44-
"quickfix": "unknown"
45+
}
4546
}

0 commit comments

Comments
 (0)