安全问题：通过https从iOS应用程序向服务器发送用户名和密码

我已经按照苹果的建议设置了应用内购买收据验证，将收据发送到我的服务器，然后服务器再将收据发送到苹果的服务器进行验证。我所有的收据处理都是在服务器端进行的，它工作得很好。我的服务器向我的应用程序发回一个非常模糊的代码，以确认购买是否有效。我在应用程序端使用了一种非常强大的模糊处理方法来掩盖返回代码的情况，以使越狱黑客尽可能难以击败它

问题是，我的php文件存储在web服务器上的一个受密码保护的文件夹中，当应用程序本身将该目录的用户名和密码嵌入其中以将收据发送到php文件开始时，我担心如何将其视为安全的

我的应用程序仅使用服务器进行应用程序内购买的收据验证。所有其他功能都在应用程序本身中，因此我不会强制每个用户拥有一个具有唯一用户名和密码的帐户

我正在使用URLSession通过TLS 1.2 https连接与服务器进行通信，因此这部分是安全的，但我想不出一种方法来阻止已确定的黑客从他们设备上的应用程序中提取用户名和密码，并直接访问我的服务器文件夹。具有该功能的人可以同样轻松地修改php文件，以始终返回指示有效购买的代码

我确实混淆了应用程序中的用户名和密码，以至于我认为大多数人可能会放弃尝试找出它，但我知道我只是让它更难提取，而不是几乎不可能

---

有什么想法吗？我在网上找到的与此相关的所有信息都与不通过http传输用户名和密码有关，而不是越狱设备的更大问题。

你想象的是一个黑客正在反转你的模糊二进制文件，试图获取用户名和密码。这是很难做到的。最简单的方法是检查网络流量

是的，即使不越狱，设备所有者也可以轻松绕过TLS。TLS可以抵御外部攻击者，但不能抵御想要检查自身网络流量的东西。这很容易做到，例如，请参见

如果您想阻止这种更容易的攻击，可以尝试实现。这在越狱设备上仍然可以轻易破解，但你可以阻止很多不想越狱的普通黑客

---

归根结底，你是对的，一个坚定的黑客将战胜这种类型的设计

所以我想我已经找到了一个相当安全的解决方案。非常感谢那些花时间对此发表评论的人，因为你的意见肯定很有帮助

首先，虽然我对Obj-C/Swift iOS开发有相当多的经验，但服务器端的东西对我来说是相当新的，但我很快就学到了很多东西。对于我来说，这可能是一个巨大的尤里卡时刻，对于一位资深的REST/Linux/PHP专家来说，这将是一个相当常规的时刻，所以请容忍我

总结一下挑战：我想从我的应用程序向服务器上的一个.php文件发送一个应用程序内购买收据的json表示，以便它可以将其发送给苹果进行验证。为了保护该.php文件，我在其文件夹中放置了一个.htaccess文件，需要用户名和密码才能访问它

NSURLSession很好地处理了这个问题，但要求我在应用程序中输入用户名和密码……不太好。这就是混淆对话的原因，让我意识到在将密码硬编码到应用程序中时无法保证密码的安全

然后我意识到我可以把文件放在我的公共html文件夹之外（我的尤里卡时刻），这就是我所做的。因此，在public_html文件夹中，也有一个index.html文件，我现在有一个非常简单的.php文件，它只调用另一个.php文件中的一个函数，该文件完成了与苹果服务器对话和解析响应的所有工作。解析完成后，它会向simple.php文件返回一个非常模糊的代码（而不是苹果返回的广为宣传的代码），而simple.php文件又会将该代码返回给我的应用程序。
根据该代码，应用程序将决定是否授予对所购商品的访问权限

使用服务器端权限，我限制了public_html目录中的simple.php文件从“world”进行读或写访问，使其仅作为可执行文件。因此，虽然黑客可以很快获得该文件的名称，如果他们黑客的应用程序，这应该对他们没有好处。我不再需要在应用程序中输入用户名或密码，而完成所有工作的“main”.php文件位于public_html文件夹之外的一个文件夹中，其权限设置为限制从“world”读取/写入/执行，尽管我认为这有点过分，但我在其中放入了一个.htaccess文件并拒绝所有内容

---

我想我这里有一个“相当”安全的解决方案，这会让一个不经意的黑客很难窃取应用程序内的购买，但我还是会一如既往地接受建议，以防我错过了一些东西。

谢谢你周到的回复。我确实会研究证书固定，但有趣的是，我对这个问题挖掘得越深，我就越感到脆弱。在这一点上，我可能花了更多的时间来确保应用程序内购买的安全，而不是我花在编写应用程序上的时间！当然，这段时间不会被浪费，因为一旦我完善了它，我也可以用它来重新安装我的其他应用程序。再次感谢。@Scooter:你说得对。你正在打一场可能比它的价值更大的战斗。特别是，证书固定的正确实现可能是一个PITA。但我希望你能从我的帖子中得到收获：所有那些困惑