iOS移动端 图片安全解决方案

iOS 安卓 移动端 图片安全解决方案
最近一个朋友公司的图片经常被搞恶意的破坏，更甚至破坏者把他们自己的广告插入到里面，很可怕，他问我有没有好一点的解决方案，想了好久总结为以下几点：

移动端安全大致上可以分为以下几个维度：
Web安全
网络通讯安全
本地安全

Web安全，主要考虑Web服务中每一层可能的漏洞，及由此衍生的一系列安全问题，如：存储层中的SQL注入问题，Nginx（容器）层的DDoS问题，前端层级的XSS跨站脚本问题等。

网络通讯安全，需要考虑通讯过程中信息的安全性，防止由于信息泄露导致的其他安全问题，比如：常见的各种形式的中间人问题等。

本地安全主要指客户端本地环境与数据的安全，以及代码被破解获得所导致的安全问题，如：明文存储问题，恶意二次打包问题，越权操作问题等。

其中，本地安全攻击大多发生在攻击者自己手机上，开发者和运维较难感知，所以容易被大家忽略，从而很容易成为整个链路的安全短板。本文将着重就本地安全，公司所采取的安全图片方案跟大家做一个介绍，其中的一些细节基于安全考虑会略去，保留其基本思路，希望对大家有所帮助，也欢迎共同交流。

安全图片解决方案

安全图片方案解决了本地安全的几个问题：
明文存储，过度依赖系统安全性（iOS：KC/UserDefault；Android：KeyStore/SharedPreference）
恶意二次打包
容易被逆向，被调试
敏感信息写入代码

优点

使用便捷简单
对工程及代码侵入性较小
显著提高APP的安全性

当然，该方案也存在一些问题，比如字段的存取需要走I/O以及二进制流处理，一定程度上会影响APP性能，同时安全性建立在SDK本身和安全图片安全性的基础上，容易在这一块出现安全短板。

所幸，正常获取字段的开销时间一般都不会超过30毫秒（视具体算法而定）。而安全性问题，还是需要靠持续加强SDK安全性，强化安全图片使用的算法，来提升短板，增大破解成本。





获取安全图片流程中，由于iOS和Android各自的包检查依赖项不一样，在输入项上会有所区别，iOS使用BundleID、Android使用keystore的数字签名SHA1值作为检查项。

在获取到用户输入信息之后，还需要一个加密的关键信息：加密密钥。

这里可以有三种思路：
由server端生成密钥，存储在服务器端，之后通过安全的通讯协议(如https)从服务器获取。
由server端生成密钥，之后按照某些算法或者规则插入到图片当中
从图片中按照某种规则或者算法，生成一个密钥

这三种方式各有利弊：
第一种方案的安全性基于通讯安全，能在本地安全被攻破的情况下保持安全链路完整，隔离不同业务方的密钥安全性，但是随之也带来了一些新的问题，如：中间人攻击、网络性能问题等。
第二种针对业务方较多的情况下，安全等级较高，能做到不同业务方不同版本APP的安全性隔离，在密钥生成算法或者密钥规则泄露后（低概率），可以及时更新密钥，阻止安全事故的扩大化；但同时也存在，可能对图片的使用造成轻微影响，算法可能较为复杂，在读取时对性能造成影响，算法门槛较高等问题。
最后一种较为简单，门槛低，同时对图片影响较小，读取开销相对较小，也能满足一般情况下的密钥获取方案；但当密钥获取算法或规则泄露后（低概率），阻止安全事故扩大化的成本相对较高，容易成为安全短板。

在得到了密钥之后，结合用户输入的信息，通过对称加密算法，生成加密后的密文再写入图片之中。

写入图片的方法很多，比如如下两种：
在jpg中，可以通过写入Exif区，这块区域存入了相机拍摄信息：时间、拍摄地点等等，可以在这个区域存入加密后的信息，实现图片的无损加密。
在png中，可以在IEND(png文件尾部)区域后追加加密信息，在此区域追加的信息不会影响图像的正常读取。但是用png格式需要注意在编译的时候会被编译器自动压缩，从而失去加密的信息。可以考虑动态获取安全图片来规避这个问题，比如从网络中加载图片再写入本地。

上述方案相对比较简单，如果对安全性有更高的需求，可以从图片本身结构入手，比如通过你要加密的信息构造出RGB、alpha等信息，然后按照标准png/jpg/bmp等格式构造出一张全新的图片，也可以在中间按照某种规则穿插一些混淆数据。这样生成的图片加密程度较高，不容易破解，但相对来说开发成本较高。
本文由于时间关系，暂时先把大概原理写给大家，具体到后面的细节大家可以在下面留言我们一起共同改进和完善，也欢迎各位赐教，共同学习，共同进步。