[wp-hackers] Moved from BlogWare to WordPress - Need Help

Mark Jaquith mark.wordpress at txfx.net
Sat May 20 10:18:56 GMT 2006


On May 20, 2006, at 6:06 AM, Sean Hickey wrote:

> That's alright, I'm here. :)

Hey Sean. ;-)

Here's my security audit:

(1) Backend is locked down to registered users (via admin.php), but  
editing of posts via backend.php does not utilize the  
"current_user_can()" functions to make sure that a low level  
"subscriber" user cannot edit posts when he doesn't have that  
capability. ("Man on the inside" attack)  You're using the functions  
on the frontend, which is good, but the user could still create the  
request manually and edit things they're not supposed to be editing.

(2) Backend appears to be vulnerable to CSF (Cross-site forgery)  
attack.  Someone creates an HTML form with a POST method, and fills  
it with data to simulate an AJAX request.  A legit WP user is tricked  
into visiting this site, which submits the form, and causes  
backend.php to perform some type of vandalism.

Referrer check is, sadly, unreliable here, because of an IE bug that  
allows for referrer spoofing for AJAX requests.  I suggest you look  
at how WP handles AJAX security in the admin (sends the login cookie  
along with the AJAX request and verifies it on the backend).

(3) Line 29 of backend.php has this SQL snippet: WHERE ID = $id
	$id comes from the raw POST data.  You are leaving it unquoted in  
the SQL, and thus assuming that it is going to be an integer.  But  
without  casting it to an integer, an attacker could use it to insert  
malicious SQL.  Note that this would require getting past admin.php,  
so it would require using #1 or #2 to do that.

	For example, raw POST data like: action=edit&id=5;DROP DATABASE  
databasename;

	I'd recommend casting to int and quoting the $id.

		$id = (int) $id;
		WHERE ID = '$id'

--
Mark Jaquith
http://txfx.net/




More information about the wp-hackers mailing list