带有服务器后端的 iPhone 应用程序 - 如何确保所有访问仅来自 iPhone 应用程序？
我不太介意盗版等，但我想确保后端（基于 Rails）不向可以 DOS 等的自动化服务开放。因此，我只想确保对后端的所有访问（这将是对 GET 和 PUT 数据的一些 REST 查询）将通过有效的 iPhone 应用程序，而不是在计算机上运行的某些脚本。
我想避免使用帐户，以便获得无缝的用户体验。
我的第一个意图是将 UDID 和密钥哈希在一起，并通过 HTTPS 连接将其（和 UDID）提供给服务器。这将允许创建经过身份验证的会话或返回错误。
如果被窃听，攻击者就可以获取哈希值并重放它，从而使该方案容易遭受重放攻击。但是 HTTPS 连接不应该保护我免遭窃听吗？
谢谢！
I don't mind so much about pirating etcetera, but I want to ensure that the backend (Rails based) isn't open to automated services that could DOS it etc. Therefore I'd like to simply ensure that all access to the backend (which will be a few REST queries to GET and PUT data) will be via a valid iPhone application, and not some script running on a machine.
I want to avoid the use of accounts so that the user experience is seamless.
My first intention is to hash the UDID and a secret together, and provide that (and the UDID) over a HTTPS connection to the server. This will either allow an authenticated session to be created or return an error.
If eavesdropped, then an attacker could take the hash and replay it, leaving this scheme open to replay attacks. However shouldn't the HTTPS connection protect me against eavesdropping?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
没有办法确保它，因为它可以被欺骗。
如果你真的想走这条路（老实说，除非你在这里做一些真正超级关键的任务，否则你可能是在浪费时间），你可以传递 iPhone 设备令牌。或者也许散列它然后传递它。当然，你无法在服务器端或其他任何地方验证它，但如果一个坏人真的想把你打倒，这是他必须首先处理的第一个障碍。
There is no way to ensure it, since it can be spoofed.
If you really want to go this route (honestly, unless you're doing something really super mission critical here you are probably wasting your time), you could pass along the iPhone device token. Or maybe hash it and then pass it along. Of course, you have no way to validate it on the Server Side or anything, but if a bad guy really wants to take you down, here is roadblock #1 that he will have to deal with first.
就像 bpapa 说的那样，它可以被欺骗，但是，就像你说的，你并不担心有人过来，只是连续向你的服务器发送一千个请求，而你的服务器必须处理每个请求。
你对哈希的想法是一个好的开始。从那里，您还可以将当前时间戳附加到预哈希值中，并将其一起发送。如果给定的时间戳与服务器当前时间相差超过 1 天，则禁止访问。无论如何，这会在一天多后阻止重放攻击。
另一种选择是使用随机数。任何人都可以从您的服务器请求随机数，但设备必须将其附加到预哈希数据中，然后再将哈希发送到服务器。生成的随机数必须被存储，或者可以只是服务器的当前时间戳。然后，设备必须将服务器的时间戳而不是自己的时间戳附加到预先哈希的数据中，从而使重放攻击发生的时间比一整天短得多。
Like bpapa says, it can be spoofed, but then, like you say, you aren't worried about that so much as anybody coming along and just sending a thousand requests to your server in a row, and your server having to process each one.
Your idea of the hash is a good start. From there, you could also append the current timestamp to the pre-hashed value, and send that along as well. If the given timestamp is more than 1 day different from the server's current time, disallow access. This stops replay attacks for more than a day later anyway.
Another option would be to use a nonce. Anybody can request a nonce from your server, but then the device has to append that to the pre-hash data before sending the hash to the server. Generated nonces would have to be stored, or, could simply be the server's current timestamp. The device then has to append the server's timestamp instead of its own timestamp to the pre-hashed data, allowing for a much shorter period than a full day for a replay attack to occur.
将 SSL 与客户端证书结合使用。您的客户端中有一个私钥并为其颁发一个证书，并且您的 Web 服务器可以要求提供此客户端证书以便会话继续进行。
我无法提供 Rails 的代码详细信息，但从架构角度来看，这是最安全的做法，尽管可能有点矫枉过正。带证书的 SSL 是一种标准的行业解决方案，并且 iPhone/客户端和服务器端都存在库，因此您不必发明任何东西或实现太多，只需让它们很好地协同工作即可。
您还可以考虑 HMAC，例如 HMAC-SHA1，它基本上是这里其他人谈论的哈希值的标准化。如果您向其中添加随机数，您也可以安全地抵御重放攻击。有关如何使用随机数实现 HMAC-SHA1 的想法，您可以查看 OAuth 协议（不是整个流程，而是它们如何将随机数和其他参数绑定到经过身份验证的请求中）。
Use SSL with client certificate. Have a private key in your client and issue a certificate for it, and your web server can require this client cert to be present in order for the sessions to proceed.
I can't give code details for Rails, but architecture-wise it's the most secure thing to do, even though might be a bit overkill. SSL with certificates is a standard industry solution and libraries exist for both the iPhone/client end and server end, so you don't have to invent anything or implement much, just get them to work nicely together.
You could also consider HMAC, like HMAC-SHA1, which is basically a standardization of the hashes stuff that other people here talk about. If you added nonces to it, you'd also be safe against replay attack. For an idea about how to implement HMAC-SHA1 with nonces, you could look at OAuth protocol (not the whole flow, but just how they tie nonce and other parameters together into an authenticated request).