[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