Re: Essential CGI Security Practices

I'm not sure about that Error Messages, or at least the example. I know I always find it incredibly frustrating to get meaningless fluff back as error messages from a website. If the error has some meat to it I might be able to remedy the thing myself by altering the form data or hand-parsing the URL.

Simply saying "Invalid Login" doesn't buy you any securty if you're sending in the clear over the wire, so why make it harder on the user? There are other ways of handling brute-force attacks that you are expressing worry about here (think escalating delays for failures).

On the other hand, if you are truly paranoid minimizing the information you betray about your system is probably a good thing e.g. paths, server information (HTTP headers, etc.) (unfortunately?) that means no "Powered by Apache" feathers either ;-)

As for %ENV I stand by "Re: perlsec question".

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

[Aristotle]

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.

[belg4mit]

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"

[Aristotle]

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.

[dsheroh]

I wouldn't go so far as to say that "Invalid login" fails to buy any security - it prevents users from trivially determining whether a username is valid or not, thus significantly increasing the search space for a brute-force attack. Not a silver bullet by any means (not even a very shiny one, really), but still enough to be significant in many cases.

(Yeah, escalating delays are good, too, but a little trickier to implement in an environment, such as CGI, where you can't reliably maintain state.)

[jonadab]

I know I always find it incredibly frustrating to get meaningless fluff back as error messages from a website.

Would it be less frustrating to get, "Error committing to table: incorrect number of fields"?

For errors the use can maybe fix (e.g., username and password don't match), I try to give a meaningful and complete explanation of the problem. (At least, in theory that's what I intend to try to do.) For internal errors, I like to do something like the following:

   mydie("Error Condition One in Section Gimmel");

My mydie subroutine starts out by explaining that there is some internal problem, that it is probably not the user's fault, that it's something the webmaster needs to fix, and that he might be able to do so more easily given the technical error code below. Then I give contact info for whoever maintains the script, and print out the string that was passed by the caller, labelled as a Technical Error Code. (The important thing about this string is that it is unique, and I can grep for it to find exactly where the problem was encountered.) All of this can be nicely formatted in a <div class=\"error\">...</div> so that the site CSS can easily style it as desired. This is MUCH nicer to the user than "Internal Server Error", but it doesn't give a potential malicious user a great deal of information, other than how to contact the admin. (Then you just have to make sure this person is not susceptible to social engineering... but you have to do that anyway)