[wp-hackers] Rethinking check_admin_referer()

[Geoff Johnson]

On 4/19/06, Owen Winkler <ringmaster at midnightcircus.com> wrote:
>
> Primarily, using database storage for the nonce becomes inconvenient for
> the case with two users logged in under the same account at different
> locations, since they would presumably be performing different
> operations at the same time, and could very likely never have a valid
> nonce, according to what's stored in the database.
>
> By the time you code a way around that, you've probably reached the
> complexity of the purely computational nonce we've been suggesting, AND
> you've added an additional albeit minor database drain.
>

Am I missing something?  Again, why not a random cookie value each time??

Each time a page is generated, a random cookie is given to the user (say,
any user who already has a cookie).   The page being generated has this
unique random key embedded in any admin 'edit' links.

When a request is made of an admin, along with (instead of, before) the
refer check, simply compare the cookie to the key embedded in the link.

In other words, administration actions must come from links on the
most-recently viewed page.

Cookie generation could be limited to admin pages, but need not be.  The
ability to safely moderate comments from the site itself would be a plus.

Multiple users are no problem -- each user gets their own random key

Other sites would only be able to bypass it if they managed to guess the
current value of the cookie -- unlikely to guess (easier to guess the admin
password, in most cases), or XSS (other problem), or reading the admin's
cookies (in which case it wouldn't matter, because the whole authentication
strategy would be compromised anyway)   Same with links embedded in comments
-- they would need to execute php code to get the current passkey.

The database strategy seems overkill to me -- we only need to validate the
link, not the user :)   I have no objection to using the database to
authenticate links, certainly, but it seems like unnecessary overhead, not
to mention a minor PITA.

Another advantage of the random cookie idea:  automation with curl et al,
would be easy.

At this point, I can only see a couple drawbacks, and they seem pretty
minor.

Drawback #1.  Administation actions must come from links on the last
generated page.  If you have multiple tabs open in your browser, you will
need to refresh the page before clicking that link. (or better, an AYS could
be used if the cookie and the link's passkey differ.  Less support questions
that way, anyway.)

Drawback #2. (obvious, and easy) the cookie should not be generated for the
page displayed in the preview pane.