Какие общие недостатки безопасности мне нужно искать? [закрыто]

Как разработчик плагина Wannabe WP, какие основные недостатки / дыры в безопасности я должен искать?

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

Например, является ли очистка данных такой большой проблемой, поскольку она находится в / wp-admin / area? Может ли кто-нибудь вредоносный напрямую зайти на мою страницу плагина и отправить POST-запросы или что-то в этом роде?

Спасибо!

Вот измененный контрольный список, основанный на моих текущих (незавершенных) настройках / контрольном списке безопасности данных, используемых для просмотра Тем (принципы не должны отличаться для плагинов, чем для тем):

1. Плагины должны иметь префикс всех опций, пользовательских функций, пользовательских переменных и пользовательских констант с помощью plugin-slug.

2. Плагины должны реализовывать страницы «Параметры плагинов» и «Настройки плагинов» преднамеренно, а не полагаться на сценарии копирования и вставки из учебных пособий веб-сайтов, таких как приведенные ниже, которые устарели и не включают надлежащую защиту данных:

   • http://www.1stwebdesigner.com/wordpress/how-to-create-an-options-page-for-your-wordpress-theme/
   • http://wpshout.com/create-an-awesome-wordpress-theme-options-page-part-1

3. Плагины должны использовать add_options_page()функцию добавления страницы настроек плагинов в Settingsменю, а не использоватьadd_menu_page() добавлять меню верхнего уровня.

4. Плагины должны использовать соответствующие возможности (например,manage_options ) для возможности добавления страницы настроек.

5. Плагины должны сохранять параметры в одном массиве, а не создавать несколько параметров для страницы настроек. Использование API настроек (см. Ниже) справится с этим.

6. Плагины должны использовать API настроек (см. Ниже) для получения и сохранения входных данных формы, а не полагаться на них $_POSTи $_REQUESTданные напрямую.

7. Для флажков и выбора опций, плагины должны использовать checked()и selected()функцию для вывода checked="checked"иselected="selected" , соответственно.

8. Плагины должны проверять и дезинфицировать все ненадежные данные перед вводом данных в базу данных, а также избегать всех ненадежных данных перед выводом в поля формы «Настройки» и перед выводом в файлы шаблона темы:

   • http://codex.wordpress.org/Data_Validation

9. Плагины следует использовать esc_attr()для ввода текста и esc_html()(илиesc_textarea() в WP 3.1) для областей.

10. Плагины должны явно обеспечивать одноразовую проверку страницы настроек, если не используется API настроек:

    • http://codex.wordpress.org/WordPress_Nonces

11. Также настоятельно рекомендуется, чтобы плагины использовали API настроек, который проще в использовании, более безопасен и берет на себя большую часть тяжелой работы страниц настроек:

    • http://codex.wordpress.org/Settings_API

Для хорошего руководства по использованию API настроек смотрите:

• http://www.chipbennett.net/2011/02/17/incorporating-the-settings-api-in-wordpress-themes/

• http://planetozh.com/blog/2009/05/handling-plugins-options-in-wordpress-28-with-register_setting/

Если вы хотите проверить тему с помощью защищенной и четко закодированной страницы настроек темы, проверьте эту тему:
http://wordpress.org/extend/themes/coraline

Есть два аспекта этого:

1. Основные принципы.

   • Все, что записано в базу данных, должно быть проверено на SQL-инъекции.
   • Все, что напечатано на экране, должно быть проверено, чтобы оно не печатало вредоносный JavaScript.
   • Всякий раз, когда кто-то что-то делает, следует проверить, что он собирался это сделать, и у него есть соответствующие возможности.
   • Есть много-много других вещей, которые вы или я либо никогда не захотите проверить.

2. Особенности.

   • Современный WordPress серьезно относится к безопасности и стремится облегчить работу разработчиков.
   • Так что для большинства вещей, которые вы хотите сделать, скорее всего, есть способ сделать это с помощью WP API.
   • Так что, чем бы вы ни занимались, ваш первый шаг - это усовершенствовать и изучить соответствующий API.
   • Чем дальше вы от обычной и простой функциональности, тем более сложные вещи вам нужно будет изучить и реализовать.

1. добавлять defined('ABSPATH') or die('Access denied'); в каждый плагин скрипт, который используется WordPress напрямую
2. Добавить пустой файл index.php в каждый каталог
3. Добавьте .htaccess в каталог плагинов с необходимыми инструкциями для предотвращения прямого доступа к файлам некоторых плагинов.