> >> Uh-oh, this is my fault. PQescapeString should escape all characters > >> greater than 126. Unfortunately, there is nothing we can do about > >> this in the current function because tha twould need four times the > >> lenggth of the input string (plus one). Drat. > > > > Please don't do that. That would break all applications those use > > the mutibyte encodings including UTF-8. > > Why? Doesn't the server perform unquoting *before* multi-byte > processing? -- Ah, it doesn't. Perhaps this is the part which should > be fixed?
No no. Probably you misunderstand why we need quoting. If special characters such as "'" or "\" appears, it should be quoted. But you should not if it's a part of multibyte characters. > >> (I don't think you should have to consider the encoding in the client; > >> strange things may happen if there is an interpretation conflict > >> between the client and the backend.) > > > > No. For the sake PQmblen() is provided. What I (and I guess Tom too) > > am thinking is like this: > > > > attacker's input: > > > > (0x95+0x27);DELETE FROM members;-- > > > > new-PQescapeString() treats this: > > > > 0x95+0x27;DELETE FROM members;-- > > But this still needs knowledge of SJIS at the client side (and both > client and backend must have the same notion of SJIS). No problem. We have the client encoding in PGConn. That's why Tom suggests PQescapeString() should have the PGCConn argument. -- Tatsuo Ishii SRA OSS, Inc. Japan ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings