2016-07-14 17:09 GMT+03:00 Warren Young <wyml@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