Parse.com API安全问题

Question

这个问题是我在解析帮助论坛上发布的错误报告的镜像

现在,我知道解析网站上的那个不是一个问题,而是一个报告,我不想离开这里只是报告的一面镜子,但只是检查我的担忧是否有充分根据,人们可能有更多和我一起经历.

问题是,解析似乎没有以正确的方式生成HMAC签名.

• 第一个测试:我接受了一个代理(Charles代理),在更新请求上设置断点并更改一个字段,保持签名不变.执行请求.服务器接受请求,并相应地更新字段(当然,甚至是在断点中修改的字段).
• 第二个测试:我没有修改请求,只是更改了签名以确保服务器实际上正在测试签名值,请求被按预期被拒绝.
• 第三个测试:不是仅修改现有字段的值,而是向请求添加一个全新的字段并执行.服务器接受请求,更新字段,如果添加的字段不存在,则将其添加到更新的行,否则只更新它.

现在,我的担忧是否有充分理由？我是否在签名生成的任何部分误解了OAuth RFC？Parse的员工/用户怎么可能没有注意到这么大的错误？

请知道,这个问题可以产生广泛的讨论,但由于这个问题的重要性(不仅对我而言,对所有解析用户而言)都留给时间让某人知情留下有效回复.

编辑:

我正在挖掘Parse iOS SDK以找出实际发生这种情况的原因.经过一些研究和他们的静态库的一些逆向工程后,我发现他们正在使用一个名为OAuthCore的修改过的文件(可能只修改了用'PF'加上前缀的方法名称).在发现这个之后,我通过查看他们的SDK的旧开源版本(发现谷歌搜索修改的库名称)得到了确认.现在,该库完成了它的工作并按预期工作,足够坚持RFC.问题是,显然,OAuth不会覆盖整个HTTP请求,而只是其中的一部分.我期待的是,恕我直言,当你提出更新字段的请求(或进行购买？登录？发送敏感数据？)时,"脏"字段应作为请求的参数发送,以便它们将包含在通过OAuth协议完成的签名/验证过程中.而是更新请求(特别是通过调用指向https://api.parse.com/2/update的POST请求)将POST请求的主体设置为表示实际更新的json字符串.说实话,在所有这一切之前,这一点很清楚,因为通过查看请求,我应该意识到json文本是作为请求的原始主体而不是x-www-form-urlencoded主体发送的(因此具有查询参数urlencoded和&-concatenated在请求的正文中).

虽然现在这是"正确的"行为,但我觉得这不应该像成千上万人使用的生产环境中那样.我现在要做的是尝试在不破坏功能的情况下修补它,如果我设法做到这一点,我将分享补丁.

仍希望直接得到Parse的回复.

编辑2:Parse已将我的问题作为一个无问题而是一个错误报告关闭.没有评论其实施意味着的主要安全漏洞.

下面是报告错误的副本

我正在使用Parse iOS SDK,我发现了一个严重威胁使用解析作为后端开发的应用程序安全性的主要错误.

现在,我很抱歉,如果我没有使用错误问题报告工具,但我没有自己的Facebook帐户,我不愿意.

前提:Parse API似乎符合OAuth协议1.0a (RFC 5849).涉及此错误的RFC的相关部分位于第18页,签名.

在oauth中,根据上面提到的RFC,每个请求都应该有一个认证头,如下所示:

OAuth realm="Example",
oauth_consumer_key="0685bd9184jfhq22",
oauth_token="ad180jjd733klru7",
oauth_signature_method="HMAC-SHA1",
oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
oauth_timestamp="137131200",
oauth_nonce="4572616e48616d6d65724c61686176",
oauth_version="1.0"

这将不仅确保请求被授权,而且甚至确保请求完整性,因为HMAC签名将强制执行此操作.事实上,签名应该通过使用由请求参数组成的规范化字符串来计算,并使用连接到令牌共享密钥的客户端共享进行签名(请参阅RFC第25页第3.4.2节).通过这种方式,恶意用户在到达服务器之前不应该能够修改请求.事实上,服务器应检查签名是否与整个请求匹配,否则拒绝签名.

可悲的是,Parse似乎并不完全符合上述要求.通过使用简单的代理,我能够完全修改请求,从更改执行请求的用户ID,更改请求中的参数值,添加一个字段和一个在所有请求中不包含的值.

现在很容易想象所有这些都可能导致的缺点.特别是我想移动开发人员在他们的应用程序中启用应用程序内购买,依赖于解析对他们来说足够安全,他们的用户将无法"欺骗",从而失去收入并使他们所做的努力无效为他们的应用程序

现在,虽然我能够在其他SDK上测试它,但我很确定同样的bug也可以在那里重现,或者更糟糕的是问题是服务器根本没有检查签名.

等待Parse员工对此错误的回应.

此致,安东尼奥

Answer 1

令人印象深刻的是，您深入研究了框架来检查安全问题。我不是 oauth 方面的专家。但我只是想评论一下您对应用内购买的担忧。无需担心应用内购买，因为这完全由 App Store 处理。任何购买都将由 iOS 的 StoreKit.framework 处理。Parse 与应用内购买无关。如果你想检查一个人是否购买了任何东西，你只需要使用StoreKit.framework带来的功能，而不是Parse。