数据安全之反爬虫策略

数据安全之反爬虫策略，在大前端时代的安全性一文中讲了Web前端和Native客户端如何从数据安全层面做反爬虫策略，今天[云沃客](https://www.clouderwork.com/?utm_source=7yue&utm_medium=lml&utm_campaign=pc1)将从API数据接口的层面讲一种技术方案，实现数据安全。
一、API接口请求安全性问题
API接口存在很多常见的安全性问题，常见的有下面几种情况
即使采用HTTPS，诸如Charles、Wireshark之类的专业抓包工具可以扮演证书颁发、校验的角色，因此可以查看到数据
拿到请求信息后原封不动的发起第二个请求，在服务器上生产了部分脏数据（接口是背后的逻辑是对DB的数据插入、删除等）
所以针对上述的问题也有一些解决方案：
HTTPS证书的双向认证解决抓包工具问题
假如通过网络层高手截获了HTTPS加证书认证后的数据，所以需要对请求参数做签名
「防重放策略」解决请求的多次发起问题
请求参数和返回内容做额外RSA加密处理，即使截获，也无法查看到明文。
关于HTTPS证书双向认证和Web端反爬虫技术方案均在大前端时代的安全性一文中有具体讲解。接下来引出本文主角：防重放
二、请求参数防篡改
在之前的文章也讲过，HTTPS依旧可以被抓包，造成安全问题。抓包工具下数据依旧是裸奔的，可以查看Charles从入门到精通文中讲的如何获取HTTPS数据。
假如通过网络层高手截获了HTTPS加证书认证后的数据，所以需要对请求参数做签名。步骤如下
客户端使用约定好的密钥对请求参数进行加密，得到签名signature。并将签名加入到请求参数中，发送给服务端
服务端接收到客户端请求，使用约定好的密钥对请求参数（不包括signature）进行再次签名，得到值autograph
服务器对比signature和autograph，相等则认为是一次合法请求，否则则认为参数被篡改，判定为一次非法请求
因为中间人不知道签名密钥，所以即使拦截到请求，修改了某项参数，但是无法得到正确的签名signature，这样构造的一个请求，会被服务器判定为一次非法请求。
三、防重放策略
在工程师文化中，我们要做一个事情，就首先要对这个事情下个定义。我们才能知道做什么、怎么做。
理论上，一个API接口请求被收到，服务会做校验，但是当一个合法请求被中间人拦截后，中间人原封不动得重复发送该请求一次或多次，这种重复利用合法请求进行得攻击被成为重放。
重放会造成服务器问题，所以我们需要针对重放做防重放。本质上就是如何区别去一次正常、合法的请求。
3.1基于timestamp的方案
理论上，客户端发起一次请求，到服务端接收到这个请求的时间，业界判定为不超过60秒。利用这个特征，客户端每次请求都加上timestamp1，客户端将timestamp1和其他请求参数一起签名得到signature，之后发送请求到服务器。
服务器拿到当前时间戳timestamp2，timestap2-timestamp1>60s，则认为非法
服务端接收到客户端请求，使用约定好的密钥对请求参数（不包括signature、timestamp1）进行再次签名，得到值autograph。比对signature和autograph，若不相等则认为是一次非法请求
假如中间人拦截到请求，修改了timestamp或者其他的任何参数，但是不知道密钥，所以服务器依旧判定为非法请求。中间人从抓包、篡改参数、发起请求的过程一般来说大于60秒，所以服务器依旧会判定为非法请求。
基于timestamp的设计缺陷也很明显，种种原因下，60秒内的请求，会钻规则漏洞，服务器判定为一次合法请求。
3.2基于nonce的方案
既然时间戳会有漏洞，那么新方案是基于随机字符串nonce。也就是说每次请求都加入一个随机字符串，然后将其他参数一起利用密钥加密得到签名signature。服务端收到请求后
先判断nonce参数是否能存在于某个集合中，如果存在则认为是非法请求；如果不存在，则将nonce添加到当前的集合中
服务端将客户端请求参数（除nonce）结合密钥加密得到autograph，将signature和autograph比对，不相等则认为非法请求
但是该方案也有缺点，因为当次的请求都需要和集合中去搜索匹配，所以该集合不能太大，不然匹配算法特别耗时，接口性能降低。所以不得不定期删除部分nonce值。但是这样的情况下，被删除的nonce被利用为重放攻击，服务器判定为合法请求。
假设服务器只保存24小时内请求的nonce，该存储仍旧是一笔不小的开销。
3.3基于timestamp+nonce的方案
根据timestamp和nonce各自的特点：timestamp无法解决60秒内的重放请求；nonce存储和查找消耗较大。所以结合2者的特点，便有了「timestamp+nonce的防重放方案」。
利用timestamp解决超过60秒被认为非法请求的问题
利用nonce解决timestamp60秒内的漏网之鱼
步骤：
客户端将当前timestamp1、随机字符串和其他请求参数，按照密钥，生成签名signature
服务端收到请求，利用服务端密钥，将除timestamp1、随机字符串之外的请求参数，加密生成签名autograph
服务端对比signature和autograph，不相等则认为非法请求
拿到服务端时间戳，timestamp2-timestamp1<60，则判定为一次合法请求，然后保存nonce
服务端只保存60秒内的nonce，定时将集合内过期的nonce删除
该集合不应该直接操作文件或者数据库，否则服务端IO太多，造成性能瓶颈。可以是mmap或者其他内存到文件的读写机制。根据场景可以选择乐观锁、悲观锁。
其中有一个timestamp的问题，服务器会将请求参数中的timestamp判断差值，其中一个致命的缺点是服务器的时间和客户端的时间是存在时间差的，当然你也可以通过校验时间戳解决此问题。时间同步请继续看下面部分。
四、计算机网络时间同步技术原理
客户端和服务端的时间同步在很多场景下非常重要，举几个例子，这些场景都是经常发生的。
一个商品秒杀系统。用户打开页面，浏览各个类目的商品，商品列表界面右侧和详情页都有倒计时秒杀功能。用户在详情页加购、下单、结算。发现弹出提示“商品库存不足，请购买同类其他品牌商品”
一个答题系统，题目是该公司核心竞争力。所以有心的程序员为接口设计了「防重放」功能。但是前端小哥不给力，接口带过去的timestamp与服务器不在一个时区，差好几秒。别有用心的竞品公司的爬虫工程师发现了该漏洞，爬取了题目数据。
所以该现象在计算机领域有非常普遍，有解决方案。
如果精度要求不高的情况下：先请求服务器上的时间ServerTime，然后记录下来，同时记录当前的时间LocalTime1；需要获取当前的时间时，用最新的当前时间(LocalTime2-LocalTime1+ServerTime)
拿iOS端举例：
App启动后通过接口获取服务器时间ServerTime，保存本地。并同时记录当前时间LocalTime1
需要使用服务器时间时，先拿到当前时间LocalTime2-LocalTime1+ServerTime
若获取服务器时间接口失败，则从缓存中拿到之前同步的结果（初始的时间在App打包阶段内置了）
使用NSSystemClockDidChangeNotification监测系统时间发生改变，若变化则重新获取接口，进行时同步
如果需要精度更高，比如100纳秒的情况，则需要使用NTP（NetworkTimeProtocol）网络时间协议、PTP（PrecisionTimeProtocol）精确时间同步协议了。