>其它>>正文

如何发现Web App Yummy Days的安全漏洞?

原标题:如何发现Web App Yummy Days的安全漏洞?

作为一个金融Web应用的开发人员,我对安全问题一直尤为关注。在过去的两年里,我参与的一些Web应用在进入生产模式之前,都会经过全面严格的安全检查,以确保它们在完全投入使用后的安全性。

在这次的经历中,也让我学到了很多关于安全的知识 – 如身份验证,潜在的危险请求,注入等等 – 以及如何设计更为安全的应用程序。

安全是我的激情所在,而吃又是我的另一种激情。午餐时间是我一天中最享受的时刻之一。 (在西班牙)/ 是预订餐厅的最方便的应用程序,其中包含很多的折扣,可以帮我省下不少的钱。

在本文中,我将向你展示我是如何发现Web App Yummy Days的安全漏洞的,以及如何构建一个简单的自动客户端,让我获得Yummy Days促销的奖品。

免责声明:本文中表达的观点是作者自己的观点,并不等同The Fork公司的观点。我已通过电子邮件通知了The Fork,他们已采取适当措施解决了该问题。此外,我还隐藏了URL等敏感信息。

注意:文中某些部分可能需要你具备一定的技术知识进行理解。

The Yummy Days

对于那些不熟悉的人来说,The Yummy Days是一个为期一周的促销活动,只要你在每日游戏中保持一致,你就可以赢得高达120€的免费餐和Yums的一套奖品,这些奖品将被添加到你的帐户并可兑换折扣(1000 Yums相当于餐厅账单10欧元的折扣)。

促销活动开始后,可以在The Fork app上看到一个活动banner。打开后的界面如下所示:

要参与游戏,你需要提供你的电子邮件,以获取游戏资格,然后单击“PLAY”按钮。提交此表单时,你必须要单击按钮才能触发动画并查看你是否赢得了奖品。

你可以每天玩一次,连续玩7天,来赢得奖品。

如果你够幸运,你会从沙拉中取出一个Yum,这表明你获得了奖品,你将获得一个代码可以在下一个预订中使用,Yums会被添加到你的帐户。反之,你则会从沙拉中取出紫色的生菜(或其他紫色的东西),这表示你没有中将。

我玩了三四天这个游戏,获取到了大概300个Yums!

对表单的思考

就在Yummy Days的最后一天,询问我电子邮件地址的表单无意中引起了我的注意和思考。促销页面是在某种嵌入式浏览器中打开的,我可以很容易地看到正在访问的URL( 隐藏在上图中)。

我很好奇,所以我在我的计算机上打开了一个URL,其中启用了谷歌浏览器及其开发者工具选项,以记录我在Yummy Days促销中的最后一次游戏中的所有请求。

很不幸,但我可以分析请求日志,以了解在每日游戏中发生的事情。似乎用户界面正在向Restful API服务器发出请求,所以我保存了请求和响应,我尝试再次使用我的电子邮件地址,我被重定向到了一个说我已经玩过游戏的提示页面。

然后,我尝试再次使用我的另一个电子邮件地址,而不是在The Fork应用程序中注册,看看会发生什么,令人惊讶的是我能够再玩一次! 这意味着API未验证插入的电子邮件是否已在应用程序中注册。这意味着我可以使用随机电子邮件地址无限次地玩游戏,获取更多的奖品,但我不能够这么做。

有人可能会认为这不是一个严重的问题,因为,这需要我们手动填写一个随机的电子邮件地址,接受促销条件,在幸运的情况下保存代码,并反复重复整个过程。虽然这个人会获得一些奖品,但这不会对促销的结果产生太大影响,但我要是将这个过程自动化并在每秒钟重复一次呢?

自动化执行

有很多不同的方法可以来自动化这个过程,但我最喜欢的是Postman。Postman是一个客户端,它允许我们向API发出HTTP请求,并在每个请求前后执行代码片段。

你还记得之前我使用Google Chrome Developer Tools记录的游戏过程中的所有请求吗?现在我们就要用到这些请求了。为此,我创建了一个包含三个请求的集合(Get Cookies,Fill Form 和 Play)。

第一个请求Get Cookies,它是HTTP GET到Yummy Dayspage的url请求。在Test选项卡中,你可以放置一段将在请求之后执行的代码,我设置了两个Postman环境变量,其中包含响应附带的两个Cookie的值,位于Set-Cookie header中,有效期为请求后15分钟。

在第二个请求Fill Form中,我想复制表单提交,即HTTP POST到url。我创建了一个简单的预请求脚本,一个在请求之前执行的代码,用于设置一个随机生成的电子邮件地址的环境变量。

我还使用这个生成的电子邮件设置了POST的JSON body,如下所示:

第一次尝试返回500状态码(内部服务器错误),表明该请求有一些问题。查看Google Chrome中记录的请求,我将之前存储的两个Cookie与其他Cookie一起设置为了header,这次响应码为200,太棒了!

最后在Play请求中,我将复制触发动画按钮的行为,以检查你是否赢得奖品。这是对URL的简单GET,使用前一个请求的相同标头。

我添加了一个test,以检查是否已赢得奖品,过滤尝试没有任何奖品或重复的电子邮件地址。如果在该尝试中有奖品,则对该请求的响应将记录在Postman控制台中。

我已收集了三个可执行的请求,以便用一个随机的电子邮件地址来玩游戏,因此我可以在N次执行的迭代中执行这个请求。

使用Collection Runner,我跑了100次游戏,但并没有获奖,所以我决定尝试更多的迭代次数,可以看到一个Playrequest的测试通过,并且以下JSON被记录到了控制台,表这明我赢得了奖品!

{ “id”: 16490, “code”: “******”, //Code has been hidden “date_to_win”: “2018–06–10 17:36:56”, “type”: “300”, //300 Yums price “value”: 5, “user_id”: 217467, “country_id”: 1, “created_at”: null, “updated_at”: “2018–06–10 17:36:57” }

到这,我已经证明我可以自动获取Yummy Days的促销奖品,这似乎是基于时间和国家的(通过date_to_win和country_id属性就可以看出),并严重影响促销的结果(updated_at与date_to_win只相差了一秒!)。

天使还是恶魔?

想象一个“邪恶”的场景:

如果我在促销期间不间断执行这些请求会发生什么?如果我为所有国家执行这些请求又会发生什么呢?

只要我愿意,我将能够获得大量的Yummy Days促销奖品。

另外,我需要知道的是它是否会对来自同一IP的大量请求有某种限制。恶魔总是贪婪的,我创建了一个简单的脚本,使用Newman在shell中无限循环运行导出的Postman collection:

while true; do newman run TheForkYummyDays.postman_collection.json; done

我不间断地执行了将近45分钟,但并没有被服务器阻止。在这段时间里,我共获得了35个奖品,300个Yums,其中包括1个1000的Yums和1个2000的Yums。

这时在我右肩的天使开始提醒我,并说服我让我停止,现在是时候通知The Fork有关漏洞的信息了。我给他们发了一封电子邮件,其中包含我赢得的不同奖品的折扣代码以及技术细节。

几天后,我收到了他们的邮件回复,并告知我说他们已将问题报告给技术部门解决,为此他们奖励了我1000 Yums的折扣码表示感谢!

缓解措施

在服务器端检查电子邮件是否是在The Fork上注册的

这应该是解决这个问题的最好方法,无论在UI上进行哪些检查,都应始终在服务器端完成安全检查。这将不允许任何未注册的电子邮件地址参与促销活动。

在The Fork应用程序中嵌入促销页面

如果Yummy Days促销页面嵌入在The Fork app中,而不是在嵌入式浏览器中打开,那么想要查看The Yummy Days的URL就会非常困难。如果你要嵌入iframe,那么我建议使用X-Frame-Options标头,只将此页面嵌入到允许的URL中,从而防止Clickjacking攻击。

阻止超过请求数限制的IP地址

如果同一IP在规定的时间段内超过一定数量的请求,应当进行限制或阻止。

*参考来源:hakin9,FB小编secist编译,转载请注明来自FreeBuf.COM返回搜狐,查看更多

责任编辑:

声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。
阅读 ()
投诉
推荐阅读
免费获取
今日搜狐热点
今日推荐