Skip to content

SONARJAVA-6244 Update rule metadata #5582

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hashicorp-vault-sonar-prod wants to merge 1 commit into from
Closed

SONARJAVA-6244 Update rule metadata #5582

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 33 additions & 39 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1313.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,42 +1,23 @@
<p>Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:</p>
<p>IP addresses hardcoded in source code couple the application to a specific infrastructure configuration. Today’s services have an ever-changing
architecture due to their scaling and redundancy needs. When an IP address changes, every hardcoded occurrence must be found and updated, which has an
impact on development, delivery, and deployment:</p>
<ul>
<li><a href="https://www.cve.org/CVERecord?id=CVE-2006-5901">CVE-2006-5901</a></li>
<li><a href="https://www.cve.org/CVERecord?id=CVE-2005-3725">CVE-2005-3725</a></li>
<li>Developers must fix the code every time the address changes, instead of having an operations team update a configuration file.</li>
<li>It leads to using the same address in every environment (dev, staging, QA, production).</li>
</ul>
<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
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,
delivery, and deployment:</p>
<ul>
<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>
<li>It misleads to use the same address in every environment (dev, sys, qa, prod).</li>
</ul>
<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
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
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
will increase an attack’s impact.</p>
<h2>Ask Yourself Whether</h2>
<p>The disclosed IP address is sensitive, e.g.:</p>
<ul>
<li>Can give information to an attacker about the network topology.</li>
<li>It’s a personal (assigned to an identifiable person) IP address.</li>
</ul>
<p>There is a risk if you answered yes to any of these questions.</p>
<h2>Recommended Secure Coding Practices</h2>
<p>Don’t hard-code the IP address in the source code, instead make it configurable with environment variables, configuration files, or a similar
approach. Alternatively, if confidentially is not required a domain name can be used since it allows to change the destination quickly without having
to rebuild the software.</p>
<h2>Sensitive Code Example</h2>
<pre>
String ip = "192.168.12.42"; // Sensitive
Socket socket = new Socket(ip, 6667);
</pre>
<h2>Compliant Solution</h2>
<pre>
String ip = System.getenv("IP_ADDRESS"); // Compliant
Socket socket = new Socket(ip, 6667);
</pre>
<h2>Exceptions</h2>
<p>No issue is reported for the following cases because they are not considered sensitive:</p>
<h2>Why is this an issue?</h2>
<p>Hardcoding an IP address embeds infrastructure configuration directly into the application. This means any change to the network environment—such
as moving a service to a different host or scaling horizontally—requires a code modification and a full redeployment. Unlike a domain name, a
hardcoded address also makes it harder to use different values across environments such as development, staging, and production.</p>
<h3>What is the potential impact?</h3>
<h4>Environment coupling</h4>
<p>A hardcoded IP address is the same in every environment the application runs in. This makes it difficult to point development, staging, and
production builds at different infrastructure without modifying the source code.</p>
<h4>Increased deployment friction</h4>
<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
cycle. This prevents operational teams from making infrastructure adjustments independently and slows down incident response.</p>
<h3>Exceptions</h3>
<p>No issue is reported for the following well-known, special-purpose addresses, as they do not represent configurable infrastructure endpoints:</p>
<ul>
<li>Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255)</li>
<li>Broadcast address 255.255.255.255</li>
Expand All @@ -48,11 +29,24 @@ <h2>Exceptions</h2>
<li>Addresses in the range 2001:db8::/32, reserved for documentation purposes by <a href="https://datatracker.ietf.org/doc/html/rfc3849">RFC
3849</a></li>
</ul>
<h2>See</h2>
<h2>How to fix it</h2>
<h3>Code examples</h3>
<p>The following code contains a hardcoded IP address instead of reading it from configuration or environment variables.</p>
<h4>Noncompliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
String ip = "192.168.12.42"; // Noncompliant
Socket socket = new Socket(ip, 6667);
</pre>
<h4>Compliant solution</h4>
<pre data-diff-id="1" data-diff-type="compliant">
String ip = System.getenv("IP_ADDRESS");
Socket socket = new Socket(ip, 6667);
</pre>
<h2>Resources</h2>
<h3>Standards</h3>
<ul>
<li>OWASP - <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">Top 10 2021 Category A1 - Broken Access Control</a></li>
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
Exposure</a></li>
<li><a href="https://wiki.sei.cmu.edu/confluence/x/OjdGBQ">CERT, MSC03-J.</a> - Never hard code sensitive information</li>
</ul>

8 changes: 4 additions & 4 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1313.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"title": "Using hardcoded IP addresses is security-sensitive",
"type": "SECURITY_HOTSPOT",
"title": "IP addresses should not be hardcoded",
"type": "CODE_SMELL",
"code": {
"impacts": {
"SECURITY": "LOW"
Expand All @@ -16,6 +16,7 @@
"cert"
],
"defaultSeverity": "Minor",
"quickfix": "unknown",
"ruleSpecification": "RSPEC-1313",
"sqKey": "S1313",
"scope": "Main",
Expand All @@ -32,6 +33,5 @@
"CWE": [
547
]
},
"quickfix": "unknown"
}
}
38 changes: 24 additions & 14 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2257.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,27 +1,37 @@
<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
been protected. Standard algorithms like <code>SHA-256</code>, <code>SHA-384</code>, <code>SHA-512</code>, …​ should be used instead.</p>
<p>This rule tracks creation of <code>java.security.MessageDigest</code> subclasses.</p>
<h2>Recommended Secure Coding Practices</h2>
<ul>
<li>Use a standard algorithm instead of creating a custom one.</li>
</ul>
<h2>Sensitive Code Example</h2>
<pre>
<p>Cryptographic operations should use proven, standard algorithms rather than custom implementations.</p>
<h2>Why is this an issue?</h2>
<p>Non-standard cryptographic algorithms are those that have not been publicly vetted by the security community or that implement cryptographic
primitives in a custom way. Creating a custom cryptographic algorithm by subclassing standard cryptographic base classes bypasses the rigorous testing
and peer review that established algorithms undergo. Custom implementations are likely to contain subtle flaws that could be exploited to break the
protection the algorithm is supposed to provide.</p>
<h3>What is the potential impact?</h3>
<h4>Data compromise</h4>
<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
application, this could expose passwords, personal data, financial records, or other sensitive information.</p>
<h2>How to fix it</h2>
<p>This rule detects custom implementations of <code>java.security.MessageDigest</code>.</p>
<h3>Code examples</h3>
<h4>Noncompliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
public class MyCryptographicAlgorithm extends MessageDigest {
...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
<h4>Compliant solution</h4>
<pre data-diff-id="1" data-diff-type="compliant">
MessageDigest digest = MessageDigest.getInstance("SHA-256");
</pre>
<h2>See</h2>
<h2>Resources</h2>
<h3>Documentation</h3>
<ul>
<li>Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#CUSTOM_MESSAGE_DIGEST">MessageDigest is
Custom</a></li>
</ul>
<h3>Standards</h3>
<ul>
<li>OWASP - <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">Top 10 2021 Category A2 - Cryptographic Failures</a></li>
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
Exposure</a></li>
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/327">CWE-327 - Use of a Broken or Risky Cryptographic Algorithm</a></li>
<li>Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#CUSTOM_MESSAGE_DIGEST">MessageDigest is
Custom</a></li>
</ul>

11 changes: 6 additions & 5 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2257.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"title": "Using non-standard cryptographic algorithms is security-sensitive",
"type": "SECURITY_HOTSPOT",
"title": "Custom cryptographic algorithms should not be used",
"type": "VULNERABILITY",
"code": {
"impacts": {
"SECURITY": "HIGH"
Expand All @@ -12,8 +12,10 @@
"func": "Constant\/Issue",
"constantCost": "1d"
},
"quickfix": "unknown",
"tags": [
"cwe"
"cwe",
"former-hotspot"
],
"defaultSeverity": "Critical",
"ruleSpecification": "RSPEC-2257",
Expand All @@ -34,6 +36,5 @@
"6.2.2",
"8.3.7"
]
},
"quickfix": "unknown"
}
}
47 changes: 27 additions & 20 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4434.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,40 +1,47 @@
<p>JNDI supports the deserialization of objects from LDAP directories, which can lead to remote code execution.</p>
<p>This rule raises an issue when an LDAP search query is executed with <code>SearchControls</code> configured to allow deserialization.</p>
<h2>Ask Yourself Whether</h2>
<ul>
<li>The application connects to an untrusted LDAP directory.</li>
<li>User-controlled objects can be stored in the LDAP directory.</li>
</ul>
<p>There is a risk if you answered yes to any of those questions.</p>
<h2>Recommended Secure Coding Practices</h2>
<p>It is recommended to disable deserialization of LDAP objects.</p>
<h2>Sensitive Code Example</h2>
<pre>
<h2>Why is this an issue?</h2>
<p>JNDI can deserialize Java objects returned by an LDAP directory when <code>SearchControls</code> is configured with the
<code>returningObjFlag</code> parameter set to <code>true</code>. If the LDAP directory is untrusted or has been compromised, an attacker can inject a
malicious serialized object that executes arbitrary code on the server when deserialized.</p>
<h3>What is the potential impact?</h3>
<p>If successfully exploited, an attacker who can control the content of the LDAP directory can craft a malicious serialized object that, when
deserialized, executes arbitrary code on the server. This can lead to full system compromise, including data exfiltration, malware installation, or
lateral movement within the network.</p>
<h2>How to fix it</h2>
<p>Set the <code>returningObjFlag</code> parameter to <code>false</code> when constructing <code>SearchControls</code> to prevent JNDI from
deserializing objects returned by the LDAP directory.</p>
<h3>Code examples</h3>
<h4>Noncompliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
DirContext ctx = new InitialDirContext();
// ...
ctx.search(query, filter,
new SearchControls(scope, countLimit, timeLimit, attributes,
true, // Noncompliant; allows deserialization
true, // Noncompliant: allows deserialization
deref));
</pre>
<h2>Compliant Solution</h2>
<pre>
<h4>Compliant solution</h4>
<pre data-diff-id="1" data-diff-type="compliant">
DirContext ctx = new InitialDirContext();
// ...
ctx.search(query, filter,
new SearchControls(scope, countLimit, timeLimit, attributes,
false, // Compliant
false,
deref));
</pre>
<h2>See</h2>
<h2>Resources</h2>
<h3>Articles &amp; blog posts</h3>
<ul>
<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
Journey From JNDI/LDAP Manipulation to RCE</a></li>
<li><a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ENTRY_POISONING">FindSecBugs - LDAP_ENTRY_POISONING</a></li>
</ul>
<h3>Standards</h3>
<ul>
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/502">CWE-502 - Deserialization of Untrusted Data</a></li>
<li>OWASP - <a href="https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/">Top 10 2021 Category A8 - Software and Data Integrity
Failures</a></li>
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/502">CWE-502 - Deserialization of Untrusted Data</a></li>
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A8_2017-Insecure_Deserialization">Top 10 2017 Category A8 - Insecure
Deserialization</a></li>
<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
presentation</a></li>
<li>Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ENTRY_POISONING">LDAP_ENTRY_POISONING</a></li>
</ul>

7 changes: 4 additions & 3 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4434.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"title": "Allowing deserialization of LDAP objects is security-sensitive",
"type": "SECURITY_HOTSPOT",
"title": "Deserialization of Java objects from LDAP should be disabled",
"type": "VULNERABILITY",
"code": {
"impacts": {
"SECURITY": "MEDIUM"
Expand All @@ -13,7 +13,8 @@
"constantCost": "2min"
},
"tags": [
"cwe"
"cwe",
"former-hotspot"
],
"defaultSeverity": "Major",
"ruleSpecification": "RSPEC-4434",
Expand Down
73 changes: 39 additions & 34 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4512.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,49 +1,54 @@
<p>Setting JavaBean properties is security sensitive. Doing it with untrusted values has led in the past to the following vulnerability:</p>
<ul>
<li><a href="https://www.cve.org/CVERecord?id=CVE-2014-0114">CVE-2014-0114</a></li>
</ul>
<p>JavaBeans can have their properties or nested properties set by population functions. An attacker can leverage this feature to push into the
JavaBean malicious data that can compromise the software integrity. A typical attack will try to manipulate the ClassLoader and finally execute
malicious code.</p>
<p>This rule raises an issue when:</p>
<ul>
<li>BeanUtils.populate(…​) or BeanUtilsBean.populate(…​) from <a href="http://commons.apache.org/proper/commons-beanutils/">Apache Commons
BeanUtils</a> are called</li>
<li>BeanUtils.setProperty(…​) or BeanUtilsBean.setProperty(…​) from <a href="http://commons.apache.org/proper/commons-beanutils/">Apache Commons
BeanUtils</a> are called</li>
<li>org.springframework.beans.BeanWrapper.setPropertyValue(…​) or org.springframework.beans.BeanWrapper.setPropertyValues(…​) from Spring is
called</li>
</ul>
<h2>Ask Yourself Whether</h2>
<ul>
<li>the new property values might have been tampered with or provided by an untrusted source.</li>
<li>sensitive properties can be modified, for example: <code>class.classLoader</code></li>
</ul>
<p>There is a risk if you answered yes to any of those questions.</p>
<h2>Recommended Secure Coding Practices</h2>
<p>Sanitize all values used as JavaBean properties.</p>
<p>Don’t set any sensitive properties. Keep full control over which properties are set. If the property names are provided by an unstrusted source,
filter them with a whitelist.</p>
<h2>Sensitive Code Example</h2>
<pre>
<p>Setting JavaBean properties from untrusted user input can allow an attacker to manipulate arbitrary object properties, including sensitive
internals such as <code>class.classLoader</code>.</p>
<h2>Why is this an issue?</h2>
<p>JavaBean property population functions such as <code>BeanUtils.populate()</code>, <code>BeanUtils.setProperty()</code>,
<code>BeanUtilsBean.populate()</code>, and <code>BeanUtilsBean.setProperty()</code> from Apache Commons BeanUtils, and
<code>BeanWrapper.setPropertyValue()</code> and <code>BeanWrapper.setPropertyValues()</code> from Spring, allow setting arbitrary bean properties by
name. When the property names or values are derived from untrusted input without validation, an attacker can set sensitive properties — for example,
<code>class.classLoader</code> — and use them to load and execute malicious code.</p>
<h3>What is the potential impact?</h3>
<p>If successfully exploited, this vulnerability can lead to remote code execution, full application compromise, data exfiltration, or lateral
movement within the network.</p>
<h2>How to fix it</h2>
<h3>Code examples</h3>
<h4>Noncompliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
Company bean = new Company();
HashMap map = new HashMap();
Enumeration names = request.getParameterNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
map.put(name, request.getParameterValues(name));
}
BeanUtils.populate(bean, map); // Sensitive: "map" is populated with data coming from user input, here "request.getParameterNames()"
BeanUtils.populate(bean, map); // Noncompliant: "map" is populated with data coming from user input, here "request.getParameterNames()"
</pre>
<h2>See</h2>
<h4>Compliant solution</h4>
<pre data-diff-id="1" data-diff-type="compliant">
Company bean = new Company();
HashMap map = new HashMap();
Set&lt;String&gt; allowedProperties = Set.of("name", "address"); // define allowed properties
Enumeration names = request.getParameterNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
if (allowedProperties.contains(name)) {
map.put(name, request.getParameterValues(name));
}
}
BeanUtils.populate(bean, map);
</pre>
<h2>Resources</h2>
<h3>Articles &amp; blog posts</h3>
<ul>
<li><a href="https://www.cve.org/CVERecord?id=CVE-2014-0114">CVE-2014-0114</a></li>
<li><a href="https://find-sec-bugs.github.io/bugs.htm#BEAN_PROPERTY_INJECTION">FindSecBugs - BEAN_PROPERTY_INJECTION</a></li>
</ul>
<h3>Standards</h3>
<ul>
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/915">CWE-915 - Improperly Controlled Modification of Dynamically-Determined Object
Attributes</a></li>
<li>OWASP - <a href="https://owasp.org/Top10/A03_2021-Injection/">Top 10 2021 Category A3 - Injection</a></li>
<li>OWASP - <a href="https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/">Top 10 2021 Category A8 - Software and Data Integrity
Failures</a></li>
<li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">Top 10 2017 Category A1 - Injection</a></li>
<li>CWE - <a href="https://cwe.mitre.org/data/definitions/915">CWE-915 - Improperly Controlled Modification of Dynamically-Determined Object
Attributes</a></li>
<li><a href="https://wiki.sei.cmu.edu/confluence/x/hDdGBQ">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms</li>
<li>Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#BEAN_PROPERTY_INJECTION">BEAN_PROPERTY_INJECTION</a></li>
</ul>

7 changes: 4 additions & 3 deletions sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4512.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"title": "Setting JavaBean properties is security-sensitive",
"type": "SECURITY_HOTSPOT",
"title": "JavaBean properties should not be populated from untrusted input",
"type": "VULNERABILITY",
"code": {
"impacts": {
"SECURITY": "HIGH"
Expand All @@ -14,7 +14,8 @@
},
"tags": [
"cwe",
"cert"
"cert",
"former-hotspot"
],
"defaultSeverity": "Critical",
"ruleSpecification": "RSPEC-4512",
Expand Down
Loading
Loading