Question

我成功验证了苹果商店的应用内购买，然后我的应用从我的服务器下载了内容。问题是如果用户嗅探外发网址请求，他们将可以访问我的所有内容。我已经在互联网上搜索过，我认为安全性不是一个简单的问题需要解决，如果你真的很认真，你应该采用多层。我只是一个开发人员并且权衡风险/努力，我真的只是想让窃取我的内容比单纯查看传出的url请求更困难。

我能做些什么吗？只是验证收据是不够的，我想让我的服务器只允许从某些文件夹下载iPhone / iPad，或者为隐藏的文件夹提供自定义网址。

编辑：与此同时，我发现这个question是相关的，但它没有直接回答我的问题。实际上，提供的唯一解决方案对我来说不是解决方案，因为我希望我的内容可以在同一用户拥有的所有设备上使用。我只是不希望有人能够在浏览器中输入他们找到的URL并下载我的所有内容。

Answer 1

您可以切换到TLS或SSL HTTP会话吗？这会减少嗅探网址的可能性。

如果您生成extremely complicated per-user URLs，那么您可以有一定程度的信心，即客户不能简单地猜测网址，而不是他们尚未购买的内容。

例如，不要通过以下方式提供新内容：

http://ns6string.example.org/app-content/spanish/verbs/

在不同的网址上提供：

http://ns6string.example.org/app-content/sarnold/
   646718ae5d25cac14775ca7074cf4808/b493881b4376a5162a38114d1bd2d88a

我用以下内容生成了那些荒谬的网址：

$ echo "sarnold spanish" | md5sum
646718ae5d25cac14775ca7074cf4808  -
$ echo "sarnold verbs" | md5sum
b493881b4376a5162a38114d1bd2d88a  -

每个用户都可以获得他们自己的一堆可怕的URL，并且需要花费超过平均数量的努力来扭转它。（当然，对于这个简单的例子，如果我刚买了“西班牙语动词包”，我可能很有可能猜测的URL格式。你可以做的不多做到这一点，因为无论你做多么复杂，拥有调试器访问权限或有足够空闲时间的人都可能找出URL混淆机制。）

这就是我选择简单机制的原因：TLS和散列应该足够快，以便您不会浪费太多时间来保护您的内容而不是编写新功能或修复最后几个恼人的错误。

Answer 2

您不仅可以验证收据，还可以使用购买者独有的收据的某些部分对下载进行模糊处理或加密，但这不是URL的一部分。

安全下载应用内购买？

2 个答案: