[wp-hackers] Rethinking check_admin_referer()

[Robert Deaton]

On 4/17/06, Brian Layman <Brian at thecodecave.com> wrote:
> >My first thought is that the real problem around which all of this is
> >base is executing actions in the admin without performing a
> >confirmation.  For example, you click on an unobtrusive link on a
> >foreign site that sends you back to your own site's admin to delete post
> >#327.  If there is no confirmation for this action, then your site is
> >vulnerable.
> The real issue isn't a link being clicked on some foreign page, but a
> redirected image url linked to from your post comments.  All this takes is
> someone putting an image in your comments (such as
> [img]http://www.evil_doers.com/example1.gif[/img]) that actually redirects
> to
> /wp-admin/post.php?action=delete&post=100.  Without having the referer check
> there, that post is history.

I think you missed the original point of the thread and the original
point of the post you replied to. We are trying to get rid of referrer
checks, there are other ways to perform checks, and that's what we are
discussing.

> Read this a few times and you start to see the real dangers here:
> http://www.tux.org/~peterw/csrf.txt

We all know what CSRF is already, please read the rest of the thread
before proceeding.

> >So the first thing we should be doing is confirming every action that
> >could be accessed externally.  This is really freaking annoying, as I've
> >noticed with deleting moderated comments from email in 2.1, since I
> >didn't have to confirm those in < 2.1 and now I do.
>
> One solution I see this for all this is to give WordPress two different
> methods of security.  Then these would be selectable in User profile. Either
> the admin/user must have a valid referer from an admin section to do any
> admin function, OR they will have to deal with an excesive number of AYS
> prompts.

Owen's idea was based on Mark's original idea. Instead of checking
referers, which has its own issues (personal firewalls, corporate
firewalls, Norton), we formulate random, unique tokens that a request
must include in order to pass. A forged request in an image form would
have no way of knowing this key, and so instead of completing the
action, at that point we prompt again, including the "nounce" to
verify that a human is clicking the link and is confirming that they
want this to happen.
> BTW I've seen complaints about the security risk known as the Preview Post
> Feature.  I never understood why it was a risk until writing this reply.  I
> think, basically, with the right (wrong) plugin enabled, the Preview could
> allow user-supplied content to have an admin referer context. Couldn't it?
> Could a plugin that shows user supplied avatars with recent comments, embed
> a redirected url with an admin level request that would pass the admin
> referer check?

I think you are terribly confused about "referer contexts" and what
exactly you're talking about.

--
--Robert Deaton
http://somethingunpredictable.com