Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Безопасная валидация данных
Собственно интересны методы какими кто обрабатывает данные, особенно через что прогонять строги, что бы защититься от sql инъекций
Мелкий
Отправлено: 14 Августа, 2013 - 14:45:00
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
nepster пишет:
защититься от sql инъекций
Препарированные запросы.
Всё. Больше от инъекций ничего делать не нужно.
Но это не является валидацией. Валидация должна заниматься вопросом "а какие данные тут должны быть?" (или же я путаю термины ) Например, что такая дата реально существует, а не 31 ноября. А статус - один из допустимых.
----- PostgreSQL DBA
esterio
Отправлено: 14 Августа, 2013 - 14:45:38
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
teddy пишет:
Если например это целое число, то abs(intval($_POST['num']));
Отрицательное число - тоже целое. Так что проверка соответствует утверждению "ожидается неотрицательное целое число".
teddy пишет:
Если строка, то $db->real_escape_string($_POST['str']);
Любая строка предполагается к обработке в запросах? Вряд ли, поэтому обрабатывать следует только непосредственно перед вставкой данных в строку запроса (выше написали лучший способ - подготовленные запросы, prepared statements)
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
teddy
Отправлено: 14 Августа, 2013 - 15:30:58
Участник
Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013
Помог: 91 раз(а)
EuGen пишет:
Отрицательное число - тоже целое. Так что проверка соответствует утверждению "ожидается неотрицательное целое число".
Да, согласен. Я просто не так выразился
EuGen пишет:
Любая строка предполагается к обработке в запросах?
Я имел ввиду тот случай, когда мы ожидаем приход обязательных данных, которые отправит пользователь.
Тоесть у меня получаеться конфиг-массив. И уже в контроллере я просто указиваю етот массив, и на выходе получаю отфильтрованые данные(число включая диапазон, емейл, регуляркы для болле сложных и т.д.)
nepster
Отправлено: 14 Августа, 2013 - 17:16:16
Частый гость
Покинул форум
Сообщений всего: 195
Дата рег-ции: Июль 2012
Помог: 0 раз(а)
а как тогда отловить код ошибки ?
esterio
Отправлено: 14 Августа, 2013 - 17:26:16
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
ну а почитать сложно
Цитата:
Значение массива будет FALSE, если фильтрация завершилась неудачей, или NULL, если переменная не определена
teddy
Отправлено: 15 Августа, 2013 - 14:53:11
Участник
Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013
Помог: 91 раз(а)
Мелкий пишет:
Препарированные запросы.
А можно подробнее про это? Я не пользуюсь подготовленными запросами, поэтому хотелось бы получить ответ на несколько вопросов. Есть например такой код
Чем отличается такой запрос от обычного? Ведь все равно в запрос подставится то что будет в переменных.
Или тут сначала выполнится запрос, а потом уже подставятся значения? Не совсем понятно честно говоря... Если так, то логика не совсем ясна... Или может просто мы говорим: "Приготовься выполнить этот запрос и только этот, и если прилетит что то левое, то принимай это как обычные данные и не в коем случае не подставляй в запрос"
И почему когда кол-во передаваемых параметров не совпадает кол-ву полей в БД интерпретатор плюется ошибкой? В обычных запросах вроде как нет... или может есть специальные настройки что бы это отключить?
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
мне вот тоже интересно почему подготовленные лучше?
ведь это как минимум 2 запроса вместо 1го(для одиночного запроса конечно)
какой такой случай инъекции возможен при использовании real_escape_string от которого спасет препарирование? (Добавление)
teddy пишет:
Чем отличается такой запрос от обычного? Ведь все равно в запрос подставится то что будет в переменных.
тем что сначала в бд улетает запрос с плейсхолдерами
а затем летят отдельно данные и подставляются в запрос(в транслированный уже план запроса)
в этом случае данные рассматриваются как данные и не парсятся на предмет управляющих символов (Добавление)
выгодно для циклов одинаковых запросов (Добавление)
teddy пишет:
может пнёт кто если что не очень хорошо.
незнаю пнет ли это тебя но я вот как-то так сделал
Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013
Помог: 91 раз(а)
LIME пишет:
тем что сначала в бд улетает запрос с плейсхолдерами
а затем летят отдельно данные и подставляются в запрос(в транслированный уже план запроса) в этом случае данные рассматриваются как данные и не парсятся на предмет управляющих символов
Спасибо
LIME пишет:
человеческие константы чтоб понятней было
Почитал в мануале, приблизительно разобрался, но как по мне мудрено как то... мне проще явно привести к типу одной строкой а потом уже писать различные условия для валидации если это требуется...
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.