-
Notifications
You must be signed in to change notification settings - Fork 0
Devin/1762486345 test sonar trigger #31
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.
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
base: master
Are you sure you want to change the base?
Conversation
This test file contains: - SQL injection vulnerability (string concatenation in query) - Bug (comparing two random values) - Code smell (deeply nested if statements) - Empty exception handler Purpose: Test that the SonarCloud workflow triggers Devin session when issues are found Co-Authored-By: Jake Cosme <jake@cognition.ai>
Added a comment to indicate the purpose of the code.
Co-Authored-By: Jake Cosme <jake@cognition.ai>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| String query = "SELECT * FROM users WHERE name = '" + userInput + "'"; | ||
| stmt.executeQuery(query); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔴 SQL Injection vulnerability via string concatenation
The vulnerableMethod directly concatenates userInput into a SQL query string without any sanitization or parameterization:
String query = "SELECT * FROM users WHERE name = '" + userInput + "'";
stmt.executeQuery(query);This allows an attacker to inject arbitrary SQL commands. For example, if userInput is '; DROP TABLE users; --, the resulting query becomes:
SELECT * FROM users WHERE name = ''; DROP TABLE users; --'Impact: An attacker can read, modify, or delete data from the database, potentially gaining full control of the database server.
Expected: Use PreparedStatement with parameterized queries to prevent SQL injection.
Recommendation: Replace with PreparedStatement: PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM users WHERE name = ?"); pstmt.setString(1, userInput); pstmt.executeQuery();
Was this helpful? React with 👍 or 👎 to provide feedback.
| } | ||
|
|
||
| public int buggyMethod() { | ||
| if (secureRandom.nextInt() == secureRandom.nextInt()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔴 Comparing two different random values instead of the same value
The buggyMethod compares two separate calls to secureRandom.nextInt():
if (secureRandom.nextInt() == secureRandom.nextInt()) {
return 1;
}Each call to nextInt() generates a new independent random number. This means the comparison is between two different random values, not comparing a value to itself.
Actual behavior: The condition will be true only when both random calls happen to return the same value by chance (probability ~1 in 2^32 for int range), making the method almost always return 0.
Expected behavior: If the intent was to check if a random value equals itself (always true), a single value should be stored: int val = secureRandom.nextInt(); if (val == val). If the intent was to compare two random values, this is correct but the logic seems suspicious.
Impact: The method has unpredictable and likely unintended behavior.
Recommendation: Store the random value in a variable before comparison if comparing to itself was intended: int val = secureRandom.nextInt(); if (val == val)
Was this helpful? React with 👍 or 👎 to provide feedback.
Uh oh!
There was an error while loading. Please reload this page.