I believe PQescapeString() has an important design bug and it casues a
security risk.
The function's signature is:
size_t PQescapeString (char *to, const char *from, size_t length);
As you might notice, it's impossible to specify encoding of "to". As a
result, it turns every occurrences of 0x27(') or 0x5c(\) to 0x270x27
or 0x5c0x5c. This is fine with ASCII, UTF-8, EUC-JP and so on. However
cetain Asian multibyte charsets such as SJIS, Big5 and GBK have a bit
pattern in that the second byte is 0x27(') or 0x5c(\). Applying
PQescapeString() to them will produce invalid character sequences.
But there's more. Problem is, PQescapeString() makes SQL injections
possible. Here is an example:
There is an application which selects particlular member info from a
table in this way:
SELECT * FROM members WHERE member_name = 'var';
Users can input value for "var" from a web form. The attacker inputs
following string:
(0x95+0x27);DELETE FROM members;--
where 0x95+0x27 is actually a SJIS mutibyte KANJI. Programmer applies
PQescapeString() to it and gets:
0x95+0x27+0x27;DELETE FROM members;--
and the result SQL will be:
SELECT * FROM members WHERE member_name = '0x95+0x27';DELETE FROM members;--';
You lose members table:-<
Conclusion:
I suggest that PQescapeString() should have a parameter to specify the
encoding of "to".
BTW it's irony that PQescapeStringt man page stats like this:-)
Tip: It is especially important to do proper escaping when handling strings that were received from an untrustworthy
source.Otherwise there is a security risk: you are vulnerable to "SQL injection" attacks wherein unwanted SQL commands
arefed to your database.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
