Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Does fatalsToBrowser give too much information to a cracker?

by Dog and Pony (Priest)
on Apr 10, 2002 at 11:09 UTC ( #157994=note: print w/ replies, xml ) Need Help??


in reply to Does fatalsToBrowser give too much information to a cracker?

If your message is informational enough to aid you when debugging, it is probably informational enough to aid a cracker. Of course, that would depend on what, exactly, you are emitting, but for fatalsToBrowser to do any good, error messages should, like normal error messages, contain as much information as possible related to the problem, yes? This could very well include complete SQL statements, "secret" parameter names, file paths, and lots of other potentially harmful things. Also, even if you craft your messages in a protected way, what is to say that something unforseen won't go fatal on you and display something critical?

All that aside, I don't want any visitors to any site of mine to get any debugging information on their screens at all, except possibly something like the really excellent method this site uses, with an error ID that I assume maps to a log entry, so the user can describe what he/she was doing and the programmer can compare that with the resulting error logs.

If the error messages should go anywhere in production code, I feel it should be to error logs on disk or in DB, or by mail to the administrator, or a healthy combination. Not to the user - the user should get a friendly "Sorry" screen, with instructions to try again, and a way to notify the webmaster. No matter what I can or who I am, if I have nothing to do with the site's administration, stack traces and debugging information is just plain ugly, and as a visitor I probably want the friendly screen even if I could understand it. Probably. :)


You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.


Comment on Re: Does fatalsToBrowser give too much information to a cracker?
Download Code
Re: Re: Does fatalsToBrowser give too much information to a cracker?
by Juerd (Abbot) on Apr 10, 2002 at 11:40 UTC

    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?

    The same goes for file paths. I see no problem in telling that my home page is located at /vhost/juerd/juerd.nl/index.plp. Does knowing the path enable you to use files that can't be read by my apache daemon? If my code was written badly, you could guess the number of times you need "../" to get to the root directory, but my code doesn't use paths without checking (or even parsing) them first, so that information is completely useless.

    Secret parameter names in your code are often a sign of bad programming too. Do you put your SQL passwords in your code, or somewhere safe, with nice 403 error messages if anyone tries to get it through http?

    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.

    I don't like using Microsoft Windows. Why? Because since the very first General Protection Fault I ever saw, to the recent blue screens and Fatal Exceptions, I have absolutely no idea about what goes wrong when something goes wrong.

    Not all users are Teletubbies saying "uh oh" and "again" when something goes wrong. There should be a friendly message for those who are, but there should be detailed information for those who like to know more.

    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.

    U28geW91IGNhbiBhbGwgcm90MTMgY
    W5kIHBhY2soKS4gQnV0IGRvIHlvdS
    ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
    geW91IHNlZSBpdD8gIC0tIEp1ZXJk
    

      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?

      I do. But I don't assume that my checking, my quoting and my security is perfect, no matter how "good" I think I am. I can always have missed something, or if we are several on the project, someone else might have. Or maybe some unknown bug in perl or apache suddenly decides to let data through in some way when this cracker exploits something I didn't know about.

      I'm pretty sure that all those exploits that has happened, like buffer overflows and other stuff in open source and closed source projects was not due to someone just saying "Ah darn it. We just skip checking this part here, let's go grab a beer instead." - I am pretty sure it was a mistake (for the most parts at least) and the guys doing it thought they quoted and checked all the data. Turns out they were wrong. (It is a strange comparison perhaps, but you used it first :) ).

      Maybe you feel confident enough to know you have checked everything possible. I don't. And even if I did, someone else might muck my safe stuff up.

      Secret parameter names in your code are often a sign of bad programming too.

      Haven't done that yet. But I've heard about displaytype=hack.

      Do you put your SQL passwords in your code, or somewhere safe, with nice 403 error messages if anyone tries to get it through http?

      Usually in a module somewhere inaccessible. At least via HTTP. :)

      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?

      No reason at all, if all the users are "white hats". All the reason in the world if just one of them wears the black, because my code has not been reviewed, refined and bug tested by thousands of volunteers, of which many are also excellent programmers. It has been tested possibly only by me, of which none is an excellent programmer. :) And that code you mention has also been known to break at times. What makes it good to use is rather the speed with which things are discovered and fixed, not the out-of-the-box safety... although that is pretty darn impressive too.

      Not all users are Teletubbies saying "uh oh" and "again" when something goes wrong. There should be a friendly message for those who are, but there should be detailed information for those who like to know more.

      That is totally ok by me. If you want to, you can provide the user with whatever you think is friendly - of course. :) And I agree it isn't all that bad an idea. But. I'd still probably craft something directed to "the knowledgable user", I'd still not dump whatever to someone I don't know what his/her intentions are.

      I have no idea if the bug is going to be huge or tiny, and I'm not motivated at all to fix it.

      We are all different, thank heavens. If I'd give you one piece of advice on how to run your sites, it would be "do what works for you". Of course. :)


      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
Re: Re: Does fatalsToBrowser give too much information to a cracker?
by ehdonhon (Curate) on Apr 10, 2002 at 15:56 UTC
    the user should get a friendly "Sorry" screen, with instructions to try again, and a way to notify the webmaster

    I think it depends on the application. If you are offering a free service, you can probably get away with this. If you are offering a service where you have customers that are paying for the usage of your page, you'll need to have more than just this.

    Otherwise, you'll end up with a support department always trying to figgure out what to tell a customer whenever they write in and ask what went wrong.

    In my experience, the best system is short descriptive error messages. These give clueful users enough info that they don't need to request support. It also gives your support department enough info to go on that they don't have to spend so much time helping the less-cluefull users (or bugging the programmers).

    Your results may vary.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (11)
As of 2014-11-24 20:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (147 votes), past polls