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

Question

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

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

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

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

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

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

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

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

Answer 1

Ввод "санации" является поддельным.

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

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

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

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

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

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

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

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