Циклические ссылки, и всё что с ними

Не так давно пришлось вплотную столкнуться с понятием «циклическая ссылка» в ТЗ заказчика. И поскольку сайтов было много, сайты были на разных движках, а требование их убрать — настойчивым, пришлось разбираться в проблеме более серьёзно, чем хотелось бы.

Что представляет из себя циклическая ссылка? Чем её присутствие может навредить сайту? Какие имеются способы от них избавиться?

WordPress сам по себе хорош, но не идеален. Разработчики хоть и стараются вовсю, но в плане безопасности всегда так: вирусы всегда пишутся раньше, чем антивирусные решения к ним. Потому, при выявлении очередной дыры в безопасности, с разной периодичностью по форумам прокатываются темы вроде «помогите! срочно! в записях появился код которого я не вставлял!!!!111» Потом приходят лучшие умы веток, пишут рецепты, разводят панику и занимаются различной имитацией деятельности.

Стоит сказать, что особенности web-разработки накладывают свой отпечаток на вирусы, предназначенные для сайтов. Самая большая проблема — скрыть вредоносный код от владельца сайта. Каких-то лет 15 назад, это ещё было сложно, но сейчас, когда только тема может состоять из нескольких тысяч файлов, спрятать что-либо проблемы не представляет. Я не буду здесь описывать правила безопасности (в частности для WordPress), этого и так в сети предостаточно. Лучше попробую описать несколько простых и универсальных способов устранить уже пробравшийся на хост вирус.

Итак, сайт начал ощутимо притормаживать, самопроизвольно падать, ВНЕЗАПНО сильно опустился в выдаче, а в записях вы обнаружили штуки вроде

<script type="text/javascript" src="//shareup.ru/social.js"></script>

или

<script type="text/javascript" src="//css.googleaps.ru/css?f=Open+Sans&cd=mb&ver=4.2.2"></script>
<script type="text/javascript" src="//uptoliked.ru/widjets.js"></script>
<script src="//wollses.com/steps"></script>

Как пишут спецы по безопасности первое, с чего стоит начать – смена паролей. Ко всему, до чего дотянетесь: админка, хост, пользователи (иногда кстати, в админпанели появляются пользователи, которых не создавали), база данных, FTP и пр. Это с большой вероятностью обрубит доступ вредоносному коду к вашему сайту.

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

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

Если антивирус ничего интересного не показал, можно приступать к удалению кода. Во-первых, нужно очистить записи от ссылок на скрипты. Можно вручную, воспользовавшись поиском по записям (искать будем по фразе «script src»): открываем каждую в результатах поиска, удаляем все замеченные <script src=»ссылка на код»></script>, сохраняем. Но если статей много, то лучше воспользоваться SQL-запросом к БД:

UPDATE wp_posts
SET post_content = REPLACE (post_content, '<script src="//ссылка_на_код"></script>', '')

Запрос удаляет из записей строку с указанным кодом (если точнее, заменяет её на пустую). Если вы не сильны в SQL или понятия не имеете о базах данных, можно воспользоваться плагином «regex search».

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

function delete_wrong_js($content){
return preg_replace("'<script.*shareup.ru*></script>'si", "", $content);
}
add_filter( 'the_content', 'delete_wrong_js', 10, 1 );

Обратите внимание, что вместо shareup.ru, между звёздочками нужно подставить значение, которе актуально именно в вашем случае. Например, если у вас в записях размещается код вида <script src=»//wollses.com/steps»></script>, то подставляем туда «wollses.com», и т.д. Теперь, даже если вирус снова разместит код в постах, WordPress его обрежет и выводить не будет.

Ну и напоследок, настоятельно рекомендую закрыть доступ к файлу xmlrpc.php в корне сайта с помощью .htaccess:

<Files xmlrpc.php>
order deny,allow
Deny from all
</Files>

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

три × 5 =