[dancer-users] Methods Of retrieving request parameters

[Warren Young]

On Jul 12, 2016, at 5:08 PM, WK <wanradt at gmail.com> wrote:
> 
> 2016-07-12 20:54 GMT+03:00 Warren Young <wyml at etr-usa.com>:
> 
>> I gave cat(1) as an example of doing it right.  For a more complex example, consider sqlite3.
> 
> Should sqlite3 (or cat) accept all three paths same time?

Of course not, and they don’t, any more than Dancer’s params() mooshes all three together:

   $ echo foo | cat <(echo bar)
   bar
   $ echo 'select 2*3' | sqlite3 x.db 'select 3*4'
   12

> Which one should first, which last?

That's up to the Dancer designers to specify.

> Should those inputs just concatenated
> together or should they divert each other in some order?

The three parameter sources should have a defined and documented precedence order.

> So POSTing path with query and form params
> 
> /item/id/123?id=223
> 
> [id=333]
> 
> we start with 3 different id-s, but at end we have one of them. Is it
> good design for app? I don't think so.

You see this kind of thing a lot, do you?

If a caller does something like what you suggest, it doesn’t matter which one Dancer chooses to pass to your app.  The caller has made an ambiguous call, so it is at the mercy of Dancer’s precedence rules.

> One way to solve this as early as possible is to have those 3
> different methods and make those access 3 separate arguments, so
> developer can choose, where from to read certain value. It leaves
> choice to the developer.

I answered that in the reply you quoted: if you, as the app developer, wish to restrict your APIs so they get data from only one of the three possible sources, I have no problem with that, and I’m glad Dancer now gives you a way to force that.

I’m just telling you that I don’t care where my data comes from, and I don’t want someone telling me I’m wrong for not caring, unless they also show me a concrete scenario where the data source affects the behavior of the app in a way that could not happen if my program only accepted input from one of the three sources.

> I am not sure why Dancer had both param and params?

These two may have the same effect:

      param 'foo'
      params->{foo}

…but they do not compile to the same code.

> Let's
> say we have app with authentication middleware. Middleware checks user
> ID from path and reads session ID from cookie, then it makes sure from
> backend, that user ID and session match, so it flags connection
> correct and gives it forward to app. In app path-ID and query-ID have
> conflict, but last one wins because precedence and now we run our
> query in rights of ID we read from query params. Seems like taking
> over to me. Avoidable, if we make distinction, from where param is
> readed.

If all it takes to fool your authentication system is to change a session ID in the query, how does restricting the parameter source fix that?  Any attacker that can insert a second conflicting session ID into the query can just change the first session ID.  Restricting the input source buys nothing.

This is the same criticism I already answered from someone else in this thread, in fact: show me an attack that can modify the URL query parameters but can’t modify the POST body.

The solution to both classes of problem is the same, because it’s the same attack: use HTTPS.