Key-passing from PHP to TCL CGI script - how is it done (web security issue)?

[comp.lang.php]

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

[Steve]

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.

A bit more detail needed, I think... is the TCL script interactive or
batch? Perhaps it could be modified so that it doesn't need to be
web-facing at all, called from PHP using exec() returning the result to
PHP which passes it on to the browser.

---
Steve

[comp.lang.php]

A bit more of an explanation. What do you mean by "interactive or
batch"? It's a CGI script that does server-side validation and then
passes form values into an XML file that only it can access.

Phil

[gwl]

Phil,

If you could post the problem script to the comp.lang.tcl newsgroup and what
OS you are using, it is more than likely we can tell you how to plug the
security hole. Partictularly from the description you include -- sounds
like it may be a well known coding problem (i.e. not handling user data in a
safe way).

To answer your question, you can pass data either as an argument to the
script on its command line (i.e. when you kick it off) or via an enviornment
variable. In general, if you are having security problems with handling
user supplied data, I'd recommend passing via an enviornment variable (it is
harder to introduce a security hole).

BTW, a properly written CGI script is no less safe than a properly written
PHP script -- you just have to know what you are doing.

comp.lang.php wrote:

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

[Steve]

A bit more of an explanation. What do you mean by "interactive or
batch"?

Can it just be given a chunk of data and get on with it's job, or does
it have an interactive conversation with the user, with several round
trips from client to server before it can do it's thing?

I suppose the question is: does it have to be a web-facing CGI script
at all, could it be coded as a simple command-line script
(#!/usr/bin/tcl) taking command-line args and returning the result to
STDOUT; it could then live outside the web directory tree and be
protected from abuse from the internet. No need for any fancy
authentication then.

---
Steve

[comp.lang.php]

Steve wrote:

A bit more of an explanation. What do you mean by "interactive or
batch"?
Can it just be given a chunk of data and get on with it's job, or does
it have an interactive conversation with the user, with several round
trips from client to server before it can do it's thing?

Ok thank you. Those are terms that I as a web developer am not used to
hearing, so it threw me.
I suppose the question is: does it have to be a web-facing CGI script
at all, could it be coded as a simple command-line script
(#!/usr/bin/tcl) taking command-line args and returning the result to
STDOUT; it could then live outside the web directory tree and be
protected from abuse from the internet. No need for any fancy
authentication then.

I couldn't run the script as a standalone command-line script because
the scripts are hosted on a remote site and I do not have privileges
outside of my account which resides within the framework of the
document root. It is a single back-end batch processing script that
must exist within CGI because CGI, as well as the user, are within the
group that has the privilege to access a group-accessible XML file
(this cannot be altered as it is set up by the hosting provider across
the board for all users on his hosting service).

Phil
---
Steve

[Steve]

I couldn't run the script as a standalone command-line script because
the scripts are hosted on a remote site and I do not have privileges
outside of my account which resides within the framework of the
document root. It is a single back-end batch processing script that
must exist within CGI because CGI, as well as the user, are within the
group that has the privilege to access a group-accessible XML file
(this cannot be altered as it is set up by the hosting provider across
the board for all users on his hosting service).

Would this work?

<?php

header( "Content-type:text/plain" );

exec( "/path/to/mytclscript.tcl arg1 arg2 arg3", $res );

print "results:\n\n";

for( $i=0; $i < count($res); $i++ )
{
print $res[$i] . "\n";
}

?>

---
Steve

[comp.lang.tcl]

It would function, yes, but I don't see how that would offer any form
of protection as the hacker would still have access to the TCL CGI
script with his/her original HTML cached page. I guess I am unclear as
to how this would tighten things up.

Thanx
Phil

Steve wrote:

I couldn't run the script as a standalone command-line script because
the scripts are hosted on a remote site and I do not have privileges
outside of my account which resides within the framework of the
document root. It is a single back-end batch processing script that
must exist within CGI because CGI, as well as the user, are within the
group that has the privilege to access a group-accessible XML file
(this cannot be altered as it is set up by the hosting provider across
the board for all users on his hosting service).

Would this work?

<?php

header( "Content-type:text/plain" );

exec( "/path/to/mytclscript.tcl arg1 arg2 arg3", $res );

print "results:\n\n";

for( $i=0; $i < count($res); $i++ )
{
print $res[$i] . "\n";
}

?>

---
Steve

[Steve]

It would function, yes, but I don't see how that would offer any form
of protection as the hacker would still have access to the TCL CGI
script with his/her original HTML cached page. I guess I am unclear as
to how this would tighten things up.

It depends on whether your setup allows you to store files in
directories other than your web root folder and below.

If the TCL script can be stored and executed outside of your web
there's no direct access to it from a browser.

For instance, my host has a fairly common setup where the web root
folder is

/home/steve/web/

but I can create folders in /home/steve that are outside the web.
---
Steve

[Donal K. Fellows]

Just an extra note that in general, the best ways of passing data are
not via either arguments or environment variables, but rather through
sockets or pipes (both of which come in many variations). On the other
hand, these are superior because they are a mechanism that is much more
difficult to snoop and which can handle much larger amounts of data,
and not because they inherently protect you from quoting issues. Not
that Tcl's particularly prone to such things when the language is used
even remotely idiomatically...

Donal.

[comp.lang.php]

Unfortunately that is not the case. The provider does not allow
storage outside of the docroot, else, that would of course solve
everything as all of the TCL scripts would work outside of the docroot
in that case.

I did manage to add one extra line of security as a measure:

...
} elseif {[string length $firstname] > 75 || [string length $lastname]

75} {

# HANDLE
}
...

Phil

Steve wrote:

It would function, yes, but I don't see how that would offer any form
of protection as the hacker would still have access to the TCL CGI
script with his/her original HTML cached page. I guess I am unclear as
to how this would tighten things up.

It depends on whether your setup allows you to store files in
directories other than your web root folder and below.

If the TCL script can be stored and executed outside of your web
there's no direct access to it from a browser.

For instance, my host has a fairly common setup where the web root
folder is

/home/steve/web/

but I can create folders in /home/steve that are outside the web.
---
Steve

[Steve]

Unfortunately that is not the case. The provider does not allow
storage outside of the docroot, else, that would of course solve
everything as all of the TCL scripts would work outside of the docroot
in that case.

Fair enough. Making this setup more secure must depend on where you
think the threat is coming from and how likely further exploits are.

If your hacked script was exploited randomly from the web with no
internal knowledge of how the form data would be used, you could just
use something simple like a password on the command line. That could
only be exploited by someone on the same server spying on ps (for
example.) I'm not sure you have really got to the bottom of how your
script got exploited so effectively to the extent that a payload was
delivered to your filesystem and executed (is that what happened?)

So I would recommend setting up a shared secret for both scripts. Pass
whatever arguments are required in clear on the command line plus a
hashed* combination of all the arguments and your password. The tcl
script should recreate this value and compare it with the passed
argument, rejecting the whole request if it doesn't match.

I can offer the PHP side, over to comp.lang.tcl for the other end...

$secret = "I like cheese";
$args = "$arg1 $arg2 $arg3 ";
$hash = md5( $args . $secret );

exec( "/path/to/tclscript $args $hash", $result );
*Yes, I know md5() could be compromised but, really, life is too
short...

---
Steve