我已根据Apple的推荐设置了应用内购买收据验证，将收据发送到我的服务器，服务器又将其发送到Apple的服务器进行验证。我的所有收据处理都是在服务器端处理的，它运行正常。我的服务器向我的应用程序发回一个非常模糊的代码，以确认购买是否有效。我在应用程序端使用了一个非常强大的混淆方法来伪装返回代码的内容，使越狱黑客尽可能地难以击败它。
问题是我将我的php文件存储在我的Web服务器上的受密码保护的文件夹中，并且当应用程序本身具有嵌入其中的该目录的用户名和密码时，我担心如何将其视为安全将收据发送到php文件开始。
我的应用仅使用服务器进行应用购买的收据验证。所有其他功能都在应用程序本身，因此我不会强迫每个用户拥有一个具有唯一用户名和密码的帐户。
我正在使用URLSession通过TLS 1.2 https连接与服务器通信，这样该部分是安全的，但我无法想办法让一个坚定的黑客可能从中提取用户名和密码应用程序在他们的设备上，并直接访问我的服务器文件夹。具有该功能的人可以轻松修改php文件，以便始终返回指示有效购买的代码。
我对应用程序内部的用户名和密码进行了模糊处理，以至于我认为大多数人可能会放弃尝试解决这个问题，但我知道我只是更难以提取，而不是几乎不可能。
对此有何想法？几乎所有我在网上发现的关于这一点的一直都是关注不通过http传输用户名和密码，而不是更大的越狱设备问题。
答案 0 :(得分：1)
所以我认为我已经提出了一个相当安全的解决方案。非常感谢花时间对此发表评论的人们，因为您的投入肯定是有帮助的。
首先，虽然我对Obj-C / Swift iOS开发有很多经验，但服务器端的东西对我来说还是很新的，但我学得很快。对我来说，看起来像是一个巨大的尤里卡时刻，对于一个伟大的REST / Linux / PHP专家来说似乎是相当常规的，所以请耐心等待。
总结一下挑战：我想从我的应用程序向我的服务器上的.php文件发送应用内购买收据的json表示，以便将其发送给Apple进行验证。为了保护.php文件，我在其文件夹中放置了一个.htaccess文件，要求用户名和密码才能访问它。
NSURLSession很好地解决了这个问题，但要求我把用户名和密码放在应用程序中...不好。这就是混淆对话的结果，让我意识到在将密码硬编码到应用程序时无法保证密码安全。
然后我意识到我可以将文件停放在我的public_html文件夹之外（我的尤里卡时刻），这就是我所做的。所以在public_html文件夹里面也有一个index.html文件，我现在有一个非常简单的.php文件，除了在另一个.php文件中调用一个函数之外什么也没做，它完成了与Apple服务器通信的所有工作。解析响应。当它完成解析后，它会将一个非常模糊的代码（不是Apple返回的公开代码）返回到简单的.php文件，该文件又将其返回给我的应用程序。
根据该代码，应用程序将决定是否授予对所购商品的访问权。
使用服务器端权限我已将public_html目录中的简单.php文件限制为来自“world”的读取或写入访问，仅将其保留为可执行文件。因此，虽然黑客可以快速获取该文件的名称，如果他们破解了应用程序，它应该没有好处。我根本不再需要应用程序中的用户名或密码，并且执行所有工作的“main”.php文件位于public_html文件夹之外的文件夹中，其权限设置为限制读/写/执行来自“世界”，尽管我觉得它太过分了，但我把一个.htaccess文件放在那里并拒绝所有。
我认为我在这里有一个“相当”安全的解决方案，应该会让一个随意的黑客窃取应用程序内购买变得非常困难，但一如既往，我愿意接受建议，以防我错过了什么。
答案 1 :(得分：0)
您正在想象一个黑客将您的混淆二进制文件转换为试图获取用户名和密码。这是很难做到的。简单的方法是检查网络流量。
是的，即使没有越狱，设备所有者也可以轻松绕过TLS。 TLS可以防御外部攻击者，但它不能防止想要检查自己网络流量的内容。这很容易做到，例如参见instructions on my blog where I beat a very popular iOS game。
如果您想要停止这种更轻松的攻击，可以尝试实施certificate pinning。在越狱设备上仍然可以很容易地破解，但是你会阻止许多不想越狱的黑客。
在一天结束时，你是对的，一个坚定的黑客将赢得这种类型的设计。