[dancer-users] Methods Of retrieving request parameters

[Warren Young]

On Jul 12, 2016, at 9:27 AM, Dave Cross <dave at dave.org.uk> wrote:
> 
> Quoting Warren Young <wyml at etr-usa.com>:
> 
>> On Jul 11, 2016, at 3:29 AM, Dave Cross <dave at dave.org.uk> wrote:
>> 
>>> The more explicitly-named methods are definitely safer. You really want to know where your parameters are coming from.
>> 
>> I’m still waiting for someone to justify that stance with more than confident prose assertions.  Someone, please show me code that the new keywords makes better.
> 
> It's to do with security.

So show me a Dancer program that exposes a security hole when data is accepted via an unexpected channel.  So far, all I’ve gotten is “because security.”

> If you've written the application, you know the channels that the params should be coming through.

Not necessarily.  The remote app might not be yours, as is common when publishing an API.

I am not saying that you, as an API designer do not have the right to insist that data be passed only via documented channels.  You certainly do.  What I’m arguing against is this idea that if I, as the API implementer choose to call param or params to retrieve the data but I document the data as coming from only one source, that my program is somehow “wrong.”

> If you've written the app so that it sends 'foo' as a body parameter and it arrives as a query parameter, then that might be evidence of someone doing something with your app that you would rather they didn't do. Perhaps they're probing it for security holes.

A sanely written Dancer route handler will do the same thing with a parameter no matter where it came from.  This is the principle of referential transparency:

  https://en.wikipedia.org/wiki/Referential_transparency

Are you arguing that this is a bad design principle?

> Imagine you have a form that contains important information in <hidden> form fields. You have filled in those fields in the HTML response that you sent back to the browser. That data should turn up in a body parameter. If it turns up in a query parameter, then someone is trying to override that value.

I’m having trouble imagining an attacker capable of modifying the URL but not the POST body.  Care to help me out on that one?

> I learned long ago that the internet is a nasty place and I'm going to be as distrustful as possible of the data I get back from my users.

I suspect I learned long before that a principle called Postel’s Law:

  https://en.wikipedia.org/wiki/Robustness_principle