Re: [Catalyst] Example of a catalyst application using FormFu to createa table
Using FormFu this can be painful. http://search.cpan.org/~snafufans/CatalystX-ListFramework-0.5/lib/CatalystX/ListFramework.pmwill build you pretty tables of data. hth, Devin On Tue, Jun 16, 2009 at 11:03 PM, Wilson Jason wrote: > > All, > > Unfortunately nobody has been able to help me with this. > > After much more trial and error I have something that almost works. > > An extract from the FromFu config looks like: > - type: Hidden >name: a_count > > - type: Block >tag: table >attributes: > border: 1 > >elements: >- type: Repeatable > tag: tr > nested_name: list > counter_name: a_count > model_config: >empty_rows: 1 > > elements: > - type: Hidden >name: id > > - type: Block >tag: td >elements: >- type: Text > name: relationship > > - type: Block >tag: td >elements: >- type: Select > name: listnames > > - type: Block >tag: td >elements: >- type: Checkbox > name: delete_me > # model_config: > # delete_if_true: 1 > > This renders well enough for my purposes. > > The problem is that the option to 'delete_if_true' doesn't work. There > is an error of the form: > [error] Caught exception in Cubs::Controller::Cub->formfu_edit "element > not found at > /usr/local/lib/perl5/site_perl/5.10.0/HTML/FormFu/Model/DBIC.pm line > 352" > > Reading the code here it would appear to be trying to find the relevant > 'repeatable' for the model_config but cant as it is inside a nested > Block. > > Any idea on how I might be able to work around this problem? I tried > moving the 'delete_if_true' onto the 'Block', but it just ignores it. > > Thanks for any assistance, > Jason > > > As of 26 March 2009 the Department of Natural Resources and > Water/Environmental Protection Agency integrated to form the Department of > Environment and Resource Management > > ++ > Think B4U Print > 1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere > 3 sheets of A4 paper = 1 litre of water > ++ > > > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > -- Devin Austin http://www.codedright.net http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost! ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Example of a catalyst application using FormFu to createa table
All, Unfortunately nobody has been able to help me with this. After much more trial and error I have something that almost works. An extract from the FromFu config looks like: - type: Hidden name: a_count - type: Block tag: table attributes: border: 1 elements: - type: Repeatable tag: tr nested_name: list counter_name: a_count model_config: empty_rows: 1 elements: - type: Hidden name: id - type: Block tag: td elements: - type: Text name: relationship - type: Block tag: td elements: - type: Select name: listnames - type: Block tag: td elements: - type: Checkbox name: delete_me # model_config: # delete_if_true: 1 This renders well enough for my purposes. The problem is that the option to 'delete_if_true' doesn't work. There is an error of the form: [error] Caught exception in Cubs::Controller::Cub->formfu_edit "element not found at /usr/local/lib/perl5/site_perl/5.10.0/HTML/FormFu/Model/DBIC.pm line 352" Reading the code here it would appear to be trying to find the relevant 'repeatable' for the model_config but cant as it is inside a nested Block. Any idea on how I might be able to work around this problem? I tried moving the 'delete_if_true' onto the 'Block', but it just ignores it. Thanks for any assistance, Jason As of 26 March 2009 the Department of Natural Resources and Water/Environmental Protection Agency integrated to form the Department of Environment and Resource Management ++ Think B4U Print 1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere 3 sheets of A4 paper = 1 litre of water ++ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Potential query string pollution vulnerability?
Tobias Kremer wrote: Thanks a lot! I didn't know that this was the recommended practice. Apparently, TIMTOWTDI striked again! :( The docs on Catalyst::Request::param don't help to make this (and the possible consequences of using this method) clear. If someone would like to volunteer to write a paragraph making this crystal clear, and recommending the other methods of accessing the parameters, then this would be _very welcome_. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Potential query string pollution vulnerability?
On Tue, Jun 16, 2009 at 1:14 PM, Octavian Rasnita wrote:
> Try
> name => $c->req->params->{name}
> I think this was the recommended way, exactly for the reason you described.
Thanks a lot! I didn't know that this was the recommended practice.
Apparently, TIMTOWTDI striked again! :(
--Tobias
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Potential query string pollution vulnerability?
On Tuesday 16 June 2009 04:11:19 am Tobias Kremer wrote:
> 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
>
Using $c->req->param for this kind of purpose (or, if you ask certain people,
for any purpose) is discouraged, and has been discouraged as long as I can
remember, for this reason. Use $c->req->params and validate your input.
(Incidentally, if you'd used $c->req->params->{name} the behavior you would
have gotten would have been "WHERE name='Foo' OR name='Bar'" which can be a
really useful behavior straight out of the box -- but the point stands that
you have to know what your data is, know what your data needs to be, and make
sure that the two are reconcileable before you do anything :)
Andrew
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Potential query string pollution vulnerability?
From: "Tobias Kremer"
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' )
Try:
name => $c->req->params->{name}
I think this was the recommended way, exactly for the reason you described.
Octavian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Potential query string pollution vulnerability?
> You are not validating your input. That's all there is to say... True, but I think that many people are led to believe that their input is being correctly quoted by DBIC which in most cases it is, but in this particular case it is not. I'm just trying to safe people from the consequences of this rare but not so obvious behaviour. Sorry, if this is not what this mailing list is about. Geez ... --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Potential query string pollution vulnerability?
Am 16.06.2009 um 11:11 schrieb Tobias Kremer:
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?
You are not validating your input. That's all there is to say...
moritz
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
Sergio Salvi wrote: I've applied both patches into this branch: http://dev.catalyst.perl.org/svnweb/Catalyst/browse/branches/Catalyst-Plugin-Session/both/ Hi, sorry for the very late followup on this, but it's been noted that the documentation wasn't adjusted to reflect the changes made. I don't suppose you could document how it works now correctly: http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Plugin-Session/0.00/trunk/ Many thanks in advance. t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Potential query string pollution vulnerability?
2009/6/16 Tobias Kremer :
> 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: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
