The Checkmarx throws the error because the values you are setting to the query parameters are not validated for its type.

For example, let us assume the query formed with your PreparedStatement is as below and the value you want to pass to the query parameter is 'Test'

Select * from XYZ where COL1 = ?

If your code is compromised and if the intruder passes 'Test' OR 1 = 1 in the query parameter, then the condition will always be true and it would return all the records from the Table.

So, before executing the query you should validate all your inputs.

Hope this helps

A second order SQL injection is an injection where the payload is already stored in the database (instead of say being delivered in a GET parameter). In that sense it is somewhat similar to stored XSS (and ordinary "first order" SQL injection would be analogous to reflected XSS).

How does it work? Lets say you let users pick any username. So an attacker could choose the name '; DROP TABLE Users; --. If you naively concatenate this username into your SQL query to retrieve information about that user you have a problem:

sql = "SELECT * FROM Users WHERE UserName = '" + $username + "'";

So, how do you deal with this?

Always use parametrized querires, always, always, always. Treat all variables as untrusted user data even if they originate from the database. Just pretend everything is GET parameters, and behave accordingly by binding them as parameters.

You can also sanitize and limit the input (e.g. only allow alphanumeric usernames) before it is stored in the database as well as after it is retrieved from the database. But I would not rely on that as my only line of defence, so use parametrized queries as well.

Checkmarx captures lot of False Positive scenarios - and it's justifiable as to warn user. But the problem is, even if you write validation functions to sanitize the inputs, it still flags them as bug - biggest issue of this tool.

Furthermore, it captures SQL Injection bugs even with MongoDB.

My recommendation is, just add validation functions which removes unnecessary characters, checks string length, data type, etc. That's good enough. Don't bother if Checkmarx still captures that as error. As rightly said - Checkmarx is far far behind from perfection.

This sounds like a false positive.

If your Java code uses Spring, I recommend configuring your scan (Settings > Scan Settings > Preset Manager) with the SQL_Injection and Second_Order_SQL_Injection items under the Java section disabled (unchecked) to avoid false positives from these items.

If your code persists data to the database exclusively via the Spring save action, it is not at risk of SQL injection exploitation. That’s because Spring saves (inserts or updates) to the database using an object mapped to your db (the ORM approach) which does not allow additional sql to be maliciously forced in.

Nonetheless, from what I’ve seen, Checkmarx marks Spring save actions, falsely, as high severity SQL Injection vulnerabilities (SQL_Injection and/or Second_Order_SQL_Injection). Given this, disabling those rules seems to me valid and in fact the only viable way around this.

But if you do take this approach, make sure your code does not for some reason also use some other some other sql approach such as a String containing SQL that’s not sanitized via the use of PreparedStatement. Those statements are vulnerable to sql injection exploits and I believe are what the Checkmarx SQL injection rules are intending to identify.

Try with st = con.prepareStatement("SELECT id,domain FROM domain") directly. Looks like checkmarx confused due to String domainquery = "SELECT id,domain FROM domain" statement and the possibility of sql injection.

This is a false positive, you need to contact the vendor and notify them about this case. When Hibernate generates SQL, it uses PreparedStatement. All the Entity fields that you change will be sent separately from the query - there won't be any concatenation.

Spring Data doesn't change the way Hibernate works with entities. So either this is a false positive, or you're looking at the wrong line of code.