[wp-hackers] Rethinking check_admin_referer()

Matt Mullenweg m at mullenweg.com
Wed Apr 19 03:38:35 GMT 2006

Mark Jaquith wrote:
> I'm still curious what Matt meant by this... it's the only thing 
> stopping me from writing the patch:



"9) Finally we can do a POST! However, when we send the post it never 
actually adds a friend. Why not? Myspace generates a random hash on a 
pre-POST page (for example, the "Are you sure you want to add this user 
as a friend" page). If this hash is not passed along with the POST, the 
POST is not successful. To get around this, we mimic a browser and send 
a GET to the page right before adding the user, parse the source for the 
hash, then perform the POST while passing the hash."

This person has gotten JS onto the domain, which confirms the fact that 
our best efforts should be on the KSES side of things, because once 
someone has snuck any JS into our "trusted" area, all bets are off.

People who know JS far better than I have told me in the past it is 
possible to do cross-domain GETs so nonces are snake-oil, however my 
best Googling can not find anything. (Perhaps for the best!)

If the best an attacker can do is embed a link in a comment or email and 
hope you click on it, then we've succeeded. At some point we have to 
stop punishing normal users for the extreme edge cases.

The most valid point thus far has been about images in drafts, which I 
think is a place where we could improve check_admin_referer to block 
actions (like delete comment) that are never going to come from the post 
screen. This would not break any compatibility, and not cause any 
additional hassle for users.

I still think the best answer to the original problem is a plugin which 
just turns check_admin_referer off.

Here are two good security essays:

(More about cryptography, but still interesting. From 1999.)

Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com

More information about the wp-hackers mailing list