Make WordPress Core

Opened 14 years ago

Closed 10 years ago

#15330 closed task (blessed) (fixed)

WP Cookies and Authenticated Access

Reported by: filosofo's profile filosofo Owned by:
Milestone: 4.0 Priority: normal
Severity: major Version: 3.1
Component: Security Keywords: has-patch
Focuses: Cc:

Description (last modified by filosofo)

This has been an issue for a while as far as I can tell, but it's been brought to my attention by the convergence of the admin bar and Firesheep. To summarize, FORCE_SSL_ADMIN gives users a false sense of security.

What Happens

Let's say you define FORCE_SSL_ADMIN to be true. This redirects login and wp-admin access to its equivalent SSL/TLS version, mostly. Good so far.

However, when you authenticate to WP thus you get two cookies:

  • SECURE_AUTH_COOKIE (a secure cookie, to be transmitted only over a secure connection.)
  • LOGGED_IN_COOKIE (a non-secure cookie, to be transmitted over both secure and insecure connections.)

When you request a front-end page, not over SSL, your browser sends the LOGGED_IN_COOKIE but not SECURE_AUTH_COOKIE. This is sufficient to authenticate you as a user, with all the capabilities of your user (such as manage_options or edit_posts).

Why We Should Be Concerned

On an insecure network (e.g., a coffee shop), it's easy enough to get someone's LOGGED_IN_COOKIE. This allows you to do a number of things, depending on the themes and plugins used:

  • You can access user information, which ranges from the trivial (the admin bar's comment and update counts) to more significant (view draft posts).
  • You can get the logout nonce at least, and possibly more. This opens up some XSS vectors.
  • Make admin-ajax requests. All you need are the appropriate nonces, and you can perform any of the admin-ajax actions. Some of the admin-ajax actions require no nonces at all; you can e.g. query tag information.
  • The sky's the limit with themes and plugins.
    • Plugins like BuddyPress let you do practically everything on the front-end, including editing user information and handling users.
    • More generally, plugins tend to check just capabilities and verify nonces; they don't usually care about whether the user is using secure authentication. With the advent of the admin bar, we can expect even more administrative functionality to appear on the front-end, courtesy of plugins that are adding to the admin bar.

Some Suggestions

  • Simpler
    • When a site is FORCE_SSL_ADMIN, do not allow LOGGED_IN_COOKIE to be insecure. Or better, just have one authentication cookie that is secure for FORCE_SSL_ADMIN.
    • Generate different nonces depending on whether they're over SSL or not.
    • From the admin, link to the SSL versions of front-end objects, so authenticated users can browse them, secure and authenticated.
  • More Involved
    • When FORCE_SSL_ADMIN, deny authentication for capabilities above a certain level. So maybe if you have subscriber capabilities you can get a LOGGED_IN_COOKIE but not above.
    • When FORCE_SSL_ADMIN, return false for any capability check above a certain level, when is_ssl() is false. So for example, current_user_can( 'read' ) would be true, but current_user_can( 'edit_posts' ) returns true only if is_ssl().

Attachments (3)

make-logged-in-cookie-secure.15330.diff (1.6 KB) - added by filosofo 14 years ago.
15330.diff (2.8 KB) - added by ryan 13 years ago.
Allow plugins more control over secure cookies.
security.php (545 bytes) - added by ryan 13 years ago.
Example use of the filters

Download all attachments as: .zip

Change History (27)

#1 @filosofo
14 years ago

  • Description modified (diff)

#2 @scribu
14 years ago

  • Cc scribu added

#3 @johnbillion
14 years ago

  • Cc johnbillion@… added

#4 @filosofo
14 years ago

  • Keywords has-patch added

In the interests of a quick fix and the absence of any feedback, make-logged-in-cookie-secure.15330.diff makes logged-in-cookie secure when secure-auth-cookie is.

#5 @fitztrev
14 years ago

  • Cc fitztrev added

#6 follow-up: @ryan
13 years ago

I think we need to flush out FORCE_SSL_HOME and make the cookie secure if that is set.

#7 in reply to: ↑ 6 @filosofo
13 years ago

Replying to ryan:

I think we need to flush out FORCE_SSL_HOME and make the cookie secure if that is set.

I guess it depends what FORCE_SSL_HOME means. It sounds like a name for something that would serve public pages only over https.

#8 @filosofo
13 years ago

Anyways, what about my patch for the time being (3.1)? Currently it's almost impossible not to leak one's authentication credentials over an insecure connection.

#9 @filosofo
13 years ago

  • Keywords 3.2-early added
  • Milestone changed from 3.1 to Future Release

#10 @hakre
13 years ago

Related: #15928

13 years ago

Allow plugins more control over secure cookies.

13 years ago

Example use of the filters

#11 @ryan
13 years ago

(In [17227]) Add some cookie filters to allow plugins more control over SSL cookie delivery. see #15330

#12 @hakre
13 years ago

Related: #16869

#13 @lancehudson
12 years ago

  • Cc lance@… added

#14 @wonderboymusic
11 years ago

  • Keywords close added; 3.2-early removed
  • Milestone Future Release deleted

I'm inclined to think this is not an issue. I have implemented custom cookies and custom auth on eMusic, and most of this stuff can be controlled by the developer / basically everything is pluggable now.

Suggesting close since FORCE_SSL_HOME has not sprung to life in the past 2 years.

Last edited 11 years ago by wonderboymusic (previous) (diff)

#15 @scribu
11 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

@wonderboymusic: Either

a) only add the 'close' tag


b) actually set the resolution to wontfix/maybelater etc. and remove the milestone

#16 @nacin
10 years ago

  • Milestone set to 4.0
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to task (blessed)

Related: #27954.

#17 @DrewAPicture
10 years ago

In 28628:

Update the $secure_logged_in_cookie variable in the 'secure_logged_in_cookie' hook docs following [28627].

See #15330.

#18 @nacin
10 years ago

[28627] missed the ticket, looks like: Use a secure logged_in_cookie when the home URL is forced HTTPS.

#19 @johnbillion
10 years ago

  • Keywords close removed

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.

10 years ago

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.

10 years ago

#22 @DrewAPicture
10 years ago

@nacin: What's left here?

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.

10 years ago

#24 @johnbillion
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

I think we've covered all we're going to cover here. The secure flag on cookies is filterable since r17227. Cookies are secure when home and admin are HTTPS since r28627.

Note: See TracTickets for help on using tickets.