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