[wp-hackers] Any other way to do it? (or, do we really need Nonces?)

[Tom Barta]

> Date: Fri, 2 Mar 2007 15:45:22 -0500
> From: "Robert Deaton" <false.hopes at gmail.com>
> To make a long story short, POST or GET does not matter. Both actions
> must be protected by nonces, period. And as far as I know, in the
> administration panel, both actions are protected by nonces.
>
> The answer to the original question is also no, because it would not
> peacefully degrade, that particular solution cannot be used, and is
> also essentially useless from a security standpoint.
>
> For GET vs. POST and safe following of links, nowhere is it stated
> that GETs in links are intended to not have side effects. There is a
> recommendation that they do not, but it is not a requirement, nor
> would it be enforceable if it was. There is no reason that a link that
> is clearly labeled in the administration panel to point to an action
> that is intended to delete something should not be allowed. If we're
> not sending the right caching headers to comply with the
> recommendations of the HTTP specification, then I suggest we change
> that. Otherwise, I see absolutely no problem with using links to
> perform operations.

Someone else has already pointed you to the W3C's resources.  One
nitpick I have is that idempotency of GET requests ACTUALLY means:
"If this request is issued X times, it is equivalent to being issued 1
time."  That means a GET request (per W3C's recommendations) can have
a side-effect, provided that the side-effect does not accumulate.  So,
"delete post id 13" would be idempotent even though it affects state,
but "delete most recent post" would not be.  However, it's generally
good practice to make GET requests completely side-effect-free.

I know that POST is no more operationally secure than GET, but I have
a few thoughts on the issue:
1) POST protects users from nosy sysadmins reading their web server
logs.  Most web servers don't log POST content, for good reason.
2) State-altering requests should be sending a HTTP 302 redirect
instead of displaying a page directly.  That way, when a use navigates
with back/forward buttons on the browser, the state-altering request
is skipped (because the browser remembers that it issued a redirect).
Nonces and security aside, using "POST -> redirect -> GET" instead of
"GET -> GET (with side-effects)" is a better idea from a usability
standpoint, since it plays nicer with web browsers.
3) Web spiders know the difference between GETs and POSTs.  I once had
a public-facing web application that would queue up music to be played
in my house - Googlebot got to it and queued everything up because I
was using links instead of POST forms.  If Wordpress really wants to
move to a broader CMS category, it will likely end up in a situation
*somewhere* down the line where someone decides to spider it.  While
it likely won't hit the admin interface with links to delete things,
it's just a bad habit to get used to using links (which will get
crawled) where POST forms are more appropriate.