0

I work for Company A, a software company integrating our platform onto a product by Company B, a hardware company. On Company B's product, Company B's process is running to manage the device, and within the process there is a webserver which is used to serve up settings pages and the like. My company's platform runs in a separate process on the device.

As part of our integration, I was asked to add a webpage which would show some information from our process. This was easy enough to add by generating an HTML file in the right place on the filesystem from our process, which the Company B's webserver will gladly serve up.

Now I have been asked to add more features to this webpage which include some interactive features (a button which will trigger a test from our process). My problem is that there is no way that I have found to have a button on a webpage trigger an event within my process. The easy solution is to use a CGI on the webserver, and have Company B's process send the data back to my process whenever it gets POSTed to. My boss has stated many times that he does not like this solution because he sees an open CGI as a security hole, and wants to completely shut off all CGIs on the webserver before the product releases.

So if I can't communicate between the webserver process and my process that way, I needed to come up with a different solution. I've made several attempts to do terrible hacky things like writing the data to a file through PHP, but I haven't found a solution that works yet.

So here's my two questions:

1) Is there any secure way to communicate a button press from a webpage to a process with root access that doesn't require the webserver to have a postable CGI?

2) If not, how can I convince my boss that opening up a single CGI which sends data to our process and can only trigger some diagnostic functions is a secure way to accomplish what he is asking for?

JD Reese
  • 113
  • 1
  • 5

1 Answers1

0

It kind of all depends on how embedded the stuff is I'd say.

If you can embed a webserver into the Company B code, you'd basically invoke functions from inside the software itself which might be considered as big a security hole than normal cgi invocations from a separate webserver process.

You could consider Fast-CGI, see your favorite encylopedia, but in the end it will leave a cgi function on the front side.

If there won't be any end user login to the system, I think the cgi option would be the best possibility if you publish just the few necessary functions you need, disable anything else you can inside the webserver and add some code to validate the input that you pass to the cgi call - probably use a wrapper before you call the Company B function to make sure that only exactly that data that would be expcected can be passed and anything else (like maybe sql-injection, buffer overflows etc.pp.) will be rejected.

If a user could login and would be able to circumvent that stuff then there is no new security hole introduced, the system can probably never be as secure as your boss wants... just my 2c

Stefan Hegny
  • 2,107
  • 4
  • 23
  • 26