How would you do "key passing" in PHP?

ppowell

On one of my sites, I have a TCL CGI script that has a security hole in spite of it having effective server-side validation (the fact that it's CGI IS its security hole). The front end is a PHP script, and I am writing server-side validation onto it, however, it is required to redirect to the TCL CGI script because only a CGI script has the ability to access a group-accessible XML script on the back end.

I had to take the whole thing down because a hacker found a way to exploit the TCL CGI script and send in viral DoS-generating data packets via simple form text field submissions, somehow even bypassing the TCL CGI script's server-side validation.

Hence, that is why I am writing server-side validation on the front-end PHP script, which is not CGI, of course.

The only way I could figure out how to make this secure was the concept of "key passing", that is, passing a key from the PHP script into a $_SESSION variable, then the TCL CGI script must have the same key on its end, somehow, in order to expedite further.

Bottom line: I have no clue how to do this. Is there anyone out there that knows this stuff and can either give me a quick tutorial or point me in the right direction? I have absolutely no idea where to begin, nor do I know any other means of ensuring web security.

NOTE I cannot destroy the TCL CGI script, because only a CGI script can access the group-accessible XML on the back end, so that's not an option by any means.

Thanx
Phil

Stathy

Hi Phil,

I'm gonna address a bunch of points in your posting as I feel it will lead you in the direction of a solution to your problem.

1) CGI is not inherently insecure, just as PHP is not inherently secure. It's the underlying code that makes it secure/insecure. Also, PHP can be run as a cgi very easily since there is a standalone interpreter. With this fact you may want to consider having the cgi rewritten in say PHP and/or Perl.

2) The fact that you have server side validation into the php script is moot because the cgi script is accessible directly. Obviously, the TCL script is not doing things correctly, the TCL interpreter has a bug or the exploit is eluding us.

3) I am unclear what "viral DoS-generating data packets" are and am skeptical they even exist 😕 Is this what the hacker told you he did? What is the actual behavior of initiating the attack? It sounds like he is just sending parallel requests to the cgi-script which eventually overload the server.

4) The fact that you are forced to use TCL is not an ideal solution as it's not as widely used as say Perl or PHP. I would think that both the PHP and Perl interpreter code are far more robust at handling "tainted" data.

5) Even with a "private" key which isn't difficult to implement but still prone to compromising and can get over engineered, your gonna need to edit the TCL script which I am not familiar with.

If you can give more information on what is happening with the compromise it would help immensely. You may just want to have a throttle in the cgi script so that it can't be executed or called repeatedly.

ppowell

I'll address each of these separately

Phil

Stathy wrote:
Hi Phil,

I'm gonna address a bunch of points in your posting as I feel it will lead you in the direction of a solution to your problem.

1) CGI is not inherently insecure, just as PHP is not inherently secure. It's the underlying code that makes it secure/insecure. Also, PHP can be run as a cgi very easily since there is a standalone interpreter. With this fact you may want to consider having the cgi rewritten in say PHP and/or Perl.

I'm not able to write PHP as CGI as it is set up by the remote hosting service; CGI scripts are only allowable in Perl, C# or TCL. I don't know C#; my Perl is extremely rusty, but TCL I've done for several years.

Stathy wrote:
2) The fact that you have server side validation into the php script is moot because the cgi script is accessible directly. Obviously, the TCL script is not doing things correctly, the TCL interpreter has a bug or the exploit is eluding us.

I suspect the same thing. I tested the TCL script repeatedly at the point of server-side validation, however, by trying to "bust" it with erroneous information pumped into a cached front-end HTML page, to no avail, TCL caught it every single time. But these hackers have a way of "bypassing" the TCL-enforced server-side validation every time, and I can't fathom how they can do it unless they are able to literally rewrite the CGI script. The validation consists of checking the values of $firstname and $lastname for length and content, using Regular Expressions to match content and simple TCL string commands for length. I did a "flood-repeat" test of accessing the CGI script 500 times with the erroneous data and it caught it every single time.

Stathy wrote:
3) I am unclear what "viral DoS-generating data packets" are and am skeptical they even exist 😕 Is this what the hacker told you he did? What is the actual behavior of initiating the attack? It sounds like he is just sending parallel requests to the cgi-script which eventually overload the server.

What they sent into the "firstname" and "lastname" HTML form text fields were binary data packets, sent in a repeated fashion to apparently overload the server. The contents appeared viral in nature as when I attempted to do a safe download my ClamAV antivirus recognzed it right away.

Stathy wrote:
4) The fact that you are forced to use TCL is not an ideal solution as it's not as widely used as say Perl or PHP. I would think that both the PHP and Perl interpreter code are far more robust at handling "tainted" data.

So did I. But like you said, writing a PHP-based server side validation is pointless in this case, especially since only CGI scripts have the rights to access the group-accessible XML file required for the process to be completed upon successful data submittal, and again, PHP cannot be run as CGI on the server.

Stathy wrote:
5) Even with a "private" key which isn't difficult to implement but still prone to compromising and can get over engineered, your gonna need to edit the TCL script which I am not familiar with.

I can edit the TCL script to handle the private key, and I was told one of the best practices is to create an environmental variable to do just that.

Stathy wrote:
If you can give more information on what is happening with the compromise it would help immensely. You may just want to have a throttle in the cgi script so that it can't be executed or called repeatedly.

colinexl

hey ppowell, how did you get PHP to work with TCL? You said you had to redirect to TCL CGI for validation, how did you do that? Did you call exec() or something to excute a TCL script?

ppowell

My host provider wrote a CGI executable stub that allowed for me to write PHP that could play with TCL as CGI. Go to www.clearlight.com and talk to the admin for more info as I to this day don't know how he exactly did it.

Phil