On Wed, Jun 23, 2010 at 7:03 AM, Nigel Peck <nigel.p...@miswebdesign.com> wrote:
> A Perl web-application I have written uses both GET and POST data at the
> same time. This is because I have URLs like:
*snip*
> I get data using CGI.pm and a little sub like this:
>
> sub _get_param_by_preference {
> my ( $q, $param ) = @_;
>
> defined $q->param ( $param )
> ? $q->param ( $param )
> : $q->url_param ( $param )
>
> }
>
> so it goes for POST data first and fails-over to GET data.
>
> Is this ok? It's not caused me any problems, but a forum post I read just
> now says that this is in violation of the RFCs and can have unreliable
> results. Is that only for the browser? That it shouldn't pass both GET and
> POST data? In which case I'm innocent but will avoid doing it any other way
> than the rewrite method I'm using. Or server-side too?
>
> Should I think about revising my approach? And if so why?
AFAIK, POST is generally used to send /changes/ and GET is generally
used for queries (getting data, but not changing it). I think it's
normal to pass both, however. I've read that secure Web sites should
actually require unique tokens as both GET and POST data before
authorizing anything. This helps to prevent cross-site scripting
attacks, like dropping HTML like the following into your own site to
hijack someone else' session on another:
<img src="http://yourbank.com/transfer?amount=1000000&dest=1234567890";
width="1" height="1" />
Obviously a ridiculous example, but the point is that by requiring
POST data it wouldn't be possible to trick a user's client into making
such a request on their behalf because it would be missing POST data
(that is also why changes should be done through POST data). It
basically just adds more complexity to the system, requiring would be
hackers or what have you to do more work to actually gain access to
the system. It's superficial security, obviously. Alone it isn't
enough to secure a site, but it helps.
What you might have read is that it's bad practice to hide GET and
POST data behind a common interface. It's bad for the reasons already
mentioned. Using the ridiculous bank example above, if the bank
expected "amount" and "dest" to be POSTed to them, but used a common
interface, then it would suffice to use GET data, which means a simple
embedded image with a carefully crafted URL or something might be able
to make a request on the user's behalf, which we can all agree is a
bad thing.
So yes, you should probably revise your approach. It would be better
to specify which data source you expect a particular field from and
require that it comes from the correct source.
--
Brandon McCaig <bamcc...@gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamcc...@castopulence.org>
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
