我正在Android中实现一个加载https网站的WebView.在这个网站上我想做证书固定,这意味着我想检查服务器所服务的证书的某些方面.但是我发现WebViewClient中没有方法可以拦截请求并检索证书.
在互联网上有很多人说它无法完成,证书固定在Androids WebView上.所以我希望这里有人知道更多.
在Android证书钢钉被很好地描述这个文章.
Android中用于证书锁定的主要里程碑是Android 7.0 Nougat(SDK 24),因为网络安全配置允许应用程序定义自己的规则集.
我建议使用TrustKit Android库来管理Android上的证书固定:它支持大多数库(OkHttp等),并且与Android SDK 24设置兼容.
但请记住,在Android 7.0之前,您无法真正管理Webview上的固定,无论您使用哪个库,后面的任何内容都是一种解决方法.
因此,如果你高于7.0,只需使用上面的库,不需要做任何其他事情.
Pre-Nougat是Webviews的最佳选择,它是自己实现WebviewClient并手动执行调用,在shouldInterceptRequest()方法中执行证书固定.
您可以在此项目中找到此示例.
该shouldInterceptRequest()前棒棒堂(5.0 - SDK 21)不给你任何东西,则URL,没有头,没有身体,没有别的.这意味着你不能真正做更多的事情,只需加载URL,并希望webapp不需要任何其他东西(标题等..).
由于Lollipop你有另一种方法可以为你提供一个WebResourceRequest包含更多信息的对象,因此你可以正确地重现一个请求.
无论Android版本,除了GET请求之外shouldInterceptRequest()永远不会收到任何东西 ; POST/PUT/DELETE不可拦截 !!
此外,如果你使用上面的方法,shouldInterceptRequest()你可能会引入主要的性能问题:在2015年10月之前,Android Webview有一个错误并且总是在同一个线程上执行该方法导致阻塞队列,javascript使用相同的方法,导致明显的"冻结webview.从Lollipop开始,Webview就会随系统升级,但在此之前问题仍然存在.
您可以注入一个自定义Javascript接口来拦截Ajax调用,并使用OkHttp或您用于HTTP请求和证书固定的任何库手动执行它们.
如果你真的想去这个路线看一下这个库,它不支持表单,只支持Ajax调用,但它可以用类似的方式完成,就像在这个其他库中所示.
但!!!我不会推荐这个全部!!!! 我引用作者本人说:
[...]到目前为止,我对这一点的适应感到不满意.[...]
因为这是一个丑陋的事!
您可以考虑预取资源,以便在shouldInterceptRequest()方法中请求时不必获取它们.这需要您已经知道您需要的所有资源,而且我不必告诉您它可能最终会占用用户从未使用过的大量带宽和磁盘空间.
shouldInterceptRequest()如果您可以控制提供Webview数据的服务器,您可以尝试依赖HPKP,这基本上意味着您的服务器应该返回每个请求的头部列出您的证书的SHA256摘要:浏览器(在本例中为webview)然后应该选择它并确保下一个请求只有在证书相同的情况下才会通过.
当然这意味着您第一次没有保护,因此您可能需要shouldInterceptRequest()HPKP和HPKP 的组合.
如果你犯了一些错误设置HPKP,也很容易把自己关在脚下(就像我给出的链接中所解释的那样).
而且,猜测一下,由于设置困难和错误风险,最初推出HPKP的Google 在2017年对其进行了弃用.这也意味着它可能在最近的Webview或将来不受支持.
如果你真的想要安全地固定证书避免webviews或目标minSDK 24(Android 7.0).
还考虑一下......
代理:忘记你的应用程序,如果你做证书固定那些.通过代理建立HTTPS连接的唯一方法是在您的设备上安装代理证书,并使代理成为"中间人".如果您将证书固定不起作用,无论如何.
重定向:如果您固定证书并且您具有更改域的HTTP重定向(301/302),则还需要固定其他域.
动态内容:如果您的应用管理动态内容(用户提供或不受您控制的网址输入),并且您不允许任何固定域/证书列表以外的内容,那么这些内容将无效,您将无法无论如何都要固定它们(重定向也是如此).
网络没有固定,世界各地的计算机浏览器都没有使用证书固定.HPKP(上面讨论过)已被谷歌本身弃用,到目前为止还没有人抱怨过它.每个浏览器都使用可信证书颁发机构列表.
移动设备完成了同样的事情.
浏览器和移动应用程序之间的主要区别在于浏览器将清楚地显示证书信息,如果它是安全的,而应用程序可以做任何想做的事情而不向用户显示任何内容.您可以将PC应用程序与应用程序进行比较,以获得更公平的比较.
您需要了解证书确实为您的应用程序的安全性做了哪些操作:无法创建ManInTheMiddle攻击.即使受到破坏的设备(用户安装的恶意证书颁发机构)也不允许建立通信,因此有人嗅探您的应用程序发送和接收的内容.
历史上唯一一次受信任的证书颁发机构受到攻击的是2011 年的DigiNotar.除此之外,打破这种信任链的唯一方法是使用受损设备(无论是PC还是手机).
你需要保护用户不受侵害吗？(又名=在他的设备上安装虚假/恶意证书颁发机构)然后使用您的应用程序并让他自己的数据和凭证被MITM窃取.
您是否需要保护自己免受用户窃取通过安全连接发送的数据的侵害？(api密钥,令牌等...) - 请记住,有更好的策略来处理这个问题,通常api密钥和令牌可以被撤销.
您只需要保护应用程序使用的一些API.OWASP建议,当然要始终固定,但我更倾向于你应该衡量对这给你的威胁的保护.这完全是我的意见.
OWASP还说另一个重要的事情是手动不做,你可能会创建比你想要解决的更大的安全威胁!(这违背了上面讨论的所有解决方法).我100%同意这个.
| 归档时间： |
|
| 查看次数： |
6501 次 |
| 最近记录： |