Re^4: Removing malicious HTML entities (now with more questions!)

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

Comment on Re^4: Removing malicious HTML entities (now with more questions!) Download Code

Replies are listed 'Best First'.
Re^5: Removing malicious HTML entities (now with more questions!) by sasdrtx (Friar) on Aug 16, 2008 at 15:51 UTC
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. sas	[reply]
Re^5: Removing malicious HTML entities (now with more questions!) by Perlbotics (Archbishop) on Aug 16, 2008 at 18:15 UTC
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.	[reply]
Re^5: Removing malicious HTML entities (now with more questions!) by ikegami (Patriarch) on Aug 22, 2008 at 04:31 UTC
http://website.com/user/me/ 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.	[reply]