详解NSURLCache缓存引发的安全漏洞

最近项目App交付第三方安全机构进行安全检测，暴露出了一个安全漏洞，具体表现为在沙盒里面检测到了交易登录账号和密码明文(HTTPS接口)，如果手机被盗丢失就有可能被破解获取到（虽然手机被盗丢失概率甚微再加上密码破解、越狱等一系列操作难度也甚大，但作为一名程序猿我们还是得从理论上来避免不是）。刚看到报告的时候，第一时间是有点诧异的，因为从来就没主动保存过密码，后来发现原来是NSURLCache引起的。

NSURLCache

NSURLCache将NSURLRequest和NSCachedURLResponse一一映射起来，配合NSURLRequestCachePolicy，iOS将为你建立了一套完整的HTTP缓存机制。NSURLRequestCachePolicy相信大家都很熟悉，这里不多说。NSURLCache同时提供了内存和磁盘的缓存，我们可以自定义缓存的大小；磁盘缓存路径默认为沙盒Library/Caches/{bundle id}/Cache.db，当然 我们也是可以自定义缓存路径的。

存储数据库

NSURLCache最终以数据库的形式存储数据，我们打开Cache.db一探究竟。我们只需关注下图的三个表：

• cfurl_cache_response，包含了request_key字段，也就是我们请求的url，如下图：

  

  看到我在测试环境下的登录接口是http://***/login(https表现一样)，同时还包含了一个主键entry_ID。
• cfurl_cache_receiver_data，包含了服务端返回的数据，我们根据上图entry_ID查找，数据如下图:

  

• cfurl_cache_blob_data, 包含了请求和响应数据，格式为blob，如下图：

  

  我们将其保存成文本，然后命令行cat即可查看到里面包含了请求的参数，如下图为登录的账号和密码：

  

  同时我们看到文件内容以bplist00开头，其实它就是一个plist文件。

删除缓存

好了，至此我们已经定位到了账号密码的缓存所在，为安全起见，必须将其删除掉。查一下API文档，NSURLCache提供了以下两个针对特定请求删除缓存的接口，那么我们顺理成章地调用它们不就把缓存解决掉了吗？事与愿违地是，经调用测试发现这两个接口都是无效的，并不能把对应的缓存删除掉，具体得等苹果爸爸在后续哪个版本修复了：

- removeCachedResponseForRequest:
    Removes the cached URL response for a specified URL request.
- removeCachedResponseForDataTask:
    Removes the cached URL response for a specified data task.
复制代码

此外，还有两个接口可以删除缓存，不过并不能做到针对具体请求，所以并不满足我们的需求。

- removeCachedResponsesSinceDate:
    Clears the given cache of any cached responses since the provided date.
- removeAllCachedResponses
    Clears the receiver’s cache, removing all stored cached URL responses.
复制代码

删除缓存的方案宣告失败。

Cache-Control

转而一想，HTTP头部有个Cache-Control字段，我们何不利用它来管理缓存的存储方案呢？ Cache-Control对应请求和响应又有不同的值，主要包括以下：

• 请求指令：

• 响应指令：

这里我们只要针对该请求或者服务端响应设置no-store值，客户端NSURLCache就不会对其进行缓存，问题得以完美解决。

小结

涉及到安全的问题还是得慎重严谨处理为上，关于此次NSURLCache引发的安全漏洞还是相对隐蔽的，因为并不是我们的主动行为。以上内容如有错误纰漏，欢迎指正。