Это в порядке для разрешения иногда динамического SQL без санитизации?
Function.toString () (неявный):
function x() {
alert("Hello World");
}
eval ("x = " + (x + "").replace(
'Hello World',
'STACK OVERFLOW BWAHAHA"); x("'));
x();
8 ответов
Что вы считаете более серьезной проблемой:
- Необходимость отслеживать ошибку, которая не вызвала сбой SQL-запроса.
- Необходимость восстановления данных после того, как вы допустили ошибку при дезинфекции ввод формы, и кто-то это использует.
Что бы вы ни выбрали, вот и ваш ответ. Лично я склоняюсь и к параноидальной стороне вещей.
Во всяком случае, вы могли бы сделать и то, и другое: создать свою собственную функцию, которая сначала проверяет значение null, а затем вызывает intval () , и использовать это вместо этого. Тогда вы получите лучшее из обоих миров.
ввод формы должен всегда очищаться idd, но не каждую переменную, которая входит в запрос, следует очищать imo ...
Происхождение переменной здесь играет важную роль.
Вам просто нужно знать, можно ли доверять используемым данным ...
Честно говоря, ваш партнер не в себе: дезинфекция обходится дешево, нет веской причины не делать этого. Даже если вы дезинфицируете то, что находится в формах HTML, если эти проверки каким-то образом не работают в производственной среде, вы будете счастливы, что у вас есть резервная копия в других местах. Кроме того, это способствует хорошей практике.
Вы должны дезинфицировать - всегда
Сначала проверьте, не является ли идентификатор нулевым. Если это так, то вы знаете, что не следует делать бесполезный запрос и продолжать с этого момента. Нет смысла отслеживать проблемы путем чтения неудачных запросов SQL или около того.
Если вы посмотрите глубже в код Zend framework, вы увидите, что $ db-> quoteInto () превращается в $ db-> quote, которая возвращает (строку) intval ($ value) с Целое число как тип.
Если тип не определен, вызывается $ db -> _ quote (). Его код следующий:
protected function _quote($value)
{
if (is_int($value) || is_float($value)) {
return $value;
}
return "'" . addcslashes($value, "\000\n\r\\'\"\032") . "'";
}
Независимо от используемого метода вызова (с указанием типа или без него), $ db-> delete полностью безопасен.
Я думаю, что ваш партнер ошибается - он не рассматривает разделение проблем между санацией в модели (где находится ваш код БД) и проверкой данных ваших форм.
Обычно логика проверки формы находится в отдельной области приложения для вашей модели. Т.е. при добавлении валидаторов в элементы формы, и поэтому это часто делается в самом классе формы. Целью этого уровня кода проверки является проверка ввода формы и возвращение соответствующих сообщений, если что-то не так.
Поэтому я думаю, что санитарную обработку данных в модели следует рассматривать отдельно от этого, поскольку Модель действительно автономный класс - и, следовательно, должен нести ответственность за собственную очистку данных. Поскольку теоретически вы должны иметь возможность повторно использовать эту модель в другом месте своего приложения, модель не должна предполагать, что санитарная обработка была проведена где-то еще, то есть как часть уровня проверки формы.
Основная мысль ваших партнеров о том, что нельзя на практике обнаружение неудачных запросов SQL не является проблемой - лучше использовать защитный код.
Все данные, полученные из формы, должны быть очищены. Без исключений. Все данные, полученные из вашей системы, должны быть уже очищены до того, как попали в вашу систему, и поэтому не должны подвергаться дезинфекции при повторном извлечении из системы.
Итак, вопрос в том, откуда это целое число?
Вы, конечно, всегда должны дезинфицировать и не полагаться на HTML-формы. Что, если вы измените свой код и повторно используете эту часть с некоторыми другими данными, которые поступили не из HTML-формы, а из веб-службы, электронной почты или любого другого источника, который вы решите добавить через год? Использование intval () здесь кажется нормальным.