安全问题涉及从iOS应用通过https向服务器发送用户名和密码 [英] Security concerns sending user name and password to server via https from iOS app

问题描述

我已按照Apple的建议设置了应用购买收据验证，方法是将收据发送到我的服务器，然后将收据发送到Apple的服务器进行验证.我所有的收据处理都是在服务器端进行的，它工作正常.我的服务器将非常晦涩的代码发送回我的应用程序，以确认购买是否有效.我在应用程序端使用了一种非常强大的混淆方法来掩饰该返回码所发生的一切，从而使越狱的黑客尽可能地难以克服它.

I have set up in app purchase receipt verification in accordance with Apple's recommendations by sending the receipt to my server which in turn sends it to Apple's servers for verification. All my receipt processing is handled server side and it is working perfectly. My server sends back a very obscure code to my app to confirm whether the purchase is valid or not. I make use of a pretty robust obfuscation method on the app side to disguise what is going on with that return code to make it as difficult as possible on jailbreaking hackers to defeat it.

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

The issue is that I have my php files stored in a password protected folder on my web server, and am concerned about how that can be considered secure when the app itself has the user name and password for that directory embedded in it to send the receipt to the php file to begin with.

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

My app only uses the server for receipt authentication of in app purchases. All other functionality is in the app itself, so I don't force each user to have an account with a unique username and password.

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

I am using URLSession to communicate with the server via a TLS 1.2 https connection so that part is secure, but I can't think of a way to keep a determined hacker from potentially extracting the user name and password from the app on their device, and having access to my server folder directly. Someone with that capability could just as easily modify the php file to always return a code indicating a valid purchase.

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

I do obfuscate the user name and password inside the app to the point that I think most folks would probably give up on trying to figure it out, but I know I have only made it harder to extract, not anywhere near impossible.

对此有何想法?我在网上找到的与此有关的所有内容都与不通过http传输用户名和密码有关，而不是与越狱设备这个更大的问题有关.

Any thoughts on this? Just about everything I found online concerning this has been concerned with not transmitting a username and password via http, not the bigger issue of a jailbroken device.

推荐答案

所以我认为我已经针对这种混乱提出了一个相当安全的解决方案.非常感谢花时间对此发表评论的人们，因为您的意见肯定会有所帮助.

So I think I have come up with a fairly secure solution to this mess. Thanks much to the folks that took the time to comment on this, as your inputs were certainly helpful.

首先，虽然我在Obj-C/Swift iOS开发方面有很多经验，但是服务器端的东西对我来说还是很新的，但是我很快就学到了很多东西.在我看来，尤里卡(Eureka)的那一刻似乎是一个巨大的时刻，对于一位经验丰富的REST/Linux/PHP专家来说，这似乎是很常规的事，所以请耐心等待.

First off, while I have quite a bit of experience with Obj-C/Swift iOS development, the server side stuff is pretty new to me, but I am learning a lot pretty rapidly. What may seem like a huge eureka moment to me, will seem fairly routine to a big-time REST/Linux/PHP expert, so bear with me.

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

To summarize the challenge: I wanted to send a json representation of an in-app purchase receipt from my app to a .php file on my server so it could send it to Apple for verification. To protect that .php file, I placed an .htaccess file in its folder to require a user name and password to access it.

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

NSURLSession dealt with this nicely, but required me to put the user name and password in the app...not good. That is what got the obfuscation conversation going, and made me realize there was no way to keep the password safe when hardcoding it into the app.

然后我意识到我可以将文件停在public_html文件夹之外(尤里卡时刻)，这就是我所做的.因此，在public_html文件夹中(其中也带有index.html文件)，我现在有了一个非常简单的.php文件，它只不过在另一个.php文件中调用了一个函数，该文件完成了与Apple服务器和服务器之间的所有工作.解析响应.解析完成后，它将非常晦涩的代码(而不是Apple返回的广为宣传的代码)返回到简单的.php文件，该文件又将其返回到我的应用程序.
根据该代码，应用程序将决定是否授予对所购买商品的访问权限.

Then I realized that I could park files outside of my public_html folder (my eureka moment), and that is what I have done. So inside the public_html folder, which has an index.html file in it as well, I now have a very simple .php file that does nothing more than call a function in another .php file which does all the work talking to Apple's servers and parsing the response. When it has finished parsing, it returns a very obscure code (not the well publicized codes that Apple returns) to the simple .php file which in turn returns that to my app.
Based on that code the app will decide whether or not to grant access to the purchased goods.

使用服务器端权限，我已限制了public_html目录中的简单.php文件对世界"的读取或写入访问权限，仅将其保留为可执行文件.因此，尽管黑客在黑客入侵应用程序后可以快速获取该文件的名称，但这对他们没有好处.我完全不再需要在应用程序中输入用户名或密码，并且完成所有工作的"main" .php文件位于public_html文件夹之外的文件夹中，其权限设置为限制读取/写入/执行来自世界"，即使我认为这太过分了，我还是在其中放置了一个.htaccess文件，并拒绝了所有内容.

Using server side permissions I have restricted the simple .php file in the public_html directory from read or write access from the "world", leaving it as executable only. So while a hacker can quickly obtain the name of that file if they hack the app, it should do them no good. I no longer require a user name or password in the app at all, and the "main" .php file that does all the work lives in a folder that is outside the public_html folder, has its permissions set to restrict read/write/execute from the "world", and even though I think it is overkill I put a .htaccess file in there and deny all.

我认为我这里有一个相当"安全的解决方案，应该使休闲黑客很难窃取应用内购买商品，但一如既往，我很愿意提出建议，以防万一我错过了一些东西.

I think I have a "fairly" secure solution here that should make it pretty hard on a casual hacker to steal an in-app purchase, but as always I am open to suggestion in case I have missed something.

这篇关于安全问题涉及从iOS应用通过https向服务器发送用户名和密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！