mrbatman
  • 0
Новичок

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

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

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

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

    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. Плагины должны проверять и дезинфицировать все ненадежные данные перед вводом данных в базу данных и должны избегать всех ненадежных данных перед выводом в поля формы настроек и перед выводом в файлы шаблона темы:

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

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

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

    Хороший учебник по использованию API настроек см.:

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

    • 0
  2. В этом есть два аспекта:

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

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

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

Оставить ответ

You must login to add an answer.