X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FRequest.pm;h=0cfcbae1c3cc583723dea6507ce508e25760a246;hb=5fa5b709e0d80a7cc43694c3513666de2de4390d;hp=5e5730593328d2acb250004f82d88f40913f1e1a;hpb=6dcc530761473f574ccde956e3a321b1dfb3d27e;p=catagits%2FCatalyst-Runtime.git

diff --git a/lib/Catalyst/Request.pm b/lib/Catalyst/Request.pm
index 5e57305..0cfcbae 100644
--- a/lib/Catalyst/Request.pm
+++ b/lib/Catalyst/Request.pm
@@ -531,7 +531,7 @@ If the POST is malformed in some way (such as undefined or not content that
 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
@@ -669,17 +669,21 @@ cause a hash initialization error. For a more straightforward interface see
 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: