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

Так уж получается, что людям свойственно совершать ошибки. К сожалению, разработчики плагина TAC, на мой взгляд, небольшую ошибочку допустили. Даже скорее не ошибку, а недочет. Смотрите. Я загружаю на сайт три шаблона оформления WordPress — все три «вшивые». Причём первые две содержат только скрытые ссылки, которые я рассматривал в первой части (с использованием php и класса в css), а третья — содержит помимо ссылок закодированный футер. Вот, что мне показывает TAC:

Две первые темы помечены как вполне пригодные для использования и, несодержащие ничего вредоносного. Назвать такое поведение плагина ошибочным? Думаю, что это будет неправильно, т.к. несмотря на вывод надписи «Theme OK» плагин всё-таки показывает все ссылки, которые обнаружил и Вы всегда можете оценить — нормальные это ссылки или это гоблин постарался. Так что договоримся, что плагин вполне пригодный, НО при его использовании следует просматривать все найденные ссылки самому, не надеясь на красивую надпись на зеленом фоне.

Теперь, что касается проверок архива с шаблоном WordPress в офф-лайне. Вчера целый вечер прокопался на сайте разработчиков WordPress, нашел много полезной и интересной информации по поводу этой CMS и, в принципе, более менее разобрался с «тонкостями» работы гоблинов. Было бы ещё у меня знание PHP на должном уровне — было б вообще супер.

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

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

< ? php bloginfo('name'); ? >

Покажет нам название нашего блога, а

< ? php bloginfo('url'); ? >

покажет, соответственно адрес блога и т.д. Таких тэгов имеется достаточно много, каждый выполняет свои определенные функции и т.д. Но, если вдруг разработчику хочется внести в свой шаблон что-то новое, такое, что не предусмотрено по-умолчанию в WordPress, то в папку шаблона укладывается ещё один файлик: functions.php в котором и содержаться функции, определяющие дополнительную функциональность темы. Чувствуете, чем дело пахнет? С одной стороны подобная схема разработки — это, безусловно, замечательно, дает разработчику простор для действий, возможность гибкой настройки шаблона и т.д. Но с другой стороны — наличие файла functions.php в архиве должно послужить нам первым сигналом для проверки шаблона на «вшивость», т.к. туда можно записать всё, что душе угодно.

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

function bloqinfo($name = '') 
{echo 'ankor ankor'; }
 
function bloq($name = '') 
{echo 'ankorankor'; }

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

< ? bloqinfo('name') ? >

теперь сравним с нормальным тэгом:

< ? bloqinfo('name') ? > //вредоносная функция
< ? bloginfo('name') ? > //тэг шаблона

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

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

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

В настоящее время вывод программы после проверки шаблона WordPress имеет следующее содержание:

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

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

Все ссылки из списка буду пропущены программой как безопасные.

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

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

Скачать WPChecker можно на странице бесплатного софта WebDelphi.ru

уважаемые посетители блога, если Вам понравилась, то, пожалуйста, помогите автору с лечением. Подробности тут.
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
1 Комментарий
Межтекстовые Отзывы
Посмотреть все комментарии
SEO-шник, Донецк
26/07/2010 22:52

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

Зачем так сильно ломать себе голову? Намного проще анализировать сгенерированный шаблоном блога текст страницы.