[wp-trac] [WordPress Trac] #15330: WP Cookies and Authenticated Access

[WordPress Trac]

#15330: WP Cookies and Authenticated Access
--------------------------+-------------------------------------------------
 Reporter:  filosofo      |       Owner:     
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.1
Component:  Security      |     Version:  3.1
 Severity:  major         |    Keywords:     
--------------------------+-------------------------------------------------
Description changed by filosofo:

Old description:

> 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.
>
> == 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()`.

New description:

 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()`.

--

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15330#comment:1>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software