Безопасность входных данных пользователя PHP

Я согласен с mikikg в том, что вам нужно понимать уязвимости SQL-инъекций и XSS, прежде чем пытаться защитить приложения от подобных проблем.

Однако я не согласен с его утверждениями об использовании регулярных выражений для проверки пользовательского ввода в качестве средства предотвращения SQL-инъекций. Да, проверяйте ввод пользователя, насколько это возможно. Но не полагайтесь на это для предотвращения инъекций, потому что хакеры довольно часто взламывают такие фильтры. Кроме того, не будьте слишком строги со своими фильтрами — множество веб-сайтов не позволяют мне войти в систему, потому что в моем имени есть апостроф, и позвольте мне сказать вам, что это головная боль **, когда это происходит.

В своем вопросе вы упоминаете два вида проблем с безопасностью. Во-первых, это SQL-инъекция. Эта уязвимость является «решенной проблемой». То есть, если вы используете параметризованные запросы и никогда не передаете предоставленные пользователем данные как что-либо, кроме параметра, база данных будет делать «правильные вещи» для вас, что бы ни случилось. Для многих баз данных, если вы используете параметризованные запросы, нет возможности внедрения, потому что данные фактически не отправляются встроенными в SQL — данные передаются без экранирования в префиксе длины или подобном большом двоичном объекте по сети. Это значительно более эффективно, чем функции выхода из базы данных, и может быть безопаснее. (Примечание: если вы используете хранимые процедуры, которые генерируют динамический SQL в базе данных, у них также могут быть проблемы с внедрением!)

Вторая проблема, которую вы упомянули, — это проблема межсайтового скриптинга. Если вы хотите разрешить пользователю предоставлять HTML без предварительного экранирования объекта, эта проблема является открытым вопросом исследования. Достаточно сказать, что если вы разрешаете пользователю передавать некоторые виды HTML, вполне вероятно, что ваша система в какой-то момент столкнется с проблемой XSS для решительного злоумышленника. В настоящее время современным решением этой проблемы является «фильтрация» данных на сервере с использованием таких библиотек, как HTMLPurifier. Злоумышленники могут регулярно взламывать эти фильтры; но пока никто не нашел лучшего способа защитить приложение от подобных вещей. Возможно, вам будет лучше разрешить только определенный белый список HTML-тегов и кодирование всего остального.

Это одна из самых проблемных задач на сегодняшний день :)

Вам нужно знать, как работают SQL-инъекции и другие методы злоумышленников. Очень подробное объяснение каждого метода есть в https://www.owasp.org/index.php/Main_Page, а также вся система безопасности для PHP.

Использование определенных библиотек безопасности из некоторых фреймворков также является хорошим выбором, например, в CodeIgniter или Zend.

Затем используйте REGEXP настолько часто, насколько это возможно, и придерживайтесь шаблонных правил для определенного формата ввода.

Используйте подготовленные операторы или класс активных записей вашего фреймворка.

Всегда вводите ввод с помощью (int)$_GET['myvar'], если вам действительно нужны числовые значения.

Существует так много других правил и методов для защиты вашего приложения, но есть одно золотое правило: «никогда не доверяйте вводу пользователя».

В вашей конфигурации php параметр magic_quotes_gpc должен быть отключен. Так что stripslashes вам не понадобится.

Для SQL взгляните на подготовленные операторы PDO.

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