Hacker Proofing My Script

awohld has asked for the wisdom of the Perl Monks concerning the following question:

Here is a script I made to do database inserts. Should I limit the amount of data that can be posted to prevent buffer overflows? I guess that there shouldn't be anymore than 30,000 characters in the text area so I was figuring using $CGI::POST_MAX = 30000. I did this assuming that 30,000 ASCII characters assuming that 1 ASCII character is 1 byte.

Also I think my query is immune from SQL injection attacks. Is it?

#!/usr/bin/perl -wT

use DBI;
use strict;
use CGI;
$CGI::POST_MAX = 30000;
use POSIX 'strftime';

my $q = CGI->new();

my $id =             $q->param ('id');
my $other_comments = $q->param ('other_comments');

my $date = strftime( "%m/%d/%Y",localtime(time) ); 

##Start database connections##########################
my $database = "database";
my $db_server = "localhost";
my $user = "user";
my $password = "password";

##Connect to database, insert statement, & disconnect##
my $dbh = DBI->connect("DBI:mysql:$database:$db_server", $user, $passw
+ord);

my $statement = "INSERT INTO database (id1, comnt, date1) VALUES (?,?,
+?)";

my $sth;
$sth = $dbh->prepare($statement) or die "Couldn't prepare the query: $
+sth->errstr";

my $rv = $sth->execute($id,$other_comments,$date) or die "Couldn't exe
+cute query: $dbh->errstr";

my $rc = $sth->finish;
   $rc = $dbh->disconnect;
#######################################################

print "Content-type: text/html\n\n";

print $date;
[download]

Comment on Hacker Proofing My Script Download Code

Replies are listed 'Best First'.
Re: Hacker Proofing My Script by hardburn (Abbot) on Oct 04, 2004 at 20:29 UTC
Frankly, if you're asking a question like "is this program hacker-proof", you've already lost. What you should always focus on is specific attacks (which you did in the body, e.g., "limit on post to prevent buffer overflows" and "secure from SQL injection"). The general statement of "is this program secure?" made in the title is far too naive to be useful. Here's a great example of securing an application, this one involving ATMs: http://www.theregister.co.uk/2004/07/21/atm_keypad_security/. Notice how very specific requirements are made ("an attacker must take the PIN pad home and spend at least 10 hours breaking it"). "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re: Hacker Proofing My Script by dragonchild (Archbishop) on Oct 04, 2004 at 19:29 UTC
Because you use bind parameters, you're are essentially immune to SQL injection attacks. As for buffer overflow ... I haven't heard of any attacks that work like that, but I'm not a security expert. Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]
Re: Hacker Proofing My Script by sgifford (Prior) on Oct 04, 2004 at 22:20 UTC
Looks pretty good to me. You're running in taint mode, using SQL parameters, and you aren't printing out any user-controlled data in your HTML (which would make you vulnerable to cross-site scripting attacks). Perhaps a user could fill up your database by sending many requests like this, if that's a concern.	[reply]
Re: Hacker Proofing My Script by lhoward (Vicar) on Oct 04, 2004 at 20:26 UTC
Perl variables (scalars, hashes, arrays) expand dynamically as needed to accomodate data. So unless there is a bug in the core perl implementation of those types (or you have them tied to something that imposes such a limitation) you're effecitvely safe from something in perl causing a buffer overflow to execute remote code. This isn't saying that youre safe from a large piece of data causing a perl processes to use too much memory and crash the server (DOS style attack), or that something before or after perl (the web server or DB server) might not exhibit such a buffer overflow vulnerability that could be expolited through your code (even though your code itself may not be vulnerable). L	[reply]
Re: Hacker Proofing My Script by Anonymous Monk on Oct 05, 2004 at 16:09 UTC
Yes, totally immune. Now, where did you say your server was?	[reply]
Re: Hacker Proofing My Script by CountZero (Bishop) on Oct 04, 2004 at 19:30 UTC
What makes you think your script is immune from injection attacks? I'm not sure that using placeholders is sufficient (the DBI docs do not state that AFAIK) in that respect. Just relying on the automatic quoting rules in the placeholder code (which might be differently implemented in every DBD-driver) seems dangerous to me. CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]
Re^2: Hacker Proofing My Script by jZed (Prior) on Oct 04, 2004 at 19:48 UTC
Placeholders are not the same as "automatic quoting rules". The $dbh->quote() method applies quoting to the values and then those are inserted into the SQL statement and that SQL statement is passed to the RDBMS. OTOH, for an RDBMS that supports placeholder, and when placeholders are used instead of $dbh->quote(), the values are not quoted, are not inserted into the SQL statement, and are passed separately to the RDBMS along with the SQL statement which still has placeholders marks in it. The RDBMS than operates on the statement + the values without ever needing to create a SQL statement that contains the values and therefore without the danger of having unkown SQL statements (injected as values) executed. So if the RDBMS supports placeholders (as distinct from a DBD that emulates them), placeholders are much more secure than quoting, even quoting with $dbh->quote().	[reply]
Re^3: Hacker Proofing My Script by CountZero (Bishop) on Oct 04, 2004 at 20:15 UTC
Quite right, thanks for refreshing my memory! But I was not entirely wrong here: what is OK on one DB might be terribly insecure on another. In that respect, MySQL supports prepared statements only since its version 4.1 and unless DBD::MySQL is updated to take advantage of it (I didn't think so), could it be that the placeholder-magic is faked by DBD/DBD::MYSLQ and that it simply relies on quoting and interpolating the placeholders? That would of course be a Bad Thing. CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]
Re^4: Hacker Proofing My Script by dave_the_m (Monsignor) on Oct 04, 2004 at 21:19 UTC
Re^3: Hacker Proofing My Script by awohld (Hermit) on Oct 04, 2004 at 21:02 UTC
jZed - So you say if my database, which is mySQL 3.22.32, supports placeholders, then I don't have to worry if the DBD supports or emulates them? Thanks Adam	[reply]
Re^4: Hacker Proofing My Script by jZed (Prior) on Oct 04, 2004 at 21:13 UTC
Re^5: Hacker Proofing My Script by CountZero (Bishop) on Oct 04, 2004 at 22:24 UTC

Back to Seekers of Perl Wisdom