> -----Original Message----- > From: Francisco Corella [mailto:fcore...@pomcor.com] > Sent: Saturday, April 02, 2011 11:14 AM > To: Dick Hardt; Skylar Woodward; Phillip Hunt; Eran Hammer-Lahav > Cc: OAuth WG; Karen P. Lewison > Subject: RE: to TLS or not on redirect on consumer websites :: security > considerations > > > Another example I mentioned earlier is when the client does not expose > > the protected resources back to the bearer of the code. For example, a > > Twitter application sending you emails when someone stops following > > you. Since all it does is get the code and then uses it internally (no > > user login functionality), TLS adds NOTHING. > > I'm not sure I understand the example. Would the attacker be able to get > emails when someone stops following the user? > Would that be OK?
No. The attacker will accomplish nothing other than to finish the flow on behalf of the legitimate user. 1. User is asked for email where to notify 2. User is redirected to Twitter to grant access 3. Someone comes back to the client with a valid code 4. Client uses code to get an access token and does not expose any data to the entity delivering the code > Anyway, an application that accesses Twitter on the user's behalf is likely to > be able to send tweets on the user's behalf. The attacks we've been > discussing would allow the attacker to send tweets on the user's > behalf. That's definitely not cool. > > User impersonation when Oauth is used for social login is not the only > consequence of not requiring TSL for the callback endpoint. The only consequence is compromising the *client* login/authentication security. I'm not trying to play it down, but I we need to be clear. This is not a compromise of the protected resources or authorization server. In your examples, it is done via stealing the authorization code. In other examples (due to the same lack of TLS security on the client) it is due to setting insecure session cookies. Any kind of incomplete client security is bad and will produce the exact same attack opportunities if it enables a MITM to interject itself into any of the client's login or authentication flows. IOW, for this security hole to be closed, clients MUST use TLS throughout the entire site, not just their redirection. You are demanding that the entire web moved to use TLS for all login and authentication of bearer credentials. That's a good goal, but the issue at hand is not whether the attacks are valid - they are. It is only what is the best LANGUAGE to use in order to move the web forward. Your solution is to force offenders to explicitly violate the protocol, but other's suggesting a more relax approach will produce the same result over time. The problem with your approach is that it already failed. Enough high profile companies on the consumer web front have said that they plan to ignore this MUST. I think it is much better for the future of web security for this document to reflect reality and find more productive ways to impact change. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
