Secure cross-domain communication between AJAX and PHP?

Question

PHP

On one server there is a PHP script, on the other there is a site using AJAX. How to transfer data between them in order to guarantee confidentiality and the impossibility of forgery (instead of AJAX there can be Flash, and regular GET / POST requests - it’s easy on sockets, but you need it like this)?

The only thing that comes to mind is an additional PHP script and sockets + SSL. But this is not very convenient (because a flash without PHP can be used). Using secret keys does not seem safe to me - flash or javascript is easy to pull off and peek at all the information. RSA - I will send it in one direction, but again in the opposite direction - you can peep the secret key.

What are the options?

Answer 1

It is obvious that you do not understand how openApi works, since you are constantly trying to compare what you need with this technology.
There the structure is as follows: there is a client browser, with javascript.
There is a site server.
There is a VKontakte server.
When a person wants to log in to the site, he presses the button "authorize through in contact". A pop-up window opens with a page from the VKontakte domain, where the user enters an email / password, his data (login and password) are sent to the contact server. The contact server checks them and if everything is OK sends the data to the server of the site on which the person logs in. The site server, having received this data, checks it and, if everything is OK, authorizes the person.
Those. data authentication happens on the server side, not on the javascript side.
Storing keys in javascript/flash is not an option and nobody does it that way. In any case, an additional script is needed on the server-client side, which will authenticate the data received from the server-provider of the service and only then transfer them to the browser (using Ajax or something else)
The answer to the question above : how to determine that the visitor is already logged in to the site - service provider?
Very simply, the service provider site sets its cookie to the client. The client site puts an iframe on its page in which a special page of the supplier site is loaded with a special parameter of the from=site-client type. The service provider site, having received a request from this page, looks to see if the person has his cookie and, if so, sends the necessary data to the server of the client site, and the client site already sends the data to the user's browser with Ajax.
All data exchange from the point of view of JS takes place within the same domain: through an iframe with the provider site and ajax with the client site.
All cross-domain data exchange (between the provider site and the client site) takes place on the server side without the participation of client browsers, and this data cannot be intercepted.

Answer 2

It all depends on whether something can be done not on the client-side, but on the server-side with the site of the person to whom the service is provided. VKontakte works exactly like this, if my memory serves me right.
(Well, to be completely accurate, there are two sets of keys, one to complicate life for those who will break, the second is really secret, which only knows the server parts).
Those. the situation changes, AJAX asks not from your site, but from the site, which then asks yours (and does this either many times, or after the first success sets the correct session cookie, etc.).
Those. if a person changes something on the client side, whatever, the server side will still refuse to process his requests.
The interaction between the client's site and your site can be on any protocol, because its user cannot fake it.
On the example of authorization:
A - AJAX, S - client site, U - your site.
A -> S: authorize me, here is my data (at least how many times forged)
S -> U: here someone wants to log in, here is his data
U -> S: ok, data is normal
S -> A: here is a session cookie for you , work on
Since in such a scheme the attacker has no control over the data between S and U, he cannot do anything critical.

Answer 3

I was interested in your question and decided to look into it.
As it turned out, VKontakte authorization is organized using its Open API and resembles openID. It 's written about him here.
Actually, at the moment I can only help with advice (read about openID and Open API ). In the near future I will try to figure it out myself and unsubscribe here if the question is relevant.

Answer 4

if you were already looking towards RSA, then you can make encryption with a public key. As I understand it, you want to transfer data from one of your domains to another of your own? Then this type of encryption will do. But this is only an assumption, how you can solve the problem, there are probably easier ways.

Answer 5

So it looks like it's much easier than I thought.
What prevents you from simply logging in with a username and password using standard methods?
Well, a script is being made that opens a window from our site, allows you to log in there, and then sets the session / cookie? And then all the scripts are already working with our site with normal authorization there ...
Or do we need to protect ourselves from crooked requests to our site? Well, if requests are sent by the client, then the attacker will eventually be able to send anything, no matter how you defend yourself, i.e. in this case, you can't do without a server.

Answer 6

Briefly:
curl and fscopen
With the keys, you can get confused, but through the same curl and fscopen as an additional measure.
And your flash or script can receive data from scripts that perform these functions.