php секретный вопрос - PullRequest
4 голосов
/ 25 февраля 2010

Это был долгий день, но я не могу выбрать в своей голове, что лучше, или я должен использовать оба.

В основном, что я должен использовать для очистки введенных пользователем значений. Это функция htmlentities или preg_match?

Тогда я буду использовать значение mysql_real_escape_string, если значение переходит в SQL-запрос, но только до тех пор, пока я не изменю его на подготовленный оператор, тогда я могу удалить это.

Или было бы неплохо использовать htmlentities и preg_match?

Ответы [ 4 ]

3 голосов
/ 25 февраля 2010

Почему вы просто не задали это в своем предыдущем вопросе ?

Используйте preg_match перед выполнением любого экранирования, чтобы убедиться, что данные соответствуют белому списку того, что вы ожидаете. Затем используйте escape для вставки базы данных. Это называется глубокой защитой (т. Е. Более чем одним уровнем проверки безопасности в случае, если злоумышленник может прорваться через первый уровень).

1 голос
/ 26 февраля 2010

Если вы используете PHP 5.2+, вам следует изучить функции фильтра для очистки ваших данных.

http://php.net/manual/en/filter.examples.sanitization.php

0 голосов
/ 25 февраля 2010

В основном, что я должен использовать для очистки введенных пользователем значений. Это функция htmlentities или preg_match?

Конечно, не htmlentities, вероятно, не preg_match (в целях безопасности). Вы изменяете представление любого вывода на носитель, на который он направляется (веб-страница htmlentites for, URL-адрес для URL, mysql_real_escape_string для базы данных mysql ....).

Если кто-то действительно хочет зарегистрироваться в вашем приложении как фиктивный 'UNION SELECT' фиктивный 'AS пользователь,' фиктивный 'AS пароль ОТ DUAL , тогда пусть он!

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

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

С

0 голосов
/ 25 февраля 2010

Лучше иметь слишком много проверок и процедур проверки, чем слишком мало. Система не более или менее безопасна, добавляя избыточность. Эфир это уязвимость или нет, это логическое значение, а не число с плавающей точкой. Когда я проверяю код и вижу избыточные меры безопасности, я воспринимаю его как красный флаг, и это побуждает меня копать глубже. Этот программист параноик и, возможно, они не понимают природу уязвимостей, хотя это не всегда так.

Есть еще одна проблема. htmlentities () не всегда останавливает xss, например, что если выходные данные находятся внутри тега <script></script> или даже href в этом отношении? mysql_real_escape_string не всегда останавливает инъекцию sql, что если: 'select * from user where id='.mysql_real_escape_string($_GET[id]);. preg_match может исправить эту проблему, но intval () - гораздо лучшая функция для использования в этом случае.

Я ОГРОМНЫЙ поклонник готовых высказываний. Я думаю, что это отличный подход, потому что по умолчанию он безопасен, но передает переменную mysql_real_escape_string () до того, как подготовленный оператор просто повредит данные. Я видел, как новичок исправил эту проблему, удалив все процедуры проверки, таким образом, представляя уязвимость из-за избыточности. Причина и следствие.

Межсетевые экраны веб-приложений (WAF) - отличный пример того, как слои могут повысить безопасность. WAF сильно зависят от регулярных выражений. Они пытаются взглянуть на картину в целом и предотвратить неприятный ввод или, по крайней мере, записать его. Они ни в коем случае не являются серебряной пулей и не должны быть единственной мерой безопасности, которую вы используете, но они останавливают некоторые эксплойты, и я рекомендую установить mod_security на производственных машинах.

...