in reply to Removing malicious HTML entities (now with more questions!)

... Is there anyway for someone to inspect the CGI script itself, bypassing the HTML it generates? ...

That's something that depends more on the web server's security than the one of the script.

The answer is "normally, no" - but it happens occasionally that a webserver config is altered by mistake and then CGI scripts are not rendered to HTML but handed out as plain text. Having the password[s] in the source would obviously expose them in such situations.

To be on the safe side, you would put your passwords in an external file and just read/include that file in your script.

Krambambuli
---
  • Comment on Re: Removing malicious HTML entities (now with more questions!)

Replies are listed 'Best First'.
Re^2: Removing malicious HTML entities (now with more questions!)
by zentara (Cardinal) on Aug 16, 2008 at 14:33 UTC
    One common mistake is to leave debugging output to the browser on. It can dump out some useful info to hackers. 
    use CGI::Carp qw(fatalsToBrowser);
die "Bad error here";

    [download]
    Another common mistake, is to upload an updated cgi script, and don't name it properly or give it executable perms. If the server dosn't catch it, a non-executable script can be returned as a text file. The server config file should catch it, but are your sure? I've been surprised a couple of times to see my script displayed as a text file, because it was mode 0644.
    I'm not really a human, but I play one on earth Remember How Lucky You Are
[reply]
[d/l]
Re^2: Removing malicious HTML entities (now with more questions!)
by Lawliet (Curate) on Aug 16, 2008 at 14:35 UTC

    If I put it in an external file and then opened the file in the cgi script, couldn't the perpetrator see the filepath and navigate there?

    I'm so adjective, I verb nouns!

    chomp; # nom nom nom
[reply]
      The files accessible via URL are controlled by the server's URL-to-filesystem mapping and other things. Normally, you would have very little of the server's filesystem exposed.

      sas
[reply]

        Huh? Let me elaborate.

        Suppose I do the suggested, my code is as follows

        # let this file be located at http://website.com/user/me/cgi-bin/file.
+cgi
open(PASS, '<../password.txt');
# read variables and assign
close PASS;

        [download]

        The user then sees where the password file is located, and constructs the appropriate url (in the case given, it would be http://website.com/user/me/pasword.txt), right?

        I'm so adjective, I verb nouns!

        chomp; # nom nom nom
[reply]
[d/l]

In Section Seekers of Perl Wisdom