Ars Longa, Vita Brevis » WordPress

Обход плагина WP Hashcash

Vladimir — Mon, 26 Dec 2011 05:43:11 +0000

Не так страшен JavaScript, как его малюют…

WP Hashcash — очередной плагин WordPress для борьбы со спамом. Принцип работы основывается на том, что спам-боты не умеют исполнять JavaScript. Идея в том, что если пользователь открыл сайт из браузера, браузер выполнит некоторый хитрый код JavaScript, и реузльтат работы этого скрипта будет передан назад на сервер в качестве доказательства «человечности» комментатора.

Недостаток этого подхода заключается в том, что используемый JavaScript является довольно-таки простым; как следствие, его можно «понять» даже из PHP-скрипта.

Пример кода JavaScript, генерируемого плагином:

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

Итак:

В PHP нет ключевого слова var (строго говоря, оно там есть, только имеет другое назначение).
В PHP несколько другой синтаксис объявления массива
Идентификаторы в PHP начинаются с доллара
Операция сдвига выглядит как >>, а не >>>.
В PHP нет классов Array, String, но никто не мешает их написать

Наша задача состоит в преобразовании кода, приведённого выше, в нечто подобное:

Это достигается таким набором правил str_replace():

$x = array(
'wphc_data' => '$wphc_data',
'var $' => '$',
'var ' => '$',
'];' => ');',
'= [' => '= array(',
'new Array($wphc_data.length)' => 'array()',
'$wphc_data.length' => 'count($wphc_data)',
' i<' => ' $i<',
'[i]' => '[$i]',
'i++' => '$i++',
'>>>' => '>>',
'a[$i] =' => '$a[$i] =',
'String.' => '',
'eval' => '',
"a.join('')" => 'join("", $a)',
);

$s = str_replace(
array_keys($x),
array_values($x),
$s
);

При желании правила можно попытаться оптимизировать, но мне было лень — скрипт ломался на коленке за 10 минут.

Реализация функции fromCharCode:

function fromCharCode($a, $b, $c, $d)
{
return chr($a) . chr($b) . chr($c) . chr($d);
}

После замены результат нужно вычислить при помощи eval(). После чего получим такой результат:

function wphc_compute(){return 43448 * 43448 + 75878; } wphc_compute();

Как можно заметить, этот код является одновременно и PHP-кодом, и JavaScript-кодом.

Следующий шаг —

$s = str_replace('wphc_compute();', '', $s);
eval($s);
echo wphc_compute(), "\n";

Результатом выполнения будет число 1887804582.

Как видим, для обхода такой простой защиты не нужен даже интерпретатор JavaScript

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

Ставим спам в комментариях на службу людям

Vladimir — Sat, 06 Aug 2011 04:48:20 +0000

Автоматическое отправление автоматического спама на Stop Forum Spam

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

Начиналось всё созданием чёрных списков типа DNSBL (сюда попадали IP-адреса спамеров) и URIBL (а сюда — рекламируемые домены), но на раскрутку очередного чёрного списка (а также на его поддержание) банально не было ни сил, ни времени.

Закончилось всё тем, что я прекратил заниматься велосипедостроительством, зарегистрировался на Stop Forum Spam и теперь отсылаю весь полученный спам туда. Хотя я не во всём согласен с SFS, положительным моментом является то, что списки спамеров мониторятся Spamhaus (пример 1, пример 2). Хотя Spamhaus о себе тоже много думает (блокировать почту на основании того, что с данного IP-адреса идёт форумный спам — бред), тем не менее, у Spamhaus больше шансов прикрыть спамера, чем у простого блоггера.

На этом лирическое отступление закончено, далее идёт рассказ о том, как автоматически сообщать об автоматическом спаме в Stop Forum Spam, ибо чем больше отчетов они получат, тем быстрее спамер будет остановлен.

Идея, на которой строится реализация метода, абсолютно не нова, но эффективна.

Шаг первый. Регистрация на SFS и получение API-ключа.

Шаг второй. Создаём в каталоге с файлами WordPress такой простенький файл (например, wp-comments-post2.php):

require_once dirname(__FILE__) . 'wp-comments-post2.php';

Шаг третий. Добавляем в comments.php используемой темы липовую форму комментариев. Например, такую:

<div style="display: none; left: -10000px; top: -10000px;">
<p><strong>Пожалуйста, не используйте данную форму комментирования — она исключительно для спамеров.</strong></p>
<form method="post" action="/wp-comments-post.php">
<p class="comment-form-author"><label>Имя</label> <input type="text" size="30" value="" name="author"/></p>
<p class="comment-form-email"><label>E-mail</label> <input type="text" size="30" value="" name="email"/></p>
<p class="comment-form-url"><label>Сайт</label><input type="text" size="30" value="" name="url"/></p>
<p class="comment-form-comment"><label>Комментарий</label><textarea rows="8" cols="45" name="comment"></textarea></p>
<p class="form-submit">
<input type="submit" value="Отправить комментарий" id="submit" name="submit"/>
<input type="hidden" id="comment_post_ID" value="" name="comment_post_ID"/>
<input type="hidden" value="0" id="comment_parent" name="comment_parent"/>
</p>
</form>
</div>

Шаг четвёртый. Меняем нормальную форму комментирования. Всё, что требуется — изменить action формы комментирования с /wp-comments-post.php на /wp-comments-post2.php.

Если для создания формы комментирования используется новомодная функция comment_form() изменить action можно так:

ob_start();
comment_form();
$s = ob_get_clean();
$s = str_replace('/wp-comments-post.php', '/wp-comments-post2.php', $s);
echo $s;
?>

Шаг пятый. Добавляем кусок кода в файл functions.php используемой темы:

Вместо API-ключ Stop Forum Spam подставляем свой API-ключ.

Вместо возни с cURL можно использовать API-функцию WordPress wp_remote_post().

Шаг шестой. Радуемся жизни

SQL Injection Vulnerability в Z-Vote 1.1

Wandering Soul — Fri, 25 Feb 2011 19:32:49 +0000

Исправление уязвимостей в плагине WordPress Z-Vote 1.1

В плагине WordPress Z-Vote 1.1 была обнаружена уязвимость, позволяющая злоумышленнику выполнять произвольные запросы к базе данных (уязвимость типа «SQL-инъекция»).

Уязвимость существует из-за неправильного использования метода wpdb::prepare() и отсутствия проверки и очистки переменной $_GET['zvote'].

Уязвимость позволяет злоумышленнику изменять запросы к базе данных, выполнять произвольные запросы, читать или изменять конфиденциальную информацию.
Вторая уязвимость (незначительная по сравнению с SQL-инъекцией) — раскрытие пути к плагину (path disclosure) при прямом доступе к файлу плагина.

Патч, исправляющий уязвимости в Z-Vote 1.1:

diff -uwdBrN z-vote.orig/zvote.php z-vote/zvote.php
--- z-vote.orig/zvote.php 2011-02-25 21:05:44.000000000 +0200
+++ z-vote/zvote.php 2011-02-25 21:10:46.531798756 +0200
@@ -9,6 +9,8 @@
License: GPL
*/

+ defined('ABSPATH') or die();
+
// --- DEFINITIONS

//define where zvote is installed on the wordpres system. In 99.9% of the case the path below is correct.
@@ -271,7 +273,7 @@
function zVote_getEntry($postid) {
global $wpdb;

- $entries = $wpdb->get_results($wpdb->prepare("SELECT * FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $entries = $wpdb->get_results($wpdb->prepare("SELECT * FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $entries;
}
@@ -282,7 +284,7 @@
global $wpdb;

$votes = 0;
- $votes = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $votes = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $votes;
}
@@ -292,7 +294,7 @@

global $wpdb;

- $votes = $wpdb->get_var($wpdb->prepare("DELETE FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $votes = $wpdb->get_var($wpdb->prepare("DELETE FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $votes;
}
@@ -353,7 +355,7 @@
global $wpdb;

//ipcheck for now, will expand to userid-check, based on the user setting in version 1.5
- $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . " AND userip = \"" . $_SERVER['REMOTE_ADDR'] . "\""));
+ $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d AND userip = %s", $postid, $_SERVER['REMOTE_ADDR']));

$wpdb->insert( $wpdb->prefix . 'zvotedata', array( 'postid' => $postid, 'userip' => $_SERVER['REMOTE_ADDR'], 'userid' => 0, 'time' => time() ), array( '%d','%s', '%d', '%d' ) );

@@ -365,7 +367,7 @@
global $wpdb, $wp_query, $redirect_meta_key;

//ipcheck for now, will expand to userid-check, based on the user setting in version 1.5
- $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . " AND userip = \"" . $_SERVER['REMOTE_ADDR'] . "\""));
+ $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d AND userip = %d", $postid, $_SERVER['REMOTE_ADDR']));

if (!$ipcheck) {
//ok to vote, register vote
@@ -382,7 +384,7 @@
}

//send user to post
- header('Location: ' .$injectionPoint);
+ wp_redirect($injectionPoint);
exit;
} else {
//user already registered, push to entry-page and inform the user.
@@ -394,7 +396,7 @@
$injectionPoint = $post . '?zvoters=2';
}

- header('Location: ' .$injectionPoint);
+ wp_redirect($injectionPoint);
exit;
}
exit;

Межсайтовый скриптинг в Register Plus

Vladimir — Sun, 13 Feb 2011 12:59:36 +0000

Патч, исправляющий уязвимости XSS и FPD

В плагине Register Plus 3.5.1 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку.

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

Судя по дате последнего изменения, плагин автором больше не поддерживается; тем не менее, пользователи не оставляют попытки использования плагина с новыми версиями WordPress.

Тем же исследователем была обнаружена уязвимость типа full path disclosure (ей подвержены очень многие плагины и сам WordPress в том числе).

Скачать патч для плагина Register Plus.

KSES в WordPress: можно ли проще?

Vladimir — Thu, 10 Feb 2011 06:07:09 +0000

Регулярные выражения против DOM XML

Вчера мне довелось разбираться с тем, как работает KSES в WordPress.

KSES (рекурсивный акроним от KSES Strips Evil Scripts) — подсистема в WordPress (изначально написанная Ulf Harnhammar), предназначенная для проверки и очистки текста, введённого пользователем: она позволяет задать список допустимых тэгов, стилей и протоколов и на основе этих параметров убрать из текста пользователя всё, что им не соответствует.

KSES является довольно стабильной подсистемой; что немаловажно, KSES работает. Работает — не трогай, а то сломаешь…

Лично мне в KSES не нравится использование регулярных выражений. Одна из причин — теория разработки компиляторов. Известно, что HTML — это грамматика второго типа в иерархии Хомского (контекстно-свободная грамматика), а регулярные выражения — грамматика третьего типа (регулярная грамматика). Грамматика второго типа является более сложной, нежели грамматика третьего типа. Как следствие, описать более простой грамматикой то, что соответствует более сложной, очень трудно (вряд ли возможно на 100%, но это моё мнение).

Что плохо, среди тестов WordPress я не нашёл тестов для KSES. Что может означать, что, вероятно, никто из разработчиков не строил и не проверял граф путей в KSES; как следствие, не гарантии, что при граничных условиях всё будет работать нормально.

Другая причина, по которой я не люблю регулярные выражения — это скорость: особой производительностью они не отличаются. Хотя с другой стороны, объёмы проверяемого текста не так велики, чтобы KSES оказывал существенное влияние на производительность.

Каковы альтернативы? Обзор.

На мой взгляд, самая удобная альтернатива — использование DOM XML и работа с полученным деревом. Тем более, что в PHP есть соответствующая поддержка. А парсер на C в любом случае быстрее парсера на PHP.

Парсер DOM XML в PHP позволяет работать даже с некорректным HTML. Что означает, что он берёт на себя решение проблемы с неправильно закрытыми или незакрытыми тэгами. Парсер понимает HTML entities и преобразует их в нормальный текст. Что означает, что не нужно возиться с разными форматами записи entities и переводить их к одному виду (чему в KSES уделено не мало кода). И так далее.

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

class Xex
{
private $protocols = array();
private $tags = array();
private $css = array();

private $strip_comments = true;
private $strip_script_text = true;
private $strip_style_text = true;

private $script_text = true;
private $style_text = true;

private $trim_text = false;

public function __construct(array $tags = null, array $protocols = null, array $css = null)
{
if (null !== $tags) $this->tags = $tags;
if (null !== $protocols) $this->protocols = array_combine($protocols, $protocols);
if (null !== $css) $this->css = array_combine($css, $css);
}

protected function checkProtocols($str)
{
$s = str_replace(array("\r", "\n", "\t", ""), '', $str);
$s = explode(':', $s, 2);

// See http://tools.ietf.org/html/rfc3986#section-3.1
if (preg_match('/^[a-z][a-z0-9+.-]*$/', $s[0]) && !isset($this->protocols[$s[0]])) {
return '';
}

return $str;
}

protected function sanitizeCss($css)
{
$css = str_replace(array("\n","\r","\t"), '', $css);

if (preg_match('![\\(&=}]|/\\*!', $css)) {
return '';
}

$arr = explode(';', trim($css));

$css = '';
foreach ($arr as $x) {
$x = trim($x);
if ($x) {
$found = false;
if (false === strpos($x, ':')) {
$found = true;
}
else {
$parts = explode(':', $x, 2);
if (isset($this->css[rtrim($parts[0])])) {
$found = true;
}
}

if ($found) {
$css .= $x . ';';
}
}
}

return $css;
}

protected function parseDOM(DOMNode $el, DOMNode $new)
{
switch ($el->nodeType) {
case XML_ELEMENT_NODE:
$prefix = $el->prefix ? ($el->prefix . ':') : '';
$tag = $prefix . $el->tagName;

if (isset($this->tags[$tag])) {
$n = $new->appendChild($el->cloneNode(false));
if ($el->hasAttributes()) {
$attrs = $this->tags[$tag];
foreach ($el->attributes as $a) {
if (!isset($attrs[$a->name])) {
$n->removeAttribute($a->name);
}
elseif ('style' == $a->name) {
$css = $this->sanitizeCss($a->value);
if ($css != $a->value) {
$n->setAttribute($a->name, $css);
}
}
elseif (in_array($a->name, array('xmlns', 'profile', 'href', 'src', 'cite', 'classid', 'codebase', 'data', 'usemap', 'longdesc', 'action'))) {
$s = $this->checkProtocols($a->value);
if ($s != $a->value) {
$n->setAttribute($a->name, $s);
}
}
}
}
}
else {
if ($tag == 'script' && $this->strip_script_text || $tag == 'style' && $this->strip_style_text) {
return;
}

$n = $new;
}

if ($el->hasChildNodes()) {
foreach ($el->childNodes as $e) {
$this->parseDOM($e, $n);
}
}

return;

case XML_TEXT_NODE:
if (!$this->trim_text) {
$new->appendChild($el->cloneNode(true));
}
else {
$new->appendChild(new DOMText(trim($el->wholeText)));
}

return;

case XML_CDATA_SECTION_NODE:
$new->appendChild($el->cloneNode(true));
return;

case XML_COMMENT_NODE:
$parent = $el->parentNode;
if ($parent && $parent->tagName) {
$prefix = $parent->prefix ? ($parent->prefix . ':') : '';
$tag = $prefix . $parent->tagName;

if ('style' == $tag && $this->style_text || 'script' == $tag && $this->script_text) {
$new->appendChild(new DOMText($el->data));
return;
}
}

if (!$this->strip_comments) {
$new->appendChild($el->cloneNode(true));
}

return;

default:
break;
}
}

public function sanitize($s)
{
$dom = new DOMDocument();
$dom->recover = true;
$dom->strictErrorChecking = false;
$dom->substituteEntities = true;
$dom->resolveExternals = false;
$dom->formatOutput = false;

$old = libxml_use_internal_errors(true);

$s = str_replace(chr(0), '', $s);
$s = preg_replace('!<([^a-z\\?\\!/])!i', '<$1', $s);
$s = preg_replace('!<((?:[\\?\\!/]\\s*)?[a-z][^>]*)(?=<)!i', '<$1', $s);
@$dom->loadHTML($s);
libxml_use_internal_errors($old);

$new = $dom->createDocumentFragment();
$new->appendChild(new DOMElement('wrap'));
$this->parseDOM($dom->documentElement, $new->firstChild);
$dom->replaceChild($new, $dom->documentElement);
$s = $dom->saveXML($dom->documentElement, LIBXML_NOEMPTYTAG);

return substr($s, strpos($s, '') + 6, -7);
}
}
?>

Менее 200 строк против почти полутора тысяч.

На 45-килобайтном документе DOM быстрее KSES от 5 до 9 раз.
На 90-килобайтном документе DOM быстрее KSES от 6 до 9 раз.
На 180-килобайтном документе DOM быстрее KSES от 9 до 10 раз.

Производительность зависит от количества тэгов и стилей (разбор стилей реализован практически одинаково). Например, на домашней странице Google XEX может опережать KSES в 25 раз; если же соединить домашнюю страницу Google саму с собой 4 раза, разница во времени сокращается.

На домашней странице WordPress разница в 7 раз.

На этой странице разница в 4 раза.

Всё-таки KSES очень медленный…

Межсайтовый скриптинг в плагине Accept Signups 0.1

Vladimir — Wed, 09 Feb 2011 04:10:34 +0000

Исправление OSVDB-70101 для плагина Accept Signups

В плагине Accept Signups 1.0 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку.

Уязвимость связана с отсутствием обработки входных данных в параметре email, передаваемом файлу wp-content/plugins/accept-signups/accept-signups_submit.php, а также с отсутствием экранирования специальных символов при выводе данных в wp-content/plugins/accept-signups/accept-signups.php.

Уязвимость позволяет при помощи специально сформированного URL выполнить произвольный код сценария в браузере жертвы в контексте безопасности уязвимого сайта.

Патч для плагина Accept Signups 0.1:

diff -uwdBrN accept-signups.orig/accept-signups.php accept-signups/accept-signups.php
--- accept-signups.orig/accept-signups.php 2010-12-21 11:07:21.000000000 +0200
+++ accept-signups/accept-signups.php 2011-02-09 06:06:33.612991546 +0200
@@ -223,7 +223,7 @@
$r = $wpdb->get_results($sql, ARRAY_A);
$xml = '';
foreach($r as $k=>$v) {
- $xml .= '["email"] . '" ip="' . $v["ip"] . '" timestamp="' . $v["timestamp"] . '" />';
+ $xml .= '($v["email"]) . '" ip="' . $v["ip"] . '" timestamp="' . $v["timestamp"] . '" />';
}
$xml .= '';
file_put_contents(ABSPATH . 'wp-content/plugins/accept-signups/accept-signups.xml', $xml);
@@ -290,7 +290,7 @@
if (strpos($v1, '@')) {
$email = $v1;
}
- $html .= ' ' . $v1 . ' ';
+ $html .= ' ' . esc_html($v1) . ' ';
}
$html .= '($email) . '" id="acceptSignupsDeleteCB">';
$html .= '';
diff -uwdBrN accept-signups.orig/accept-signups_submit.php accept-signups/accept-signups_submit.php
--- accept-signups.orig/accept-signups_submit.php 2010-12-21 11:07:21.000000000 +0200
+++ accept-signups/accept-signups_submit.php 2011-02-09 06:03:04.017742924 +0200
@@ -1,6 +1,5 @@
-require_once('../../../wp-config.php');
-require_once('../../../wp-includes/wp-db.php');
+require_once('../../../wp-load.php');

if (true) {
if (isset($_GET['email'])) {
@@ -9,6 +8,16 @@
if (hasEmail($_GET['email'])) {
echo get_option('accept-signups-email-already-exists');
} else {
+ $email = stripslashes($_GET['email']);
+ if (function_exists('filter_var')) {
+ if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
+ die('-1');
+ }
+ }
+ elseif (!preg_match('/^([a-z0-9_\-\.])+\@([a-z0-9_\-\.])+\.([a-z]{2,4})$/i', $email)) {
+ die('-1');
+ }
+
saveEmail($_GET['email']);
echo get_option('accept-signups-email-saved');
}

Помимо OSVDB-70101, данный патч исправляет еще пару мелких недочётов.

Межсайтовый скриптинг в WordPress BezahlCode-Generator 1.0

Vladimir — Wed, 09 Feb 2011 03:13:15 +0000

Патч для BezahlCode-Generator, исправляющий уязвимость

В плагине BezahlCode-Generator 1.0 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку. Уязвимость связана с отсутствием обработки входных данных в параметрах gen_name, gen_account, gen_BNC, gen_amount, gen_reason в bezahlcode-generator/der_generator.php.

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

Патч для BezahlCode-Generator 1.0:

--- der_generator.orig.php 2011-02-09 04:52:27.000000000 +0200
+++ der_generator.php 2011-02-09 05:00:20.457537559 +0200
@@ -16,15 +16,15 @@
($_REQUEST['gen_type']=="singlepaymentspende") echo 'checked="checked"'?>/> Spendenzahlung

($_REQUEST['gen_type']=="singledirectdebit") echo 'checked="checked"'?>/> Lastschrift

-Name:
(this, 'dtaus')" name="gen_name" maxlength="27" value="($_REQUEST['gen_name'])?$_REQUEST['gen_name']:""?>">
+Name:
(this, 'dtaus')" name="gen_name" maxlength="27" value="($_REQUEST['gen_name'])?esc_attr($_REQUEST['gen_name']):""?>">

-Kontonummer:
1234" id="gen_account" onblur="checkInput(this, 'ganzzahl')" name="gen_account" value="($_REQUEST['gen_account'])?$_REQUEST['gen_account']:""?>" >
+Kontonummer:
1234" id="gen_account" onblur="checkInput(this, 'ganzzahl')" name="gen_account" value="($_REQUEST['gen_account'])?esc_attr($_REQUEST['gen_account']):""?>" >

-BLZ:
1234" id="gen_BNC" onblur="checkInput(this, 'ganzzahl')" name="gen_BNC" value="($_REQUEST['gen_BNC'])?$_REQUEST['gen_BNC']:""?>" >
+BLZ:
1234" id="gen_BNC" onblur="checkInput(this, 'ganzzahl')" name="gen_BNC" value="($_REQUEST['gen_BNC'])?esc_attr($_REQUEST['gen_BNC']):""?>" >

-Betrag in Euro (z.B. 1234,50)
1234,50" onblur="checkInput(this, 'dezimalzahl')" id="gen_amount" name="gen_amount" value="($_REQUEST['gen_amount'])?$_REQUEST['gen_amount']:""?>" >
+Betrag in Euro (z.B. 1234,50)
1234,50" onblur="checkInput(this, 'dezimalzahl')" id="gen_amount" name="gen_amount" value="($_REQUEST['gen_amount'])?esc_attr($_REQUEST['gen_amount']):""?>" >

-Verwendungszweck:
(this, 'dtaus')" name="gen_reason" maxlength="54" value="($_REQUEST['gen_reason'])?$_REQUEST['gen_reason']:""?>" >
+Verwendungszweck:
(this, 'dtaus')" name="gen_reason" maxlength="54" value="($_REQUEST['gen_reason'])?esc_attr($_REQUEST['gen_reason']):""?>" >

WordPress, поиск и кириллица

Wandering Soul — Sun, 02 Jan 2011 14:11:53 +0000

Правильные результаты поиска при использовании красивых ссылок

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

Например, есть такая ссылка:

http://blog.sjinks.pro/search/%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F/

%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F — это слово «Генерация», закодированное функцией urlencode().

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

Проблема заключается в том, что WordPress выдаёт разные результаты для двух казалось бы идентичных запросов:

«Традиционный поиск» — без использования красивых ссылок:
http://blog.sjinks.pro/?s=%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F
Поиск с использованием красивых ссылок:
http://blog.sjinks.pro/search/%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F/

В первом случае WordPress вернул 6 результатов, во втором — только один. При этом в первом случае искомое слово отображается правильно, во втором — нет.

Если посмотреть на запросы при помощи плагина SQLMon, увидим такую картину: в первом случае запрос имеет вид

SELECT SQL_CALC_FOUND_ROWS wp_posts.*
FROM wp_posts
WHERE 1=1
AND (((wp_posts.post_title LIKE '%Генерация%') OR (wp_posts.post_content LIKE '%Генерация%')))
AND wp_posts.post_type IN ('post', 'page', 'attachment')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')
ORDER BY wp_posts.post_date DESC
LIMIT 0, 10

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

SELECT SQL_CALC_FOUND_ROWS wp_posts.*
FROM wp_posts
WHERE 1=1
AND (((wp_posts.post_title LIKE '%\\%D0\\%93\\%D0\\%B5\\%D0\\%BD\\%D0\\%B5\\%D1\\%80\\%D0\\%B0\\%D1\\%86\\%D0\\%B8\\%D1\\%8F%') OR (wp_posts.post_content LIKE '%\\%D0\\%93\\%D0\\%B5\\%D0\\%BD\\%D0\\%B5\\%D1\\%80\\%D0\\%B0\\%D1\\%86\\%D0\\%B8\\%D1\\%8F%')))
AND wp_posts.post_type IN ('post', 'page', 'attachment')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')
ORDER BY wp_posts.post_date DESC
LIMIT 0, 10

Создаётся впечатление, что WordPress забыл выполнить urldecode(). Вполне вероятно, что этим никто и не озадачивался: при передаче параметров через строку запроса (как в первом случае) ответственность за перевод значений в «читаемую форму» лежит на PHP. А во втором случае закодированное значение является частью URI, поэтому PHP его не трогает.

Решение тривиально: в файл functions.php темы нужно добавить такой код (можно оформить плагином, но банально лень):

Хак применяется и на этом блоге, поэтому приведённые скриншоты более не воспроизводимы.

Capital P, Dang It!

Vladimir — Tue, 21 Dec 2010 03:11:33 +0000

Цензура в WordPress

Пару недель назад я заметил интересную особенность в WordPress: он автоматически заменяет Wordpress на WordPress. Как оказалось, такое поведение существует в WordPress где-то с версии 3.0. Со временем приоритет фильтра замены изменился; что характерно, оба эти изменения прошли совершенно незаметно — не было никакого обсуждения в Trac.

Что мне не нравится, так это отсутствие «изкоробочной» возможности отключить такое поведение. Я очень не люблю, когда система считает себя умнее пользователя

Как это убрать: можно добавить этот код в functions.php используемой темы:

if (function_exists('add_action')) :

function mytheme_init()
{
remove_filter('the_content', 'capital_P_dangit');
remove_filter('the_title', 'capital_P_dangit');
remove_filter('comment_text', 'capital_P_dangit');

remove_filter('the_content', 'capital_P_dangit', 11);
remove_filter('the_title', 'capital_P_dangit', 11);
remove_filter('comment_text', 'capital_P_dangit', 31);
}

add_action('init', 'mytheme_init');

endif;

Желающие могут воспользоваться плагином Remove Wordpress to WordPress Filter, но он не убирает фильтр с comment_text для WordPress 3.0.1 и выше.

WordPress: кэширование средствами nginx

Vladimir — Fri, 10 Dec 2010 12:08:15 +0000

Уменьшение потребления ресурсов во много раз

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

Метод основан на использовании кэша FastCGI web-сервера nginx.

Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на WordPress/PHP. Знакомые с принципом работы WP Super Cache заметят, что WPSC использует тот же принцип работы.

В чем же преимущество перекладывания работы на Web-сервер (nginx)?

PHP — интерпретируемый язык. Как следствие, аналогичный код на компилируемом языке будет во много раз быстрее.
WordPress во многом bloatware От момента начала загрузки страницы до окончания выполнения стадии init выполняется очень много «лишнего» кода.
В зависимости от нагрузки на сервер от запроса страницы до выполнения PHP-кода может пройти некоторое время: всё зависит от загруженности PHP (если все дочерние процессы PHP заняты обработкой запроса, новому запросу придётся ждать освобождения одного из процессов. Если за приемлемое время ни один процесс не освободился, пользователь видит сообщение о печально знаменитой ошибке 504).
Когда обслуживанием кэша занимается web-сервер, шансы на возникновение подобной ситуации

Теперь переходим от теории к практике.

fastcgi_cache_path /var/lib/nginx/myblog levels=2 keys_zone=myblog:10m max_size=512m inactive=20m;
server {
server_name example.com;
root /path/to/blog;
index index.php;
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
fastcgi_cache_bypass $do_not_cache;
fastcgi_no_cache $do_not_cache;
fastcgi_pass_header Cookie;
fastcgi_cache myblog;
fastcgi_cache_key $request_method|$host|$request_uri;
fastcgi_cache_valid 301 8h;
fastcgi_cache_valid 404 1h;
fastcgi_cache_valid 200 15m;
if ($http_user_agent !~ FeedBurner) {
# Здесь идут перенаправления для FeedBurner
}
error_page 404 = @wordpress;
log_not_found off;
location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}
location ~ ^/(wp-admin/.*\.php|wp-login\.php|wp-register\.php|(feed|comment/feed)(/.*)?)$ {
try_files $uri @wordpress;
set $do_not_cache 1;
fastcgi_cache_bypass 1;
fastcgi_no_cache 1;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location @wordpress {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
try_files $uri @wordpress;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ^~ /blogs.dir/ {
internal;
root /path/to/blog/wp-content/;
}
}

Документация по использованию FastCGI в nginx приведена здесь, поэтому я не буду подробно останавливаться на том, что конкретно каждая директива делает.

Основная магия происходит в строка 8—10: здесь определяются условия, при которых отдаётся свежая страница. В данном случае проверяется наличие авторизационных cookie и cookie комментатора. Важно, чтобы в случае отказа от кэширования переменная $do_not_cache устанавливалась в 1.

Строка 16 задаёт ключ, по которому страница доступна в кэше. В ключе присутствует $request_method, чтобы различать запросы GET и HEAD (для HEAD данные не возвращаются, только заголовки).

Строки 17—19 задают время жизни кэша в зависимости от кода ответа. Чем больше время жизни, тем реже будет обновляться информация для незарегистрированных пользователей.

В строке 32 задаётся маска для страниц, которые не должны кэшироваться (например, админка, страницы логина и регистрации, фиды).

Так как содержимое страницы может отличаться в зависимости от cookie пользователя, в строках 49 и 59 для закэшированных страниц принудительно выставляется заголовок Vary: Cache. Если используются другие правила (например, фильтрация по User-Agent), нужно добавлять соответствующее правило.

Строки 21—23: подробнее описано в статье «Перенаправление RSS в WordPress на FeedBurner для nginx»

Строки 28—30, 63—66 подробнее описаны в статье «WordPress MultiSite, nginx и X-Accel-Redirect»

Вроде бы ничего не забыл. Теперь о том, какую производительность мы получаем:

$ ab -n 10000 -c 100 http://blog.sjinks.pro/
Server Software: nginx
Server Hostname: blog.sjinks.pro
Server Port: 80

Document Path: /
Document Length: 50294 bytes

Concurrency Level: 100
Time taken for tests: 46.925 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 504940000 bytes
HTML transferred: 502940000 bytes
Requests per second: 213.10 [#/sec] (mean)
Time per request: 469.254 [ms] (mean)
Time per request: 4.693 [ms] (mean, across all concurrent requests)
Transfer rate: 10508.28 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 16 94 76.9 94 3125
Processing: 118 373 81.7 360 1334
Waiting: 17 69 38.5 57 422
Total: 156 467 105.0 445 3535

Percentage of the requests served within a certain time (ms)
50% 445
66% 454
75% 471
80% 494
90% 541
95% 589
98% 655
99% 768
100% 3535 (longest request)

Сервер зафлудили 10,000 запросами в 100 параллельных потоков. Сервер выдал практически полгигабайта за 47 секунд; в среднем сервер обрабатывал 213 запросов в секунду, при этом 99% запросов были обработаны за 768 мс (при том, что на сервере несколько сайтов в Alexa Top 100,000)! Нагрузка на сервер была минимальной (изменений Load Average замечено не было).

UPDATE: есть один небольшой нюанс: CAPTCHA. Если вы их используете, убедитесь, что они работают. Дело в том, что страница со статьёй будет отдаваться непосредственно из кэша nginx, PHP загружаться не будет. Поэтому если CAPTCHA полагается на использование сессии, она может работать неправильно. Здесь всё зависит от используемого плагина.