How To Prevent Cookies From Being Created Under Different Hosts - asp.net

I've run into a problem and I'm not sure how to go about fixing it. Here is the scenario.
A user visits my website (www.MyWebSite.com) and clicks on a button that puts a cookie on their computer. If I examined that cookie on their machine it would list the "host" as www.MyWebSite.com.
If the user then changes the URL in their browser to MyWebSite.com (without the www) reloads the page and then clicks on the button, a brand new cookie with the same name as the first cookie is created. The host of this cookie is MywebSite.com
Obviously this is not good - beside two cookies with the same name, only the cookie with the corresponding URL address is being read by my program.
Can I force cookies to be created with the www host and/or can I force the page to be www or what??? What and how is the best way to prevent this problem?
Cookie Creation using VB.net
Response.Cookies("AAA")("bbb") = strABC
Response.Cookies("AAA").Expires = DateTime.Now.AddDays(1)
Any help is greatly appreciated.

For (obvious) security reasons you can only read cookies that are set by the same domain the user requests. It doesn't matter if it is just a difference like in your example, or an entirely different domainname.
What you could do in this situation (it should improve your SEO as well), is redirect (301) all traffic from the site without www to the site with www.
If you're using IIS 7 or higher, you can find an example on how to do that with URL Rewrite here: http://weblogs.asp.net/owscott/archive/2009/11/27/iis-url-rewrite-rewriting-non-www-to-www.aspx

That's for security reasons. Any subdomain of a host is considered to be another realm, another world.
If you want your cookies to be sent to your subdomains too, then start the Host attribute of the cookie with a .. In other words, set your cookie for .MyWebSite.Com.
See Wikipedia for more information.

Related

Same cookie to 2 domain drupal which is One site

I have a Drupal 6.22 webpage. And I have a .de and a .at top level domain. Now the .at domain is an alias of .de. And I want:
I want to use the .at and the .de domain separately, exactly when anybody open my .at/indexp.php, not drop trough the .de domain.
I want to monitoring the incoming users.
So I want to hosting 2 site from 1 server, and I want to have a same login cookie, so anybody log in at .at, and navigating to .de, he keep logged in.
I know, the 2 page with same cantainment is killing the SEO, so thats a new more question.
I tried to solve the "Same Cookie" problem width $cookie_domain, but i can't. As I read, it's just working with 2 different server's 2 different sites.
Without some coding to authenticate the user between both sites, you can't do this.
Technically, browser won't send the cookies to other domains.
If the $cookie_domain is example.com, then www.example.com, extras.example.com will not get the cookies of example.com.
If it's .example.com, all example.com and its sub domains will get the cookies from browser. (note the leading dot before example.com)
You can't send example.com's cookies from another domain. That's why you are seeing you get redirected to Youtube and back to google when you login at a google domain.
You can point both domains to the same domain and it will work without a problem. But users will have to login twice in both sites.
Alternately you can send the user to the other site right after they login.
For an example, when user logs in at example.com, when the login is successful, send the user to the other domain immediately and the other site (example.net for instance) can do the same authentication and send user back to the origin site.
I don't know any module that does this though.

Pass session through secure channel without losing it

I have installed nopcommerce v 2.5 on abc.domainName.com and I have a wildcard SSL Certificate to different domain name but on Same server ex abc.domainNameSSL.com. So When I'm using it, When I transfer from non-secure page to secure page, I am losing my session.
So Can anyone tell me What is best way to pass session in this condition.?
Thanks in advance.
If you are authenticated on one domain and then transfering to another domain, you'll loose the session cookie because it can not cross domains.
For example if you are logged into abc.name.com and then transfer to another domain (i.e. abc.nameSSL.com), even if it is the exact same website you'll loose the session. The server is looking for the session cookie which was stored under abc.name.com. Now that you are on abc.namessl.com it can not find it. Thus you are not logged-in.
A work around would be to not change the root domain (name.com) and instead do something like abcssl.name.com. You'd have to set up a domain wildcard for the session cookie, but it would work.

asp.net cookies subsites

How should I go about creating a cookie that can be read on my sites URL, and all subsites.
i.e. cookie called "myCookie" created on http://www.mysite.com/
Once created, it can then be read on http://site1.mysite.com/ and http://site2.mysite.com/ etc etc.
The above scenario should happen if the user has opted to "remember" their cookie.
I am assuming that if the cookie isn't persisted, it will be "lost" when the change site.
The above sites are in their one IIS entries, and in my case, completely different servers.
Cheers!
EDIT:
I created my cookie on the sub-domain, so that fire cookie reads its domain as ".mysite.com".
The mainsite doesn't recongise this cookie, but I think it is their site that needs to change.
Create the cookie so that my site can read it,
Be able to read the cookie is my site creates it.
You are going to need to fix your cookie domain on your PHP site. The subsites will not be able to read your cookies unless you do that. Since you are saying that your main site is in PHP and the cookie domain is "www.mysite.com", this will need to be done on the PHP side.
ini_set('session.cookie_domain', 'mysite.com');
You are not going to be able to read it otherwise.

web application with secured sections, sessions and related trouble

I would like to create web application with admin/checkout sections being secured. Assuming I have SSL set up for subdomain.mydomain.com I would like to make sure that all that top-secret stuff ;) like checkout pages and admin section is transferred securely. Would it be ok to structure my application as below?
subdomain.mydomain.com
adminSectionFolder
adminPage1.php
adminPage2.php
checkoutPagesFolder
checkoutPage1.php
checkoutPage2.php
checkoutPage3.php
homepage.php
loginPage.php
someOtherPage.php
someNonSecureFolder
nonSecurePage1.php
nonSecurePage2.php
nonSecurePage3.php
imagesFolder
image1.jpg
image2.jpg
image3.jpg
Users would access my web application via http as there is no need for SSL for homepage and similar. Checkout/admin pages would have to be accessed via https though (that I would ensure via .htaccess redirects). I would also like to have login form on every page of the site, including non-secure pages. Now my questions are:
if I have form on non-secure page e.g http://subdomain.mydomain.com/homepage.php and that form sends data to https://subdomain.mydomain.com/loginPage.php, is data being send encrypted as if it were sent from https://subdomain.mydomain.com/homepage.php? I do realize users will not see padlock, but browser still should encrypt it, is it right?
EDIT: my apologies.. above in bold I originally typed http but meant https, my bad
2.If on secure page loginPage.php (or any other accessed via https for that instance) I created session, session ID would be assigned, and in case of my web app. something like username of the logged in user. Would I be able to access these session variable from http://subdomain.mydomain.com/homepage.php to for example display greeting message? If session ID is stored in cookies then it would be trouble I assume, but could someone clarify how it should be done? It seems important to have username and password send over SSL.
3.Related to above question I think.. would it actually make any sense to have login secured via SSL so usenrame/password would be transferred securely, and then session ID being transferred with no SSL? I mean wouldnt it be the same really if someone caught username and password being transferred, or caught session ID? Please let me know if I make sense here cause it feels like I'm missing something important.
EDIT: I came up with idea but again please let me know if that would work. Having above, so assuming that sharing session between http and https is as secure as login in user via plain http (not https), I guess on all non secure pages, like homepage etc. I could check if user is already logged in, and if so from php redirect to https version of same page. So user fills in login form from homepage.php, over ssl details are send to backend so probably https://.../homepage.php. Trying to access http://.../someOtherPage.php script would always check if session is created and if so redirect user to https version of this page so https://.../someOtherPage.php. Would that work?
4.To avoid browser popping message "this page contains non secure items..." my links to css, images and all assets, e.g. in case of http://subdomain.mydomain.com/checkoutPage1.php should be absolute so "/images/image1.jpg" or relative so "../images/image1.jpg"? I guess one of those would have to work :)
wow that's long post, thanks for your patience if you got that far and any answers :) oh yeh and I use php/apache on shared hosting
If the SSL termination is on the webserver itself, then you'll probably need to configure seperate document roots for the secure and non-secure parts - while you could specify that these both reference the same physical directory, you're going to get tied in knots switching between the parts. Similarly if your SSL termination is before the webserver you've got no systematic separation of the secure and non-secure parts.
Its a lot tidier to separate out the secure and non-secure parts into seperate trees - note that if you have non-SSL content on a secure page, the users will get warning messages.
Regards your specific questions
NO - whether data is encrypted depends on where it is GOING TO, not where it is coming from
YES - but only if you DO NOT set the secure_only cookie flag - note that if you follow my recommendations above, you also need to ensure that the cookie path is set to '/'
the page which processes the username and password MUST be secure. If not then you are exposing your clients authentication details (most people use the same password for all the sites they visit) and anyone running a network sniffer or proxy would have access.
Your EDIT left me a bit confused. SSL is computationally expensive and slow - so you want to minimise its use - but you need to balance this with your users perception of security - don't keep switching from SSL to non-SSL, and although its perfectly secure for users to enter their details on a page served up by non-SSL which sends to a SSL page, the users may not understand this distinction.
See the first part of my answer above.
C.

ASP .NET create other Session when switch to http://example.com or http://www.example.com

If I type http://example.com and login to my site and close my browser, re-open it and retype http://example.com then I am logged in.
However, when I type http://example.com, login, close the browser, re-open it, type http://www.example.com then I am NOT logged in.
I do not use ASP .NET authentication classes.
I run IIS 6 with both example.com and www.example.com URLs added to "Multiple identities for this web site" in IIS.
I do not wish the current behavior. Are there other things that can be affected because of this behavior?
Please make sure from your domain panel that it is referring to same IP Address and code.
I was having same issue and found that IP Address was different.
The problem is that you can't share cookies between example.com and www.example.com, due to a quirk in the cookie specification.
Instead, what you should do is pick one of the domains as your primary. Then, detect references to the other domain, and redirect users from there back to the primary. For example, you could choose www.example.com as the primary, and redirect references to example.com back to www.example.com.
That way, the authentication cookies will be present if the user tries to switch from one domain to another.

Resources