iPhone 应用程序到网页的安全 https 加密 [英] Secure https encryption for iPhone app to webpage

查看:34
本文介绍了iPhone 应用程序到网页的安全 https 加密的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想销售一个 iPhone 应用程序,它将包含一个网页视图,例如 http://www.myapp.com/webview/ 我希望该应用能够有效地将身份验证所需的凭据存储在网站上(即只有购买了该应用的人才能查看此页面)

我还能如何在 iPhone 上拥有安全、简单的 webview,而不需要用户登录(基本上他们购买应用程序将构成他们对页面的身份验证)

有人可以帮忙吗?

解决方案

没有绝对的方法来实现这个目标.如果您有一个使用共享凭证(捆绑在应用程序中的凭证)的 Web 服务,则可以对该凭证进行逆向工程.最终无法确保在另一台机器上运行的客户端是您的"客户端.

已经有很多关于这个的讨论.不是没有希望,只是不可能100%(甚至90%)解决.通过 SSL 的简单共享秘密将阻止大多数攻击者,而不会伤害您的用户或花费大量开发成本.它是混淆,而不是安全,但便宜且最有效"比昂贵且最有效"要好得多.

如果您拥有非常高价值的产品,那么它可能需要更积极(昂贵)的解决方案.所有这些解决方案都包括以下两件事之一:

  • 验证用户而不是程序,或
  • 持续保持警惕,留意新的攻击,并通过修补程序进行响应.

后者非常昂贵且永无止境.确保它物有所值.

其他一些有用的讨论:

<小时>

编辑 关于我提到的基于 SSL 的共享秘密",我想指出一件事.请记住,如果您不验证证书,则很容易受到中间人攻击.Charles 等现成的代理可以做到这一点.最好的方法是确保返回的 SSL 证书由您的根证书签名,而不仅仅是任何受信任的证书".您可以使用 SecTrustSetAnchorCertificates() 重新配置您的应用程序信任哪些证书.iOS5:PTL 在第 11 章(第 221 页)中介绍了这项技术.我还将它封装到一个名为 RNPinnedCertValidator 的库中.

另一个好的层是实现一个质询-响应系统,其中服务器验证客户端拥有共享秘密,而无需将其放在网络上.维基百科关于挑战响应身份验证的文章对算法进行了很好的解释.>

I want to sell an iPhone app, that will house a single web view to a web page, say http://www.myapp.com/webview/ I would like the app to effectively store the credentials required for authentication at the website (ie only someone who has bought the app can view this page)

How else would I have a secure, simple webview on the iPhone, without requiring the user to log in(essentially they buying the app will constitute their authentication to the page)

Can anyone help with this?

解决方案

There is no absolute way to achieve this goal. If you have a web service that uses a shared credential (one bundled in the application), then it will be possible to reverse engineer that credential. Ultimately it is impossible to ensure that a client running on another machine is "your" client.

There have been many discussions of this. It is not hopeless, only impossible to solve 100% (or even 90%). A simple shared secret over SSL will stop the majority of your attackers without harming your users or costing a lot to develop. It is obfuscation, not security, but cheap and "mostly effective" is much better than expensive and "mostly effective."

If you have a very high-value product, then it may warrant more aggressive (expensive) solutions. All of these solutions include one of two things:

  • Authenticating the user rather than the program, or
  • Continual vigilance, watching for new attacks and responding with fixes that patch them.

The latter is very expensive and never ends. Make sure it's worth it.

Some other useful discussions:


EDIT I wanted to point out one thing about my mention of "shared secret over SSL." Remember that if you don't verify the certificate, you are subject to very easy man-in-the-middle attacks. Readily available proxies like Charles can do this. The best approach is to make sure that the SSL certificate being returned is signed by your root certificate, not just "any trusted certificate." You can reconfigure which certificates are trusted by your application with SecTrustSetAnchorCertificates(). iOS5:PTL covers this technique in Chapter 11 (page 221). I've also wrapped this into a library called RNPinnedCertValidator.

Another good layer is to implement a challenge-response system where the server authenticates that the client has the shared secret without ever putting it on the wire. The Wikipedia article on Challenge-resonse authentication includes a good explanation of the algorithm.

这篇关于iPhone 应用程序到网页的安全 https 加密的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆