I have read many post talk about addslashes is not safe for SQL injection, but they all refer same example using GBK encoding. So my question is: Is it safe using addslashes() to prevent SQL injection in php when parameter charset is utf-8?
-
Short answer: no, long answer http://stackoverflow.com/q/60174/1207346 – Dale May 11 '16 at 10:52
-
First of all, any reason you want to use addslashes for mysql? – Your Common Sense May 11 '16 at 11:24
-
@Dale, sorry but I still get any help from this article, could you explain in short? – jamesse May 12 '16 at 03:53
-
@YourCommonSense , good question, I just evaluate if it is necessary to do that, because my company has lots of 'addslashes' code, and all UTF-8 encoding – jamesse May 12 '16 at 03:55
-
Thank you for the clarification. I'll update my answer. – Your Common Sense May 12 '16 at 08:19
-
@YourCommonSense, got it, thanks. – jamesse May 13 '16 at 06:26
1 Answers
In fact, there are two questions in one. And so it's better to voice them separately.
For the question
Is it safe using addslashes() if charset is utf8?
The answer is YES, it is safe.
Taken by itself, with isolated example, addslashes can produce a safe sequence to be used in the SQL string literal if your charset is utf8
.
However, taken as a protection measure, intended, as it is commonly used, to "process all the input data to make it safe" it is proven to be fatally insecure. Which for the question
Is it safe using addslashes() to prevent SQL injection
makes it the only answer:
NO WAY!
Simply because that this honest function has nothing to do with protection from any injections. And never has been.
What you have to understand, is that the main threat is coming not from the semi-mythical GBK vulnerability, but entirely from the misuse of this function. As it's just not intended to protect you from injections. The topic of protection is much more complex than simple string escaping.
The problem is that there are a lot of rules to keep in mind. And there are a lot of points of possible failure.
For these reasons, a simple string escaping just cannot be considered as an all-embracing protection rule.
From this point of view, parametrized queries, although not offering the 100% protection, can be considered a WAY better measure anyway, eliminating three most dangerous threats:
- because numbers also covered, there is no way to inject via numeric literal
- because of complete formatting, a wrongly escaped identifier becomes not a breach but a development stage error.
- because of automated formatting, a human error is eliminated
The above these three reasons I consider enough for changing your approach.
Besides, properly implemented parametrized queries make your code DRAMATICALLY cleaner. Give me your addslashes-based code snippet, and I'll show you how to make it 3-5 times shorter and cleaner.

- 1
- 1

- 156,878
- 40
- 214
- 345
-
What would you recommend for cases where you can't use parameterized queries? Of course I use them everywhere I possibly can, but if you're storing MySQL statements in something like a MySQL dump, then you have to escape it somehow – Brian Leishman Oct 04 '17 at 14:44