2009/6/16 Tobias Kremer <[email protected]>: > 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?
I remember someone pointing this out at YAPC-europe 2006 - so I'd be surprised if it's not mentioned in the docs somewhere. Personally, using HTML-FormFu I add the SingleValue constraint to all form fields, by default. I would expect all form validation modules to provide a similar functionality - in which case, never touch $c->req->params() and always use $form->params(). Carl _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
