File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JDBC and the fly likes Preventing Sql Injection: Does PreparedStatement is enough? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Preventing Sql Injection: Does PreparedStatement is enough?" Watch "Preventing Sql Injection: Does PreparedStatement is enough?" New topic
Author

Preventing Sql Injection: Does PreparedStatement is enough?

Neeraj Dhiman
Ranch Hand

Joined: Dec 19, 2011
Posts: 63

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. :-)


Correct Me if i am wrong
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29253
    
139

Using a PreparedStatement *correctly* is enough. Good:


Not good:


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Wendy Gibbons
Bartender

Joined: Oct 21, 2008
Posts: 1106

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

Joined: Aug 22, 2010
Posts: 3436
    
  47

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
internet detective
Marshal

Joined: May 26, 2003
Posts: 29253
    
139

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

Joined: Oct 21, 2008
Posts: 1106

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
 
subject: Preventing Sql Injection: Does PreparedStatement is enough?
 
Similar Threads
SQL Injection
Using strings within strings to read vars?
SQL injection?
Dynamic SQL Injection Prevention.
Struts and SQL Injection.