security - Parse.com API 安全问题

Question

这个问题是 a bug report I made on parse's help forum 的镜子
现在，我知道 parse 网站上的问题不是问题，而是报告，我不想在这里留下报告的镜像，而只是检查我的担忧是否有根据，可能有更多的人和我一起体验。
问题是 parse 似乎没有以正确的方式生成 HMAC 签名。

第一个测试:我使用了一个代理(Charles 代理)，在更新请求上设置了一个断点并更改了一个字段，使签名保持不变。执行请求。服务器接受请求并相应地更新字段(当然甚至是在断点中修改的字段)。

第二个测试:我没有修改请求，而是更改了签名以确保服务器实际上正在测试签名值，请求按预期被拒绝。

第三个测试:不只是修改现有字段的值，而是在请求中添加一个新的字段并执行。服务器接受请求，更新字段，如果添加的字段不存在，则将其添加到更新的行中，否则仅更新它。

现在，我的担忧有根据吗？我是否在有关签名生成的任何部分误解了 OAuth RFC？ Parse 的员工/用户怎么可能从未注意到如此巨大的错误？
拜托，我知道这个问题可以引起广泛的讨论，但是由于这个问题的重要性(不仅对我，而且对所有 parse 的用户)留出时间让知情的人留下有效的答复。
编辑 :
我正在研究 Parse iOS SDK 以找出实际发生这种情况的原因。在对他们的静态库进行一些研究和一些逆向工程之后，我发现他们正在使用一个名为 OAuthCore 的修改后的库(可能他们只是修改了前缀为“PF”的方法的名称)。 .在发现这一点后，我通过查看他们的 SDK 的旧开源版本得到了确认(发现谷歌搜索修改后的库名称)。现在，该库按预期完成了它的工作和工作，足够遵守 RFC。问题在于，显然，OAuth 并没有涵盖整个 HTTP 请求，而只是其中的一部分。我所期待的，恕我直言，当您请求更新字段(或进行购买？登录？发送敏感数据？)时，应该将“脏”字段作为请求的参数发送，以便它们将包含在通过 OAuth 协议(protocol)完成的签名/验证过程中。相反，更新请求(特别是通过调用定向到 https://api.parse.com/2/update 的 POST 请求)将 POST 请求的主体设置为表示实际更新的 json 字符串。老实说，这在这一切之前就已经很清楚了，因为通过查看请求，我应该已经意识到 json 文本是作为请求的原始正文而不是 x-www-form-urlencoded 正文发送的(因此有请求正文中的查询参数 urlencoded 和 & 连接)。
虽然这是现在的“正确”行为，但我觉得这不应该是在成千上万人使用的生产环境中。我现在要做的是尝试在不破坏功能的情况下对其进行修补，如果我设法做到这一点，我将分享补丁。
仍然希望直接得到 Parse 的回复。
编辑 2 : Parse 已将我的问题作为一个非问题而是一个错误报告来结束。没有对其实现所暗示的主要安全漏洞发表评论。
在报告的错误副本下方

I was playing around with the Parse iOS SDK and I found a major bug that seriously threat the security of the apps developed using parse as a backend.

Now, I'm sorry if I'm not using the bug issue reporting tool but I do not own a facebook account and I'm not willing to.

Premise: Parse APIs seems to conform to OAuth protocol 1.0a (RFC 5849). The relevant part of the RFC that involve this bug is at page 18, signature.

In oauth, according to the above mentioned RFC, each request should have an authentication header composed like:

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"

This will ensure not only that a request is authorized but even request integrity since the HMAC signature will enforce this. As a matter of fact the signature should be calculated by using a normalized string composed by the request parameters and signed with the client shared concatenated to the token shared secret (see section 3.4.2, page 25 of the RFC). In this way a malicious user should not EVER be able to modify the request before it reaches the server. The server in fact should check for the signature to match the whole request, rejecting it if it doesn't.

Sadly enough Parse seems not to totally conform to the above. By using a simple proxy I'm able to totally modify requests, from changing the user ID performing the request, change the value of a parameter in the request, ADD A FIELD AND A VALUE THAT WERE NOT INCLUDED IN THE REQUEST AT ALL.

Now it is really easy to imagine the drawbacks that all of this can lead to. In particular I'm thinking to the mobile developers that enable in-app purchases in their app, relying that parse is secure enough for them that their users will not be able to "cheat", thus losing the income and nullifying the efforts they made for their app.

Now, while I was able to test it on the other SDKs, I'm pretty sure the same bug is reproducible there too, or even worse the problem is that the server is not checking the signature at all.

Waiting response from a Parse employee about this bug.

Regards, Antonio

Answer 1

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