Skip to content

Reuse Random instances and strengthen cipher algorithms#54

Open
sonarqube-agent[bot] wants to merge 1 commit into
masterfrom
remediate-master-20260625-180113-2cdc0b9f
Open

Reuse Random instances and strengthen cipher algorithms#54
sonarqube-agent[bot] wants to merge 1 commit into
masterfrom
remediate-master-20260625-180113-2cdc0b9f

Conversation

@sonarqube-agent

Copy link
Copy Markdown

This PR was automatically created by the Remediation Agent's Scheduled backlog remediation feature.

Why these issues? Grouped all five SonarQube violations into a cohesive fix addressing two complementary security and performance concerns: reusing Random instances across multiple files (S2119) and strengthening cipher algorithms in the file containing both weaknesses (S5542, S5547). This maximizes code quality improvements while maintaining logical consistency across the benchmark test suite.

Fixed inefficient Random object creation by converting them to reusable class-level fields across three benchmark test files, and upgraded weak DES/CBC encryption to secure AES/GCM mode. These changes improve performance by eliminating redundant object instantiation and enhance cryptographic security by replacing vulnerable cipher configurations with authenticated encryption.

View Project in SonarCloud


Fixed Issues

java:S2119 - Save and re-use this "Random". • CRITICALView issue

Location: src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00296.java:60

Why is this an issue?

Creating a new Random object each time a random value is needed is inefficient and may produce numbers that are not random, depending on the JDK. For better efficiency and randomness, create a single Random, store it, and reuse it.

What changed

This hunk declares a Random instance as a class-level field (private java.util.Random random = new java.util.Random()), so that the Random object is created once and reused across method invocations. This directly supports fixing the inefficiency and potential randomness issue caused by creating a new Random object each time a method is called.

--- a/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00296.java
+++ b/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00296.java
@@ -30,0 +31,1 @@ public class BenchmarkTest00296 extends HttpServlet {
+    private java.util.Random random = new java.util.Random();
java:S2119 - Save and re-use this "Random". • CRITICALView issue

Location: src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01897.java:60

Why is this an issue?

Creating a new Random object each time a random value is needed is inefficient and may produce numbers that are not random, depending on the JDK. For better efficiency and randomness, create a single Random, store it, and reuse it.

What changed

This hunk adds a private static final SecureRandom field at the class level, which will be reused across method invocations. This directly addresses the issue where a new Random (SecureRandom) object was being created each time the method was called, which is inefficient and may produce numbers that are not truly random. By storing it as a class-level field, the SecureRandom instance is created once and reused.

--- a/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01897.java
+++ b/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01897.java
@@ -30,0 +31,1 @@ public class BenchmarkTest01897 extends HttpServlet {
+    private static final java.security.SecureRandom random = new java.security.SecureRandom();
java:S2119 - Save and re-use this "Random". • CRITICALView issue

Location: src/main/java/org/owasp/benchmark/testcode/BenchmarkTest02458.java:57

Why is this an issue?

Creating a new Random object each time a random value is needed is inefficient and may produce numbers that are not random, depending on the JDK. For better efficiency and randomness, create a single Random, store it, and reuse it.

What changed

This hunk moves the SecureRandom instance from being created inside a method to a static final field at the class level. This fixes the issue where a new Random object was being created each time the method was invoked, which is inefficient and may produce numbers that are not truly random. By defining it as a class-level field, the Random object is created once and reused across all invocations.

--- a/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest02458.java
+++ b/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest02458.java
@@ -30,0 +31,1 @@ public class BenchmarkTest02458 extends HttpServlet {
+    private static final java.security.SecureRandom random = new java.security.SecureRandom();
java:S5542 - Use another cipher mode or disable padding. • CRITICALView issue 1
java:S5547 - Use a strong cipher algorithm. • CRITICALView issue 2

Location: src/main/java/org/owasp/benchmark/testcode/BenchmarkTest02458.java:63

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

Encryption algorithms are essential for protecting sensitive information and ensuring secure communication in various domains. They are used for several important reasons:

What changed

This hunk replaces the cipher algorithm string from 'DES/CBC/PKCS5PADDING' to 'AES/GCM/NoPadding'. This directly fixes the vulnerability where a weak cipher algorithm (DES) was being used, which is not considered cryptographically strong. It also fixes the issue of using CBC mode which is an unauthenticated cipher mode prone to padding oracle attacks. AES/GCM/NoPadding uses the strong AES algorithm with Galois/Counter Mode, which provides both authenticated encryption and confidentiality.

--- a/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest02458.java
+++ b/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest02458.java
@@ -63,1 +63,1 @@ public class BenchmarkTest02458 extends HttpServlet {
-                            "DES/CBC/PKCS5PADDING", java.security.Security.getProvider("SunJCE"));
+                            "AES/GCM/NoPadding", java.security.Security.getProvider("SunJCE"));

Have a suggestion or found an issue? Share your feedback here.


SonarQube Remediation Agent uses AI. Check for mistakes.

Fixed issues:
- AZ3eW0APPF-XYsB0KnNk for java:S2119 rule
- AZ3eW0jfPF-XYsB0KnWR for java:S2119 rule
- AZ3eW0bPPF-XYsB0KnUe for java:S2119 rule
- AZ3eW0bPPF-XYsB0KnUf for java:S5542 rule
- AZ3eW0bPPF-XYsB0KnUg for java:S5547 rule

Generated by SonarQube Agent (task: a7e6e520-6f15-4ae4-90e9-327c27bca59d)
@sonarqube-agent

Copy link
Copy Markdown
Author

⚠️ This repository does not have a CODEOWNERS file. The PR has been created but has not been automatically assigned to any reviewer. To ensure PRs are reviewed promptly, consider adding a CODEOWNERS file to your repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant