Те, кто уже двадцать раз прочитал о том, как не надо использовать mysql_query, include, eval и system, порой могут отмочить что нибудь еще :)

Часто вижу, что при проверке в базу данных переменные вроде User_agent или Client-IP (X-forwarder-for) кладутся вообще без проверок, безумное использование import_request_variables или extract и куча других. Вспоминаем недавний баг в WordPress, я думал авторы уже научены предыдущими уязвимостями.

В версии 2.5.0 они решили сделать cookies юзера более защищенными

«wordpress_».COOKIEHASH = USERNAME. «|». EXPIRY_TIME. «|». HMAC

COOKIEHASH md5 хеш от имени сайта
USERNAME Имя пользователя
EXPIRY_TIME Срок жизни cookies до того как они станут невалидными

HMAC представляет из себя хеш из USERNAME и EXPIRY_TIME, основанный на ключе, полученный путем преобразования USERNAME, EXPIRY_TIME и SALT, проще говоря формула такая

HMAC_KEY = HMAC md5(USERNAME.EXPIRY_TIME, SALT), HMAC = HMAC md5(USERNAME.EXPIRY_TIME, HMAC_KEY)
$hmackey = hash_hmac('md5', $user. $time, $salt);
$hmacpass = hash_hmac('md5', $user. $time, $hmackey);

Вроде бы все хорошо, но нет, разработчикам надо было и тут ошибиться :)

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

Объясняю популярно — имеем пользователя admin1, после входа в блог получаем куки

[admin1]|{1897534539}|hash

Теперь просто переделываем cookies так, чтобы левая часть перед hash была идентична для юзера admin

[admin|1](единичка переходит сюда){897534539}|hash

В новом билде хватились и исправили, но такое не забывается :)