Безопасность подготовленного заявления Kohana SQL

В документации по подготовленному оператору Kohana указано

Несмотря на то, что все параметры экранированы для предотвращения SQL-инъекций, все же рекомендуется проверять/очищать введенные данные.

Из того, что я прочитал в подготовленных операторах, у меня сложилось впечатление, что параметры привязки предотвращают внедрение SQL. Если это не так, какой метод очистки/экранирования следует использовать перед привязкой переменных?


mysql php prepared-statement kohana
person flurry    schedule 14.10.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я думаю, когда они говорят, что «проверка/санация по-прежнему является хорошей идеей», они имеют в виду использование действительного класса или/и класса проверки... Чтобы убедиться, что вы вставляете правильные данные в свою БД.

Дополнительная информация о проверке в Kohana: http://kohanaframework.org/3.2/guide/kohana/security/validation

ОБНОВИТЬ:

Вам также следует изучить XSS: http://kohanaframework.org/3.2/guide/kohana/security/xss

person jnbdz    schedule 14.10.2011
comment
согласен, например, что произойдет, если вы вставите целое число, а вместо этого получите текстовую строку. вы, вероятно, получите 0 в базе данных вместо того, что вы ожидали. - person bumperbox; 14.10.2011
comment
Так что, чтобы было ясно, причина, по которой он говорит, не из соображений безопасности, а просто для того, чтобы убедиться, что типы данных, которые вы ожидаете, входят в запрос? - person flurry; 14.10.2011
comment
На самом деле это может стать проблемой безопасности, если в вашу БД будут добавлены неправильные данные (например, можно вставить скрипт в БД, который может быть выполнен где-то и в какой-то момент в вашем приложении). Это также может вызвать ошибки. - person jnbdz; 14.10.2011

arrow_upward
1
arrow_downward

Kohana предоставляет абстракцию db для различных типов баз данных. Не все конкретные базы данных могут иметь подготовленные операторы, поэтому они будут смоделированы. Некоторые встроенные функции экранирования для определенных баз данных могут даже не работать.

Как вы никогда не знаете, всегда хорошо иметь не только один уровень безопасности.

Другой уровень заключается в том, что ваш сценарий действительно получает данные, которые имеют смысл. Например. например, строка имени размером 8 мегабайт. Не имеет смысла независимо от того, что с ним делает база данных.

person hakre    schedule 14.10.2011