Today I updated my WordPress installation to version 2.6. The upgrade went smooth as usual. However afterwards I couldn’t login anymore because one of my ModSecurity rules was triggered at the login. Turns out the WordPress developers changed the use of the ‘redirect_to’ argument in wp-login.php. WordPress uses it to redirect the browser to some part of the weblog software after a successful login. Some time ago there used to be a vulnerability in WordPress as described here: http://www.securityfocus.com/archive/1/463291. To prevent exploitation on my box at the time I created the following rule:

SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS:/^s*redirect_to$/ “^(ht|f)tps?://”

This worked because WordPress only used relative paths as values for the ‘redirect_to’ argument. With 2.6 however, this has changed. WordPress now tries to redirect to a full URI. So the above rule needed an update. What I wanted is to adapt the rule so that it only allows the redirect to my own domain. So I created the following rule:

SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS:/^s*redirect_to$/ “^(?:ht|f)tps?://(.*)$” “chain,capture”
SecRule TX:1 “!@beginsWith %{SERVER_NAME}”

What it does is take the domain name from the ‘redirect_to’ variable and strip the leading http:// or https:// from it. Next, that is compared with Apache2’s SERVER_NAME variable. It is tested using ‘beginsWith’ so the rule can’t be bypassed using something like ‘redirect_to=http://evil.com/www.inliniac.net/’.

This way the logins work again and I still should be notified when someone tries this old (and patched) trick on me!