Sometimes, you have to work with plain JDBC (or ODBC). Here is a couple of tricks that help:
- First and foremost, avoid concatenating strings for SQL queries. Use prepared statements unless is not possible (i.e. cases when you have undefined number of parameters)
- Leverage the language type system: If you're passing a number, use Integer instead of String... any invalid character will fail the conversion and will not reach the DB.
- If there's no option but concatenate strings, make sure the database comment quotes are escaped (for example, in DB2 you have to replace the single quote character with 2 single quote characters: instead of "SELECT * FROM users WHERE name='"+param+"'" use "SELECT * FROM users WHERE name='"+param.replaceAll("'","''")+"'"
Note: by no means this is a comprehensive list. Application security is very hard, check your database documentation...
9 comments:
No, no, no!
You do not EVER concatenate user inputed data into sql strings, and try to sanitize it.
Use placeholders (put a questionmark "?" where the data goes).
@Kreiger
Yep, that's recommendation #1.
But in rare cases you have an undefined number of parameters and is not practical to use parameters.
IN clauses can be an example, although you're right: you can "unroll" it in a series of " OR value=? " ... I guess at that point is a trade off...
No, that's against recommendation #3.
If you have an undefined number of parameters, you build your statement with one placeholder for each, and set the value for each.
Just build the in clause dynamically with placeholders: "... IN (?,?,?,?,?,?) ..."
You're totally right and I like the approach.
The only drawback is that in some complex query cases, it can make the code even more complex (I guess is the price to pay for safety).
I imagine you need to keep a list of parameter values, and for every "?" you add to the query, you add the value to the list, then compile the statement and apply the parameters
Exactly right.
Also if it is possible at all allow ONLY valid post or GET variables Maybe check from an allowed list everytime ?
Web Development Company
SQL Injection is subset of the an unverified/unsanitized user input vulnerability and I actually have alot of experience updating older apps to use PreparedStatements, it is fairly easy except if you are using alot of dynamic statements. Still this process is time consuming, and the idea is to convince the application to run SQL code that was not intended. If the application is creating SQL strings naively on the fly and then running them, it's straightforward to create some real surprises.
Really I enjoy your site with effective and useful information. It is included very nice post with a lot of our resources.thanks for share. i enjoy this post. 统计代写
Post a Comment