--- "Michael R. Fahey" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was looking at a perl script where the developer used different names
> for the incoming parameters and the database field names. He told me
> that this was done for security reasons-- to ensure that malicious users
> would not be able to discover the field names in the database being
> updated or queried. How dangerous is this? I think it would be easier to
> work with a hash of parameters from the input form.
>
> I'm using cg.pm, DBI, and postgresql.
>
> Thanks.
>
> Michael Fahey
Hi Michael,
Great question! This raises some security issues that many people just don't consider.
Wether or not this is a security risk depends upon exactly how you use the incoming
data. Let's
look at a short script that does this horribly, horribly wrong:
#!/usr/bin/perl -w
use warnings;
use strict;
use CGI qw/:standard/;
use DBI;
my $dbh = DBI->connect( 'dbi:ODBC:stuff', 'name', 'password',
{ RaiseError => 1} ) or die DBI->errstr;
my %data = map { $_, param( $_ ) } param();
my ( @fields, @values, $name, $value );
while ( ($name, $value) = each %data ) {
push @fields, $name;
push @values, $dbh->quote( $value );
}
my $sql = "INSERT INTO theTable (" .
join ( ",",@fields) .
") VALUES (" .
join ( ",",@values ) .
")";
print header,
start_html,
p( $sql ),
end_html;
So far, everything might look okay. The developer was even security conscious and
quoted the
values. Imagine what happens if this script is called with the following URL:
http://www.somehost.com/cgi-bin/db.cgi?name=Ovid&color=red
You get back a nice Web page with the following SQL:
INSERT into theTable ( name,color) VALUES (Ovid,red)
That's all well and good. Now, let's alter the URL slightly:
http://www.somehost.com/cgi-bin/db.cgi?name%29%20VALUES%20%28%20%27Ovid%27%20%29%3BDROP%20TABLE%20theTable%3BINSERT%20INTO%20theTable%20%28name=Ovid
Hmm, that's a bit more complicated. I wonder what the SQL is?
INSERT INTO theTable (name) VALUES ( 'Ovid' );DROP TABLE theTable;INSERT INTO
theTable (name)
VALUES ('Ovid')
Oops. We might lose that table. Now, by crafting a good query string, we can attempt
to execute
arbitrary SQL against the database (there are many, many variations of this attack).
These
attacks are kind of tricky because you usually need to craft the URL in such a way as
to ensure
that *all* of the SQL is valid at the time it's evaluated, but it's still a possible
exploit.
There are ways to make this secure and still use the field names, but I wouldn't
suggest it. While
I am not an advocate of Security by Obscurity, I do advocate not revealing information
that you
don't need to reveal.
Cheers,
Curtis "Ovid" Poe
=====
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
