在参与Twitter漏洞赏金项目的过程中，我通过一些安全测试发现了Twitter存在的重大漏洞：攻击者不需要获取他人账户权限，就能以任意账户发布推文。我于2017年2月26日发现了该漏洞，Twitter方面于2017年2月28日及时对其进行了修复，并最终向我奖励了$7560美元漏洞赏金。我们一起来看看该漏洞细节：
简 介
Twitter Ads最早为向企业开放的广告服务平台，为了扩大自媒体广告业务，Twitter Ads于2013年5月1日向所有美国用户免费开放，用户可以通过https://ads.twitter.com/注册个人广告业务，实现推文（Tweet）推广、竞价排行、个性化定制等个人广告宣传。Twitter Ads服务中包含了一个多媒体库，注册用户可以向该库上传个人广告相关的视频、图片、GIF动图等多媒体文件，另外，用户在发布推文之前也能对这些文件进行审核。该多媒体库存在以下链接中：
https://ads.twitter.com/accounts/*id_of_your_account*/media
前期试探
如果你是Twitter Ads注册用户，用以上链接登入多媒体库后会发现其多媒体文件上传功能：
我们点击右上角的媒体文件下载按钮Download media-file（Загрузить медиа-файл），选择某一上传图片文件后，会显示相应的已经上传的图片：
点击该图片放大，请注意查看上图中显示的功能，将出现以下情景：
1、我们可以推送发布该多媒体文件
2、我们可以与任何用户分享该多媒体文件
通过BurpSuit抓包具体分析一下该推文布动作的相关功能：
可以发现网络请求包中包含以下参数：
account_id：账户ID，为已登录入库的账户ID；
owner_id：图片文件所有者ID；
user_id：推文分享用户的ID；
media_key：媒体文件发布ID，如下图的地址栏URL后部分数字：
接下来，让我们来定义一些相关的测试标识：
我的第一个测试账号：account №1
我的第二个测试账号：account №2
由于我不记得错误输出的确切语句，所以我们暂且把两个账号对应的错误输出定义为error №1、error №2。
漏洞发现
首先，我拦截监听了推文发布的网络请求信息，并尝试进行以下参数更改：
基于json的GET请求owner_id和user_id，在POST方式下，被设置从account №1发往对应的account №2处，此时，发生了错误error №1；
之后，我尝试在POST包中更改owner_id和user_id，又出现了错误error №2，我记得当时的错误提示是这样的：
作为替代*的，owner_id为*id的用户，并不是该多媒体文件的所有者，*这里应该是一个media_key*
我想，既然这样，那我们作出如下更改：
我使用account №2登录ads.twitter.com，进入媒体库，上传图片，以提前让Twitter解析出media_key的值。
举一反三
我们回到account №1登录状态：
拦截监听推文发布的网络请求信息，针对推文接收方account №2，我们对GET方式和POST请求中的owner_id和user_id作出相应更改，同时使用了之前知道的media_key值，之后，将会得到错误error №1，尽管如此，但在对owner_id和user_id的更改替换中，仅只出现了一种错误error №1；而仅在POST方式中对owner_id和user_id作出更改替换，会出现另一种错误error №2。那我们再试试其它的？
终于，在POST请求中对owner_id、user_id和media_key作出一系列更改替换之后，响应信息提示我们尝试的推文发布动作成功执行！对于account №2账户来说，可以发现尽管该账户本身没有执行任何推文发布动作，但其实以其身份和相应media_key的上传图片已被account №1当成推文发送出去了！
漏洞探索
好了，现在，我们可以以任意用户账户身份发布推文了，但同时也存在一些可能会消弱漏洞严重性的限制条件：我们用来发布推文的受害者用户必须具有一个已经上传的多媒体文件，而且，还需要知道这个多媒体文件的media_key，但由于media_key包含18位数字，一般来说，很难通过暴力猜解或其它方式知晓该数值，media_key值的获取存在一定限制性难度。
难道这就歇菜了吗？就这样向Twitter上报该漏洞？再想想看！我个人感觉该漏洞可能非常严重，想想看，还记得之前可以对任何用户分享该媒体文件的情况吗？我想到了一个非常有趣的点子：如果我们向受害者用户（即用他的账户发送推文）分享我们的多媒体文件，那么此时，该受害者用户也将被视为是这个多媒体文件的所有者， 错误error №2情况也将不会发生，而以该账户身份发送的推文也能成功发布！经过测试证明，该情景确实能成功实现！
综合以上场景可知，其实对该漏洞的成功利用并不需要media_key的值，当然，如果我们是多媒体文件的所有者，当然也就知道media_key值了。
最终，可以总结出以下漏洞利用的实现条件：
1、我们上传自己的多媒体文件；
2、向受害者用户（推文发布用户）分享该多媒体文件；
3、拦截监听向受害者用户发起的推文发布网络请求信息，并对owner_id和user_id值进行修改，；
4、之后，就可以接收到以受害者用户身份成功发布推文的响应信息。
5、利用该漏洞尽情玩耍吧！
好了，可以安心地向Twitter上报漏洞并等待漏洞赏金了！
