use CGI::Carp qw(fatalsToBrowser); should be removed from any production web page else you may inadvertantly give out too much information to potential attackers.
Jason L. Froebe
Team Sybase member No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1
| [reply] |
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.
| [reply]
[d/l] |
There's also a large amount of discussion on this subject in
Does fatalsToBrowser give too much information to a cracker?.
--
Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
| [reply] |