Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Hacker Proofing My Script

by awohld (Hermit)
on Oct 04, 2004 at 19:09 UTC ( #396346=perlquestion: print w/replies, xml ) Need Help??

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;

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.

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.

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.

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

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?
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

      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().
        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

        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2019-12-09 14:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?