Opened 14 years ago
Closed 14 years ago
#18618 closed defect (bug) (invalid)
WordPress still relies on HTTP_REFERER for redirects which can be invalid
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.2.1 |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
Apparently this has not been fixed in over six years either.
The HTTP_REFERER header is not a valid method of redirecting users. It can be forged, blocked, removed or replaced by proxies, firewalls, etc.
This can cause unexpected behavior in user and admin interfaces.
The most common situation is that the header has been removed by personal firewalls to protect privacy. So I suggest developers use a browser plugin to temporarily block the referer and see what behaviors happen.
One consistent example is to try re-checking for spam on comments in the WP admin with akismet but there are other obvious pitfalls in the WP codebase when you search for HTTP_REFERER
Change History (2)
Note: See
TracTickets for help on using
tickets.
Nowhere does WordPress rely first on HTTP_REFERER. This was addressed years ago.
Akismet is not core. That can be reported on http://plugins.trac.wordpress.org/. They should be using wp_get_referer().
wp_get_referer() falls back to HTTP_REFERER after checking for a _wp_http_referer field.
There are some old MU functions that we don't use that also fall back to HTTP_REFERER. Those can be addressed in another ticket.
N.B. _ck_, is the tone truly necessary?