Intereting Posts
Пользовательские поля не отображаются на моей странице блога WP + Google analytics = / search? Есть ли способ установить отношения родителя / ребенка в ссылках только в меню WP? Отключить раздел «Blogroll» или «WordPress Dashboard News» в WordPress v.4.1? Как получить вложенный запрос только для отображения содержимого, которое выводит основной запрос Как получить только определенное количество изображений из сообщения (за вычетом выделенного изображения)? Как проверить правильность строки? Получение пути хранения изображений конвертировать из одного сайта в многосайтовый (сетевой) с существующими субдоменами Остановить `update_post_meta` работу с каждой страницей обновляется? Установка почтовых метаданных в случайное значение во время перехода статуса должности / публикации Загрузка содержимого WordPress в другом домене Безопасно ли использовать Web Invoice 2.1.0 без SSL? Редактировать выбранные категории в Admin Перенос перенаправленных адресов на локальный хост после успешного входа в систему

Передовая практика проверки и санитаризации данных

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

Для обработки данных я подключаюсь к init и использую следующую функцию;

 function mh_post_actions() { if ( isset( $_POST['mh_action'] ) ) { do_action( 'mh_' . sanitize_text_field( $_POST['mh_action'] ), $_POST ); } } // mh_post_actions add_action( 'init', 'mh_post_actions' ); 

Затем валидация и дезинфекция происходят в результирующих функциях, подключенных к mh_* .

Однако недавно я принял решение опубликовать плагин через репо WordPress.org.

При проверке мой код был отклонен, указав, что в соответствии с руководящими принципами мне необходимо проверить и дезинформировать данные до того, как будет выполнена обработка WordPress.

Это хорошо, но, как уже упоминалось, данные могут быть любыми, массивами, int, str, url, электронной почтой и т. Д. …

Я хотел бы сохранить функцию, которая у меня есть, поскольку она хорошо работает для меня, поэтому задался вопросом, есть ли более простой способ для дезинфекции общих данных $ _POST, которые я мог бы добавить к вышеуказанной функции, чтобы соответствовать рекомендациям?

Входы должны быть проверены / дезинформированы, прежде чем принимать решение о потоке выполнения на основе этого. На самом деле +100 рецензенту, который его поймал (или кто писал автоматический инструмент), как я бы пропустил его.

Санитация – это то, что требует контекста. Просто потому, что функция A выполняет санитацию в контексте хранения отображаемого текстового ввода, не делает его подходящим для использования в контексте потока выполнения.

В вашем конкретном случае «враждебное» может инициировать любой крючок, который начинается с «mh_», отправив специальное заданное значение в поле mh_action . Что нужно проверить перед запуском любого действия, так это то, что значение является одним из тех, которые вы ожидаете получить из своей формы.

 If (in_array($_POST['mh_action'], array('string',int','array'....) do_action('mn_'.$_POST['mh_action'],$_POST); 

Не уверен, что этого будет достаточно для группы обзора, но это будет (более) безопасный код.

Первая проблема, которую я вижу с вами, заключается в том, что вы предполагаете, что $_POST['mh_action'] – это строка, исходящая от $_POST вы никогда не можете быть уверены, что это правда.

И если это массив, вы не можете сделать sanitize_text_field( $_POST['mh_action'] ) не вызывая ошибки.

Вторая проблема заключается в том, что do_action ничего не возвращает. Это означает, что вы меняете супер глобальный $_POST напрямую, что я настоятельно рекомендую вам избежать.

Одна из многих причин заключается в том, что часть кода, обрабатывающего данные, должна будет иметь доступ к $_POST и даже если вы дезинформируете использование этого действия, глядя только на код, который использует данные, это не будет неясным.

Более того, какой-то другой код (возможно, злонамеренный, может быть, и нет) всегда может remove_action( 'mh_foo' ) и ваше поле «foo» никогда не будет экранировано, поэтому код, который $_POST['mh_foo'] к $_POST['mh_foo'] и обрабатывает его, будет обрабатывать потенциально опасные данные.

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

Просто доказательство концепции:

 function mh_post_action() { $action = isset($_POST['mh_action']) ? $_POST['mh_action'] : ''; if ( ! $action ) { return; } $validated_action = mh_post_action_validate( $action ); if ( ! $validated_action ) { // handle the error return; } mh_post_action_process( $validated_action ); } function mh_post_action_validate( $action ) { // as example I'm validating it is a string that starts with "mh_" if ( is_string( $action ) && strpos( $action, 'mh_' ) === 0 ) { return $action; } return ''; } function mh_post_action_process( $action ) { $sanitized_action = sanitize_text_field( $action ); // process sanitized_action here } add_action( 'init', 'mh_post_action' ); 

Теперь, если я посмотрю на mh_post_action я могу ясно видеть, что данные, поступающие из $_POST , проверяются, и я могу ясно видеть, что mh_post_action_process() дезинформирует данные, прежде чем что-либо делать с ним.

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