matches the content-type) we raise a L<Catalyst::Exception> with the error
text as the message.
-If the POSTed content type does not match an availabled data handler, this
+If the POSTed content type does not match an available data handler, this
will also raise an exception.
=head2 $req->body_parameters
C<< $c->req->parameters >>.
B<NOTE> Interfaces like this, which are based on L<CGI> and the C<param> method
-are now known to cause demonstrated exploits. It is highly recommended that you
-avoid using this method, and migrate existing code away from it. Here's the
+are known to cause demonstrated exploits. It is highly recommended that you
+avoid using this method, and migrate existing code away from it. Here's a
whitepaper of the exploit:
L<http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/>
+B<NOTE> Further discussion on IRC indicate that the L<Catalyst> core team from 'back then'
+were well aware of this hack and this is the main reason we added the new approach to
+getting parameters in the first place.
+
Basically this is an exploit that takes advantage of how L<\param> will do one thing
in scalar context and another thing in list context. This is combined with how Perl
chooses to deal with duplicate keys in a hash definition by overwriting the value of
existing keys with a new value if the same key shows up again. Generally you will be
-vulnerale to this exploit if you are using this method in a direct assignment in a
+vulnerable to this exploit if you are using this method in a direct assignment in a
hash, such as with a L<DBIx::Class> create statement. For example, if you have
parameters like:
projects / catagits/Catalyst-Runtime.git / blobdiff