3

In the High Performance JavaScript Callback Handler I'm attempting to use my own code to get the current user's ID.

To give a quick rundown, by returning data at a much lower bootstrap level (DRUPAL_BOOTSTRAP_DATABASE) I can return a page in ~90 milliseconds instead of the ~1500 milliseconds that a full bootstrap takes on this server. For simple content that any user can see, such as a published, publicly-viewable node, there aren't any security concerns. But if I need to perform any kind of access check, I need to know the current user's UID. I'm getting the UID by querying the sessions table for their sid/ssid. Consider this code:

  $session_name = session_name();
  if (!empty($session_name)) {
    if ($uid = db_query("SELECT uid FROM {sessions} WHERE sid = :sid", array(':sid' => $_COOKIE[$session_name]))->fetchColumn()) {
      $account = new stdClass();
      $account->uid = $uid;
      $account->roles = array();
      $account->roles[DRUPAL_AUTHENTICATED_RID] = 'authenticated user';
      $account->roles += db_query("SELECT r.rid, r.name FROM {role} r INNER JOIN {users_roles} ur ON ur.rid = r.rid WHERE ur.uid = :uid", array(':uid' => $account->uid))->fetchAllKeyed(0, 1);
    }
  }

I am not yet including logic for their ssid (HTTPS), as I just wanted to get a proof of concept working quickly.

Are there any security concerns that I'm missing here? I've gone through session.inc and, while I'm completely ignoring the anonymous user handling, page caching, etc., none of those really matter to me within the context of what I'm doing. If I don't have an authenticated user, I don't need to create a new session for them or anything like that, they just get an access denied response from the server.

Edit: I should add that, with the above $account, permissions checks like user_access() and node_access() can be run.

Edit 2: Here's the original issue where I'm dialoging on this particular topic within the js module: http://drupal.org/node/1922406

1 Answer 1

1

The approach is vulnerable to a man-in-the-middle attack but just like any connection that isn't encrypted (HTTP). An attacker could use this to read the comments of nodes they otherwise don't have access to.

Otherwise, without knowing more context of how this used and displayed I can't say there are no other security concerns. I'll comment on a possible XSS issue with your comment display code at http://drupal.org/node/1922406.

I would recommend that you check for the session cookie though:

if (!empty($session_name) && !empty($_COOKIE[$session_name])) {
2
  • 1
    Good catch on checking the session cookie. Regarding man in the middle attack – absolutely, but that's not really within the scope of this, i.e. that could happen on the "normal" Drupal login if it wasn't over HTTPS, right? Commented Feb 20, 2013 at 18:27
  • 1
    Indeed, if the whole site communicates over HTTP then any privileged session communication would be vulnerable to mitm, not just login.
    – bjeavons
    Commented Feb 20, 2013 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.