本文讲的是这个漏洞值7650美元，原因是你可以在任意Twitter账户上发小片儿，在对Twitter的安全测试期间，我发现了一个漏洞，它允许黑客在任何用户使用该服务的情况下在Twitter网络中发布条目，并且无需访问受害者的帐户。这个漏洞发现于2017年2月26日，并于2017年2月28日被修复。
现在来看看这个漏洞的技术细节。
twitter网络中有一项服务为：https://ads.twitter.com/，它具有可以上传媒体文件（视频，图片，gif动画）的媒体库，也可以查看之前上传的文件，这是在发布Twitter的时刻使用的。
当我们打开该库，我们就会看到其上传媒体文件的功能：
点击“下载媒体文件”按钮并选择适当的文件后，我们就会看到图片：
点击上传的图片，然后我们就会看到：
我们可以推送我们的媒体文件，也能够与任何用户共享媒体文件。
好！所以，现在让我们仔细看一下tweet的功能：
我们在这里可以看到
account_id – 帐号（直接在库中）
图片拥有者的owner_id -id
user_id – tweet将被发布给具有此id的用户
media_key – 要发布的媒体文件的ID（查看图3中的地址字符串）
我们来介绍一下我所使用的符号：
帐号№1 – 我的第一个帐户
帐号№2 – 我的第二个帐号
因为我不记得输出错误的确切语句，所以我把他们暂且称之为：“错误№1”，“错误№2”。
揭示漏洞的步骤如下：
首先，我拦截了tweet发布和更改参数的请求：GET-request中的owner_id和user_id，由POST-method发送的json从帐号№1的id到相应的id号，但是没有收到预期的结果，而是得到了错误№1。
之后，我决定在POST中更改owner_id和user_id，然后我就收到了错误№2，其具体内容是：«User with owner_id * id which was a substitute* is not an owner of this media-file *here should be a media_key*»
再然后我做了下面的这些事情：
我拿了帐号№2，打开了服务ads.twitter.com，然后点开该库，并提前上传图片来了解media_key。
一件事往往会导致另一件事的发生
我们回到帐号№1：
然后，我们截取Twitter的请求，并更改GET和POST方法中的owner_id、user_id，以便在帐户№2上传图片时我们可以获取到帐户№2的相应数据和媒体密钥。这时我们又看到了错误№1。这是非常难过的…但是，尽管如此，当我们在GET和POST方法中替换owner_id和user_id时，只有一个错误（错误№1），而在POST方法中仅替换owner_id和user_id的情况还有其他错误（错误№2）。我们继续！
在POST方法中更改请求owner_id，user_id和media_key，然后…我们就会看到响应，我想关于这一漏洞的验证成功了！转到帐号№2，我们可以看到已经发布了之前帐号№2上传图片的推文，但事实上帐号№2本身并没有公布。
那么也就是说，我们现在理论上有可能发布在任何用户的账户中发布twitter，但实际上这一切还是有明确的限制的，这严重地减少了该漏洞的影响（一个漏洞的严重程度），限制包括：我们用来入侵进行发布的用户必须上传了一个媒体文件。此外，需要知道这个文件的media_key，而它几乎不可能以暴力的方式揭示它，因为它包含18位数字。事实上，在我的整个测试过程中，我并没有找到100％的方式来了解这个media_key，总是有一些情况会限制你来获取media_key。那么到这里就结束了？真的没有其他办法了吗？我是不是应该报告现在的这个情况呢？
绝对不 ！我个人认为这个漏洞可能会带来极端的严重性！你还记得分享上传的媒体文件的可能性吗？我来到一个非常有趣的想法，如果我们与用户共享我们的媒体文件，用于从他的帐户发布，他将被视为这个媒体文件的所有者，那么错误№2就不会出现而转发的tweet将成功发布。而这一切真的实现了！
要想完整的利用该漏洞就需要我们获取media_key，然而我们没有，但是在我们是这个文件的所有者的情况下，我们就可能会看到它的media_key（截屏№3）啊！
现在，情景如下：
我们上传我们的媒体文件。
与用户共享此文件，该用户的帐号用于发布条目。
拦截查询的tweet发布，只需更改POST方法的以下数据：owner_id和user_id到受害者帐户的id twitter。
我们就会收到有关Twitter发布成功的消息。
是不是很有趣？现在我们可以安心地报告漏洞了！
原文发布时间为：2017年5月31日
本文作者：Change
本文来自合作伙伴嘶吼，了解相关信息可以关注嘶吼网站。