概述
Facebook允许用户直接加载Dropbox账号中的文件，这种整合进来的功能使用的是OAuth 2.0协议，而这个协议中存在一个经典OAuth CSRF漏洞的变种，具体请看下面这个视频：
介绍
Facebook给用户提供了一个非常方便的功能，而用户可以通过这个选项直接从Dropbox账号中加载文件：
这个功能将允许用户直接在浏览器窗口查看并上传Dropbox账号中的文件：
这种功能性的整合是通过OAuth 2.0协议的一个变种版本实现的，具体可参考这篇文章【传送门】。注：OAuth是一种符合国际互联网工程任务组（IETF）标注的访问代理协议。OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。业界提供了OAUTH的多种实现如PHP、JavaScript，Java，Ruby等各种语言开发包，大大节约了开发人员的时间，因而OAUTH是简易的。互联网很多服务如Open API，很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。OAuth的工作流程如下图所示：
通常情况下，客户端会采用下图所示的方法发起认证：
接下来，资源的拥有者会对发起请求的客户端进行身份验证，验证完成之后，认证服务器会将验证码发送给客户端：
Facebook与Dropbox的整合
Facebook将Dropbox整合进自己的服务之后，Dropbox就成为了发起请求的客户端，而Facebook就是认证／资源服务器。
上图所示即为OAuth协议的标准工作流程，此时的资源请求应当由客户端发出，也就是Dropbox，但事实并非如此。请看下图：
实际上，客户端（Dropbox）会通过下面的URL将资源拥有者重定向至认证服务器：
|
1
|
|
除此之外，其他的步骤均是按照OAuth协议的标准流程走的。
OAuth 2协议中的CSRF漏洞
眼睛比较尖的同学可能已经注意到了下面这个初始链接了：
|
1
|
|
而上面这个链接中缺少了一个名叫“state”的关键参数，根据OAuth协议的描述，这个参数的定义如下：
为了让大家能够更好地理解这个CSRF漏洞，我们用下面这张流程图来给大家解释：
如果这张图片无法让您很好地理解这个漏洞的话，您也可以参考Egor Homakov的这篇关于OAuth2常见漏洞的文章。【传送门】
Facebook引入Dropbox之后的CSRF漏洞
在对特定的攻击进行描述之前，我们还需要强调一件非常重要的事情：OAuth协议中针对CSRF的保护机制（即state参数的使用）在这里是不会奏效的。正如我们之前所看到的那样，发起请求的是Facebook，而不是Dropbox。这样一来，Dropbox将无法检查state参数是否进行了正确配置。此时，攻击者将能够通过https://asanso.github.io/facebook/fb.html 中的一个恶意链接（包含伪造的验证码）来伪造出一个Web页面，并实施攻击。
|
1
2
3
4
5
6
7
8
9
|
<html>
<img src="https://www.dropbox.com/fb/filepicker?restrict=100000740415566
&group_id=236635446746130
&code=AQAJspmJvIyCiTicc4QNr7qVU4EF05AYqBE_K9pl-fbhSuKyxtjHS_UyYU8K0S
czXZCTa9WxtG7I8EoxAIcyqhyO0tagiVSa1m2H3Umg8uZR6gixrlmUXKuyoXmYsb14yxPbwonY
xvepwP2N93gWxhVwl1me-qeenZIX2oKgqBuFMRHAW5SCaYCvYSYtaMlrDyYGoftTCAYM0QfU_
bX94LfkHUl81O1tmrLU2NtnU5Eh_XKvxjiD5j2ftSWfpCoxeb7ccaz_9UPZjsFnKGCtTTPX_2dCqi99aT
7B3M4idq6hzY-wUuDmaOL143WolrCGkDUu-np8gyEFx4wfMMdX0a0g#_=_" />
</html>
|
接下来，当目标用户访问了这个地址之后，他的Dropbox将会以攻击者的身份上传任意文件。下面的这个视频演示了完整的攻击过程：
漏洞上报时间轴
大家都知道，报告这种产品整合方面的问题永远是很困难的，因为我们很难弄清楚到底谁才是导致这一漏洞出现的罪魁祸首。但是这一次，罪魁祸首很明显就是Dropbox，而Facebook才是受害者。但尴尬的地方就在于，Dropbox自身并不会受到这个漏洞的影响，所以Dropbox的技术团队对于我所提交的这个漏洞并不感兴趣。而对于Facebook来说，如果没有Dropbox的帮助，仅靠他们自己也是很难修复这个漏洞的。而我呢？我只是一个尴尬的中间人…
2017年1月13日 - 将漏洞上报给Facebook的安全团队。
2017年1月14日 - 通过Hackerone将该漏洞上报给Dropbox的安全团队。
Dropbox #1
2017年1月15日 - Dropbox回复称：“这个漏洞的存在是由于Facebook对Dropbox API的错误使用所导致的，而并非Dropbox的API存在安全问题。”
2017年1月15日 - 我给Dropbox的回复是：“这个漏洞的确是你们Dropbox的API设计不当所导致的。”
2017年1月15日 - Dropbox回复称：“我们会重新审查这个漏洞，如果我们认为这是一个有效漏洞的话，我们会进行处理。”然后给我的声望值减了五分…
2017年1月15日：虽然我不太在意这些积分，但我还是向Dropbox表示：“给你们提交了一个漏洞，却让我损失了五点声望值，这确实很令人沮丧。”
2017年1月17日：Dropbox重新开启了这个漏洞报告，我重新得到了这五点声望值。
2017年1月20日至2017年2月25日 - 我与Facebook的技术人员在尝试复现这个漏洞。
2017年2月25日 – Facebok关闭了这个问题，并表示：“我们能够复现你所提交的这个漏洞，但是这个漏洞是由Dropbox（/fb/filepicker）导致的，我们这边无法进行修复。”
2017年3月4日 – 询问Facebook是否有可能与Dropbox方面沟通并解决这个问题。
Dropbox #2
2017年3月7日 – 再一次通过Hackerone向Dropbox安全团队上报这个漏洞。
2017年3月22日 – Dropbox向asanso提供了1331美元的漏洞奖金。
2017年4月10日 – 漏洞细节披露
本文由 安全客 翻译，作者：WisFree
原文链接：http://blog.intothesymmetry.com/2017/04/csrf-in-facebookdropbox-mallory-added.html