2016-07-14 17:09 GMT+03:00 Warren Young <[email protected]>: > 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 _______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
