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

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

14 голосов
/ 24 января 2010

Я разрабатываю приложение, используя 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().

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

1 Ответ

16 голосов
/ 24 января 2010

Ввод «дезинфекции» является поддельным.

Вы не должны пытаться защитить себя от проблем с внедрением, фильтруя (*) или избегая ввода, вы должны работать с необработанными строками до тех пор, пока вы не поместите их в другой контекст. На этом этапе вам нужна правильная функция экранирования для этого контекста, которая составляет 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.

...