API网络数据安全

时间 2019-12-19

原文原文链接

前言

个推做为国内第三方推送市场的早期进入者，专一于为开发者提供高效稳定的服务，在保证稳定的状况下，咱们的网络数据交互也达到了一个很高的级别，今天给你们分享的是网络数据安全的经常使用方法算法

简介

TCP/IP做为互联网使用的标准协议集，在设计之初就是创建在接入主机互相信任的前提下，缺少对安全方面的考虑，而且为了保证网络的开放性，TCP/IP协议的内容是彻底公开的。所以，只使用TCP/IP协议在互联网上传输的数据，实际上都是不安全的。在SDK开发场景下，一般会在API设计时加入一些网络安全的措施，这里主要从数据防泄露、内容防篡改、身份放假装、请求防重放几个方面分析如何保证API网络数据安全。 api

数据防泄露

为了保证数据的机密性，通常会对数据作加密操做，这样即使数据在传输时被抓取，也须要解密才能获取真实数据。而要加密就须要用到加密算法，下面按两种粗略的分类介绍下不一样加密算法的特色，如何选择合适的加密算法，以及加密算法使用的密钥该如何管理。数组

公开加密与非公开加密算法

按照算法是否公开的特色，加密算法可分为公开算法和非公开算法。缓存

公开加密算法加密算法公开，密码的安全基于密钥的安全
非公开加密算法加密算法不公开，只有开发人员知道，密码的安全性基于加密算法的安全；

建议使用公开加密算法。公开算法由于受全世界的密码学者研究，经受了很大的考验，加密强度有保障。而非公开算法除了做者以外基本上没人看过，加密的强度没有保障。一旦加密方式泄露，非公开加密算法须要作修改算法这种复杂操做来补救，而公开加密算法原本就是公开的，只要密钥不泄露就是安全的，即便密钥泄露也只需更换密钥的简单操做便可。 ##对称加密与非对称加密按照密钥的特色，公开加密算法又能够分为对称算法和非对称算法安全

对称加密算法只有一个密钥，简称私钥，加密和解密使用同一个密钥特色：计算量小，速度快，密钥交换复杂常见的对称加密算法：DES，AES，TDEA 等
非对称加密算法有一对密钥，可公开的公钥与补课公开的密钥，用其中一个密钥对数据进行加密后，只有用对应的另外一个密钥才能解密。特色：计算量大，速度较慢，支持数字签名，密钥交换简单。常见的非对称加密算法：RSA，Elgamal，Rabin，ECC，D-H。

实际使用中一般采用非对称加密算法管理对称算法的密钥，而后用对称加密算法加密数据，这样咱们就集成了两类加密算法的优势，既实现了加密速度快的优势，又实现了安全方便管理密钥的优势。服务器

内容防篡改

数据在网络的传输过程当中，颇有可能被拦截并对内容进行篡改，对于这种状况，一般在传输内容中增长特定哈希算法生成的hash值，用来校验内容是否被篡改过，以保证数据的完整性。网络

常见的哈希函数有 md4,md5,sha-1等，一般会在请求或响应的内容体中增长一个校验参数sign，为了增长破解的难度，校验参数通常不会只是简单地对内容进行哈希运算生成，而是使用一种被称为加盐哈希的操做。具体作法能够是在内容中增长一些别的参数，好比SDK开发场景中一般会由开发者平台生成一个appSecretKey，能够把这个key放入请求内容中的特定位置，而后在再用哈希函数生成hash值，这以后还能够根据须要多进行几回哈希操做，好比先用md5作哈希计算生成hash值，再把这个值当成盐放到下次的sha-1计算中等等。接收端在接收到内容时使用一样的哈希操做计算sign值，并将两个sign值进行比对，若是不同则说明内容被篡改过了。app

身份假装

在网络通讯中，通讯双方的身份验证也是网络安全中很是重要的一环，它既能够保证网络通讯双方的身份，又能够防止经过网络完成交易时，交易方宣称交易没发生过的抵赖行为，保证了通讯双方身份的可鉴别和通讯过程的不可抵赖。在SDK开发中，因为api接口是对外公开的，所以对客户端的身份校验通常不会很严格，主要是对服务端的身份验证。函数

Token 身份校验

服务端为了防止接口的未受权调用，一般会生成一个用于标识客户端身份的token，客户端在调用接口时在请求头中添加token，服务端检查token是否有效，若是有效则说明客户端的身份可靠，能够返回响应数据，一般会对token设置一个有效期以防止token泄露后的长期非法调用。若是对客户端身份验证要求较严，能够将token的生成与apk的签名文件关联起来，若是不是使用指定签名的客户端，则没法经过校验。加密

数字签名

服务端通常经过数字签名的方式支持身份验证，数字签名是非对称加密算法的另外一种用法，用私钥加密，用公钥解密，它能够提供和现实中亲笔签名类似的效果，在技术上和法律上都有保证。数字签名与验证过程：

发送方用哈希函数从报文文本中生成一个hash值；
发送方用本身的私钥对这个hash值进行加密造成本身的数字签名；
发送方将数字签名和报文一块儿发送给接收方；
接收方收到报文后，用一样的哈希函数从原始报文中计算出hash值；
接收方再用发送方的公钥来对报文附加的数字签名进行解密得出另外一个hash值；
若是两个hash值相同，那么接收方就能确认该数字签名是发送方的；

请求重放

即便传输的数据是通过加密的，窃听者没法获得数据的准肯定义，但从请求的地址分析出这些数据的做用以后，能够经过原封不动地屡次发送这条请求进行攻击，就拿最简单的数据入库操做，若是API接口没有作对应的安全防御，将可能形成屡次入库的严重后果。

为了不这种状况，一般会在请求中增长一些用于校验的参数，好比时间戳、随机数、流水号等等，下面简单介绍一下这几种方式的特色，以及经常使用方案。

加时间戳

在请求中增长一个时间戳，服务端将时间戳跟当前时间对比，若是时间差大于必定值(好比1分钟)，则能够认为该请求失效。这种方式没法防止在指定时间差内的重放攻击，好比时间差是1分钟的话，那么只须要在1分钟内完成重放攻击便可。

加随机数

在请求中增长一个随机数，服务端检查缓存中是否有相同的随机数，若是有则认为是无效请求，若是没有则将其加入缓存。这种方式的问题在于，服务端不可能缓存全部请求的随机数，只能缓存一部分，若是重放攻击内包含的随机数恰好被清除了，则依然能被攻击。

加流水号

在请求中增长一个递增的流水号，服务端若是收到的流水号不是连续递增的，就认为是无效请求。这种方式的缺点在于流水号的变化太过单调了，很容易就能被识别出来并作对应的修改。

时间戳+随机数

经常使用的方案是把时间戳和随机数配合使用，给每次请求都增长一个当前时间的时间戳timestamp，和一个随机数nonce。服务端收到请求时，先检查时间戳是否超时，若是超时则认为是无效请求，若是没超时再检查缓存中是否有相同的nonce，若是有则认为是无效请求，若是没有则将其加入缓存，服务端只须要缓存超时时间内的nonce记录便可。

使用 https

前面介绍的这些网络安全的相关手段，若是实际开发中要严格按照上面的标准实现的话，仍是须要花费一些时间的，那么有没有一种快速简单的方式来实现上面提到的那些功能呢，答案是有的，那就是直接使用Https。 Https其实是由Http+SSL组成，SSL可以提供数据加密、身份验证功能，只需再加上简单的防篡改和防重放功能便可知足上面的数据防泄密、内容防篡改、身份防假装、请求防重放四个要求。

SSL/TLS

SSL是Netscape公司研发的用于保障数据在互联网上安全传输的协议，SSL在更新到3.0时，IETF(互联网工程任务组)对SSL3.0进行了标准化，添加了少数机制，并将其改名为TLS。 SSL/TLS创建安全通讯的过程大概能够分为三步：

对等协商支持的密钥算法；
基于公钥加密的对称密钥交换，基于证书的身份认证；
基于对称加密的数据传输保密

数字证书

使用Https时，须要用到数字证书，数字证书的原理其实仍是前面说到的数字签名，通常数字证书都是由CA机构用私钥签发的，固然也有企业本身用私钥签发的数字证书，只是这种证书默认是不被信任的，使用数字证书能够有效地防止参数篡改和身份假装。数字证书的大体生成过程以下图：

步骤：

根据证书内容（好比公司名，公司税号等）使用哈希算法生成一个证书摘要
拿这个哈希过的摘要进行 RAS 加密。
加密的数据又存放到证书中

数字证书的验证过程大体以下图：

步骤：

在创建连接以前，下载证书进行校验
对证书内容进行哈希等到数字摘要 H1
使用密钥解密数字签名获得数组摘要 H2
若是 H1=H2 则认为校验经过

在SDK开发中，使用CA颁发颁发的证书和使用自生成的证书差异并不大，主要区别在于，若是使用CA颁发的证书，只需在SDK中使用系统自带的信任证书库验证便可（系统默认内置CA机构根证书），若是使用自生成的证书，则须要在SDK中导入证书或公钥用于证书验证过程。

单向与双向认证

单向验证客户端须要验证服务器的身份，服务端不须要验证客户端身份。
双向验证客户端须要验证服务器身份，服务端也须要验证客户端身份。使用单向验证仍是双向验证，一般是由服务端提供的服务决定的。通常状况下服务器是对全部客户端开放的，因此默认的配置是单向验证。若是要限制访问的客户端，则须要在服务端开启双向验证。

书籍推荐

《TCP-IP 详解卷一》，《图解 Http》

总结

安全是个大课题，这篇文章仅是基于网络安全这个很小的点进行拓展。后续还会出 设备安全，数据安全，代码安全等文章,但愿你们多多关照。