[dancer-users] Methods Of retrieving request parameters

[WK]

2016-07-14 17:09 GMT+03:00 Warren Young <wyml at etr-usa.com>:

> 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'm sorry, if my mail seemed arguing, I tried to think along with you,
to drag in someone who could give better reasoning, where those
security issues may lay...

Only place I was really arguing, was aspect of old system being flexible.

>> 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.

Actually, I never mentioned changing session ID in the query. My
described mechanism was founded on assumption, that there may be two
uncoupled places, which independently choose 1 of 3 possible ID-s, and
they choose differently. It is not about restricting input sources, it
is about consistency.

wbr,
-- 
Kõike hääd,

Gunnar