Can I stop SQL injection by escaping characters?

I know that the best way to avoid SQL injection attacks is to use parameterized queries or preparedStatements in Java because there would be no string parsing that be misdirected.

However, I have an application that is 12 years old and it is just not worth the effort to re-architect the app so I can eliminate all the string concatenation.

I have seen that MySQL has a function mysql_real_escape_string()  that escapes 7 different characters:

mysql_real_escape_string() calls MySQL's library function 3. mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

So, I am wondering if that should be enough to prevent SQL injection attacks?
jkurantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

CEHJCommented:
So, I am wondering if that should be enough to prevent SQL injection attacks?
How would you use that without rewriting the code?

In any case, it might help, but would not be sufficient
0
jkurantAuthor Commented:
i would pass any strings I was going to execute on the database server through a routine like mysql_real_escape_string() to escape the characters that could be used in an attack. That wouldn't require re-writing code, just refactoring it a bit.

If string replacement is not sufficient, I may have to re-write the app, meaning re-design it so as to not build SQL strings containing user input at all, but rather passing those strings in as arguments.
0
CEHJCommented:
That wouldn't require re-writing code, just refactoring it a bit.
Not sure how you can avoid rewriting or how indeed refactoring is not rewriting.

The point is, (say) nx2 effective rewriting is better than n ineffective rewriting
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

jkurantAuthor Commented:
@CEHJ: Neither of your comments contain anything like an answer to my question. If you have something helpful to add, please do.

Can anyone think of a SQL injection attack that could succeed even with escaping the following characters: \x00, \n, \r, \, ', " and \x1a
0
CEHJCommented:
I have answered your question. I'm sorry you don't like the answer
0
jkurantAuthor Commented:
This wasn't really a yes or no question. If escaping those 7 characters will not prevent SQL injection, why won't it? What kind of attack could defeat that defense?
0
dpearsonCommented:
If you're not willing to switch to Prepared Statements then I think your escaping function is the next best option.

I've heard that the weakness for these methods is folks coming up with clever Unicode encodings of strings - which is a hugely complex area in MySQL (the client, the server, the database and the table can all be encoding and decoding the strings in and out of UTF-8/ASCII etc as they travel) and that with the right Unicode encoding, you can bipass the ASCII-centric string escaping approaches.

So escaping your character string puts another barrier in front of an attacker, but I think proving that it's 100% injection resistant would be exceptionally hard.  It really depends how bad it would be if the data was extracted/corrupted by an attacker.  If this is for a database of where you store your MP3s I'd say you're good to go.  If  it's a corporate database of passwords, I think maybe not so good.

Doug
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CEHJCommented:
If escaping those 7 characters will not prevent SQL injection, why won't it?
This is not really the place to go into sql injection in detail, but the facts are that

a. it's not limited to just the use of escape characters
b. the set of characters you mentioned is limited

http://en.wikipedia.org/wiki/SQL_injection
0
Anthony PerkinsCommented:
The Technet article SQL Injection goes to some length to explain some of the subtleties involved with SQL Injection, as well as lists the characters you should escape (they are not the same as MySQL)

And yes, I do understand that all you can do is reduce the risk, as changing your code to use Stored Procedures or parameterized queries is out of the question.
0
jkurantAuthor Commented:
I eventually found this, which is very helpful. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.