[wp-hackers] Rethinking check_admin_referer()

[Brian Layman]

>We are trying to get rid of referrer checks, there are other ways 
>to perform checks, and that's what we are discussing.
>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. 

I understand that and I have read the entire thread. The point I was trying
to make is that since the referrer check seems to be the most full proof
method to block a CSRF attack and it is only certain users that have
conditions that strip/block the referrer, perhaps removing that check
entirely is not the best solution.  Providing an alternate method for only
those that have an issue with the primary line of defense should be an
option.

My first reply suggested building that into the user profile because: 
1. I'm not sure that the nonce suggestion can be made completely foolproof.
Just in this thread, a few objections were raised.  It doesn't look like its
been completely worked out yet.
2. I thought Mark was suggesting using AYS prompts as the only security.  I
see now that he was suggesting that only for plugins that haven't added the
nonce.  That's a much better approach than putting AYSs everywhere by
default.  It could probably be enhanced one step further. If the referrer
check passes, why should the users deal with that extra prompt?  Again,
another reason not to dismiss the referrer check entirely.

I was also swayed by this text in the link I referenced:
>> Alternatively, the sessionid could be
>> required to come with the GET/POST request variables, rather than by
cookie.
>...thereby exposing an important piece of authentication information to
>history files and proxy servers; I really don't like URL mangling for
>authentication purposes, especially in non-SSL systems. A combination of
>cookie + URL mangling might not be bad, though in the message board case, a
>CSRF attacker could use an intermediate redirect (as described earlier) to
>get the URL mangling (from the Referer), and redirect back to the
>messageboard with the proper mangling as well as all cookies that might be
>expected/needed. So in your example case, URL mangling would buy nothing.
:-(


>> think, basically, with the right (wrong) plugin enabled, the Preview
could
>> allow user-supplied content to have an admin referer context. Couldn't
it?
>I think you are terribly confused about "referer contexts" and what
>exactly you're talking about.

You're right that I might be missing something here, which is why I asked
the question.  

If I am working in http://www.somewpblog.com/wp-admin/post.php and click on
a link in the preview post, I don't know what my referrer would show as...

OK, I tested this by creating a post that was simply a link to
"/wp-admin/post.php?action=delete&post=101" and it comes up with "Sorry, you
need to enable sending referrers for this feature to work.".  So apparently
this is not a concern and I still don't know why people view the preview
feature as an issue.