TechBlogSD - Все для WordPress и WEB разработки
WEB и WordPress инструкции, новости, обзоры тем и плагинов

Разработка защищенных плагинов в WordPress

1 094

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

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

1. Вы должны подготовить () для каждого запроса

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

Все функции базы данных WordPress используют класс $wpdb. Большинство методов в этом классе (и все основные методы WordPress, такие, как get_posts(), в этом отношении) будут использовать функцию prepare() $wpdb для проверки запросов и того, что ничего плохого не может пройти. Так что, если вы используете стандартные методы WordPress, вы, вероятно, в безопасности. Если вы используете $wpdb-> query() напрямую (или даже хуже; функции php mysql) Вы вероятно, не в безопасности.

Функция prepare в классе $wpdb отфильтровывает любую ссылку MySQL и очищает строку, передаваемую в вашу базу данных. Если вы уже знакомы с предотвращением SQL-инъекций в PHP, вы, вероятно, знаете, что уже доступен целый ряд методов, так зачем использовать prepare()? Ну, подготовка обновляется, когда WordPress обновляется. Основная команда WordPress стала очень хорошо разбираться в последних хитростях, которые могут попробовать хакеры … доверяйте ядру WordPress, и ваш плагин будет в порядке.

2. Вы должны использовать одноразовые номера nonce в формах и URL

Nonce означает «номер используется только один раз». Он используется против неожиданных или дублирующих запросов, которые могут привести к нежелательным постоянным или необратимым изменениям в установке WordPress и особенно в его базе данных. Это в основном проверяет намерение пользователя.

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

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

wp_nonce_field( md5( 'my_plugin_nonce' );

В ссылках это немного сложнее; нам нужно также обернуть URL в эту функцию:

$url = 'https://techblog.sdstudio.top'; $wp_nonce_url( $url, md5( 'my_plugin_nonce' ) );

Оба одноразовых номера могут быть проверены с помощью простого

wp_verify_nonce( md5( 'my_plugin_nonce' ) );

Функция wp_verify_nonce() возвращает простой оператор TRUE / FALSE, поэтому вы можете использовать его непосредственно в условиях Вашего плагина.

3. Проверяйте роли пользователей

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

Роли пользователей являются важной частью любого веб-приложения. Допустим, вы создали плагин для фотоальбома; тогда я держу пари, что вы не хотите, чтобы подписчики добавляли или удаляли фотографии в этот альбом. Вы, вероятно, захотите, чтобы редакторы и администраторы могли это делать … Что ж, вы можете сделать это очень легко в WordPress, установив возможность для роли и затем проверив, есть ли у текущего пользователя такая возможность с блестяще названной функцией current_user_can( ‘имя-возможности’), которое возвращает истину или ложь.

Короче говоря; пользовательские роли существуют по определенной причине, а WordPress позволяет легко создавать новые роли и проверять запрос для определенных пользовательских ролей; используй их.

4. Экранирование

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

esc_url()
Кодирует и проверяет URL.

esc_html()
Убедиться, что строка не разбивает ваш HTML-документ с помощью дополнительных скобок и (двойных) кавычек

esc_attr()
Почти так же, как esc_html (), но используется для экранирования атрибутов html-тегов.

Вы можете найти все эти функции в WordPress Codex
Escaping – это очень простая вещь. В идеале вы делаете это прямо перед выводом. Так

должен стать

5. Установите для WP_DEBUG значение true и проверьте наличие ошибок.

Это может быть легко для некоторых людей, но ошибки это плохо. Даже если они не сломают ваш сайт. С WP_DEBUG в вашем файле wp-config.php, установленным в «true», вы увидите все ошибки, которые вызывает ваш плагин. WordPress и PHP дают вам постоянную обратную связь о том, как вы можете делать вещи лучше. Рядом с этим, вы сможете увидеть, если функция устарела. WordPress старается обеспечить как можно более обратную совместимость, поэтому устаревшая функция обычно просто выдаст предупреждение о том, что она устарела и вам следует использовать что-то еще, но она не вызовет ошибку, приводящую к сбою сайта. Это хорошо для целей обновления, потому что WordPress обычно не ломается при обновлении, но все же ОЧЕНЬ умно слушать WordPress и использовать более новые альтернативы, предлагаемые WordPress.

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

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

Бонус: префикс каждой функции и использование классов

Плагины WordPress на самом деле довольно жуткие маленькие вирусы, им разрешено делать буквально все что угодно в системе. Они также загружаются полностью с самого начала загрузки страницы. Вместо файлов тем, которые загружаются контекстно на основе URL-адреса и запрашиваемой записи, файлы плагинов загружаются сразу.
И их много. Я ИМЕЮ В ВИДУ. НАГРУЗКИ.

Имея 26800 плагинов и считая только в общедоступном репозитории, довольно сложно убедиться, что все работает для всех. Тем более, что вы не знаете, какие из других 26799 плагинов загружаются. Перекрывающееся имя функции обязательно должно произойти где-то. И тогда это приведет к фатальной ошибке, дающей пользователю (который, вероятно, не установил WP_DEBUG значение «true») небольшую задачу – выяснить, почему его сайт возвращает пустой документ.

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

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

Источник записи: https://wpmayor.com

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