Уменьшаем количество спама с помощью .htaccess

Устали от спама? Akismet, конечно, помогает, но и ваш .htaccess может хорошо помочь. Этот простой рецепт не даст спам-ботам напрямую обращаться к файлу wp-comments-post.php, через который и постятся каменты в блог.

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

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yourdomainname.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>

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

via wprecipes.com

WordPress 3.2.1 Core Module XSS

Информация по данной уязвимости уже пролетела по просторам Сети, но может кто еще не в курсе (или для тех, кто не следит за безопасностью своего блога) — товарищем Darshit Ashara была найдена XSS в WordPress (post-template.php), ничего сверхинтересного, но безопасность на первом месте.

Пока официального патча нет, новой версии нет, под вот временное решение.

Файл post-template.php

Добавляем htmlentities() к указанным строчкам
Vulnerable Code Part 1

function the_title($before = '', $after = '', $echo = true) {
	$title = get_the_title();

	if ( strlen($title) == 0 )
		return;

	$title = $before . $title . $after;

	if ( $echo )
		echo htmlentities($title); /* Line No 52 Patch*/
	else
		return htmlentities($title); /* Line No 54 Patch*/
}

Vulnerable Code Part 2

function the_title_attribute( $args = '' ) {
	$title = get_the_title();

	if ( strlen($title) == 0 )
		return;

	$defaults = array('before' => '', 'after' =>  '', 'echo' => true);
	$r = wp_parse_args($args, $defaults);
	extract( $r, EXTR_SKIP );

	$title = $before . $title . $after;
	$title = esc_attr(strip_tags($title));

	if ( $echo )
		echo htmlentities($title) ;/* Line No 87 Patch here By adding htmlentities*/
	else
		return htmlentities($title); /* Line No 89 Patch*/
}

Vulnerable Code Part 3

function get_the_title( $id = 0 ) {
	$post = &get_post($id);

	$title = isset($post->post_title) ? $post->post_title : '';
	$id = isset($post->ID) ? $post->ID : (int) $id;

	if ( !is_admin() ) {
		if ( !empty($post->post_password) ) {
			$protected_title_format = apply_filters('protected_title_format', __('Protected: %s'));
			$title = sprintf($protected_title_format, $title);
		} else if ( isset($post->post_status) && 'private' == $post->post_status ) {
			$private_title_format = apply_filters('private_title_format', __('Private: %s'));
			$title = sprintf($private_title_format, $title);
		}
	}
	return htmlentities(apply_filters( 'the_title', $title, $id )); /* Line No 119 Patch*/
}

Итого: 5 строк затронуто

via habrahabr

Обновление WordPress 2.2.2 до 3.2.1

Сейчас проведем эксперимент и обновим Wordpress 2.2.2 до 3.2.1 простой заменой файлов. Затем WP должен обновить БД, и в теории — это все.

Ранее таким же способом был запросто обновлен WordPress 2.9.2 до 3.2.

На всякий случай создан XML файл всех записей и комментариев блога. В идеале надо обновить так, что сохранились все настройки, в частности, настройки ЧПУ и шаблон.

Бэкап файлов WP старой версии делаться не будет, так как обратный откат ни в коем случае не планируется.

Итак, новые файлы залились на сервер, настал момент истины.

БД была успешно обновлена. Админка работает. И сам сайт на первый взгляд работает нормально. Не помешает вручную обновить файл wp-config.php.

Внезапно старый бложик оказался на cp1251, это может стать небольшой проблемой. Меняются все настройки, все файлы шаблона преобразуются в нужной кодировки — и все готово. Сайт готов к дальнейшему развитию, чем старая версия WP мешала.

Уязвимость нулевого дня в WordPress

Генеральный директор технологической компании Feedjit Марк Маундер (Mark Maunder) опубликовал на своем блоге информацию об обнаруженной им уязвимости в WordPress. По его словам, злоумышленники имеют возможность эксплуатировать часто используемое расширение web-платформы, с помощью которого можно получить контроль над web-сайтами жертв.

Уязвимость затрагивает практически все web-страницы, применяющие утилиту для изменения размера изображений TimThumb. По словам Маундера, данная утилита «небезопасна изначально», так как она упрощает работу хакеров по выполнению вредоносного кода.

Маундер обнаружил уязвимость после того, как его собственный web-сайт markmaunder.com был взломан. Страницы сайта неожиданно начали отображать рекламу неизвестного происхождения, хотя функция рекламы на сайте была отключена.

После тщательного расследования, он пришел к выводу, что злоумышленники использовали TimThumb для загрузки PHP-файла на одну из директорий сайта. Утилита, по словам Маундера, по умолчанию дает возможность удаленно загружать файлы из blogger.com, wordpress.com и еще пяти сайтов, без каких либо проверок.

«Если создать на web-сервере файл, подобный такому: http://blogger.com.somebadhackersite.com/badscript.php, а затем дать timthumb.php команду загрузить его, он сделает это и поместит его прямо в кеш, готовым к выполнению», — говорит Маундер.

Разработчики TimThumb работают над обновлением, закрывающим данную уязвимость.

via Security Lab