В каких контекстах используются плагины, ответственные за проверку / санитарию данных?

Я хочу убедиться, что все данные в моих плагинах / темах безопасно обрабатываются перед входом в базу данных и перед их выходом в браузер. Моя проблема заключается в том, что существуют ситуации, когда API обрабатывает санитацию для вас – например, при сохранении почтовых мета-полей – и других, где автор плагинов / тема несет полную ответственность за это – как при сохранении пользовательских настроек.

Для области этого вопроса меня не интересует проверка данных на уровне домена – например, проверка того, что поле Возраст в форме находится между 0 и 120 или что адрес электронной почты действителен. Я беспокоюсь только о безопасности – например, избегаю SQL-запросов, чтобы избежать SQL-инъекций при сохранении в базе данных или дезинформировать данные, которые выводятся в HTML-шаблоны, чтобы избежать XSS.

Для дезактивации продукта я знаю, что вам всегда нужно использовать такие функции, как esc_html() и esc_attr() при переходе переменных в HTML-шаблоны. Но как насчет использования тегов шаблонов ? Они все уже санируют выпуск? Если да, для какого контекста (общий HTML, атрибуты тегов и т. Д.)? Некоторые функции имеют варианты для разных контекстов (например, the_title_attribute() , но большинство нет.

Для ввода санитарии я знаю, что мне нужно использовать $wpdb->prepare() при выполнении ручных запросов, но как насчет того, когда вы используете API настроек для создания страницы настроек плагина или сохраняете почтовые метаполя для настраиваемого типа сообщений?

Прямо сейчас я только что копал Core и читал учебники каждый раз, когда я использую функцию, чтобы выяснить, является ли она оздоравливаемым или нет, но это подвержено ошибкам и занимает много времени. Я надеюсь найти какой-то исчерпывающий список всех возможных ситуаций и будет ли API обрабатывать его. например,

API проверяет / санирует

  • Сохранение метаданных сообщений с помощью update_postmeta()
  • Сохранение метафайла пользователя с помощью update_user_meta()
  • Вывод заголовка сообщения – используйте контекстно- the_title() вариант the_title()
  • и т.д

Вы должны вручную проверить / дезинформировать

  • Сохранение параметров плагина с помощью API настроек. Передайте обратный вызов в качестве третьего параметра register_setting() .
  • Прямые запросы к базе данных: $wpdb->prepare() запрос в $wpdb->prepare() .
  • Вывод переменных в HTML. Используйте esc_attr() , esc_html() и т. Д.
  • и т.д

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

Solutions Collecting From Web of "В каких контекстах используются плагины, ответственные за проверку / санитарию данных?"

Здесь есть две концепции:

  • validation – убедитесь, что данные действительны , т.е. целое число является целым числом, дата – это дата (в правильном формате и т. д.). Это нужно сделать непосредственно перед сохранением данных.
  • санитария – обеспечение безопасной даты для ее использования в текущем контексте (например, экранирование SQL-запросов или выход HTML на выходе).

Валидация, почти повсеместно, исключительно для вас . Вы знаете, какие данные вы запрашиваете у пользователя, и знаете, какие данные вы ожидаете – WordPress этого не делает. Проверка будет выполняться, например, в save_post перед тем, как сохранить его в базе данных с помощью update_post_meta , или это может быть сделано путем указания функции обратного вызова в API настроек, вызываемой непосредственно перед тем, как WordPress сохраняет данные.

Санитация немного более неоднозначна. Когда вы работаете с данными, которые WordPress знает изначально (например, плита сообщения), вы можете быть уверены, что WordPress уже сделал данные безопасными. Однако «безопасный» зависит от контекста; что безопасно для использования на странице, не обязательно безопасно как атрибут элемента. Следовательно, WordPress будет иметь разные функции для разных контекстов (например, the_title() , the_title_rss() , the_title_attribute() ), поэтому вам нужно использовать правильный .

По большей части ваш подключаемый модуль может обрабатывать метаданные сообщений или, возможно, данные о событиях из пользовательской таблицы. WordPress не знает, для чего эти данные или для чего это необходимо, поэтому он определенно не знает, как сделать это безопасным. Это зависит от вас . Это особенно важно при использовании esc_url() , esc_attr() , esc_textarea() т. Д., Чтобы предотвратить проникновение вредоносного ввода в код. Поскольку WordPress знает, что next_posts() предполагает напечатать URL-адрес страницы, он применяет esc_url() – но с esc_url() сообщения, скажем, он не знает, что он хранит URL-адрес или что вы хотите с ним делать (если esc_url() , esc_url() , если перенаправление esc_url_raw() . Если в dobut – ошибаться на стороне осторожности и убежать от него самостоятельно – и делать это как можно позже.

Наконец, как насчет сохранения данных? Вам нужно сделать это безопасным? Как уже упоминалось, вам необходимо убедиться, что данные действительны. Но если вы используете WordPress API ( wp_insert_post() , update_post_meta() т. Д.), Вам не нужно дезинфицировать данные, потому что при сохранении данных единственная дезинфекция, которую вы должны выполнять, – это избегать операторов SQL – и WordPress делает это. Если вы используете прямые инструкции SQL (скажем, для чтения / записи данных из пользовательской таблицы), вы должны использовать класс $wpdb чтобы помочь вам дезинформировать ваши запросы.

Я написал это сообщение в блоге о санитарной обработке данных и проверке, которые могут оказаться полезными – в этом я расскажу о том, что от вас ожидается в этом отношении.

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

Это более оптимальная практика для программирования PHP, чем WordPress.

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

Если бы я был слишком расплывчатым, задайте более конкретный вопрос.