[wp-hackers] Moved from BlogWare to WordPress - Need Help
seanhickey at gmail.com
Sat May 20 10:39:58 GMT 2006
> (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
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.
More information about the wp-hackers