Я разрабатываю приложение, использующее WordPress в качестве CMS.
У меня есть форма с большим количеством полей ввода, которые необходимо очистить перед сохранением в базе данных.
Я хочу предотвратить SQL-инъекцию, используя javascript и PHP-код и другой вредоносный код.
В настоящее время я использую свои собственные методы для дезинфекции данных, но я считаю, что лучше использовать функции, которые использует WP.
Я посмотрел на Data Validation в WordPress, но я не уверен, сколько из этих функций я должен использовать и в каком порядке. Может ли кто-нибудь сказать, какие функции WP лучше всего использовать?
В настоящее время я «дезинфицирую» свой вклад, выполняя следующие действия:
Потому что персонажи с акцентами (é, ô, æ, ø, å) были загружены забавным способом в базе данных (хотя мои таблицы установлены как ENGINE=InnoDB , DEFAULT CHARSET=utf8 и COLLATE=utf8_danish_ci ), теперь я конвертируя поля ввода, которые могут иметь акценты, используя htmlentities ().
При создании строки SQL для ввода данных я использую mysql_real_escape_string() .
Я не думаю, что этого достаточно, чтобы предотвратить атаки. Поэтому предложения по улучшению очень ценятся.
Ввод «санитария» является фиктивным.
Вам не следует пытаться защитить себя от проблем с инъекциями путем фильтрации (*) или выхода из строя, вы должны работать с необработанными строками до тех пор, пока вы не поместите их в другой контекст. В этот момент вам понадобится правильная функция экранирования для этого контекста, которая представляет собой 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 . Затем проверьте, что ваше соединение MySQL установлено на UTF-8, например, с помощью mysql_set_charset() .
При создании строки SQL для ввода данных я использую mysql_real_escape_string ().
Да, это правильно. Пока вы это делаете, вы не уязвимы для SQL-инъекций. Вы можете быть уязвимы к HTML-инъекции (вызывая XSS), если вы используете HTML-экранирование в конце базы данных, а не в конце вывода шаблона. Поскольку любая строка, которая не прошла через базу данных (например, полученную непосредственно из $_GET ), не будет экранирована с помощью HTML.