tobias.kremer at gmail
Jun 16, 2009, 2:11 AM
Views: 713
Permalink
|
|
Potential query string pollution vulnerability?
|
|
Hi all,
I just experienced a nasty case of query string pollution
vulnerability in one of my Catalyst/DBIC apps. I think that the
circumstances under which this applies are not _that_ rare, so I
figured it'd be best to inform the world.
Imagine the following code in one of your actions:
sub crashme :Local {
my( $self, $c ) = @_;
my $result = [. $c->model( 'Foo' )->search( {
-or => [
name => $c->req->param( 'name' )
],
} ) ];
}
To me, this never looked like a potential security threat because
$c->req->param('name') is correctly inserted/quoted via bind
parameters, right? Well, let's see what happens, if we "pollute" the
query string a bit:
/crashme?name=Foo&name=Bar
This results in the following SQL:
SELECT ... FROM ... me WHERE ( ( name = ? OR Bar IS NULL ) )
Oh oh! :(
'Bar' is used as a column name here because Catalyst::Request::param
returns an Array if the caller desires it (wantarray). Solving this
problem is easy: Either force scalar context, or force array context
and take only the first element.
I'm not sure if it makes sense or is even possible to fix this within
DBIC and/or Catalyst. By the way, I'm using DBIC 0.08107 and Catalyst
5.71.
What do you think?
--Tobias
_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
|
Potential query string pollution vulnerability?
