最近沉迷爬虫无法自拔。。。做到现在也算是有点收获，总结一下。
最开始想要爬的APP，用Charles抓包发现，抓到携带数据的包都是zip，批量解压后分析发现并没有有效的数据。猜测数据传输不是HTTP协议，抓不到包，只能通过群控来做。
然后想分析一些其它同类的APP，鉴于之前分析移动端APP可能抓不到包的情况，转而去看有没有对应的微信小程序。微信小程序的请求是一定能抓到包的，因为，微信小程序的项目在编译时是将wxml、wxss编译成js来压缩打包为wxapkg文件，微信小程序在微信中的运行其实就是在微信内嵌浏览器（渲染引擎：安卓端X5内核，IOS端Webkit内核）的JSCore（JS引擎）中解压执行JS代码。而浏览器中的请求一定是遵循http协议的（HTTP协议是Web浏览器和服务器之间通信一定遵循的规则）。所以比移动端APP抓到包的概率大很多。
其他方式：
- 一些移动端App如果开启了debug模式，在手机连接电脑之后可以在
chrome://inspect中进行inspect调试。 - 尝试了一下类似
selenium的移动端自动化测试工具appium，在App授权的操作上卡死了。
有关抓包
先来理解 代理 ：正常浏览器访问网页时是直接去访问服务器，如果中间通过代理来访问，代理可以帮忙做很多事，比如修改你请求的内容或者将请求的资源映射为本地的资源。
Charles实际上就是一个代理服务器，对手机、电脑等抓包分析。
Charles抓不到包时，可以查看
是否勾选了电脑系统代理
windows proxy或Mac OSX Proxy是否关闭了电脑的自动代理
Automatic Proxy Configuration是否给手机配置了代理？
是否给电脑或手机安装了信任证书
SSL Proxying > Install Charles Root Certificate或https://chls.pro/ssl
抓包分析了四个小程序，可以很明显地发现对应的请求拦截策略的不同：
最基本的会对爬取频率有限制，那就每个请求sleep几秒钟
针对定位的拦截，定位信息包括经纬度
lat,lng、城市city_id、编码串address_code针对设备有关参数的拦截：设备信息包括
User Agent、编码串device_id针对
token的拦截：大多抓取到的token不会很快过期，伪造方式不明。其中有一个小程序的token获取基于微信接口返回的code参数，这个请求过期时间在一分钟左右，而微信根据用户信息去获取code的请求是抓不到包的。针对签名串
sign的拦截：这个参数是基于请求query中携带的其他参数加密得到的签名串，同样不知如何伪造。
通过真机定位去爬取定位地区的数据，自己对爬虫的分析目前只能做到这个程度，想要进一步实现爬虫自动化，需要考虑的问题列在下面：
- 数据存储方式，与做数据分析的小伙伴如何对接。
- 遇到这种接口变更或者反爬策略变更的情况如何实时应对。
- 每款App请求构造规则都不同，需要每个都写一套爬虫？可复用性如何考虑。
- 各种参数编码串如何伪造。
- 针对定位的不同，不同App可拉取数据方式不同，比如：
- 一款App是定位到同一城市不同地区可拉取到的数据是一致的，这种形式的数据拉取可以通过一些地图接口批量给不同城市的地址解析得到对应的经纬度信息。
- 另一款App是定位到同一城市不同地区会有不同的数据来源，针对这种形式的数据获取，可能需要先在地图中搜索到需要的地址，然后伪造对应经纬度信息作为拉取参数。
有关反爬
为什么要反爬
直接影响：占用服务器带宽，影响正常用户访问，数据泄漏。
爬虫是所有攻击链中的重要构成，无论是采集竞争对手网站的数据，尝试破解用户口令还是自动下单，其实都离不开爬虫。
新零售目前发展很火，平台及数据都是众矢之的，爬取方可能是创业小公司、可能是在校生、商业对手、搜索引擎。比如新零售行业最关心的可能是商品价格，如果竞争对手有能力能够抓到想要的数据，时间长了用户知道了就会流失。
就最近马蜂窝爬虫事件可以看到，商家为了转化率与销售业绩，会想到依靠爬虫爬取其它拥有真正用户参与的商品评论内容。评论在订单转化上具有非常重要的作用，当用户在浏览网站上的商品时，如果商品没有对应的评论记录或者购买记录，则会产生不信任很难转化到实际下单。如果自己平台上优质评论被原样拷贝到对方平台上，而用户在选择时往往会很大程度上参考商品评价，这样潜在用户损失难以估计。
如何能够阻止或者提高对方获取自己平台数据信息，值得引起注意。
如何反爬
首先需要明确的是，只要人类能够正常访问，就不可能百分之百防爬，但是可以增加爬虫爬取成本，当爬虫爬取成本大于爬取数据收益时，也就是反爬胜利时。
可以通过对其app进行分析给出报告，针对爬虫部分，可以给出其app目前防爬存在的缺陷并给出增强策略（这个增强策略可借鉴其他app分析结果，同时还必须对我方友好（白名单），方便我方之后爬取分析）。
还有一个思考，就是我们单方面取爬取分析来输出防爬报告，有点像找漏洞，如果能够通过接入我们的前端信息采集服务等，感知到对方已经可能存在的爬虫问题？防水墙团队目前在推进的Kepler业务安全解决方案的第一环就是接入js来进行初级态势感知。
1. headers反爬
- 除基本的设备参数、地理位置参数、时效性参数等之外，还可针对所需携带的参数设计一个加密串作为签名。（借鉴永辉生活小程序抓包分析结果）。
- 伪造ua成本很低，可以针对不同的浏览器加入不同的检测。
2. 用户行为反爬
- 同一ip短时间大量访问，或者同一账户短时间在页面上有相同操作。这时是否可以应用腾讯防水墙的前端设备指纹/轨迹信息采集？
- 正常人的操作应该是在一段时间内有绝大部分请求之后开始骤减，而爬虫的访问量则随时间增长而增长，应该在一个短周期内设置较宽的阈值，随时间增长收紧阈值，超过阈值的非正常请求加入验证码拦截（顺便推一波我们腾讯防水墙的验证码能力，可以衡量恶意的不同等级给出不同类型的验证），不管对方是验证码识别还是人肉打码，都能增加对方的爬取成本。
- 除拦截外，也可以给假数据。
- 可能存在逻辑漏洞，请求几次，退出登陆再重新登陆，来绕过短时间多次请求会被封的限制。
- 秒拨动态IP服务，可能存在商家刷单、批量注册账号获取优惠券等等风险。这篇km文章有一点浅显的分析，这种秒拨动态ip的情况，简单的IP限制策略并不能阻挡，文中提到了威胁情报感知这种应对手段，但也没有具体说明。所以也可以推出我们的风险感知能力？
3. 动态页面反爬
- 可以针对性的研究目前一些主流的无头浏览器、web测试框架，进行检测/拦截。
- 在页面上添加一些隐藏链接，入坑的便是爬虫。
- js基于一定规则执行生成随机变量发请求时携带进行服务端验证。
4. 其他可参考的反爬方式
- 访问者的URL访问丰富程度：普通用户在打开网页时会有比较丰富的地址访问，而自动爬虫通常只有少数固定的页面访问
- 访问者是否具有连贯的访问轨迹：用户在进行页面访问时，通常是有一个合理的访问轨迹，如从页面A跳转到页面B，但爬虫在自动获取数据时，往往是对页面地址进行逐个访问，没有连贯的轨迹
- 访问者是否查看了页面上的静态资源：爬虫获取数据时往往只关心具体的文字内容和数据，但不会查看图片以及加载页面上的CSS或者JS信息，这就给出了一个较为显著的判断特征
- 访问者每次访问之间的时间间隔：爬虫在获取页面信息时，会出现连续两个Click之间时间非常短的情况，而人手动点击页面不会出现如此短时间或固定的时间访问模式
- 蜜罐：设置一些隐含字段，让爬虫认为请求需要携带
- 访问者请求类型集中：正常用户在浏览过程中并不会产生集中为某种类型的请求。
Reference
JavaScriptCore解析
Using Charles from an iPhone（可能需要翻墙）
SSL Certificates （可能需要翻墙）