in reply to Re: Perl, Die, and IIS
in thread Perl, Die, and IIS
Quoting merlyn’s Computing Securely article:
Don’t be too chatty in error messages
Certainly, the user wants to know when something breaks, but usually the user seeing the error message isn’t the person who has to fix the code. They don’t need to know the precise SQL that triggered the error, or the name of the database being accessed, and so on, because that stuff is all very useful information to a bad guy.
The most frequent violation I see of this principle is when use CGI::Carp qw(fatalsToBrowser) is left enabled on production code. This is wrong, very wrong. The random user at the other end of the HTTP connection needs only to be told that “something went wrong” and “we’re looking in to it,” and maybe a unique timestamp so they can report the error. Everything else that would have printed should be captured in an error log somewhere, not sent to the user for exploit.
Make sure you read the rest of the article as well if this is news to you.
Makeshifts last the longest.
|
|---|