Java, UX, HTML, CSS, WEB-design

Как защитить свой сайт WordPress

Краткое описание по статье Как защитить свой сайт WordPress

Название: Как защитить свой сайт WordPress . Краткое описание: [ad_1] ⭐ Даниэль . Дата публикации: 19.02.2022 . Автор: Алишер Валеев .

Для чего создан сайт Novosti-Nedeli.ru

Данный сайт посвящен новостям мира и мира технологий . Также тут вы найдете руководства по различным девайсам.

Сколько лет сайту?

Возраст составляет 3 года

[ad_1]

  • Даниэль Патаки

  • 0 Комментарии

Как защитить свой сайт WordPress

  • 17 минут чтения

  • WordPress, Безопасность, Методы (WP)

Краткое резюме ↬

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

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

Дальнейшее чтение на SmashingMag:

  • Распространенные вредоносные программы для WordPress
  • 10 полезных настроек безопасности WordPress
  • Контрольный список для создания идеального сайта WordPress
  • 10 шагов для защиты области администратора в WordPress

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

Еще после прыжка! Продолжить чтение ниже ↓

изображение безопасности

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

Эксплойты на основе URL

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

https://mysite.com/trying/to/exploit/%2F/config

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

Использование .htaccess в качестве брандмауэра

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

Например, нет веской причины для открывающей скобки ([) to be in a URL. If a request is made using a URL that contains a bracket, then either the user has mistyped something or someone is looking for a security hole. Either way, generating a “403 Forbidden” page is good practice in this case.


RedirectMatch 403 [

Paste the line above in your .htaccess file to block any request that contains an opening bracket.

To guard against more than just brackets, you will need a more complex ruleset. Luckily, our awesome editor Jeff Starr has gone out of his way to create a great .htaccess ruleset. The latest iteration is called 5G Firewall and is freely available from Perishable Press for your copy-and-pasting pleasure.

The firewall is modular, so you can delete lines from it without breaking the functionality. If something goes wrong when you’re using it, you can usually track down the problem by deleting lines until it starts working again. Once you’ve found the offending line, you can delete it and paste back the rest.

Protecting Directories

On many servers, it is possible to view the contents of a directory simply by typing it in the URL bar.

https://myblog.com/wp-content/uploads/2011/08/

Visiting this typical URL for a WordPress blog will list the contents of that directory, showing all of the uploads from August 2011. You might want this, but you can also disable or fine tune it using the good ol’ .htaccess file.


Options -Indexes

Popping the above line into your .htaccess file will disable directory listings; so, users will get a “403 Forbidden” message if they try to view a directory. While many people seem to be aware of this, far fewer know of the other options besides allowing or disallowing access. You can control which file types are listed using the IndexIgnore directive. Take these three examples:


IndexIgnore *
IndexIgnore *.php 
indexIgnore *.jpg *.gif *.png

If directory listing is enabled, then the directory will be displayed in the first example, but no files will be listed because all will be ignored. The second example will list all files except ones with a .php extension. The third example will omit the three image types specified.

Note that some hosts (such as MediaTemple) disable directory browsing by default, so you won’t need to modify the .htaccess file. To verify this, just type a directory location in the URL bar and see what happens.

Additional Server-Level Protection

So far, the measures we have taken have nothing to do with our website’s actual code. However secure your code is, you will still need to implement something like what we did above. We don’t have time to look at all tips and tricks for .htaccess, but you can do quite a few other things:

  • Password-protect directories,
  • Use smart redirects,
  • Deny access based on IP or an IP range,
  • Force downloading of files,
  • Disable hotlinking,
  • The list goes on.

Look at the “Further Reading” section at the end of this article, and become good friends with your .htaccess file. It might seem daunting and confusing at first, but solid knowledge of how to use it will go a long way.

Protecting Against Malicious Users

The second type of problem that can arise is when someone performs an action that they are not supposed to do. This doesn’t necessarily mean that they intended to harm the website, but it could happen.

If users are listed somewhere in the admin part of your website, chances are that a link is displayed to delete each user. The link could point to the script in the following location:

https://mysite.com/admin/scripts/delete_user.php?user_id=5

This link is relatively obscure; that is, a normal user doesn’t have a good chance of stumbling on it. But if directory listings are enabled, then someone naughty could go to https://mysite.com/admin/scripts/, see that you have a delete_user.php file there, and make various requests to try to delete a user.

If the script does not check permission or intent, then anyone who visits the link above could delete user 5.

Authority and Intent

Whenever a user initiates an action, we need to take two things into consideration. Does the user have authority to perform the action (i.e. do they have permission)? If the user does have authority, do they also intend to complete the action (i.e. do they mean to do what they’re doing)?

WordPress has functions to help you make sure that both conditions are met before an action in the script is triggered. We will look at these in detail shortly. If you are building your website from scratch, then you will need to make sure that each user has associated permissions and that you know which action can be performed under which condition.

For example, you would probably want only administrators to be able to delete content from the website. Every time a user tries to delete content, you would need to make sure that they are actually an administrator — this is the “authority” part.

Intent is best described with an example. Let’s assume you can use the following link to delete a comment:

https://mysite.com/admin/scripts/delete_comment.php?comment_id=5

The script itself will check that the user is currently logged in and is an administrator, so it takes care of the authority check. Could someone still wreak havoc? Sure they could! A sneaky hacker could put a link on their own website pointing to the same location:

<a href=“https://mysite.com/admin/scripts/delete_comment.php?comment_id=5">Super-Happy Times Here!</a>

Because everyone likes super-happy times, many users would click the link. In 99% of cases, nothing would happen, because those visitors would not be administrators of mysite.com. But if a logged-in administrator of mysite.com did click on the link, then the action would execute, even though the link was actually clicked from vilehackerperson.com.

You might think that the odds of this happening are astronomical. In a way you’d be right, but remember that a hacker can do this extremely easily and can automate it. Millions of people get spam email saying that Bill Gates will take away the Internet unless they pay $1,000. Most recipients don’t see the email or throw it out or mark it as spam or what have you, but perhaps 1 out of every 2 million people is lured in. A thousand bucks for basically doing nothing is not bad at all. And a hacker probably wouldn’t put the link on their own website; all they would need to do is hack a big website and embed the link there without anyone noticing.

Checking For Authority In WordPress

WordPress has a permissions system built in referred to as “Roles and Permissions.” Capabilities are the basis of the whole system; roles are just a way to group a set of capabilities together.

If a user has the delete_posts capability, then they have the authority to delete posts. If a user has the edit_posts capability, then they can edit their posts. Quite a few capabilities are available, and you can even create your own.

Roles are basically groups of capabilities. A user with the role of “contributor” has three capabilities: read, delete_posts and edit_posts. These give the user the authority to read posts and to edit or delete their own posts. These capabilities could be granted individually to any user, but grouping them into frequently used bundles is much easier and more practical.

With that in mind, let’s look at how to use WordPress functions to ensure that a user has the authority to complete an action that they initiate.


if(current_user_can("delete_users")) {
    wp_delete_user(5);
}
else {
    die("You naughty, naughty person. Of course, you could just be logged out…");
}

Here, we’ve made sure that the user has the delete_users capability before they are able to complete the action. Don’t make premature assumptions when protecting your scripts; in many cases, especially those of authority, the intent is not malicious.

The current_user_can() function takes one argument, which can be a role or a permission. We could let “editors” (who don’t normally have the delete_users capability) delete users in the following way:


if(current_user_can("editor")) {
    wp_delete_user(5);
}
else {
    die("You must be an editor to delete a user");
}

Be careful with the method above because the roles are not inclusive. This function doesn’t require the user to be at least an editor; it requires them to be exactly an editor (if that makes sense). Because of this, I find it preferable to use capabilities, especially if I have modified the default permissions extensively.

Two other similar functions enable you to examine the capabilities of users other than the currently logged-in one.


if(user_can(5, "manage_links")) {
    echo "User 5 is allowed to manage links";
}
else {
    echo "Sadness! User 5 may not manage links";
}
if(author_can(1879, "update_themes")) {
    echo "The author of post #1879 is allowed to update themes";
}
else {
    echo "Oh noes, our friend, the author of post #1879 may not update themes";
}

The user_can() function checks whether a given user has the given capability (or role). The first argument is the user’s ID or a user object; the second argument is the name of the capability or role that we want to check for.

The author_can() function checks whether the author of a given post has the given capability (or role). The first parameter should be a post ID or a post object; the second is the capability or role that we are examining.

Checking For Intent In WordPress

Intent is a bit more difficult to check. In the good ol’ days, a check of $_SERVER[‘HTTP_REFERER’] был путь. Это сохранило страницу, с которой пришел пользователь. Если доменное имя было их собственным, то с пользователем, вероятно, все было в порядке… если, конечно, кто-то не залез в его файлы и не вставил ссылку, которая удаляла базу данных пользователя, если он нажимал на нее как администратор.

Недавно в WordPress 2.03 был реализован более безопасный метод под названием nonces. Nonce означает «номер, используемый один раз» и часто используется в криптографии для защиты связи. Это число, которое генерируется перед инициализацией действия, затем прикрепляется к вызову действия, а затем проверяется перед завершением действия.

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

Nonce в формах


<form id="myform" method="post" action="myawesomescript.php">
    <h2>Enter an awesome word here</h2>
    <input type="text" name="word">
    <?php wp_nonce_field( 'awesome_name_nonce') ?>
</form>

Это создаст скрытое поле ввода, содержащее сгенерированный одноразовый номер, который будет отправлен вместе со всеми другими данными формы. То wp_nonce_field функция принимает четыре параметра:

  1. Первый параметр является необязательным, но рекомендуется, поскольку он дает одноразовому номеру уникальный идентификатор.
  2. Второй параметр — это имя поля. Это также необязательно и по умолчанию _wpnonce.
  3. Третий параметр является логическим. Если установлено trueон также отправит реферер для проверки.
  4. Четвертый параметр также является логическим и определяет, отображается ли поле прямо здесь и сейчас.

Полученное скрытое поле будет выглядеть примерно так:


<input type="hidden" id="_wpnonce" name="_wpnonce" value="d6d71w4664">

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


if (!wp_verify_nonce($_POST['_wpnonce'],'awesome_name_nonce') ) {
   die('Oops, your nonce didn't verify. So there.');
}
else {
   awesome_word_inserter($_POST["word"]);
}

Здесь мы использовали wp_verify_nonce() функция, чтобы убедиться, что наш одноразовый номер правильный. Эта функция принимает два параметра: первый — значение поля nonce, а второй — название действия, которое мы определили (это был первый параметр для wp_nonce_field() функция). Если одноразовый номер проверен, функция вернет true; иначе вернется false.

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

https://mysite.com/admin/scripts/deletethatthing.php?thing_id=231

Чтобы сгенерировать одноразовый номер для ссылки, мы можем использовать следующий метод:


$base_url = "https://mysite.com/admin/scripts/deletethatthing.php?thing_id=231";
$nonce_url = wp_nonce_url( $base_url, "thingdeleter_nonce");
echo "<a href="".$nonce_url."">Delete that thing</a>";

В результате ссылка будет выглядеть примерно так:

https://mysite.com/admin/scripts/deletethatthing.php?thing_id=231&_wpnonce=d6f77f1364

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


if (!wp_verify_nonce($_GET['_wpnonce'],'thingdeleter_nonce') ) {
   die('Oops, your nonce didn't verify. So there.');
}
else {
   delete_that_thing($_GET["thing_id"]);
}

Проверка полномочий и намерений одновременно

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


$nonce_url = wp_nonce_url("https://mysite.com/scripts/delete_comment.php?comment_id=1451", "delete_comment_nonce");
echo "<a href="".$nonce_url."">dispose of this comment</a>";

А вот и сам скрипт:


if (wp_verify_nonce($_GET['_wpnonce'],'delete_comment_nonce') AND current_user_can("edit_comment")) {
   wp_delete_comment($_GET["comment_id"]);
}
else {
   die('Oops, your nonce didn't verify, or you are not permission-endowed enough.');
}

Безопасность данных

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

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

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


// A hacker goes to your search field and searches for elephant' - note the apostrophe at the end. In the script, the following SQL is run:
SELECT ID, post_title FROM wp_posts WHERE post_title LIKE '%elephant'%'

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

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


SELECT user_email FROM wp_users WHERE user_login = 'danielp'

Если хакеру удастся выполнить атаку SQL-инъекцией, он может ввести ’ OR 1=1 ‘ в форме, что приведет к следующему запросу:


SELECT user_email FROM wp_users WHERE user_login = ’ OR 1=1 ’

Это вернет все адреса электронной почты в базе данных, потому что мы получим все адреса, для которых имя пользователя для входа является пустой строкой, или 1=1что всегда true.

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

При работе без фреймворка вы обычно используете addslashes() или что-то подобное, но WordPress предлагает свое решение…

Дезинфекция данных в WordPress

При общении с базой данных в WordPress предпочтительным методом является использование $wpdb сорт. Обо всем этом вы можете прочитать в статье «Основы WordPress: взаимодействие с базой данных WordPress». Класс предлагает ряд методов, чтобы облегчить ваши проблемы с SQL-инъекциями.

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


// Perform any query
$wpdb->query("DELETE FROM wp_users WHERE user_id = 5");
// Get one column of data
$posts = $wpdb->get_col("SELECT post_title FROM wp_posts WHERE post_status="publish" ORDER BY comment_count DESC LIMIT 0,10");
// Get a row of data
$post = $wpdb->get_row("SELECT * FROM wp_posts WHERE ID = 1453");
// Get multiple rows and columns
$posts = $wpdb->get_results("SELECT ID, post_title, post_date FROM wp_posts WHERE post_type="publish" ORDER BY post_date DESC LIMIT 0, 12 ");
// Get a single value 
$author_id = $wpdb->get_var("SELECT post_author FROM wp_posts WHERE ID = 2563");
// Insert a record
$wpdb->insert("wp_postmeta", array("post_id" => 2323,  "meta_key" => "favorite_count", "meta_value" => 224 ), array("%d", "%s", "%d"));
// Update a record
$wpdb->update("wp_postmeta", array("meta_value" => 225), array("meta_key" => "favorite_count", "post_id" => 2323), array("%d"), array("%s", "%d"));

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

Более простой способ — просто использовать escape() метод:


$data = $wpdb->escape($_POST[about_me]);
$wpdb->query("UPDATE wp_usermeta SET meta_value="$data" WHERE meta_key = 'description' AND user_id = 154  ");

Немного сложнее, но лучший способ сделать это — использовать prepare() метод. Пример из Кодекса WordPress прекрасно иллюстрирует это:


$metakey = "Harriet's Adages";
$metavalue  = "WordPress' database interface is like Sunday Morning: Easy.";
$wpdb->query( $wpdb->prepare( 
   "
      INSERT INTO $wpdb->postmeta
      ( post_id, meta_key, meta_value )
      VALUES ( %d, %s, %s )
   ", 
        10, 
   $metakey, 
   $metavalue 
) );

Дополнительная защита с помощью санитарной обработки

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

Последние мысли

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

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

Общее чтение

  • Брандмауэр 5G, скоропортящаяся пресса
  • Советы по безопасности для .htaccess
  • «SQL-инъекция», Википедия
  • «Атаки с внедрением SQL на примере», Стив Фридл
  • «MySQL: предотвращение SQL-инъекций», Тизаг
  • «filter_var», PHP.net
  • «Очистка и проверка данных с помощью PHP-фильтров», Nettuts+

Чтение для WordPress

  • «Роли и возможности», WordPress Codex
  • Полное руководство по ролям и возможностям«, Гэри Цао
  • «WordPress 2.0.3: Nonce», Марк Джакит.
  • «Повышение безопасности в плагинах WordPress с помощью одноразовых номеров», Владимир Преловац
  • «WordPress Nonce», Кодекс WordPress
  • «Справочник классов/wpdb», WordPress Codex
  • «Проверка данных», Кодекс WordPress
Сокрушительная редакция
(аль)



[ad_2]
Source: https://smashingmagazine.com

Заключение

Вы ознакомились с статьей — Как защитить свой сайт WordPress

Пожалуйста оцените статью, и напишите комментарий.

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован.

Кнопка «Наверх»