I would like to have certain knowledge inside a binary routine (foo) about what called it. Foo will be called from certain php scripts, and I am looking for a way for foo to verify that it is really called from that script. Is there any way for foo to get this information? I apologize if this question is offensively stupid, but this is completely new territory for me.

It probably depend upon how sure you want to be that it was called from a specific php script.

The php script would be run by another program (either the web server or the cli version of php) so looking at the PPID could give you some idea of how the program was run but not down to the script level. You could use your script to write some details to a file so that you know that the script has requested the binary to run and the binary could check that file but obviously there are ways around that if you are worried about this from a security perspective.

Looking at it from a security perspective you would want to put your binary in a directory so that the permissions to run it are restricted, such as only by the web server user and then you might be able to configure some clever .htaccess rules to restrict its usage even further.

that depends on how you call the binary routine, and if and how arguments are passed to it, perhaps you could simply add the name of the script as a static argument in each script, then simply store that information..

I am looking at this from a security perspective. I am trying to build as many defense layers as I can. The script will be running under apache, and the binary routine will be called using something like system(), exec(), or pcntl_exec(), etc. I am not sure yet which one will be best. As suggested, I will be doing some sort of incantation from the php script when calling the binary routine, and this adds one layer of defense. As graemef pointed out however, this (like most anything else) can be overcome.

Giving the module the ability to perform its own independent verification of the calling script would seem to be a strong defense layer.

I would like to be able to do something in the module along the lines of walking the stack to find this info. But sadly I do not know if this is possible, or what info can be determined if it is. It seems there must at least be a reference for the modules return value to go to.

Another thought would be to access the apache info, perhaps through apachectl, or maybe a custom module. If I could get a list of pending http requests and verify that there is an active request with url/parameters that would coincide with the type of request being made to the binary module... Browsing through the apache docs leads me to believe that this could be possible, but it is still not as secure as the first method.

Can anyone show me the path to enlightenment?

Thank you for your responses.

The only thought that I have had is that it might be easier to make your binary a php module, then it can only be run from php. You may then be able to add extra checks to ensure that it is being run from the correct script.

That is true. However, suppose this were to be a encryption module. One that used a key pushed from a remote server, not stored on the drive anywhere. Now if the key is broken up and encrypted in memory it should be fairly safe, but if someone penetrated the server and saw the php code they could run their own script to fetch the key. On the other hand a binary module that simply decrypted/encrypted strings that were passed to it would be more difficult to thwart. Since the key itself is never revealed, an intruder would have to pass the data to it and get it back unencrypted. Now supposing this server had something in place that would trigger an alarm if a legitimate php script was altered in any way, then it should be sufficient to verify that the module was being called from a legitimate php script.

I was actually thinking along the lines of a php extension (I had the terminology wrong, sorry), compiled in C using the ZEND conventions to make it a bespoke php extension. Maybe you can then use debug_backtrace() to work out how your function is called, possibly using md5 checksums to ensure that none of the source code has been tampered with and all of this will be in a compiled binary.

But if your server has been compromised then you have bigger problems to worry about!

Oh, I see. I will have to give this some reading, but initially I am hopeful about it. Thank you for your help.

And yes I agree that a compromised server is a mighty big problem, but it is all about trying to add defense layers in the event of a worst case scenario. This way if someone grabs the database and code, even if they copy the whole server, the important data is still encrypted and they do not have the keys. If I can make getting the decrypted data more effort than it is worth, then all is well.