Достаточно ли подготовленных запросов и и проверки на спец. символы для защиты?
Всем привет!
Если на сервере установлены подготовленные запросы и обработка текста на вводе htmlspecialchars.
Этого достаточно, чтобы быть спокойным, что с вашей БД ничего не случится и пользователи не смогут получить вредоносный скрипт из базы?
И в чём разница белого листа от подготовленных запросов, и вообще, нужен ли он, если по факту подготовленный запрос исключает возможность любой манипуляции с БД со стороны, которая не предусмотрена кодом разработчика?
- подготовленные запросы защищают данные (то есть числа и строки) передаваемые в запрос. Если у тебя данные передаются во все запросы без исключений через параметры, то ты защищён
- белый лист нужен для того чтобы защищать имена полей или ключевые слова, буде появится необходимость добавлять их в запрос динамически
То есть эти два подхода защищают разные части запроса, и вместе гарантируют защиту.
А htmlspecialchars вообще не имеет никакого отношения к БД
Для защиты от SQL-инъекций необходимо удостовериться, что данные с клиента (именно данные, а не пользовательский ввод, ибо ничего не мешает выполнить веб-запрос нештатными методами) никогда не передаётся на сервер напрямую, а всегда экранируется. Значения никогда не передаются в запрос напрямую, а только через параметры.
У тебя тоже каша в голове. И в итоге ответ еще больше запутывает автора.
Подумай над несколькими вещами:
1. Что такое "передается на сервер напрямую"? Какой ещё сервер? Что значит "напрямую" и чем это отличается от "не напрямую"?
2. Что такое это "экранирование" и причем оно вообще здесь?
3. Что такое "данные с клиента", и нужно ли вообще такое понятие в контексте защиты запросов? Админ - это клиент? Информаця прочитанная из файла на диске - это данные с клиента? Ты уверен что хочешь постоянно думать над такими вопросами и в итоге все равно ошибиться?
Потом прочитай мой ответ.
Я раньше тоже путался, но потом понял что все гораздо проще.
FanatPHP, По полочкам:
1. PHP в 99% случаев - это веб-технология, где данные передаются от клиентской части (браузера) на веб-сервер. В данном контексте, возможно, следовало выразиться иначе. Напрямую - это без изменений.
2. Экранирование символов почитай, что это, и зачем нужно.
3. Веб-клиент выполняет запрос, пересылая некие данные на веб-сервер. Это и есть данные с клиента. Напоминаю, что вопрос задан под тэгом PHP, соответственно, из этого контекста, делается вывод, что речь идёт о веб-разработке. В этом свете вполне очевидны понятия "данные с клиента".
1. Тут ты просто запутался :) По твоим словам, "данные от клиентской части (браузера) на веб-сервер" не дожны передаваться "напрямую". Мало того что ты не пояснил, что значит не напрямую и чем плохо передавать из браузера на сервер как обычно, но даже не можешь объяснить, какое это всё отношение имеет к SQL инъекциям.
2. Ты слышал звон да не знаешь где он. И пытаешься отбрехаться бессмысленной ссылкой на википедию. На будущее запомни - если ты используешь подготовленные выражения, то никакое "экранирование" делать не нужно.
3. Я не зря упомянул файл на диске. И еще примерно миллион источников, помимо "данных из браузера". Все они тоже потенциально опасны. Поэтому зацикливаться на каких-то конкретных источниках постпуления данных просто глупо. Важно не откуда пришли данные, а куда они идут. В SQL запрос? Передаем через параметры. И не надо забивать себе голову экранированием, сложными построениями про 99% и совершать прочие пассы руками. Всё гораздо проще.
о даже не можешь объяснить, какое это всё отношение имеет к SQL инъекциям.
И не пытался. Разве в этом был вопрос?
На будущее запомни
На будущее, запомни, мальчик. Не стоит с таким высокомерием переписываться с незнакомыми людьми на узкоспециализированные темы. Это ничего не говорит о твоей квалификации, зато многое - о твоих личных комплексах. Если внимательно прочесть мой оригинальный ответ, и читать глазами, а не другими мягкими частями тела, то внезапно обнаружится, что термин "экранирование", которого ты, по всей видимости, просто не знал, более обобщающий, чем один из его вариантов, реализованных конкретно в виде механизма параметризированных запросов.
