Is this malicious piece of software external a native application either past of a native client or external to the browser?
EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Wednesday, September 14, 2011 6:51 AM > To: Eran Hammer-Lahav > Cc: Niv Steingarten; oauth@ietf.org > Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) > > Hi Eran, > > >> As far as I understood, in a textbook CSRF attack the attacker would > >> create his own requests in order to abuse a user's session. This can > >> be prevented by utilizing standard CSRF coutermeasures (page token, > >> nounce, signature as parameter on every request URL), which bind URLs > >> to a certain session. > > >A textbook CSRF attack is when an attacker constructs a URI and then > >manipulate a user-agent with an active session to call that. In the > >simplest example, an >attacker constructs a URI that transfers a > >million dollars from the current account to its, then tricks the user > >to click on that link or automatically >redirects the user to that URI. > > Because the user is already signed in and has an active session token, > >the request goes through. > > >To prevent it, the request URI must include an artifact that binds the > >request to the active session. Since the attacker has no way of > >accessing the session >information, it cannot construct as a URI. In > >practice, this means adding a hidden form parameter to the button with > >some hash of the session information >that the server can verify. > > So I would conclude we have the same understanding of what CSRF means. > > >> But why should the attacker create requests et all? All he needs is > >> already provided by the authorization server themselves. The > >> malicious client can download the HTML pages comprising the > >> authorization flow from the authz server and use the embedded URLs to > >> issue the requests which normaly would have been issued by the > >> resource owner herself (using the use agent indeed). It's more or > >> less the push on a "I agree" > >> button we are talking about. The authorization server may add a page > >> token to the respective form URL. But it does not matter since the > >> client just uses the authz server manufactured URL to post the form. > > >Of course it matters. > > >The only way the attacker can get access is by calling the 'I agree' > > button action via an active user session. The attacker cannot access > >the hidden form >value with the session hash (or whatever the server is > >using for CSRF protection). So whatever URI it constructs will not work > >when called with the active >user session. > > My point is: the attacker in the threat I'm trying to describe does not need > to > create any URL since it just remote controls the user-agent. The malicous > code runs outside of the browser and "just" uses the URLs provided by the > authz server. Yes, there need to be a session. No, the attacker does not > need to inject any URL he made up. > > >> So let's assume the attacker has to programmatically handle HTML > >> forms the authorization server delivers to the user agent. As you > >> correctly pointed out, the pre-requisite for such an attack to > >> succeed is that the resource owner must be authenticated somehow, > >> e.g. based on a session cookie. Which also means, we are talking > >> about clients running on the victim's device, within the user agent > >> or as native app. > >> > >> I see the following possible scenarios: > >> > >> 1) external system browser - The app could utilize an existing > >> session within the system browser on the victim's device. It could > >> then remote control a browser window, e.g. using low-level operating > >> system messages ("send mouse click") or component techniques such as > >> ActiveX. There are tools available to create macros which > >> automatically control and obtain data from such applications. So this > >> should be feasible. > >> > >> 2) internal browser (cross-browser cookies) - If the authorization > >> server uses cross-browser cookie techniques, such as flash cookies, > >> the attacker could instantiate an internal (invisible) browser and > >> try to utilize a session associated with such a cookie. I assume > >> controlling such a browser instance will be even simpler then in (1). > >> > >> 3) internal browser (silent authz flow) - This is a scenario where > >> the attacker is unable to abuse an existing session on the device. It > >> could instead create an internal browser and perform an authorization > >> flow with the resource owner for one particular scope. Using the same > >> browser instance and based on the cookies obtained in the first run, > >> it could silently perform additional authorization flows for other > >> scopes. > >> > >> 4) internal browser (non-interactive authentication methods) - There > >> are authentication methods available w/o the need for > >> user-interaction, for examples SIM card authentication or > >> certificate-based authentication. > >> The attacker could utilize an internal, invisible browser instance in > >> combination with such an authentication method in order to perform > >> the authorization process. > >> > >> I'm not sure whether the scenarios described above can be classified > >> as CSRF. > > >I'm having a hard time following all these scenarios. But the > >important part is that OAuth assumes the 'user-agent' is a compliant > >and secure web browser. If >the user-agent does not enforce cookie > >boundaries, XSS, CORS policy, etc. there isn't much we can do. In other > >words, if the user installs a poorly design >native application which > >has its own user-agent implementation opened to known web attacks, all > >bets are off. > > > >The security model behind all these is pretty simple. The active user > >session has to be protected from any external access by attackers and > >enforce same-origin policy. > > What didn't you understand? I would be happy to improve my description. > What I basically try to get across: a malicious piece of software running on > the > resource owners device can simulate her consent. As a pre-requisite the > attacker must be able to either abuse an existing session or to create a new > one. I gave four examples of how this could be achieved. At least the last has > obviously nothing to do with browser security features. The threat also has > nothing to do with poor design or user-agent implementation flaws. It is a > deliberate attack against the resource owner. > > One could argue that prevention of malicous software is not the > responsibility of the authz server. I could agree with that. But people seem > to > expect an OAuth authz server to cope with such attacks. That's why I believe > we either clearly draw this boundary in the spec or give a hint on how to > prevent this kind of threat. > > regards, > Torsten. > >I still don't see the need to add the proposed section. > > >EHL > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
