Jump to content

Recommended Posts

I started http://forums.phpfreaks.com/topic/292413-cookie-priority-with-common-names/ a while back, and basically heard that I should use separate domains if I wish to ensure that cookies cannot be manipulated between one another.  For instance, each of the following three URLs will have their own cookies which cannot be accessed from the others.

  • joe.user-sites.example.com/index.php
  • joe.site-admin.example.com/index.php
  • main-site.example.com/index.php

Problem is I don't wish to force the user to use these long URLs.  Instead, I wish the user to see:

  • joe.example.com/index.php
  • admin.joe.example.com/index.php (or joe.example.com/admin/index.php if it is easier to make secure)
  • example.com/index.php

 

How is this accomplished?  Thank you

Link to comment
https://forums.phpfreaks.com/topic/292517-cookies-per-subdomain/
Share on other sites

There seems to be some confusion.

 

The whole point of the “long URLs” is to put the user sites into a separate namespace so that people won't mistake them for your content. Imagine a user choosing a name like “login”. In your model, they'll get the domain login.yourdomain.com and may fill it with any content, which is obviously a big problem (it would allow them to perform the perfect phishing attack).

 

To make a clear separation between your content and the content of your users, I suggested the user-sites subdomain. Obviously you don't want that. Well, then don't use it. But this means you have to manually check every single registration and make sure people won't choose confusing or “dangerous” names (“joe” would be OK, “payment” probably not).

 

Either way, using the “short domains” as some kind of alias for the long ones would cirumvent the whole purpose.

Thanks Jacques1,

 

Yes, there was some confusion, but less so now.  Not saying I necessarily do or do not wish to do so, just that I wish to understand the implications.

 

Good point about login.yourdomain.com, and I probably should put some controls in place for login.user_sites.yourdomain.com as well.

Yes, you'll probably want a blacklist to at least block the obvious abuse.

 

Ideally, the user sites shouldn't be on your main domain at all, because any official-sounding subdomain will be attributed to you. But I understand that the whole purpose of the project is to host the sites under your name. ;)

After giving more thought, I am going with the longer domains as you recommend.

  • bob.public.mysite.com
  • bob.administrator.mysite.com
  • www.mysite.com

 

The "administrator" subdomain is user defined, and I will just query the DB using the name "bob" to confirm it matches, else return a missing page header.

 

www.mysite.com is the features/signup/etc site.  It seems to me that "www" is just another, albeit very common, subdomain.  Cookies under this site will be isolated from the other two, right?

That looks good.

 

However, a subdomain can set a cookie for a parent domain. So bob.public.mysite.com is able to create a cookie for .public.mysite.com which would get sent to all user sites as well as www.mysite.com. This comes with several problems:

  • If you fail to regenerate the session ID, it's possible to perform a session fixation attack: Bob would simply set a custom PHPSESSID cookie for .public.mysite.com and wait for the victim to log in with the known session ID.
  • If you keep the anti-CSRF token in a cookie, an attacker may be able to overwrite it with a known value and circumvent the protection.
  • Anybody can start a session and make another visitor resume it. Imagine the following scenario: I log in under my account on this forum and plant the session cookie on you. Then you write a private message to somebody, not realizing that you're logged in as me. I'm now able to retrieve your private message from my own message folder.
  • There's no defined precedence for cookies which only have different domains, so your session cookie may actually be overriden by a “fake” cookie, leading to a denial-of-service attack.

Some of this can be fixed, some problems you simply have to accept. In general, pay extra attention to any cookie-related features, especially the sessions.

Not saying I didn't trust you :), but I put together the following script just to prove it to myself.  Sure enough, using domain .mysite.com allows subdomains to set cookies for one another.  I'll need to mull it over for a bit.  Thanks again for your help.

<?php

$domain=explode('.', $_SERVER['HTTP_HOST']);
$primary=$domain[count($domain)-2].'.'.$domain[count($domain)-1];
$value="value for cookie {$domain[0]}";
$host=$_SERVER['HTTP_HOST'];
$cookies=print_r($_COOKIE,1);

setcookie('server_side_cookie_'.$domain[0], $value);

echo("<script type='text/javascript'>
    document.cookie = \"client_side_cookie_{$domain[0]}='{$value}';domain=.{$primary};path=/\";
    </script>
    <p>Host={$host}</p>
    Cookies Array:<pre>{$cookies}</pre>");
?>

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.