SQL Injection on JDBC Driver - MySQL? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

Okay so basically I'm a little bit stumped. This question is regarding the JDBC driver. Basically we own a server that is hosted on this driver, and it's running MYSQL. We are using coldfusion as our language of choice. We have a GET parameter ?lang= and injecting the character '\' into it prompts the error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near and no other character causes this error. I am sort of worried here. Can anyone tell me how an attacker would approach an sql injection attack into this parameter? So I can understand how I can filter it because in my code I am properly filtering preg_match on \ character and yet I still get this error. How would I be able to inject this parameter? Can someone point me to a guide or something, or if it's even possible. Just so I can rest in piece assuming it's not. But anyhow if this information is necessary the mysql version is 5.1.30 and the exact driver name is MySQL-AB JDBC Driver. Thanks for taking your time to help me out!

Answer 1

\ can be an escape character in mysql.

For example, an attacker could use the \b sequence to delete portions of your query and rewrite with their own injected sql.

The most reliable way to prevent sql injection attacks is to use parametrized queries.

See also:

• Mysql character escape sequences
• Preventing Sql Injection in Java
• Using prepared statements

Also be aware that in many databases (not absolutely sure about the JDBC/Mysql combination) it is also possible to "inject" a wildcard character into a sql LIKE clause, even with a parametrized query. "Injection" in this particular case is not always a problem - in fact, in many cases it may be exactly the desired behavior. However, it can be a problem, if for example, you were doing something horrid like SELECT * FROM Users WHERE UserName LIKE @userInput AND Password LIKE @passwordInput (which would allow anyone to log in simply by inputing the % wildcard character on the screen for both fields).