I know the security risk associated and have brought it up with the business, but they want to have their 5 domains to share the login cookie.
We are using and have no plan to stop using ASP.Net Membership and Profiles. Is this possible? A hack would even be greatly appreciated.
It is not possible with out of the box ASP.NET.
Forms based authentication is based on a cookie and cookies can only be set to a specific domain.
If you want true cross domain (not sub domains) shared authentication, you need a Single Sign On solution.
I've rolled my own and it's relatively simple. The basic principle is that you have a master domain which holds your authentication cookie (ticket). You then redirect to that domain from all other domains. It's not really pretty, but event Microsoft Passport worked that way.
You can find a lot of examples on the net, take a look at these two links:
Authentication cookies
Cross domain authentication
You may setup all these domains as sub-domains for your company:
www.company.com
shop.company.com
sales.company.com
research.company.com
..
then you will be able to set cookie to the parent domain and it will be visible for all sub-domains.
var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
cookie.Domain = ".company.com";
Repsonse.Cookies.Add(cookie);
Regards,
Max Chernyshov
http://prontocoder.com
Not only with ASP.Net is this not possible, but not at all. Cookies are always domain-specific - no commercial browser will work any other way. This is by design and very much necessary to prevent widespread abuse of cookies.
Muerte pointed you into the right direction (single sign-on).
Related
Is there a way to share cookies across different domains and different applications (classic ASP and ASP.NET)
No, there isn't.
The issue is the cross domain one, rather than the asp.net/classic asp and is security reasons.
If the domains are subdomains you can share the cookies, provided you use a cookie path that both can access (ie. for the domain sub.example.com you can read and write cookies using the example.com domain).
You can share cookies via some behind the scenes communication between servers, or through querystrings.
Both are ill advised, unless the information in the cookies is harmless (but be aware that harmless looking data quite often isn't actually harmless).
Native support for accessing cookies is not possible cross domain, and probably will never be for security reasons.
you can use cookie convertor which save all the cookies in the share database and try to recreate them again.
I have been trying to Google over this topic like crazy. I have this primary domain that has got a couple of subdomains and alied domains. All of these sites share the same set of members that will log-on. Naturally I will have to give them a single sign-on. So I have been looking various forums(including ours) and still have no luck. This is what I have done uptil now.
I have set a common machine key and decryption key of all the websites and also my authentication mode is set to forms. As far as sub domains are concerned, they work fine and a user signed in on the primary gets acknowledged on the sub-domain. The same case unfortunately does not work on domains(and I know cookies cannot be accessed across domains but I have set the machine key and decryption key).
Yes and no. .NET does not support this "out of the box".
If you're willing to force users to a specific domain to sign in, you can then redirect users to that domain/login page. After you have authenticated the user on your primary domain, then you redirect the user back to their original page and post some kind of encryption key to the page that tells the site that the user is authenticated, you then set a cookie for the new domain if you want a persistent authentication cookie.
This is more or less the method used by sites such as Stack Overflow when using Open ID, or for msn when using live id.
Is there a way to share cookies across different domains and different applications (classic ASP and ASP.NET)
No, there isn't.
The issue is the cross domain one, rather than the asp.net/classic asp and is security reasons.
If the domains are subdomains you can share the cookies, provided you use a cookie path that both can access (ie. for the domain sub.example.com you can read and write cookies using the example.com domain).
You can share cookies via some behind the scenes communication between servers, or through querystrings.
Both are ill advised, unless the information in the cookies is harmless (but be aware that harmless looking data quite often isn't actually harmless).
Native support for accessing cookies is not possible cross domain, and probably will never be for security reasons.
you can use cookie convertor which save all the cookies in the share database and try to recreate them again.
If I am on a website#1, and I enter my username/pwd for website#2 on a login page that is on website#1, and website#1, behind the scenes, makes a httpwebrequest to website#2 and posts to the login page. If I then navigate to website#2, should I be logged in?
website#2 uses formsauthentication and I call a httpHandler that is on website#2 and pass it the username/password via the querystring.
Should this work?
What you're trying to do is called Single Signon. The way you're doing it, posting values from one site to another, probably won't work because you're using the same technique a hacker might use to trick user into sharing their login information. It's called a cross-site request forgery attack. IIS is configured not to allow that.
Generally, you need a central authentication system that both sites use to share login information. This can be done in several ways, including a shared database-based login system. Google "asp.net single sign on" for more ideas.
Do site #1 and #2 want their users to have single sign on?
If so, read up on single sign on. It's a bigger project than can be addressed here. There is a good book on it though from Wrox :
http://www.amazon.com/Professional-ASP-NET-Security-Membership-Management/dp/0764596985/ref=cm_lmf_tit_10
Or are we imagining something sinister?
If we are imagining something sinister, then evil site #1 would collect the credentials, then automate a browser on the server side to start checking to see if site #2 uses the same password and user combination. Then the server would have an authenticated session. This wouldn't give the user who accessed site #1 an auth cookie, the HttpWebRequest object on the server would get the auth cookie. Site #2 couldn't really do anything to prevent this because a browser request from one computer looks much alike a browser request from another. A well crafted attack would spoof all elements of the browser's request so that it looks like it came from a browser instead of a primitative HttpWebRequest object, which may not even set the user-agent.
Site #2 should stop using passwords and user Id or use 2 factor ID if they are concerned abut this, or do something that requires javascript for logon because spoofing a browser that is executing javascript is harder than spoofing a browser that just sends and receives http requests and responses.
There are too many security issues trying to auto-authenticate between sites. There needs to be a central security provider that both sites belong to so that hand off is completed securely.
We use CA's Siteminder for cross site authentication. Effectively, web 1 creates a unique session id on the siteminder server and passes any credentials and info to it. Siteminder invokes web2 and passes the information by means of session variables. Web 2 retrieves the data from the session and uses it. There's much more going on there but that's the just of it.
To do something like this, I would strongly consider using an out of the box solution as generally coding up custom security generally falls short.
While this can be done on some cases, in the form of an HTTP request with POST parameters, you will not be authenticated once you browse to site #2.
This is because, generally, these sites store a cookie on your end and these are domain-based, which means that even if you grabbed that and stored it yourself from site #1, the cookie name would not match site #2.
Additionally, site #2 may not be easy to authenticate against and this is usually a security concern that developers are aware of. This can be considered an attempt of XSS as well.
In case you're simply doing this for yourself, I'd recommend LastPass and save most of your info in it.
Please reconsider your goals and how to achieve them, this is not the way.
Edit: Link text.
This could work, depending on the security measures in place on website #2. For a secure website, this would fail.
I would recommend against this purely on the basis of good security and good coding/design practices.
If you are unclear what security measures stop this, you should probably educate yourself so you can prevent the same issues on your own site. See http://www.owasp.org/index.php/Top_10_2007
Since both your sites are using FormsAuthentication you can easily configure both of them to share FormsAuthentication encryption schemes.
This will allow you to do Cross Application Authentication automatically :)
Wondering if it is possible for my claims aware application (ASP.NET) to save a cookie that can be read by the ADFS Service (ASP.NET also). This is so I can give it the URN of a specific client at the time of the SSO based on the subdomain. However I am not sure if a website can read cookies from a different website or not.
I think it's possible, but only when both webapplications are on the same domain. The following question, and especially the marked answer, handles a similar question:
sync cookies and sessions in different subdomains (asp.net)
If it were possible to do it with different domains, that would be a huge security risk. Then your cookies would be readable by any other website you visit. So I don't think that's possible. But if I'm wrong, someone please correct me on this one.
Further information # MSDN: http://msdn.microsoft.com/en-us/library/ms178194.aspx.
See the section called Limiting Cookie Domain Scope.