Intereting Posts
Обновление до версии 4.5 натолкнуло мой виджет «главной боковой панели» на место Отображать содержимое из настраиваемых мета-полей в версиях Функции WP в .js Как вернуть строку с переменной внутри в коротком коде? Постоянная ссылка не работает с Vagrant Как добавить CSS-класс в previous_post_link или получить URL-адрес предыдущего / следующего сообщения Создать форму поиска для фильтрации через термины В WordPress Network (multisite), Sub Блоги в подкаталогах или поддоменах? Что лучше? Пользовательские данные пользовательской таксономии не сохраняются на экране редактирования Как перенести сайт Multi на отдельный сайт? Добавление пользовательского Javascript в заголовок в Admin Запросить страницы и выложить выдержки динамически Невозможно опубликовать собственный тип сообщений – «Вы не можете редактировать этот пост». Определите, является ли страница страницей сообщений Заказ по наиболее используемому тегу

Безопасность в разработке плагинов WordPress

Мой плагин – Mailer.app для WordPress, я на 85% завершен, и я сосредоточен на безопасности перед выпуском. Перед вопросами я должен описать архитектуру плагинов:

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

  • Могут ли другие плагины получить доступ к моему коду плагина? например, require("../plugins/mail/class.client.php') и вызвать new Client() ? Если да, то каким образом я могу предотвратить его и почему это разрешено?
  • Может ли другой плагин считывать содержимое файла, поскольку я храню ключ шифрования в классе Client ? Если это так, вы можете порекомендовать место для хранения, чтобы только доступ к этому классу был доступен только классу Client() этого плагина?
  • Я использую current_user_can() и nonces но этого достаточно для добавления достаточной безопасности для AJAX? может ли истец истекать? и где я больше читаю о них, связанных с безопасностью, ajax и веб-приложениями.
  • Может ли multisite создать любые проблемы с добавлением из моего сценария ?.

Давайте посмотрим пример моего кода:

class.client.php

 final class Client { const SALT = "bsas8D889b8989sHBsd"; // hash salt const EKEY = "23123asdas9dsbbad96"; // db encryption key const CKEY = "b797a78skj15hjhHJDa"; // cookie encryption key private static function GetUserData(){ return $this->decrypt_data() } public static function StoreUserData($data){ return $this->validate_and_store(); } public static function GetEmails(){ return $this->show_emails($this->GetUserData()); } } 

class.admin.php

 final class Admin { public function __construct(){ add_menu_page('mlr', 'mlr', 'manage_options', 'mlr', array($this,'admin_page')); } public function admin_page(){ $user = new Client(); echo $user->GetEmails(); } } 

Какова моя конечная цель: другие плагины заражаются (бэкдор и т. Д.) Или нет, не могут получить доступ к username / password / mail моего письма, что является основной частью вопроса. Пользовательские данные, которые зашифрованы и хранятся в базе данных, могут быть дешифрованы только с использованием файлов Cookie и $key ; $key является уязвимым элементом.

Извините за добавочный длинный пост, но мне нужно получить эти вопросы о моей груди и, надеюсь, прочесть и помочь.

благодаря

Solutions Collecting From Web of "Безопасность в разработке плагинов WordPress"

Какова моя конечная цель: другие плагины заражаются (бэкдор и т. Д.) Или нет, не могут получить доступ к username / password / mail моего письма, что является основной частью вопроса.

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

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

Могут ли другие плагины получить доступ к моему коду плагина? например require("../plugins/mail/class.client.php') и вызвать new Client() ?

Да.

Если это так, […] почему это разрешено?

Это не «разрешено», поскольку это следствие интерпретируемых сценариев. «Расширение WordPress» с темами и плагинами – это просто – это изменение исполнения WordPress с использованием исходного источника для достижения желаемого результата. Я не знаю ни одного интерпретируемого языка, который фактически обеспечивает надежные механизмы «блокировки» частей исходного сценария из других частей внутри одной и той же базы кода. Операционные системы, конечно.

Скорее эта ответственность ложится на среду исполнения и тех, кто ее контролирует.

Как я могу предотвратить это?

Возможно, можно добиться использования какого-то серьезного сложного песочного бокса и выполнения разных частей WordPress в разных потоках, но это совсем не то, как WordPress разработан, и для загрузки потребуется переконфигурация тяжелой среды. Даже в этом случае он по-прежнему будет восприимчив к нескольким атакам – несмотря на то, что JavaScript-песочный песок Google Chrome, вредоносный код по-прежнему способен преодолеть эти меры.

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

Если потребители вашего плагина не смогут должным образом защитить свои установки WordPress или установить скомпрометированный код, нет никакой части файловой системы или базы данных, которые могут считаться «безопасными» для хранения важной информации. Точно так же, как если бы вирус обнаружил, что это на вашем компьютере, никакая программа или документ не могут быть доверены, чтобы оставаться неподтвержденными или неэкспонированными – если вы храните пароли в текстовом файле, вы должны предположить, что все соответствующие учетные записи скомпрометированы или уязвимы. Здесь, как и везде в мире безопасности ИТ, пользователи не должны устанавливать исполняемые файлы, которым они не доверяют или не понимают, – те, у кого нет хорошей основы для дифференциации надежных или хорошо реализованных программ, должны иметь ограниченную способность приобретать и / или установите такие элементы.

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

Может ли другой плагин считывать содержимое файла, поскольку я храню ключ шифрования в классе Client?

Да. Фактически, любой плагин мог бы проанализировать файл wp-config.php установки WordPress и получить информацию о базе данных и соли, если это будет желание автора. Дело в том, что плагин не должен даже делать это, чтобы скомпрометировать установку, поскольку среда PHP и WordPress уже предоставляет плагинам, что позволяет свободно управлять файловой системой и файловой системой, чтобы достичь своих целей, насколько позволяют база данных и файловая система. Без этих возможностей плагины были бы крайне ограниченными по охвату.

Если это так, вы можете порекомендовать место для хранения, чтобы только доступ к этому классу был доступен только классу Client () этого плагина?

Нет. Учетные данные, хранящиеся и / или передаваемые в виде обычного текста, никогда не являются полностью «безопасными», периодами.

Если вашему приложению требуется такое хранение / передача, учетные данные могут быть настолько безопасными, как среда, в которой они хранятся. Вы можете добавить дополнительные обручи для обфускации учетных данных, но факт остается фактом: если в вашем коде есть все необходимое для дешифрования учетных данных, тогда также и любой другой код в среде. Это по сути то же самое, что хранить зашифрованный файл, содержащий пароли на вашем компьютере, вместе с скриптом оболочки, который дешифрует файл сразу после его выполнения. Лучший способ сохранить их безопасность – это защита окружающей среды.

Я использую current_user_can() и nonces, но этого достаточно для добавления достаточной безопасности для AJAX?

Это зависит от особенностей вашего приложения и того, что передается через AJAX. Как правило, эти механизмы при правильной реализации достаточны для проверки того, что запросы AJAX производятся из постоянного источника. Однако они сами по себе являются лишь компонентом безопасности AJAX. Как общие правила:

  • Не предпринимайте никаких действий, пока запрос не будет «достаточно» проверен, включая использование current-user_can() , check_ajax_referer()
  • Побег, проверка и дезинфекция всего, что содержит динамические данные. Эти методы необходимы для предотвращения инъекций SQL, произвольного выполнения PHP и доставки вредоносного JavaScript посетителям. Это включает в себя данные $_GET , $_POST и $_COOKIE а также все, что извлекается из базы данных, которая будет оцениваться как PHP или отправлена ​​в браузер. Узнайте, какие функции WordPress обрабатывают задачи для вас, но когда вы сомневаетесь, выполняйте их самостоятельно, пока не сможете быть уверены.
  • Если вы контролируете серверную среду, закрепите свой сайт сертификатом SSL и работайте по протоколу HTTPS, чтобы уменьшить шансы на атаки «человек в середине» ( проект Let's Encrypt на его пути к бесплатному предоставлению надежных сертификатов ).
  • Убедитесь, что ваша обработка ошибок реализована таким образом, что, если ваш серверный скрипт дросселирует или получает доступ непосредственно клиентом, никакие конфиденциальные данные не отбрасываются обратно в браузер.

Может ли истек срок действия?

Да. Для этой цели WordPress предоставляет фильтр nonce_lifetime . По умолчанию WordPress nonce действует в течение 12-24 часов.

Может ли многопользовательский создать любые проблемы с добавлением из моего сценария?

Это зависит от того, как установлен ваш плагин, и вы намерены использовать его в многопользовательской среде – потенциальные «проблемы», которые могут возникнуть, могут быть действительно желательными результатами в зависимости от того, для чего вы стреляете.

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