Re: Sql injection attacks
От | Lincoln Yeoh |
---|---|
Тема | Re: Sql injection attacks |
Дата | |
Msg-id | 6.1.2.0.1.20040728170935.01f2ef38@localhost обсуждение исходный текст |
Ответ на | Re: Sql injection attacks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Sql injection attacks
|
Список | pgsql-general |
At 11:13 PM 7/26/2004, Tom Lane wrote: >I think you misunderstood. Escaping is perfectly safe (given a correct >escaping function) if it's used on *every* untrustworthy input string. >The argument for the "keep data separate from code" approach is >essentially just that it's easier to be sure you haven't forgotten >anyplace where you need to escape. Just curious on what are the correct/official ways for dealing with the following scenarios: 1) Input string contains % and _ and would be used in a LIKE query that should not have user controllable wildcards. 2) Input string are numbers which can hold negative and positive values and could potentially be used in the following query: update tablea set a=10-$inputstring where key=1; When I tested at least one version of DBD::Pg doesn't appear to escape the inputstring when it's a number. e.g. $SQL="update tablea set a=10-? where key=1"; And $SQL is used in a prepared statement with $inputstring as a parameter. I found that when $inputstring contained a negative number, all rows in tablea are set to the same value. 3) Postgresql queries with select .... from ... where ... LIMIT $inputstring Postgresql 7.3.4 doesn't like LIMIT '1' Nor does it like LIMIT '1'::integer Haven't checked OFFSET. (sorry- I downgraded to 7.3.4 and haven't upgraded). Regards, Link.
В списке pgsql-general по дате отправления: