There are 2 domains on one server. If user is logged on one domain he has to be logged on the another domain too.
How to make cross-domain authorization in php on one server?
I solved it for sub-domains, but can't solve for different second-level domains.
The main problem is that the cookie isn't send by the browser if you're on another domain.
You can't make the browser to write a cookie for another domain, too.
What can be done is send a unique token to the other domain, and when validated, write a cookie on the second domain. That can be done when authenticated, using an iframe or a double-redirect (iframe cookies are blocked by some browsers, like safari). The unique token will have to be validated by the second domain, and then invalidated (removed) so it can't be used again by another user (man in the middle attack).
You must research for CAS and implement it depending on what framework you are using. For example, in my Zend application I would use Zend_OpenId and Zend_Oauth .
Related
I'm learning about Laravel passport package and creating a SPA using Vue.js to test it, I'm wondering about saving the Token in the client browser, If I saved it on local storage it would be accessible from Javascript and anyone run js on the browser would be able to read it !
My questions are; What is the solution for this situation ?
If I saved the token in the cookies It would be accessible too, and I read about httpOnly cookies, so How can I set the cookies to save the token from the response from the API if it's not accessible by Javascript ?
Is there a way to save the cookies from the API ?
I hope I can find answers for my Questions.
Well, there are a couple of things to understand here.
HTTP only cookie
First, HTTP cookies are set by the server using set-cookie header. In this case, you as a developer need not do anything. The browser will automatically set it for you and will send back to the server on each Ajax or non-ajax requests. It will send the cookie as long as it is not expired.
LocalStorage
When using LocalStorage for storing the token, any JavaScript code can read it (known as XSS attack if misused). But, the key thing to understand here is that other domain's JavaScript code cannot read the LocalStorage. The scope is restricted to your own site. Other website's JS cannot read it. So, if you are not using any external dependency or compromised CDN, you are safe.
Cross-site cookie
No. It is impossible to set a cross-domain cookie under any circumstances. Only other domain's server can set a cookie for itself (Unless you have some backend mechanism like Gmail + Youtube to share session). However, in case of a subdomain, the following things are allowed:
Parent domain can set a cookie for any child domain. That is example.com can set a cookie for *.example.com.
Child domain can set a cookie for the parent domain. That is xyz.example.com can set a cookie for example.com.
Of course, the rules are more complicated than that. This article should help you understand further.
I'm currently facing a following problem:
A main domain is running a particular PHP framework with framework specific sessions; now there is a new subdomain, which runs a different PHP framework, and I need to share the login session information from the main domain with the subdomain. I.e. users only register on the main domain, but once logged in, they will also be logged into their account on the subdomain. And it should also be noted that the subdomain cannot have access to the main domain db.
With these restrictions, I came up with the following solution: first I set the domain cookie to .mydomain.com, so I can access the session cookie on the subdomain. Next I implement a simple API call on the main domain, which returns loggedin status as well as other session information. The API url will have IP whitelist limited to the subdomain server, and once loggedin user comes from the main domain to the subdomain, the API url is requested with the users cookie serverside (cURL presumably). Once and if the user is authenticated this way on the subdomain, he is assigned a token for the particular session, and from there on I can manage that as a regular and separate session on the subdomain.
Now my question is whether you can see any flaw security-wise in this setup? Or suggest any improvements or a more preferable way to do this...
Thanks
For me, i think i will use single sign-on concept. Once user logs-in through any of domain or sub-domain, generate access-Token for that user, sign-in.
After that use that same access Token to check and authenticate user for different domain names, instead using separate sessions. This might lead to session hijacking and difficult to manage multiple sessions. Once session is created, allocate access-token, with access rules. This will make seamless process for sign-in and easy to manage as well.
For more information look to search Single Sign on or OAuth 2.0 protocol.
Im familiar with reading cookies using php, but i was wandering if there is a way you can read a users browser cookies set by another 3rd party site (ie. not your own.)
Could somthing like this be written to view all of the users set cookies ?
print_r($_COOKIE);
No, it's impossible.
You can only read cookies that come from your own domain. The other cookies are not even sent to your server.
If you could read every cookies the user has, you would be able to obtain personal information such as their facebook password, connection to their bank etc.
It would be a serious breach of privacy, and as such, browsers do not send cookies except those from the same domain.
No
When you visit a website, your web browser requests information from that domain (somedomain.com), and that third-party domain is allowed to set a cookie. Each domain can only read the cookie it created, so there is no way anotherdomain.com could access the cookie created by somedomain.com.
To read a cookie you must match the domain that the cookie was originally created under. Browsers consider this a security principle and will not let a site access any cookies that they did not create.
Note that there are several other security considerations that could potentially circumvent this rule, such as DNSMasq in combination with spoofed browser certificates. This is why DNSSec (and SOPA) were such a hot issue; the security hole DNSSec plugs will also protect your cookies from getting stolen from your cookie jar.
There are real-world examples of security holes that have leaked in the past. See here for an example of an even different security vulnerability from 2008.
No, this is not possible, because browser only sends the cookie that set by your domain, usually, it's attached to header of the HTTP request if previously being set by the domain.
Third party cookie are those cookie that set by another domain in the context of the target domain, for example: while opening example.com it might has a banner from another website (example2.com), at this case, if example2.com set cookie it can't be read by example.com because they are from different Origin that Browser prevent even scripts to access it.
No, of course not. Otherwise your website would know my bank's login cookie, and you'd be able to steal all my money. Cookies are only available to the domain that set them.
I have a webserver with a drupal 7 installed on.
Many primary domains are pointing to this webserver (es domain1.com, domain2.com) and each domain is see the same website.
But if i log in into one (domain1.com) when i visit the domain2.com i'm not logged in.
I know that is a domain cookie problem, but there is a way to generate the cookie for a list of domain when i register/log in?
Hope that someone can help me
Here my module developed for getting a SSO system working with Drupal and Domain Acces.
https://github.com/andreacavattoni/DomainSSO
This is the very good question and have done small research on your question on different ways:
OAuth:
After reading the documentation and gone through many service providers it is not possible. Oauth service provider gives the consumer key and secret and they check the request coming from the domain and thus if the same oAuth consumer key is used on different domain Names that doesn't work.
Setting Cookie Multiple domains
Simply, it is not possible to set the cookie without visiting the domain by any means
Thus, I can say that it is not possible to set cookie or use the same consumer key and secret for multiple domains
Alternative ways
Use HTML5 Web Storage for storing the information and then accessing
the information from different domains is possible.
Use AJAX/CURL for sending the request for setting the cookie for different domains such as example.com/session_cookie.php?info=xxxxx
Maintain a single sub-domain/page for all the domain for login purpose for across all the domains.
I think you may want to look at Bakery
Could be of interest: Stack Exchange Blog: Global Network Auto-Login (using HTML5's local storage)
Is there a way to disable PHP sending cookies in a specific page's header, on a server that normally uses cookies?
The scenario is that I have a server that uses cookies, but some pages are actually programming API calls that don't need cookies, and in fact slow down the user's API request by sending this irrelevant data.
The way that many sites use to serve their static resources without the cookie overhead is using a different domain. For Stack Overflow, for example, that domain is http://sstatic.net
In a web app, you can restrict cookies to a specific path. By default, they will be restricted to the directory in which they were set. You can also explicitly specify it using the $path parameter in setcookie().
I agree with Pekka's answer and Dagon's comment. If you look at what goes in an http request with a tool like firebug you'll see that cookies are only sent when there is a setcookie call, however, the browser will always send valid cookies it has for the domain.
The way around this is to use a seperate domain or subdomain for your api. You can also configure the web server supporting the api to disable any support for cookies, however, if your domain has implemented a domain cookie anywhere, you can't stop the clients from sending all the cookie data in the header of their requests. Thus it's probably best if you use an entirely different domain for your api, and avoid cookies entirely in doing so. If you can insure that no domain cookies exist, then subdomains is the next best solution.