File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Preventing Sql Injection: Does PreparedStatement is enough?

 
Neeraj Dhiman
Ranch Hand
Posts: 68
IBM DB2 Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi friends,
I am just trying to prevent SQL injection in small project. I am just using PreparedSatement in all my forms. Does this is enough? if not suggest what else?

thanks in advance. :-)
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33696
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using a PreparedStatement *correctly* is enough. Good:


Not good:
 
Wendy Gibbons
Bartender
Posts: 1107
Eclipse IDE Oracle VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne what is the difference?
In the not good example are you presuming that the user (hacker) typed in the column name as well?
 
Martin Vajsar
Sheriff
Pie
Posts: 3747
62
Chrome Netbeans IDE Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, the problem is stuffing a variable into the statement. The origin of the variable is important: when it was read from a config file, or from a list of known columns, it won't be a problem. However, all to often these variables can be traced back to input parameters that arrived "somewhere from the web" (or other untrusted source). In this case, a malicious user might alter the input parameters and put parts of SQL commands into them which, when combined with the rest of the statement, will change its meaning. I'm no expert on SQL injection so I won't provide an example for this particular case, but it should be easily searchable.

Sometimes the SQL injection vulnerability is (wrongly) understood as just stuffing the parameters into the SQL string. Actually, putting anything from untrusted source into an SQL text constitutes SQL injection vulnerability.

There are also more arcane forms of SQL injection too. One is caused by implicit conversions (ie. from date to String), where an attacker who would be able to alter the session format string might use that to execute malicious code. It is also good to remember that SQL injection vulnerability might be present in stored procedures too. In these two cases, the problem might not be identifiable from the Java code only.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33696
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wendy Gibbons wrote:Jeanne what is the difference?
In the not good example are you presuming that the user (hacker) typed in the column name as well?

Right. I was just giving an example of using any untrusted input in building the string.
 
Wendy Gibbons
Bartender
Posts: 1107
Eclipse IDE Oracle VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:
Wendy Gibbons wrote:Jeanne what is the difference?
In the not good example are you presuming that the user (hacker) typed in the column name as well?

Right. I was just giving an example of using any untrusted input in building the string.


Ok my last company did a lot of SQL where the selects were built from the database metadata, so it didn't automatically ring bells in my head as user entered data.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic