Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^2: Essential CGI Security Practices

by Aristotle (Chancellor)
on Feb 03, 2002 at 01:07 UTC ( #142999=note: print w/ replies, xml ) Need Help??


in reply to Re: Essential CGI Security Practices
in thread Essential CGI Security Practices

I think you're confusing input validation with error messages here. A script should produce meaningless fluff for errors a visitor cannot fix anyway - like could not open /path/to/config/file. That stuff belongs in the server error log and nowhere else. Of course it is useful to tell the user what went wrong if his input was rejected for some reason, but that's not quite the same as an error message. As Ovid wrote in his tutorial, your script may break at any - even unforseen - point, so you have no control about what information a visitor may see if you indiscriminately set fatalsToBrowser.

Makeshifts last the longest.


Comment on Re^2: Essential CGI Security Practices
Re: Re: Re: Essential CGI Security Practices
by belg4mit (Prior) on Feb 03, 2002 at 02:10 UTC
    Are you replying to the right node? If so, I say nothing of fatalsToBrowser. And Invalid password/Invalid login is something the user can fix, and it is not really input validation as you cannot (usually) do it programmatically i.e. verify that the user has in fact authenticated himself. Also my discussion of paths (your point about open) was seperate, following "on the other hand", therefore we are in accordance.

    --
    perl -pe "s/\b;([st])/'\1/mg"

      Yes, I was replying to your note. I think you simply confused the one kind of error message with a different kind of error message. There's a distinct difference between what you were talking about and those error messages that should not be let out due to CGI security concerns. Input validation, as I mentioned it, was meant in the extended sense of any and all checks you may perform on your input data - ie not only the initial "does this look like a valid username" but also "do we have this username in our database" and "does the password match". Point taken that you mention paths and similar information separately, however I think you should drop the condition "if you're truly paranoid" because if you're anything less than truly paranoid there's not even a chance of achieving security. :-)

      Makeshifts last the longest.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (13)
As of 2014-07-10 19:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (215 votes), past polls