Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

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

by sasdrtx (Friar)
on Aug 16, 2008 at 15:06 UTC ( #704695=note: print w/ replies, xml ) Need Help??


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.


sas


Comment on Re^3: Removing malicious HTML entities (now with more questions!)
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 http://website.com/user/me/cgi-bin/file. +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 http://website.com/user/me/pasword.txt), 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.


      sas

      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.

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://704695]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2014-09-16 08:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (157 votes), past polls