Рекомендации по безопасности для разработчиков плагинов и тем WordPress

Опубликовано: 2020-12-09

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

Эти советы основаны на моем опыте разработки плагинов в CleverPlugins и помощи бесчисленному количеству клиентов в восстановлении их веб-сайтов после взлома. Разработка плагина безопасности, такого как WP Security Ninja, не сделала меня менее параноидальным по отношению к чужому коду.

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

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

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

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

А как насчет группы проверки WordPress.org?

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

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

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

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

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

1. Думайте о безопасности со всех сторон!

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

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

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

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

Это звучит параноидально? Может быть. Но, если и когда ваш плагин или тема станут суперпопулярными, вы будете рады параноидальному подходу к безопасности.

Если и когда ваш плагин или тема станут суперпопулярными, вы будете рады параноидальному подходу к безопасности.

2. Предотвращение XSS-атак — межсайтовых сценариев

Это становится все более и более важным, поскольку WordPress становится все более ориентированным на внешний интерфейс проектом с Gutenberg и ReactJS.

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

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

Хакер попытается отправить комментарий с помощью "<script>alert('XSS');</script>" .

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

Мы можем предотвратить это с помощью проверки, очистки и экранирования.

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

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

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

Давайте рассмотрим тот же простой пример, который мы использовали ранее: "<script>alert('XSS');</script>"

Если мы ничего не сделаем с этим кодом, браузер будет думать, что это HTML-код. Важной деталью здесь являются символы < >, которые используются для определения HTML-тегов. Избегая их, мы превращаем < в &lt; и > в &gt; Браузер теперь понимает, что это не настоящий HTML-код, и вместо этого он должен просто отображать знак «меньше» и «больше».

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

3. Будьте осторожны с SQL-инъекциями

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

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

SQL-инъекция — это старый способ атаки на веб-сайт, но он по-прежнему очень эффективен, и многие люди ищут способы использовать эту форму атаки. В октябре 2020 года популярный плагин Loginizer для WordPress объявил, что у него есть уязвимость SQL-инъекций, которая поставила под угрозу более миллиона веб-сайтов.

В 2019 году неизвестные хакеры украли миллионы налоговых данных болгар с помощью SQL-инъекций, а в 2016 году группа российских хакеров извлекла информацию об избирателях примерно 500 000 человек в Огайо. Эти виды атак по-прежнему очень эффективны, и вы можете найти много информации о них.

Комикс о очистке входных данных

Источник: https://xkcd.com/327/

Чаще всего SQL-инъекция происходит в поле формы, которое принимает пользовательский ввод, например, имя. Атака происходит путем ввода частей кода SQL в поля ввода, создавая пользовательский запрос, дающий результат, отличный от ожидаемого.

Допустим, у вас есть форма, которая позволяет людям искать определенное имя.

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';

В этом простом примере будут выбраны все строки из метатаблицы сообщений со всеми строками, которые имеют имя Henry и определенный ключ, celebrity_name — таким образом, мы не возвращаем всю базу данных, а только определенные строки, которые нам нужны.

Злоумышленник попытается проанализировать другое значение, например 'Henry' OR 1=1--

Теперь запрос будет возвращать все строки с нашим конкретным значением или что-то еще, поскольку OR 1=1 в SQL всегда верно.

Однако становится еще хуже. Наш SQL-запрос запрашивал только результаты, в которых meta_key соответствует конкретному значению, которое мы ищем, поэтому мы не будем возвращать все. Это должно ограничить влияние атаки SQL-инъекцией, верно?

Ну, не так. В SQL двойное тире является индикатором комментария, поэтому все, что идет после него, комментируется.

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';

Это означает, что запрос выглядит так:

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1

Теперь запрос по существу возвращает все в этой таблице базы данных.

Это был просто простой пример. Есть много более сложных способов доступа к большей части, если не ко всей информации в базе данных. Злоумышленник сможет попробовать слепые атаки SQL-инъекций, что означает запуск кода в вашей базе данных — добавление нового администратора, удаление всех ваших данных и так далее.

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

Простой и эффективный способ — послать апостроф ' в качестве входных данных и посмотреть, изменится ли что-нибудь, возникнет ли ошибка или будет возвращено больше результатов.

WordPress в помощь

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

Класс $wpdb в WordPress обладает всеми функциями CRUD, необходимыми для безопасного взаимодействия с базой данных, и вы даже можете использовать этот класс для взаимодействия с собственными таблицами базы данных, если ваш плагин или тема нуждаются в этом.

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

Самое важное, что вы можете сделать для решения проблемы, — это подготовить данные с помощью функции $wpdb->prepare() .

Эта функция принимает подготовленную строку запроса и массив аргументов, которые вы хотите добавить в запрос SQL.

$meta_key = 'celebrity_name';
$meta_val = 'Henry'
$allhenrys = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM $wpdb-&gt;postmeta WHERE meta_key = %s AND meta_value = %s",
    $meta_key,
    $meta_val
  )
);

Вся работа происходит внутри функции prepare() . Первый параметр, подготовленный запрос, содержит заполнитель %s вместо фактических значений. Это заменяется другими анализируемыми переменными, $meta_key и $meta_val .

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

Это упрощенный пример, но тот же процесс можно использовать для любого запроса к базе данных, и вы можете использовать %s для строк, %d для целых чисел и %f для чисел с плавающей запятой.

Существуют также функции для конкретных ситуаций, например, для добавления новой строки в базу данных. Для этого вы можете использовать $wpdb->insert() .

$wpdb->insert(
  "{$wpdb->prefix}my_custom_table",
  array(
    'name'   => 'Henry',
    'userid' => 123,
    'score'  => 10,
  ),
  array(
    '%s',
    '%d',
    '%d',
  )
);

Использование функции подготовки может помочь предотвратить большинство попыток SQL-инъекций для вашего продукта.

Пожалуйста, не забудьте проверить документацию $wpdb. Некоторые функции избегают ввода для вас; другие ожидают, что вы сами избежите ввода, прежде чем анализировать данные для функции.

4. Используйте одноразовые номера для защиты ваших запросов

Использование системы nonce в WordPress может помочь вам предотвратить множество атак. С точки зрения безопасности одноразовый номер — это число, используемое только один раз. Идея состоит в том, чтобы добавить этот уникальный номер ко всем запросам, которые вы отправляете из своего кода в установку WordPress, чтобы убедиться, что этот запрос является законным.

Это немного похоже на секретный пароль, который нужно сообщить вышибале, чтобы попасть в клуб.

Однако одноразовые номера в WordPress немного отличаются — они не являются ни числом, ни одноразовым одноразовым номером.

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

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

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

На примере всегда немного проще, поэтому давайте рассмотрим простой способ загрузки файла .js в ваш плагин, выполнив следующие действия:

Использование одноразовых номеров в плагине WordPress

add_action('wp_enqueue_scripts', 'load_my_plugin_script');

function load_my_plugin_script() {
  // Register the script with all details and ensures it is loaded after jQuery
  wp_register_script('secure-plugin', plugin_dir_url( __FILE__ ). 'js/secure-plugin.js', array( 'jquery' ) );

  // Here happens the magic, we add some details to an object that we can later reference and read from in our JS code.
  wp_localize_script(
    'secure-plugin',
    'plugin_ajax_object',
    array(
      'nonce' => wp_create_nonce('secure-plugin-nonce')
    )
  );

  // Once that is done, we can now enqueue the script
  wp_enqueue_script('secure-plugin');
}

В этой функции мы говорим WordPress загрузить файл JavaScript. Во-первых, мы регистрируем файл, который хотим загрузить, с помощью wp_register_script() .

Затем мы используем wp_localize_script() для анализа массива данных, в частности «одноразового номера», который содержит уникальный одноразовый номер, который мы хотим использовать в нашем коде JS. Помните, что вы также можете отправлять любую другую информацию в этом массиве, но в этом примере мы просто упростили ее.

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

Использование одноразового номера из плагина WordPress в файле JavaScript

jQuery(document).ready(function($) {
  $.ajax({
    url: ajaxurl, // WP variable, contains URL pointing to admin-ajax.php
    type: 'POST',
    data: {
      'action':      'get_custom_data',
      '_ajax_nonce': plugin_ajax_object.nonce,
      'user_data':   'Some input from a user'
    },
    success: function( response ) {
      // Here we do what happens if all is good - update the interface with a success message!?
    },
    error: function( response ) {
      // Whooops, something went wrong!
      // console.log(response);
    }
  });
});

Поскольку мы использовали wp_localize_script() , мы можем использовать переменную plugin_ajax_object в JavaScript. Мы отправляем одноразовый номер как переменную _ajax_nonce .

Проверяйте и проверяйте одноразовый номер в плагине WordPress из кода JavaScript

add_action('wp_ajax_get_custom_data', 'get_custom_data');

function get_custom_data() {
  // Ready for the magic to protect your code?
  check_ajax_referer('secure-plugin-nonce');

  /**
   * That's it - the check_ajax_referer function verifies the nonce is correct or it dies and stops code execution if it fails.
   *
   * If you want to customize the error handling and perhaps return an error to your JS code, you could change the code to something like:
   * if ( ! check_ajax_referer( 'secure-plugin-nonce', false, false ) ) {    
   *   wp_send_json_error( 'Invalid nonce' );
   * }
   */

  $sanitized_user_data = sanitize_text_field( $_POST['user_data'] );

  // ... continue with the rest of your plugin's function code ...
}

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

Вы можете дополнительно настроить код, чтобы вернуть пользователю конкретную информацию о том, что произошло.

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

Помните, я говорил о том, что никому нельзя доверять? Это подводит нас к еще одному способу защиты вашего кода — очистке.

Подпишитесь и получите бесплатную копию нашей книги

11 проверенных способов увеличить процент успешных споров по кредитным картам на 740%

Поделитесь с другом

Введите адрес электронной почты вашего друга. Мы отправим им только эту книгу по электронной почте, честь скаута.

Спасибо, что поделились

Потрясающе — копия «11 проверенных методов увеличения числа успешных споров по кредитным картам на 740%» была только что отправлена ​​на адрес . Хотите помочь нам распространить информацию еще больше? Продолжайте, поделитесь книгой с друзьями и коллегами.

Спасибо за подписку!

- мы только что отправили Вашу копию «11 проверенных способов увеличить процент успешных споров по кредитным картам на 740%» по адресу .

В письме есть опечатка? нажмите здесь, чтобы изменить адрес электронной почты и отправить снова.

Книжная обложка
Книжная обложка

5. Дезинфекция пользовательского ввода

В предыдущем примере мы включили дополнительный фрагмент данных, отправленный из JS в PHP. Каждый раз, когда вы получаете данные в свой код, вы должны ожидать, что это будет небезопасно.

'user_data':'Some input from a user'

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

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

В этом примере мы использовали функцию sanitize_text_field() , но WordPress поставляется с множеством функций очистки, подходящих для разных типов данных.

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

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

И это подводит меня к следующему совету, с которым столкнулось большинство разработчиков WordPress:

6. Помните, что is_admin() — это не то, что вы думаете

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

Нет, к сожалению нет. Функция is_admin() только определяет, выполняется ли код на стороне администрирования веб-сайта. Он ничего не делает, чтобы определить, выполняется ли ваш код обычным пользователем или администратором.

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

Правильный способ проверить, является ли пользователь администратором, — это проверить возможности пользователя:

  if ( current_user_can( 'activate_plugins' ) ) { 
    // Do your code here
  }

Существуют разные возможности для разных ролей пользователей, поэтому у вас гораздо более детальный контроль. В большинстве случаев 'activate_plugins' — это то, что вам нужно только для администраторов.

Если вы хотите, чтобы и администраторы, и редакторы могли что-то делать, вам следует протестировать возможность 'edit_pages' .

7. Добавьте rel="noopener" или rel="noreferrer" к своим ссылкам.

Ссылки на внешние ресурсы вполне нормальны, и старый метод добавления target="_blank" к этим ссылкам имеет смысл, потому что вы не хотите, чтобы ваши пользователи покидали страницу вашего плагина/темы.

Тем не менее, это открывает вас для того, что называется Tabnabbing. Это проблема безопасности, когда вредоносный код JavaScript может украсть информацию у ваших пользователей, злоупотребив функцией JavaScript window.opener .

Предотвратить это можно просто добавив rel="noopener" к вашим ссылкам. Страница, на которую вы ссылаетесь сегодня, может быть в порядке, но это может измениться в будущем.

rel=noopener означает, что страница, на которую вы ссылаетесь, не может получить доступ к информации или получить какой-либо контроль над вашей страницей.

rel=noreferrer делает то же самое, а также указывает браузеру не передавать никакую реферальную информацию через заголовок Referrer. Добавление rel="noreferrer" означает, что страница, на которую вы ссылаетесь, не знает, откуда пришел ваш посетитель.

Примечание. Эти два свойства не следует путать с rel=nofollow , связанным с SEO.

8. Используйте HTTPS и безопасные токены со сторонними API

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

К счастью, уже существуют стандарты того, как сделать это безопасно; один из них HTTPS. Использование HTTPS представляет собой уровень безопасности, при котором все передаваемые данные шифруются.

Однако для защиты ваших данных от посторонних глаз недостаточно использовать HTTPS.

Как объясняется в этой статье Ars Technica, «HTTPS не означает, что ваши данные защищены, это просто означает, что ваше соединение защищено».

Безопасные токены — JWT

Безопасным стандартом для обработки связи и интеграции API является использование веб-токенов JSON, JWT.

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

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

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

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

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

Хорошим ресурсом, если вы хотите больше узнать о токенах и о том, как они работают, является Introduction to JSON Web Tokens.

9. Не используйте внешние библиотеки из CDN

Хотя может возникнуть соблазн включить любые библиотеки, которые могут вам понадобиться, через cdnjs.com или другие бесплатные глобальные CDN, есть несколько недостатков.

Во-первых, у вас нет контроля над библиотеками и любым вредоносным кодом, проникающим во включаемые вами файлы.

Хотя CDN, как правило, стабильны и быстры по определению, они также подвержены большему количеству атак. Если ваш код основан на JS-библиотеке на атакуемой CDN, то ваш плагин и тема будут загружаться либо очень медленно, либо вообще не загружаться.

Это произошло с веб-сайтом клиента, где общедоступный CDN, который плагин использовал в то время, истек для пользователей в некоторых регионах, что сделало интерфейс непригодным для использования. В конце концов мне пришлось изменить плагин, чтобы вместо него использовать локальную копию JS-скрипта в качестве быстрого исправления.

Использование внешнего стороннего источника также может поставить под угрозу конфиденциальность. CDN сможет регистрировать все IP-адреса ваших пользователей — обязательно ознакомьтесь с политикой GDPR и сообщите об этом своим клиентам.

В целом, если вы используете авторитетных сторонних поставщиков CDN, у вас не возникнет никаких проблем, но самый простой и надежный подход — распространять JS-библиотеку, включенную в ваш продукт.

Вы знали? WordPress поставляется с несколькими библиотеками JS. Многие из наиболее распространенных библиотек JS, которые вы, возможно, захотите использовать, поставляются вместе с WordPress. Эти библиотеки покроют большинство ваших основных потребностей.

Совет разработчика: Пожалуйста, загружайте дополнительные файлы JS и CSS только на те страницы, которые вам нужны. Как разработчик и пользователь, я очень не люблю плагины, которые замедляют работу администратора, загружая ненужные файлы JS и CSS на каждой странице. Это не только замедляет работу других административных страниц, но также может сильно испортить визуальный макет и сделать некоторые административные страницы практически непригодными для использования. Пожалуйста

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

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

10. Используйте инструменты и сервисы для анализа кода

Кодриск

Существует множество автоматизированных сервисов, помогающих выявлять проблемы с кодом. Exakat, SonarSource и PHPStan, и это лишь некоторые из них, а также мой фаворит — Coderisk.com — простой способ найти наиболее очевидные ошибки безопасности в вашем коде.

Эта компания сканирует все плагины WordPress из общедоступного репозитория WordPress.org. Их программное обеспечение способно сканировать и выявлять сотни различных проблем безопасности на основе различных стандартов кодирования.

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

Зарегистрироваться в их бесплатном сервисе довольно просто — вы можете создать бесплатную учетную запись, а затем начать требовать свои плагины. Заявить права на плагин так же просто, как взять одну строку кода, которую вы вставите в файл readme.txt в следующий раз, когда будете развертывать новую версию.

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

Панель безопасности Coderisk

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

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

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

Примечание. Если вы никогда не запускали Coderisk (или любой другой инструмент из этой категории) для своего кода, не беспокойтесь о количестве предполагаемых проблем, о которых вы будете предупреждены. Эти инструменты могут генерировать большое количество ложных срабатываний, поскольку они только анализируют код без понимания бизнес-логики. Используйте выходные данные инструмента в качестве надежного начального списка элементов для просмотра.

PHP_CodeSniffer

Еще один отличный инструмент для проверки кода — PHP_CodeSniffer. PHPCS состоит из двух сценариев: PHPCS, который проверяет ваш код и сообщает вам об ошибках, и PHPCBF, который может автоматически исправлять широкий спектр проблем, которые определяет PHPCS.

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

Также возможно интегрировать PHPCS непосредственно в ваш редактор, такой как Sublime Text и Visual Code. Таким образом, вы можете легко увидеть любые ошибки и быстро исправить их в своей среде IDE.

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

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

11. Не копируйте и не вставляйте код из Интернета без надлежащей проверки

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

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

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

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

Помните, что ваша репутация под угрозой

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

Уязвимости системы безопасности могут оказать огромное влияние на доверие клиентов к вашему бренду или продуктам. Приведенный выше пример Loginizer показывает, что даже самые досадные уязвимости в безопасности могут случиться с самими разработчиками плагинов безопасности! А другие примеры фальсификаций на выборах и правительственных взломов говорят нам о том, что любой человек уязвим.

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

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

Спасибо за прочтение!

Может быть сложно изучить все, что вам нужно сделать, когда вы не знаете, с чего начать, и может быть трудно найти нужную информацию. Если вы не знаете, с чего начать, подумайте о том, чтобы ваш продукт проверил эксперт по безопасности WP (я тоже провожу проверки безопасности).

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

Это лишь некоторые из способов, которыми вы можете и должны защитить свой продукт WordPress от злоупотреблений. Если у вас есть какие-либо сомнения, просто помните - никому не доверяйте