I'd like to remove the cookies of another site from users on my site. Is there any way to access the cookies from different domains.
No, the same origin policy forbids that. You can only view or set cookies that you set and that are valid for the current URL.
No, of course not. That would be terrible. How would you like it if any site you went to could just read your stored password to any site you have saved?
Try it and Google will block your site from Chrome and your whole site will end up being blacklisted as it appears to contain Malware! While it's not illegal, it's a kind of behaviour that makes you as popular on the Internet as the average spammer...
Furthermore, the storage of cookies depends on the browser that is used by the client. You don't have any control over that.
However, if the other site has an URL that will remove the cookie, you can inline that URL in an IFrame on your site so visitors of your site will call the cookie cleaner from the other site, thus clearing their cookie in a valid way. The Same Origin Policy will apply in this case since it's the original site that clears it. But if the other site offers no such functionality then it won't work...
The only place I can think that this you'd need this would be if you owned many domains, and you log in on one domain, you want to log off in another domain.
In php, the "setcookie" function has a way to specify a domain. You should put in the domain you wish for the cookies to be modified under. Then when you can erase/modify the cookies across all those domain.
Otherwise though, the answer is no, you cannot modify a cookie on another domain unless it gave you permission to modify such cookies.
Wow, I certainly hope there's no way to do this! If there is a way, it's a bug in the browser security.
Obvious follow-up questions: Is there any way I can set something in a user's browser that will prevent him from accessing a competitor's site? Is there any way I can cause other people's web servers to explode and kill everyone in the building?
Related
I have a code which generates iframe which user can embed on his site.
I want to show my iframe only on particular sites.
How can I do this?
For example:
I can give a unique key to user and use this key on server side.
But another user can get this key an use it.
Is there simple solution?
The referrer solution is not robust in any way. Referrer is something "said" by the browser it can be manually overridden as said above, moreover anyone could simply use a proxy and reintegrate the iframe.
So, basically, it depends on how much code can be put on the "Trusted server".
If you can, use one time tokens. Trusted server gets a list of tokens from server having the iframe. The url served by the trusted server contains the token which will be invalidated upon serving the content of the iframe. This does mean that there is a "write" for each read. And tokens will take some space.
You can use the referrer response-header as described in the HTTP standard.
Though expert users (the übergeeks/browsermodders) know how to omit this. You should may not do this for security reasons.
I use session objects in my web application which are traced by ASP.NET session cookie internally as we all know. So access to that cookie is essential to have access to session objects. I want my asp.net application work under http:// and http://www or any subdomain (domain is unknown to me at development time).
Can't be done. The session cookie only works for 1 domain and 1 domain only.
You could, however, write your own session management system and maybe accomplish shared session that way. I still don't think you'd be able re-use the cookie because the browser won't even send it in the first place.
After some more thought I've decided that I'm not sure. :) Perhaps if both subdomains map to the same ASP.NET application you could get share session to work. All you'd have to do is set your cookies as such:
<httpCookies domain=".maindomain.com">
If the different subdomians don't map to the same app, I think you'd definitely have to write your own session management.
Clearly, at this point you should take everything I've written with a grain of salt. I'm only leaving my answer up for you to get some ideas and so that people may comment on the correctness of it.
Why don't you leave domain field empty? That way you won't bind your cookies to some specific domain and will be able to play well whatever the domain of your site will be.
I have an application with different sections. Each section is accessed through a domain. Example: www.section1.com, www.section2.com, www.section3.com. I need to preserve the session when the user navigates from one to another URL. The application is the same in IIS. How to accomplish that?
You will need to pass on the session-cookie, and re-set that cookie on the new domain. That will make the session live over several domains (assuming you use the same app).
Example:
Link from section1.com:
<a href="http://www.section2.com/?s=askdjh3k4jh234kjh">
then, OnSessionStart (or OnRequestStart) check for query-parameter s and attach session to it. Meaning, just manually set cookie ASP.NET_SESSIONID to the value you pass on.
This has severe security-implications, so don't allow this unless you know what you're doing. another solution might be to store something into a common backend (database?) and pass around the user with a token that represents the actual session (and set the cookie based on that token), that you generate on a middle-page when navigating away from section1.com -> transferusertonewdomain.aspx -> section2.com/?token=randomTokenThatMatchSessionInDatabase
That would prevent that anyone could hijack a session by jsut knowing the value of the cookie. However, that is possible never the less if you're somewhat familiar with a computer anyway.
If you have multiple domains (and not just subdomains, which are easier), you're going to have more complications doing this than you'd like, because you can't share cookies across different domains.
The usual workaround is to embed a link an image on the other domains that are served by an asp.net page (or HttpHandler if you like). That page should contain a querystring with a unique token and a hashed version of that data appended with some shared secret. Then, that page will set a cookie on the response appropriate to for that domain to associate itself with appropriate data. It will serve typically a 1x1 transparent image as the response. Usually you only want to do this upon login to one of the sites.
Unless you do some customizations, session is specific to an application regardless of session mode you are using. Here's an article that talks about how to customize SQL session so that you can use session across multiple applications.
You should start by change the sessionState from being "InProc" to either StateServer or SqlServer, ensure that the MachineKeys are identical across all sites (domains and servers), and then set up the relevant backend systems to capture the state information.
More information can be found on:
Session-State Modes
ASP.NET State Management Overview
You could use a cookie to pass it, still researching to find out how. I will repost.
** EDIT
There is another Stack Overflow question, see if it helps, 315132
It basically asks
I need to share SSO information
between two different domains with a
cookie, can this be done in PHP and
how?
the answer given was
On both domains, place an image or
other web element that is pulled from
the other domain. Use the URL to
notify the other domain that user X is
on domain A, and let domain B
associate that user ID with that user
on their system.
It's a little complex to carry out
correctly, but if you think it through
it'll work out very well.
Vinko points out in a comment
(thanks!) that I shouldn't take it for
granted that you understand the
security risks involved. If this
information is of any value to anyone,
then you should make sure you use
proper encryption, authentication, etc
to avoid releasing sensitive
information and to avoid various
attacks (replay, man in the middle,
etc). This shouldn't be too onerous
since you control both websites and
you can select a secure secret key for
both, since the communication is only
going between the two servers via this
special URL. Keep it in mind though.
The user is Adam Davis.
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 :)
When do you initially get assigned your unique http cookies when visiting a website?
I'm asking this in the sense of when creating a gui auth login from a website. Do you get your cookies the moment you visit the website? If so, if you don't visit the website by homepage and go straight to the http://website.com/login.php form, do you initially also get your cookies there if you haven't received them yet?
On load of the the first page that sets a cookie.
It will be sent along with the content of that page, in the HTTP header.
In PHP:
You can set a cookie any time before sending output to the browser.
You can read it (via $_COOKIE) any time after setting it, including in the same page load.
Just remember that if you read it in the same page load where you set it, you are reading it from the current process, and not from the client's cookie, which won't have been sent yet.
The server/application can set cookies whenever your browser makes an http request. In other words, the answer is implementation-dependent.
I would suggest that you take a look at Fiddler (or some other http tracing tool) to better understand the interaction.
There is no correct answer to this. It is an implementation detail that no two websites (using different base code) do the same way. Variables include the implementation system/language (ASP, PHP, Python, Ruby, etc), use of standardized (or custom) libraries, how security-minded the website is, how long ago the website was written, etc.
Most websites will set your session cookie no matter what page you first arrive from. There are many ways to do this but all involve every possible entry point calling common routines in the website's source code for handling sessions, permissions, navigation, logins, etc.
Having said that, I'm there a significant number of websites that do not set any cookies until you do something that needs to be remembered (login, adding a product to a shopping cart, setting a preference, etc).
How you should do it depends on what is important to your website. There is no single answer to this.
Here's the official standard for cookies and their behaviors:
http://www.ietf.org/rfc/rfc2965.txt
Most browsers will try to conform to this standard as closely as possible, but note that it is up to the implementer. If there are bugs, then of course the behavior is different.
I think the thing you're looking for is that cookies are passed in with the request as long as the domains or URI are the same.
As someone else alluded to, cookies can be manipulated and are inherently insecure. Don't use them as a way for security. You can keep track that they've been logged in successfully with them, but you should put an expiration date on that fact.