Retrieval of script values

[4am]

Hi, I have a quick question concerning the finalized .pl script file. I recently downloaded a script used to implement security. Instructions in the script had me change "$sreon" value.

$datadir = "/home/sites/www.yoursite1.com/data/";
$datadir2 = "/home/sites/www.yoursite2.com/data/";
$sreon = "formetoknow";
$dbmmanageyn = "no";

My question, then. I know that Perl is a serverside language, so nobody will be able to read the script (.pl file) entirely. Is it, then, impossible for them to discover the "$sreon" value within the script? I'm specifically curious about the use of GET or other queries to retrieve the "$sreon" value.

Please excuse my lack of knowledge about all this. I'm extremely new. (I think I'm posting to the correct place, but if not, feel free to move.)

Thanks!

[kutsu]

To help get an understanding of web security I suggest you look at a fellow monk's introduction and look at the Web Security Faq.

[duff]

In general, it's impossible for people on the internet to discover the value of a variable within a perl program acting as a CGI. However, if that program is placed in a directory that is listed on the server as being a directory for web pages rather than CGI programs, it may be possible for anyone to view your program and so learn the value of the $seron variable. Also, if the program is poorly written it could reveal the value of that variable as well.

[Roger]

Also, if the program is poorly written it could reveal the value of that variable as well

Hi duff, do you have an example to show a badly written script?

One way I can think of is when the script is invoked as a get, and the next page it generates has http://site.com/cgi-bin/script.pl?seron=blahblah in the URL.

[Cody Pendant]

Another example would be if you used CGI::Carp for debugging and didn't remove it from production code and it helpfully said "can't open /path/to/file, /path/to/script.cgi line 99" or the like when it hit a problem.

[duff]

I don't have a particular example, but I can think of all sorts of ways a program could be written to reveal parts of its own source. Your GET example is quite common though (I've seen it in at least one persons graduate project!). Debugging code inadvertantly left in, the program is actually designed to print its own source, the variable's value is displayed as part of an error message, the value is put in a "hidden" field, etc. There are a wide variety of ways to screw things up :-)

[Trimbach]

When you're accessing a script through the web the server's webserver handles the POST and GET requests to the script... if everything's set up properly the script will execute and the webserver will forward the script's output to the client's browser. In this situation $sreaon will not be exposed to the web client so long as the script itself does not output it; the server leaves everything to the CGI, and it's up to the CGI to determine what gets output or not.

However, the kicker here is "everything properly set up." If the webserver doesn't recognize your script as a CGI (i.e., if the permissions are set incorrectly) then a POST or GET request for your script will output the source of your script to the browser instead of the executed script's output. In addition, if there's some other CGI on your server that allows webusers to view scripts without executing them you could be exposed that way, too. (There used to be, for example, a script installed in old Apache distributions that could be abused to "echo" arbitrary sourcecode to a browser window.)

And of course your source could be read using methods other than the web server. If the server handles other services (FTP, Telnet, SSH, etc.) someone could potentially access your source and secret variable that way, too. It gets very complicated very quickly... how much effort you go to to protect your information depends on your paranoia level and the value of your data.