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

[Sean Hickey]

> (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.

I recall making a conscience decision to not use that function, but I
can't remember why. Either way, good point.  I've never run a blog
that has users other than myself, so it's not something I've given
enough thought to.

> (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.

Like I was saying to Paul, that check seems very pointless to me.
Also like I was saying to Paul, I've submitted comments to WP blogs
using telnet and sending raw HTTP data, no form needed.  This seems to
be a security hole that is unavoidable.

> 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).

Wouldn't that be pointless with admin.php included, since those
scripts check the cookie?

> (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.

Right.  My thinking is by the time the script gets that far, the user
has already been verified, which is a bit sloppy on my part.

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

Isn't wpdb::escape() supposed to handle issues like that? :)

Good points Mark.  My "flagship" plugin is being beta tested now, and
released on Monday.  After that I'll run the Edit N Place plugin
through the mill and lock it down more.  That being said, I still
think the plugin is pretty safe for now.  A lot has to go wrong before
someone can gain entry, and the plugin is only susceptible to some of
the holes that WP in general is vulnerable to.

- Sean
-- 
http://www.headzoo.com