网络数据安全思考

见过一些系统和应用在裸奔，也见过一些简单的应用设计了极其复杂的安全机制，不仅团队成员很难掌握，而且还影响到业务开发。所以我经常会想，什么样的网络请求才是合理的？

• 一个APP或者网站，怎么区分当前用户是谁呢？我可以在请求参数里附带UserID，通过UserID我可以知道返回什么样的数据或者展示什么样的内容。这时只要我在请求时修改一下UserID，就能看到其他用户的信息了，别笑，这样的系统确实存在，只在登录时确认了下UserID。

网络请求时序图 .png

• 当然能犯这么低级错误的比较是少数，为了防止这种情况，有些系统每次请求都附带了用户名和密码(加密后的也可以直接使用)，这样你不知道别人密码 ，很难冒充别人请求了，但是这种设计依然很差劲，即使你的用户名和密码是加密的，每天这么传来传去也不合适，传输过程中随便有人抓个包，拿到你的用户名和密码，就可以冒用你身份了，关键还要把用户名这么重要的东西存储的客户端。

网络请求时序图.png

• 于是有人更进一步，通过登录请求返回一个token，这个token有一个有效期，这样后面所有请求都通过传递token标识用户身份。虽然登录请求时依然要传递用户名密码，但是大部分情况下只需要传递token还是安全很多的，毕竟可以有很多token失效策略用来提高安全性。当然token可以像上面改UserID一样被暴力试出来，尤其是量级很大的应用，所以UserID+token比单纯token被试出概率低很多。目前很多应用都是采用这种方式，虽说可以被抓包，毕竟这个门槛还是很高的，当然前提是你不要轻易连接未知WIFI。

网络请求时序图 (3).png

• 怎么可以不怕被抓包呢？有一个简单的方法就是给请求加一个验签，简单说就是每个请求都加一个签名用来证明是你发出的请求，而不是恶意第三方。最常见的一个方法就是根据请求的参数生成一个签名附带到请求中，那么即使有人抓包拿到了你的请求，他也很难冒充你去发请求，因为他不知道签名生成策略，而拦截到的签名，通常也都跟时间戳相关，所以也很难再继续使用。例如下面的截图，是哔哩哔哩APP的请求，如果你觉得现在你就可以自己直接发请求去拉他们数据，那只能说你图样图森破，仔细看一下它的url:http://api.live.bilibili.com/AppNewIndex/common?_device=android&appkey=1d8b6e7d45233436&build=505000&mobi_app=android&platform=android&scale=xxhdpi&ts=1495789431&sign=cb2bd248088aee941a0a8f5d75fbb091 看到后面那个sign=xxxx了么？这个就是延签，你不知道它的生成算法，你的所以请求它都不鸟你的。当然也可以把所有数据都加密，抓包抓到的就是一堆乱码。目前主流的网络请求基本都是采用这种策略。攻击者可以通过分析前端代码或者分析反编译后的客户端代码，获取加密或者生成验签的算法来破解这种安全方案。

image.png

• 还有一种方法，就是使用https，它能保证数据传输过程中实安全的。尽管有中间者攻击，但是只要客户端验证服务器证书，就可以很容易识破攻击者。浏览器默认可以验证CA签署的证书的，自签名或者攻击者的签名，浏览器会有安全警告。手机APP的话需要自己实现证书验证步骤。各方面来讲，https还是很安全的，目前各个大厂都在推https，如果说缺点的话，那就是可以通过抓包工具分析请求，上面说了可以防止中间者攻击，但是用户安装中间者证书并且信任它那就没办法了，并且通常场景https都是单向验证，那么如果接口设计不合理，攻击者就可以通过直接发送请求完成攻击。

网络请求时序图 (6).png

• 根据上面分析，可以把5和4组合使用，达到类似于双向验证的效果来提高安全性。那么这种方案唯一的攻击入口就在于破解4中提到的加密算法。
• 前端代码通过混淆实现算法保护，android也是通过混淆对java代码进行保护，不过它的反射机制暴露了每一个Activity，给破解者提供了一个很好的切入点，所以为了提高安全性，很多Android开发者都把一些核心算法的实现放到lib.so中实现。放lib.so中就很安全吗？答案肯定是否定的，但是它把破解难度提高了很多，它是ELF文件格式，通过工具可以拿到汇编代码，尤其android中native方法名不能混淆，也暴露了默认C/C++实现的函数名。不少Android应用仅仅通过lib.so获取字符串方式隐藏加密密钥或者特殊code，这种方式破解难度就更低了，找到特殊关键字直接从汇编代码中搜索，更有甚者破解者直接写代码调用你的lib.so获取结果，可以看下面的截图，是默认JNI的例子生成的so反编译后的结果。为了再次提高安全等级，就出现了加壳技术。IOS程序就是加壳后的ELF文件，如上分析Android做了这么多工作才达到了IOS的安全程度，这也是为啥大家都说IOS难破解，当然加壳后也不是绝对安全，大家应该经常听到脱壳技术。梆梆和360都推出了针对Android的加固服务，但是很快就被安全爱好者脱壳并公布方法(当然它们肯定会推出新的加固方案)，所以安全没有绝对的，就看你要做到什么地步了。下一篇我会按照上述思路实现一套网络数据安全方案。

image.png image.png