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

[tachyon]

my $sth = $dbh->prepare("SELECT * FROM customers WHERE name = '$name'"
+);
$sth->execute();

# so what happens if:
$name = "O'Deary";
SELECT * FROM customers WHERE name = 'O'Deary'

# or even
$name = "Just another' or name = name or name = 'Perl hacker,"
SELECT * FROM customers WHERE name = 'Just another' or name = name or 
+name = 'Perl hacker,"

Sure so you should use ? place holders. With fatalsToBrowser active a *creative* user will probably get an informative error after submitting the first name. Then such a user might get the entire customer database. Thanks for coming....

Security is all about hurdles, depth and vigilence. You need to accept that nothing can ever be 100% secure. You attempt to make it more trouble than it is worth to breach your security. Just as you would be unwise to publish the wiring diagram for your alarm system so to you are unwise to (widely) advertise your source code. Of course code reviews like those offered by merlyn are a good idea (if you trust him ;-)

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[Juerd]

Sure so you should use ? place holders.

Well, doh :) Not using placeholders or a quote function is a beginners mistake - I agree that code like that should be concealed in every possible way.

I have very simple style rules I always try to follow:

• Do not use double quotes (qq//) for SQL queries
• Do not use double quotes for system calls
• Put parameters for system calls in a list, NEVER use backticks with user input (unless very well checked). (use IPC::Open2 or IPC::Open3 if necessary)
• Use 3-argument open when file names are variable (5.6+)
And there are probably some that I can't think of right now. In general, use double quotes only if you need them (I really wonder why books and tutorials and examples like merlyn's use double quotes most of the time - they imply trouble (in my experience). Trouble with @-signs, with 's (apostrophes), etcetera etcetera.).

Simple style rules can prevent a lot of trouble. Check for definedness, never use input without checking first. But another good thing is knowing how problems like the code you supplied can be exploited, so you can avoid such stupidity in your own programs.

It's a learning process, but also a matter of self-confidence.