Use PPI to Find SQL Injection Attacks

This is a quick and dirty PPI hack I threw together, but it attempts to spider through your codebase and look for SQL injection attacks. It returns some false positives, but that's better than false negatives. It could use some work, particularly since identifying something as SQL is difficult.

#!/usr/local/bin/perl

use strict;
use warnings;

use File::Find::Rule;
use PPI;

my $extensions = join '|' => qw(pm pl cgi);
my @files = File::Find::Rule->file->name(qr/\.(?:$extensions)$/)->in('
+.');

$| = 1;
my $files         = @files;
my $count         = 1;
my $bad_files     = 0;
my $total_attacks = 0;
foreach my $file (@files) {
    warn "Processing ($file)  $count out of $files\n";
    $count++;
    my $quotes     = extract_quotes($file);
    my $injections = find_injections($quotes);
    if (@$injections) {
        $bad_files++;
        $total_attacks += @$injections;
        my $possibles = join "\n--\n\t" => @$injections;
        print "\nFile $file might have injection attacks:\n\n\t$possib
+les\n";
    }
}

print <<"END_SUMMARY";
Summary
-------
Out of $files files analyzed:
    $bad_files file(s) might have SQL injection attacks.
    $total_attacks attack(s) may have been present.
END_SUMMARY


sub find_injections {
    my $quotes = shift;
    
    my @injections;
    foreach my $quote (@$quotes) {
        next unless $quote =~ /^\s*(?:select|insert|update|delete)/i;
        if ( $quote =~ /=\s*'?[\$\@]/ )
        {    # won't catch interpolated field names
            push @injections => $quote;
        }
    }
    return \@injections;
}

sub extract_quotes {
    my $file = shift;
    my $doc = PPI::Document->new( $file, readonly => 1 );
    unless ($doc) {
        warn "Could not create a document for ($file).  Skipping";
        return [];
    }
    return [
        map { $_->can('string') ? $_->string : $_->heredoc }
          @{ $doc->find('Token::Quote')   || [] },
          @{ $doc->find('Token::HereDoc') || [] }
    ];
}

sub slurp {
    my $file = shift;
    open my $fh, '<', $file or die "Cannot open ($file) for reading: $
+!";
    local $/;
    my $contents = <$fh>;
    return $contents;
}
[download]

Cheers,
Ovid

New address of my CGI Course.

Comment on Use PPI to Find SQL Injection Attacks Download Code
Re: Use PPI to Find SQL Injection Attacks by jZed (Prior) on Aug 14, 2007 at 18:14 UTC
Unless I'm misreading, some of the more serious false negatives include: `$dbh->do(qq{ /* comment */ INSERT INTO foo VALUES('$bad_stuff') }); $dbh->do(qq{ INSERT INTO foo VALUES($bad_stuff) }); $dbh->do( sprintf( "INSERT INTO foo VALUES(%s)", $bad_stuff ));` [download] A better approach might be to find all the prepare() and do() statements and run them through a safe DBI subclass that does the prepare and evaluates what it prepared.	[reply] [d/l]
Re^2: Use PPI to Find SQL Injection Attacks by Ovid (Archbishop) on Aug 14, 2007 at 18:58 UTC
Excellent points on the SQL. I like the DBI subclass idea. Can you point me to some examples? I've never tried to do anything like that before. Cheers, Ovid New address of my CGI Course.	[reply]
Re^3: Use PPI to Find SQL Injection Attacks by jZed (Prior) on Aug 14, 2007 at 19:08 UTC
A minimal DBI subclass can be found here: Interpolate binds into SQL on error - DBI subclassing (possibly not the best example but since I wrote it I knew where to find it :-)). Basically you'd need to redefine execute() to do nothing, and redefine prepare() (in MyDBI::db) to do your injection checking.	[reply]
Re: Use PPI to Find SQL Injection Attacks by tinita (Priest) on Aug 15, 2007 at 07:51 UTC
and how about TaintIn in DBI? this should also find possible security holes. `DBI->connect($dsn, $user, $pass, { TaintIn => 1 });`	[reply] [d/l]


more useful options
	PerlMonks

Use PPI to Find SQL Injection Attacks

What level of existential comfort do you require?