Interaction of a client-server application in C, a site in PHP and a third-party site

Question

User identification

So, the actors are: a third-party site that works with ours through the API, our site in PHP, a server application in C and a client application in C. A third-party site must request information from our site, our site transmits data to the server application (using the exec or similar), it, in turn, connects to the client via sockets, throws off the public keys for encryption and the requested data. The client application asks the user to enter data (for example, insert a dongle or place a finger on a fingerprint scanner), then encrypts it and sends it to the server. The server then decrypts the data, processes and sends a response to a third-party site (for example, authenticates the user).

So here's how to do it in the most transparent way for the user and the site using our API. So that the user simply receives an inscription on a third-party site with a suggestion to perform some action (all third-party sites will be checked before being allowed to use the API), perform it and receive a message about the result. If the interaction between applications in C is even more or less clear, then the third-party site-our site-server application chain looks vague. Those. I can go through the third-party site-our site-server-client-server chain, but I can’t figure out how to return the result to a third-party site.

Answer, if possible with the simplest example - for example, a third-party site sends a number, the client multiplier, the server multiplies the number and multiplier and sends the result to the third-party site.

Oh yeah, how does the server know the client's IP address to open the socket? After all, the user can use a proxy, and more than one, and the final IP knows only a third-party site, but not ours at all (especially if the proxy is also anonymous).

PS This is not a startup. I saw such a system on one security site and became curious how it works. Well, I decided to choose this topic for coursework on the security of information systems.

Answer 1

The answer lies in understanding the http protocol. Let's go in parts:
1) Transferring a third-party site is your site. Everything is simple here, sites written in php generally interact via http. There are some exotic options with sockets in php, but in my opinion it is necessary to use the tool in accordance with its intended purpose. So to business. A third-party site makes an http request to your site, posting (or getting) the necessary information. Most likely, protecting it by transferring a hash sum with some salt known only to sites. For example:
your-site.ru/api/setNumber?num=10
2) Transferring your website to your server application. the hardest part. The secret lies in the fact that php's ability to work with the host system is very limited. Not sure if php will be able to send for example a message to another process on the server system. Here the exchange can be implemented, for example, like this: php launches some microprogram with parameters that passes information to the server program, for example by sending a system message (this is really fraught with security problems, allowing php to run programs is quite dangerous). Either php writes information to a certain database and the server program constantly scans this database for new information.
3) transfer your server application - user's client application. Here again, everything is simple. Your mistake is only that the server, in general, cannot open a socket before the client. The client can be behind nat, behind a proxy and just ports can be closed. Therefore, the client application opens a socket to the server, logs in, and keeps it open (like ICQ or mail agent. Or whatever you use there :)). When some information is received, the server program sends them over an already open connection to the client.
Now let's go back:
1) client application - server application
Already discussed. We have an open socket, we send it on it.
2) server application - your site.
But it is very easy for the application to send information to your site, it is enough to make an http request to your site from the server application.
3) your site is a third party site
again just an http request from your php script to a third party site
Please note that if all elements of the chain are important for transferring "there": a third-party site can most likely only make an http request, then your site is needed to accept it. Your site will not be able to hold the socket and send information to the client program - your server program is needed. Then, when going back, you can safely exclude any of the items: your server program can itself, without the help of your site, make a request to a third-party site. Moreover, the client program itself can make a request to a third-party site, and in general, you can throw your server program and your site out of the way back. Naturally, all this must be protected by encryption from reading and salts from forgery. (as you think, everything is quite simple :) )
Here it is already necessary to look from the organization of the system. I would leave the server program as the main api handler, and make your site as simple as possible with the only function of passing information to the server program.
This is if we talk about your scheme: in life, most likely, “your site” does not exist at all, and the “server program” has an Apache module or by itself listens to the appropriate port and responds to http requests. To eliminate the bug with the transfer of information from php to the server program. This place will fail all the time. Because php is not designed for this. And in the case of implementation with a database poll, there will be an additional delay.