Facebook and Dropbox in the CSRF vulnerability analysis-vulnerability warning-the black bar safety net

ID MYHACK58:62201785188
Type myhack58
Reporter 佚名
Modified 2017-04-13T00:00:00


Facebook provides the user with a very handy feature, and the user can pass this option directly from the Dropbox account to load file: ! This feature will allow the user directly in the browser window to view and upload to the Dropbox account in the file: ! This functional integration is through the OAuth 2.0 Protocol, a variant of the version implemented, the specific reference to this article【portal】。 Note: OAuth is a In line with the international Internet Engineering Task Force(IETF)label of the access proxy protocols. The OAUTH Protocol for the user resource authorization provides a secure, open and simple standards. At the same time, any third party can use the OAUTH Authentication Service, any service provider can implement their own OAUTH authentication service, and thus OAUTH is open. The industry provides OAUTH multiple implementations such as PHP, JavaScript, Java, Ruby, etc. a variety of language development kit, greatly saves the developer's time, and thus OAUTH is simple. The Internet many services such as Open API, a lot of big companies such as Google, Yahoo, Microsoft, etc. are provided in the OAUTH Authentication Service, these are sufficient to illustrate the OAUTH standard has gradually become the open resource authorization standards. The OAuth workflow as shown below: ! Typically, the client will use the lower figure shows the method to initiate the authentication of: ! Next, the owner of the resource to the requesting client is authenticated, the authentication is completed, the authentication server sends a verification code sent to the client: ! Facebook and Dropbox integration Facebook the Dropbox integration into their service, Dropbox has become a initiates a request of the client, and Facebook's authentication / resource Server. ! Shown above is the OAuth Protocol is a standard workflow, in this case the resource request should be made by the client sent, i.e. Dropbox, but the fact is not so. See the following figure: ! In fact, the client, Dropbox will by following the URL will be the resource owner is redirected to the authentication server:

https://www.facebook.com/dialog/oauth?display=popup&client_id=210019893730&redirect_uri=https%3A%2F%2Fwww. dropbox. com%2Ffb%2Ffilepicker%3Frestrict%3D100000740415566%26group_id%3D840143532794003&scope=publish_actions%2Cuser_groups%2Cemail&response_type=code In addition, other steps are in accordance with the OAuth Protocol is a standard process to go. ! The OAuth 2 Protocol CSRF vulnerability Eyes tip students may have noticed following this initial link:

https://www.facebook.com/dialog/oauth?display=popup&client_id=210019893730&redirect_uri=https%3A%2F%2Fwww. dropbox. com%2Ffb%2Ffilepicker%3Frestrict%3D100000740415566%26group_id%3D840143532794003&scope=publish_actions%2Cuser_groups%2Cemail&response_type=code While the above this link is missing in the one named“state”of the key parameters according to the OAuth Protocol Description, This parameter is defined as follows: In order to let everyone to better understanding of the CSRF vulnerability, we use the following flow chart to give you to explain: ! If this picture doesn't let you have a good understanding of this vulnerability, you can also refer to Egor Homakov this article about OAuth2 Common Vulnerability of the articles. 【Portal】 Facebook introduced the Dropbox after the CSRF vulnerability In the specific attack described before, we also need to emphasize one very important thing: the OAuth Protocol for CSRF protection mechanism, i.e., the state parameters used in here is not going to work. As we have seen, to initiate the request of is Facebook, rather than Dropbox. As a result, Dropbox will not be able to check the state parameter is configured correctly. In this case, the 攻击 者 将 能够 通过 https://asanso.github.io/facebook/fb.html in a malicious link that contains a bogus verification code to fake out a Web page, and implement the attack. &group_id=236635446746130 &code=AQAJspmJvIyCiTicc4QNr7qVU4EF05AYqbe_k9pl-fbhSuKyxtjHS_UyYU8K0S czXZCTa9WxtG7I8EoxAIcyqhyO0tagiVsa1m2h3umg8uzr6gixrlmuxkuyoxmysb14yxpbwony xvepwP2N93gWxhVwl1me-qeenZIX2oKgqBuFMRHAW5SCaYCvYSYtamlrdyygofttcaym0qfu_ bX94LfkHUl81O1tmrLU2NtnU5Eh_XKvxjid5j2ftswfpcoxeb7ccaz_9upzjsfnkgctttpx_2dcqi99at 7B3M4idq6hzY-wUuDmaOL143WolrCGkDUu-np8gyEFx4wfMMdX0a0g#=" /> Next, when the target user access to this address after his Dropbox will be the identity of the attackers upload arbitrary files. Below this video demonstrates the complete attack process: Vulnerability report timeline Everyone knows that reporting this kind of product integration issues is always very difficult, because we find it difficult to figure out exactly who is causing this vulnerability to appear the culprit. But this time, the culprit obviously is Dropbox, and Facebook are the victims. But the awkward thing is that, Dropbox itself will not be affected by this vulnerability, so Dropbox technical team for which I submitted this vulnerability is not interested. And for Facebook, if there is no Dropbox help, only rely on their own is also very difficult to repair this vulnerability. And I? I'm just an awkward middle man...

[1] [2] next