Является ли это достаточным образом, чтобы предотвратить инъекции и другие плохие вещи в строках


Бы эта функция будет достаточно, чтобы убрать все вредоносный код и иностранные символы из строки?

//Clean the string
$out = ltrim($do);
$out = rtrim($out);
$out = preg_replace('/[^(\x20-\x7F)]*/','', strip_tags($out)); 

Этих данных не будет в базе данных SQL, поэтому я не придется беспокоиться по поводу попыток SQL-инъекций. Есть ли способ, чтобы улучшить мой код и сделать его более эффективным?

Эта функция позволит очистить любые введенные пользователем данные (формы, а ?), а затем сохранить его, сделать базу данных. Это будет использоваться в глобальной функцией дезинфекции.



478
11
задан 21 января 2011 в 06:01 Источник Поделиться
Комментарии
2 ответа

Что один довольно простой (для меня по крайней мере), так как есть очень общий ответ :)

Нет

Нет никакого способа, вы можете когда-либо действительно безопасно "ремонт" для ввода данных пользователем.


"Укажите, пожалуйста, список всего, что вы не должны с молотка"

это путь сложнее, чем


"список всех соответствующих использует молотка".

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

Это может показаться суровым, но что-то всегда байт и если это только функция eval(UNHEX(ASD23426363)) или что-то подобное. (Пример SQL всеже ты сказать, что это не SQL, но все).

Конечно, вы можете делать вещи, как вырезать теги из ввода для HTML-контекст в любом случае, так что дыра в вашей другой код не так легко эксплуатируется и меньше вреда будет сделано, но я не должна быть ваша единственная защита.


Кто-то сказал, что фильтр входной, побег, выход лучше, чем я мог. Терри Чай


Короче: все, что вы делаете там, найти соответствующую функцию экранирования и использовать его.

Контексте оболочки ? escapeshellarg

HTML контексте ? функции htmlspecialchars

Контекст базы данных ? Использовать подготовленные операторы и больше никогда не беспокоиться о SQL-инъекции


Маленькая правка:
Я знаю, что я сказал и в блоге противоречит немного, но это нормально со мной. На практике всегда будут отличаться от общих рекомендаций и иногда хочется делать все что можно ;)

17
ответ дан 21 января 2011 в 06:01 Источник Поделиться

Я делаю копи-пасте из моего ответа на подобный вопрос так:

Всегда помните, фильтра, побег для всех пользователей поставлен (или ненадежного) вход.

При чтении пользователь ввел данные, фильтровать их с известными значениями. НЕ ИГНОР! Всегда всегда всегда всегда белый, что вы ожидаете получить. Если вы ожидаете шестнадцатиричное число, проверить его с помощью регулярного выражения, как: ^[А-и F0-9]+$. Выяснить, что вы ожидаете, и фильтр к этому. Неужели никто из ваших именах есть что-нибудь, но буквы, цифры и .? Затем фильтр С ^[а-З0-9.]+$. Но не начинайте думать, что исключение в отношении вещи. Он не будет работать.

При использовании пользовательских данных, защитить его должным образом для использования на руку. Если это будет в базе данных, либо привязать его в качестве параметризованного запроса, или избежать его функция защитить базы данных. Если ты называешь командной оболочки, выйти из него с escapeshellarg(). Если вы используете его в regex шаблон, выйти из него с preg_quote(). Есть больше, но вы получаете идею.

При выводе пользовательских данных, защитить его должным образом для формата, который вы выводить его как. Если вы будете выводить его в HTML или XML, использовать функции htmlspecialchars(). Если вы будете выводить в заголовки Почему-то избегают любых переносы строк (как str_replace(массив (как"\R", "\Н"), массив('\р', '\п'), $строка)). И т. д. и т. п. и т. д.

Но всегда фильтр, используя белый список, и всегда избежать с помощью правильного метода для контекста. В противном случае существует значительный шанс, что вы что-то пропустила...

8
ответ дан 21 января 2011 в 08:01 Источник Поделиться