In Java, if a user input is directly appended to an SQL query without using methods like setString() or setInt(), but the query is executed using a PreparedStatement, is it still considered SQL injection?
Can we consider this as SQL injection?
-
4Yes, indeed it is. SQL injection does not depend on whether you use a PreparedStatement or not. It depends on how you supply the parameters. If you pass the parameters as part of the query, then it's vulnerable to SQL injection.k314159– k3141592024-09-17 16:06:14 +00:00Commented Sep 17, 2024 at 16:06
-
1See stackoverflow.com/questions/8263371/…k314159– k3141592024-09-17 16:10:10 +00:00Commented Sep 17, 2024 at 16:10
-
1@T.S. that "duplicate" question is very unclear and goes down a rabbithole with unrelated things like JSON, and the answer is about using Hibernate, which this current question does not even mention.k314159– k3141592024-09-17 16:49:47 +00:00Commented Sep 17, 2024 at 16:49
-
@k314159 baeldung.com/sql-injectionT.S.– T.S.2024-09-17 16:51:35 +00:00Commented Sep 17, 2024 at 16:51
-
@k314159 you should write that as an answer.aled– aled2024-09-17 17:15:52 +00:00Commented Sep 17, 2024 at 17:15
Add a comment
|
3 Answers
Yes. Concatenating or interpolating untrusted input into an SQL string before it is parsed is SQL injection.
It helps to understand why prepared statements are often mentioned as a defense against SQL injection.
The problem with SQL injection is that you combine some content with your SQL query string, and then submit the string to be parsed an executed. If the content changes the SQL syntax of your query, then this causes the query to do something you didn't intend.
Using prepared statements allows you to separate the step of parsing SQL from the execution of the query. Once the query has been parsed in the prepare step, then it's not possible for content added with setString() or setInt() to change the syntax of the query. The query has already been parsed by the database engine, and parameters can only be treated as if they are scalar values, not other SQL syntax.
In other words, setString() is not the same as string concatenation. It adds the string content into the query after the query has been parsed. So it's safe to add content that contains characters that would have resulted in different query logic.
If you concatenate SQL strings with untrusted content before preparing the statement, this does not help. Prepared statements do not confer any kind of "blessing" to make unsafe queries into safe queries.
They only give you the opportunity to combine parameters after the query has been prepared.
Comments
Yes, indeed it is still vulnerable to SQL injection.
A PreparedStatement by itself does not prevent SQL injection. What prevents it is a parameterized query. In order to use a parameterized query with JDBC, you need a PreparedStatement. But just using a PreparedStatement does not automatically mean you're using a parameterized query. A PreparedStatement does not prevent you from adding user input to your query string. To prevent SQL injection, you need to pass all your user input as parameters.
Comments
It will be a SQL injection because automatic interpretation of the value as sql code.
If you use prepared statement as ps.setString(value), it will interpret the value as data, not as code and will do automatic escaping of problematic characters, which will prevent it from sql injection.
