Используя Wordpress, может ли кто-нибудь сказать мне лучший способ дезинфекции ввода?

Я разрабатываю приложение, используя Wordpress как CMS.

У меня есть форма с большим количеством полей ввода, которые необходимо очистить перед сохранением в базе данных.
Я хочу предотвратить SQL-инъекцию, используя javascript и PHP-код и другой вредоносный код.

В настоящее время я использую свои собственные методы для дезинфекции данных, но я считаю, что лучше использовать функции, которые использует WP.

Я просмотрел Проверка данных в Wordpress, но я не уверен, сколько из этих функций я должен использовать, и в каком порядке, Кто-нибудь может сказать, какие функции WP лучше всего использовать?

В настоящее время я "дезинфицирую" свой ввод, выполняя следующие действия:

Поскольку персонажи с акцентами (é, ô, æ, ø, å) были загружены смешно в базе данных (хотя мои таблицы имеют значения ENGINE=InnoDB, DEFAULT CHARSET=utf8 и COLLATE=utf8_danish_ci), Теперь я конвертирую поля ввода, которые могут иметь акценты, используя htmlentities().
При создании строки SQL для ввода данных я использую mysql_real_escape_string().

Я не думаю, что этого достаточно, чтобы предотвратить атаки. Поэтому очень ценятся предложения по улучшению.

Ответ 1

Ввод "санитария" является фиктивным.

Вам не следует пытаться защитить себя от проблем с инъекциями путем фильтрации (*) или выхода из строя, вы должны работать с необработанными строками до тех пор, пока вы не поместите их в другой контекст. В этот момент вам понадобится правильная функция экранирования для этого контекста, которая mysql_real_escape_string для запросов MySQL и htmlspecialchars для вывода HTML.

(WordPress добавляет свои собственные функции экранирования, такие как esc_html, которые в принципе не отличаются.)

(*: ну, кроме требований к конкретным приложениям, например проверка адреса электронной почты, действительно является адресом электронной почты, гарантируя, что пароль является разумным и т.д. Также разумный аргумент для фильтрации управляющих символов на этапе ввода, хотя это редко делается на самом деле.)

Теперь я конвертирую поля ввода, которые могут иметь акценты, используя htmlentities().

Я настоятельно рекомендую не делать этого. Ваша база данных должна содержать необработанный текст; вам намного сложнее выполнять операции с базами данных в столбцах, если вы закодировали его как HTML. Вы избегаете символов, таких как < и " одновременно с символами, отличными от ASCII. Когда вы получаете данные из базы данных и используете их по какой-то другой причине, кроме копирования на страницу, теперь у вас появились ложные HTML-экраны в данных. Не берите HTML-код до последнего момента, когда вы пишете текст на странице.

Если у вас возникли проблемы с получением не-ASCII-символов в базе данных, это другая проблема, которую вы должны решить сначала, вместо того, чтобы искать неустойчивые обходные пути, такие как хранение данных в формате HTML. Здесь есть несколько сообщений о том, как заставить PHP и базы данных правильно говорить UTF-8, но главное, чтобы ваши выходные страницы HTML правильно служили UTF-8, используя заголовок Content-Type header/meta. Затем проверьте, что ваше соединение MySQL установлено на UTF-8, например, используя mysql_set_charset().

При создании строки SQL для ввода данных я использую mysql_real_escape_string().

Да, это правильно. Пока вы это делаете, вы не уязвимы для SQL-инъекций. Вы можете быть уязвимы к HTML-инъекции (вызывая XSS), если вы используете HTML-экранирование в конце базы данных, а не в конце вывода шаблона. Поскольку любая строка, которая не прошла через базу данных (например, полученную непосредственно из $_GET), не будет экранирована с помощью HTML.