in reply to Re^2: Removing malicious HTML entities (now with more questions!)
in thread Removing malicious HTML entities (now with more questions!)

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.

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

Replies are listed 'Best First'.
Re^4: Removing malicious HTML entities (now with more questions!)
by Lawliet (Curate) on Aug 16, 2008 at 15:25 UTC

    Huh? Let me elaborate.

    Suppose I do the suggested, my code is as follows

    # let this file be located at +cgi open(PASS, '<../password.txt'); # read variables and assign close PASS;

    The user then sees where the password file is located, and constructs the appropriate url (in the case given, it would be, right?

    I'm so adjective, I verb nouns!

    chomp; # nom nom nom

      That open should fail, as you're trying to go to the parent directory of the root node. And the fundamental point is, the root node for serving documents is not the file system's root node, and there's no URL that would allow access to it (assuming a non-insane configuration). So put your password file at '/etc/secret/password.txt' or any other location outside the web server's document directory structure, and it will not be accessible by browsing, even if the path and file name is known.

      There is no rule that requires any file to be directly accessible by URL. What can be accessed is controlled by the server configuration.


      You can add another layer of protection by saving the passwords in a way that makes them nearly useless in case somebody manages to steal your password DB. If you don't save the passwords as clear-text but i.e. as salted message digest of the clear-text password, then an attacker might steal your password file but will have problems to exploit this knowledge directly.

      When the customer provides a (clear-text) password, your CGI will 'salt' it ('salt'-value from your DB), re-compute the message digest, and compare it to the value stored in your password-DB. If it matches, it is very likely, that the password is correct (simplified description). The 'salt' makes it harder for an attacker to pre-compute password lookup tables. The paranoid also checks for weak passwords.

      Since you do not store the clear-text password, nobody can steal it. One consequence is that you cannot provide a password to a customer who has forgotten it - because you don't have it.

      It's not perfect, but adds a little more protection for your password DB. CPAN provides a lot of suitable modules, Authen::Passphrase::MD5Crypt is only one of them. The principle is described here. should map to something like ~me/www/ and the password file should be located somewhere outside of ~me/www/ like ~me/data/, meaning somewhere no url can address.