http://www.perlmonks.org?node_id=158005


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

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.
  • Comment on Re: Re: Re: Does fatalsToBrowser give too much information to a cracker?
  • Download Code