in reply to Re: Writing a perl quiz. Need advice.
in thread Writing a perl quiz. Need advice.

Update: Don't keep fatalsToBrowser in your production script. See postings below for reasons.

You've also got fatalsToBrowser in there - however once your program is done and dusted I would have thought it best to remove it?

I disagree. In the same line of thought, you could propose to remove use strict/use warnings after your program is thoroughly tested. This is somewhat like asking your children to forget their good education once they are grown up :-).

The only reason I can come up with to remove any of the three is to to improve speed, and even that one is not sufficient: I challenge you to prove that the speed gain is more than marginal.

My experience shows that for many scripts I "finished" at a certain time, there is another time I have to go back and make some changes. Software is not like a statue that you once create and never change. But if you are going to change it, you better leave all the security mechanisms in place, or else you'll shoot yourself in the foot.

Even software that you are "sure" you will never modify might fail mysteriously due to not-yet uncovered bugs, a section of code you never really tested, an error condition that never ocurred before etc. For this, it's good to have FatalsToBrowser.

Apart from that, I like to treat every piece of software I write seriously. It helps me to acquire good coding habits, and it tends to save me a lot of work later.

Replies are listed 'Best First'.
Re: Forgetting your good education
by adrianh (Chancellor) on Mar 08, 2003 at 13:52 UTC

    I disagree with your disagreement :-)

    Fatals to browser can reveal information that you do not want the users to see. The error message can potentially reveal information about your code that would allow a malicious user to exploit the bug that caused the error in nasty ways.

    In production code you log the errors, but don't show them to use user.

[reply]

      Okay, I agree that replacing fatalsToBrowser with something like fatalsToMyLogFile might be even better. But my point still is true :).

[reply]
        Uhm, isn't "fatalsToMyLogFile" default behaviour under just about every webserver there is? I only have (some) experience with apache and afaik fatals do end up in the error log on apache.
[reply]
Re: Forgetting your good education
by Anonymous Monk on Mar 08, 2003 at 21:10 UTC
    The reason to remove fatalsToBrowser is that you know something about security and you are not an idiot. Let me be clear. I am not saying that you are an idiot. I am saying that you have something basic to learn about security. Please learn it from my post and then stop giving dangerously bad advice.

    The purpose of fatalsToBrowser is to provide useful debugging information in the browser. This speeds up development. However it means that if someone finds "unexpected behaviour" in your application, they can use your debugging information to get insight into how your application works, and then use that to fine-tune an attack.

    For a common example, suppose that you interface with a database. And, as happens depressingly often, you don't quote a field that shows up in an SQL query. You now suffer from the possibility of an SQL injection attack - someone can enter in anything they want and have it become part of your SQL. If they can figure out the right thing, they can get "interesting results". (Such as downloading your credit card data. Or taking over your database server.)

    Now obviously this is much easier if they can find out something about the structure of the query that they are breaking. And something about your database. Which is far, far easier if you provide useful debugging information in the browser. See, for instance, http://www.sensepost.com/misc/SQLinsertion.htm (or many other pages on SQL injection at Google) for how an attacker can use debugging information to keep on escalating an attack until they can get anything they want from your database.

    Not publically providing debugging information doesn't fix the bug, but it does make it a lot harder to exploit. It often makes the difference between a minor intrusion and a serious problem.

    So how do you do this with minimal impact on your ability to debug? The answer is simple. You make fatalsToBrowser be something that is readily flipped in your code. Preferably either in a configuration variable that differs between production and development, or as something that your standard build process does. That way you get all of the benefits while developing or whenever you need it in production, but without making an attacker's life any easier than it has to be.

[reply]

In Section Seekers of Perl Wisdom