|Perl: the Markov chain saw|
Re: Re: Does fatalsToBrowser give too much information to a cracker?by Juerd (Abbot)
|on Apr 10, 2002 at 11:40 UTC||Need Help??|
This could very well include complete SQL statements, "secret" parameter names, file paths, and lots of other potentially harmful things.
Could you explain to me how SQL statements can help a cracker if your program is well written? After all, you do use quote methods or placeholders, and you check data before using it -- or don't you?
To avoid being cracked, it's better to conceal version numbers than source code. After all, Apache's entire source code is open, MySQL's source is completely disclosed, and so is Perl's. Why hide parts of your own source if those parts can help debug?
Not to the user - the user should get a friendly "Sorry" screen, with instructions to try again
Yes, the user should get a "try again" and a "sorry". But some users, like me, hate to not know what's going on. If I'm going to report a bug, I'm going to report it in great detail. If there's no information, I never report it - I assume some automatic e-mail is being sent, because if the author wanted me to report the bug and does not send error e-mails automatically, he'd have included the information he needs to fix it.
This site uses error IDs, which apparently are mapped to some place in a log. I have seen quite a few after the server move, and it was annoying. The only thing I could do was paste the message, while I would have liked to be able to suggest a fix, or at least have a clue about what error I had triggered.
When I get an e-mail message with a bug report from one of the sites I maintain, and the user was smart enough to supply all information, I can often fix it within a few minutes. If I get an error-ID (I tried several methods of reporting bugs), I have no idea if the bug is going to be huge or tiny, and I'm not motivated at all to fix it.