I have a slightly strange scenario, but a problem that needs solving all the same!
Please note, the websites described below are on different top level domains
I have two web applications, 1 ASP.NET MVC, and another in PHP, both on separate domains. Lets call them asp.com and php.com. Users authenticate on asp.com, and therefore have an authcookie set by ASP.NET.
Now the php.com website fetches data via a rest service from asp.com. This rest service authenticates via the same mechanism, so when I call this rest service via javascript JSONP from php.com it works fine. However I wish to call the same REST service from the server in PHP.
Is it possible to somehow get the asp.com website to copy and set an authcookie for php.com (the domain is known and trusted), and then in the PHP code pass this cookie on to athenticate against the REST service on asp.com?
It doesn't need to be the exact AUTH cookie, I could create a new cookie with the relevant session key, an long as a valid authcookie could be created and submitted to the REST service.
Questions
Is this possible?
How do I set the cookie for php.com in asp.com?
Short of one of the domains becoming compromised, are there any
security concerns?
No
The first site, asp.com, will have to redirect to a page in php.com. Then php.com can set the cookie itself, and redirect back to asp.com.
Yes, which is why you can't do it.
Also, see this answer.
Related
Background:
We currently have a fully functional CAS implementation using JSP, but want to migrate it to a PHP implementation.
Currently, we have a central CAS server that authenticates the user and redirects them to a landing page(in JSP), which then takes their authentication data and passes it onto a third-party-application.
In this JSP we use the following snippet to retrieve the user's data
String usr = request.getParameter("id");
String nid = session.getAttribute("netid");
Question
How do I retrieve this information using PHP?
I have tried doing:
$_GET
$_POST
$_REQUEST
$_SESSION
and more.
I have a feeling that I may need to install phpCAS in order to do this, but do not want to do so unless absolutely necessary.
Thank you for your time.
Every consumer of a CAS service ticket needs to be able to validate a token, parse the response, etc. It seems like you're currently using some JSP-based CAS client which is doing the work for you? (possibly Yale's, as the Jasig one does not deal with JSP). If you want to switch your client to a non-JSP/Java application, but to a PHP one, your best option is to protect that page/client application with phpCAS. phpCAS will intercept the ticket in the url, validate it against the CAS server and set the appropriate session variables.
Here's a simple example of phpCAS in action:
https://github.com/Jasig/phpCAS/blob/master/docs/examples/example_simple.php
Alternatively, you can write your own interception/validation/parsing code, but since this is a security product, I recommend using one of the well-known/tested clients.
For my example , i'll use this variables :
first_site.com = my website where i will execute the cookie get commands
specified_site.com = my second website that the client is already logged in
my_server.com = my server adress where i have a php script to handle the received data
the user is already connected to first_site.com and specified_site.com
and i want to get cookies from "first_site.com" and save them to "my_server.com"
Any way to do that , with php or javascript ?!
Regards
If both sites are yours and you have access to the server-side code on both sites, then you can have the first server forward the cookies to the second server using server-to-server communication.
The "same origin" protections built into a browser try to prevent you from doing what you want to do from purely client code (without involving both servers).
This is because you can only retrieve cookies when your page is on the domain that the cookie belongs to. And, you can only send the cookie (using ajax) to a server on the same domain as the page. So, you can't send one domain's cookie to another server. This is an obvious security violation which the browser intends to block with its "same origin" protections. You can read about those protections here.
If, you have a cooperating server from the first site, you can have that server retrieve the cookie when it is sent along with the original page request and then that server could send the cookie along to your second site using server-to-server communications. If the first domain is not yours where you can modify the server-side code, then obviously you can't run code on that server to do this.
There is no way to do that, as it would be a hudge security flaw.
Imagine if I made a website saving all your PHPSESSIDs, I could access your profile on many websites...
These are few of the options. Not the best ones though. Some general pointers to get you started:
a. You can also consider setting up VPN. This whitelist the IPS from both the servers.
You can create a REST API containing your cookie info(not public though)!!
Make your cookie data available on App1;
Make your cookie available as a Cookie object that can be served through a Request/Response Object
using "same origin" policy; you can have app2 talk to app1
I have a webservice (abc.com) for my company with an own user database and it is working just fine. Now my company wants to add some additional services which are located on a completly different server with another domain (xyz.com) but still use the same login data from abc.com because we have complete control over it and there are going to be similar servers like xyz.com so it is out of question to just import the user database on xyz.com.
My first thought was to use my checkuser.php from abc.com while submitting the login form from xyz.com but then I learned that the session cookie stuff is bound to the domain. At least that is how I understood it.
After that I wanted to access my checkuser.php via AJAX and HTTPS and submit the session data encrypted via POST to xyz.com. That failed too as AJAX seems not to work across multiple servers for security reasons.
Now I am out of ideas and dont know how I can securly authenticate out users on the foreign servers using our user database.
I would use single sign on (SSO) in stead of a shared session. That way, you don't make the sites code dependent on each other. If you later decide to change something on one of the sites, there is less reason to worry about breaking functionality on the other sites, and if you choose to link in a new site you are able to reuse the same solution.
What's better is that someone already made it for you, and it may even be more secure that what you'll be able to create yourself.
Wikipedia has some good general knowledge on SSO. Also, look into OAuth and OpenID. Combine these terms with PHP and a search should get you on the right track.
Another option is to simply have the login function on xyz.com connect directly to the database of abc.com to check the login name and password. Then you use xyz.com's database for everything else. Also if you really wanted to you could store the session information in your database on abc.com instead of a temporary file then you can also access that data from xyz.com. Here is an example of how to do this.
I haven't been working with php very long and have not encountered this problem myself, however, I've been hitting the books hard and came across an answer that my help you out.
If you are just trying to access the scripts and DB on server xyz.com, you can literally grab the content of a script using its url or IP address from within a script located on a separate server (abc.com) using the following function:
/* This example allows my example script on server mvc.com
to access the script on oreilly.com */
file_get_contents("http://oreilly.com");
Since you are accessing the code remotely, and I'm taking a shot in the dark here, I think that file_get_contents ( ) would allow you to set variables via $_POST or $_GET methods from the script on server xyz.com and send the values to the script on server abc.com. From there, you could then store these variables inside $_SESSION variables located on a single server, which ever server that handles the original $_SESSION variables and most of the processing.
It could become a quite complex 'game of catch' between the servers if you need to go back and forth frequently, but I think it may be a way around your problem if you can't move the data onto a single server. If you plan the structure of your scripts well this would allow you to store those $_SESSION variables all in a single place.
I'm making a PHP app to allow our customers to retrieve information from our database, using pre-defined functions. Perhaps PHP isn't the best choice for this, but the same page is also used as a backend for a flash app, and we don't have the time to rewrite it in another language (still, if we did have that time, I'm open to suggestions).
They will access the page via a URL, something like:
http://myurl.com/test.php?function=getUser&username=John
This will call the function getUser($username) and pass the value John as the $username parameter. Here's the twist: this page will be called from an application that the customer creates, not from a browser.
They are allowed to get info about some users, but not others. To enforce this, I require them to provide login information. I'm not sure how I can keep that user logged in so that they don't have to pass their login information every time they call a function, which can be multiple times per second.
I don't think I can use sessions or cookies, since they are not calling the page from a browser. So how can I keep that user logged in?
You can look into setting up something like a SOAP API on your end. Then, you can provide them with a token that goes back and forth (and possibly changes) between each request they make.
Have a read over SOAP and see if it gives you any inspiration at the very least. As far as implementing it, your options are many. Maybe consider using a framework?
You've hit the stateless wall :D .
You will either need to create a session aware browser client object with some library or some token exchange. But as long as you are using a separate session between calls you will need to hit the database again to authorize the user; token or not.
Simple answer: You can't, since HTTP is stateless.
But: You can use the same principle as cookies do, which is "send some authentification info along with the request without transmitting the secret". Have a look into OAuth and if it fits into your scenario. You can even use ready-made libraries for PHP.
two years ago I had to design a system to share authentication data across multiple domains, all of them shared the same server/db. I was able to pull this off with a complex system of cookie sharing which, to date still works.
I'm now in the process of redesigning the system and I was wondering if there are better ways to achieve this without having to write cross domain cookies.
Basically the system MUST do this.
Once logged in one site the user must be logged in all of the other site seamlessly, not only following a link, but even by directly writing the domain name on the address bar.
To my knowledge the only way to achieve this are cross-domain cookies, if there are alternatives please tell me.
Thank you very much
My Idea would be to include a login-Javascript from a third domain which gets includet in all sites. This javascript sets and reads the session-cookie and calls the current domains server via ajax with the result. (No validation should be done in the JS - this simply sets and reads the cookie)
If cross domain AJAX does not work, you can still call the thirds domain server which acts like a proxy and calls the current domains server.
The StackOverflow sites have implemented something similar to this. Check out the details at the following links.
Here is a post giving an outline of how they did it.
And here is even more detail.
For this you do have to use cookies, but you can vary what you store in the cookie. The cookie doesn't have to contain user credentials but can instead contain something more like a token that you use to "centralize" your sessions.
Easies way would be to let all hosts share a single memcached server and use the content of the users cookie as your key.