关于模拟登陆的小结-抓包、cookie、session和token

概述

上个星期根据bcloud写了个Java版本的登陆项目。其实本来时想做个Linux的百度云登陆软件，但是做到获取bdstoken的时候出了问题解决不了。后来我把bcloud项目下了下来用发现也有问题，应该是百度登陆的过程有了一些改动。通过 web抓包找到一些线索，但是不知道为什么用相同的cookie和stoken访问得到的却是页面不存在或会话已超时之类的错误提示页面。另外有些参数确实猜不出来是什么或者怎么获取，能力精力所限，昨天晚上决定还是就到此为止吧，毕竟世上无难事只要肯放弃。这段时间还是学了不少东西，想要了解的内容基本上也都做了一定练习，准备写3-4篇博客对近期的内容进行一些简单的回顾。 
这篇文章主要说的是模拟登陆的过程和实现的方法。

模拟登陆及抓包

总的来说模拟登陆有两大类方式：

1. 一类是正规的途径通过官方的授权的接口： 
   比如说你注册一个百度的开发者账号申请一个应用会得到一些授权，通过这些授权验证，你可以通过调用百度提供的SDK来获取资源，发布应用等等。 
   采用这样的方式是安全简单，不会出现很多的bug，也不会涉及维护问题，因为SDK都是官方提供的，官方会维护的很好。这样其实是一个互利互惠的过程，官方提供平台，开发者丰富应用。比如说pcs还有大量的百度第三方应用都是这类。 
   目前来说国内大部分的授权协议都是Oauth2.0。这个协议简单的说通过给用户提供一个令牌（token），而不是通过用户密码来授权，这样的一个好处时，可以方便开发者开发软件，而使用者不需要将密码提供给开发者从而避免一些隐私的问题。 
   当然官方授权虽然有很多好好处当然也时有一些问题的，首先访问资源是受限的，只能访问官方限定的资源，当然如果只是这样还好，但是也存在官方根本不提供授权和SDK的情况，这样当然也就完全无解了。而且作为开发者还需要获得官方许可也是个挺麻烦的事情，比如有些官方对开发者有一定要求，比如需要是公司等等，如果是学生想写写东西自己玩的话就不值得了。

2. 第二类是通过模拟浏览器过程来实现： 
   如果我们曾经登陆用浏览器登陆过一个网站，那下次登陆的时候就会自动保持登陆状态那这样的情况。之所以能这样时因为浏览器保存了cookie，也就是用户的一些信息。再次登陆的时候通过检测这些信息就可以直接登陆从而省去用户手动登陆的步骤，当然这涉及一定的隐私问题。你可以通过模拟浏览器的类型来实现模拟登陆。 
   这样做的最大的好出万能有效且无资源限制，理论上说的话如果你能做个浏览器那任何网站你都能模拟登陆。当然实际中并不需要做到这一步，通常来说只要做到三点基本上就可以模拟登陆任何网站了。一是了解http协议，并能解析基本结构，包括请求头、相应头、json、xml或者html之类的数据；二是管理cookie；三是获取token。比如bcloud就是者一类。 
   当然说起来似乎比较简单。但是其实时一个看起来简单做起来麻烦的工程问题。主要的难点不在远离上而在工程性上。首先，官方不会将传递数据的信息告诉你的，所以你需要猜，这就很依靠经验和悟性甚至运气了。其次，对于官方的每一次改动你都需要跟进，比如说bcloud项目。有很多的issues都是因为官方对登陆过程有了一些调整，你也就需要进行相应的调整，所以即使你当时做出来了，隔两个月也许就不能用了，需要再去分析，修bug。最后，官方不是傻子，不会让你这么简单的就搞定，会有一些防盗的技术手段。而且我对这个领域还不是太了解，模拟登陆虽然还达不到算是白帽或者黑帽的地步，但是毕竟没有官方授权，如果真的有一些意外也不好。

   第二类模拟登陆的基本步骤就是

   1. 通过抓包，分析获得cookie和token 的步骤和方式
   2. 通过模拟浏览器骗过服务器。

   本文剩下的部分就主要介绍下如何去抓包，以及cookie和token的基本概念，具体实现会放到后面的博客继续介绍。

抓包

其实抓包是一个很简单的概念，只要对http协议有基本的了解就可以，网上有大量的可以抓包的库。其实只要时基本的实现了http协议的客户端都可以抓包。比如说Python的url，bcloud就是在此基础上实现的。我找到的java的库是okhttp，之前似乎还有httpclient，没用过不多说了。就我用过的url和okhttp来说感觉都差不多，毕竟http协议也不会有太大变化了。 
抓包其实不光是用在模拟登陆，很多很多地方都用得到，比如说做服务器的时候需要分析性能或者分析bug之类的，比如写爬虫之类的，是一个比较基本的技能。

抓包有很多中方法，除了用库分析以外，也有一些软件可以抓包，一般来说如果时浏览器抓包的，浏览器自身自带了很多分析工具网上教程也很多，搜搜就有。 
但是浏览器抓包也有一些不好的地方。有些数据的信息时看不了的。比如说gzip格式的数据，json没有分析之类的，需要自己分析。通常来说都是用web浏览器抓包作为分析资料，用库来模拟实现web浏览器过程。

Cookie、Session 和 token

这里尝试解释一下，如果以后发现问题再修改，其实没完全理清楚。

Cookie

Cookie出现的主要目的是为了解决HTTP无状态的问题，是HTTP拓展协议。就好像之前所说的问题，用来保存用户的状态信息，比如说用户名，密码信息，购物车信息等等。Cookie通过浏览器来在客户端管理，不同浏览器之间互相独立。也有说法cookie分为内存和硬盘两种储存方式，硬盘上的cookie是浏览器共享的。

Cookie主要有名字、值、缓存时间、路径和域： 
名字和域就是键值对没什么好说的。 
Cookie有缓存时间限制，如果超过时限会消失，如果cookie没有设置缓存时间，则时间为本次会话，浏览器窗口关闭后就消失了。 
路径和域构成了Cookie的作用范围，传送给服务器的cooki必须是作用范围大于请求资源的域才传送。 
Cookie有大小限制，最大4k。另外浏览器通常也也限制每个站点cookie的数量和cookie的总量。

cookie产生的方式：正常来说是通过浏览器或者说http交互的，但是实际上也可以通过程序语言自己构建cookie。

Session：

可以说Cookie是客户端对用户信息的储存，而Session则是实现保存用户状态信息的机制。 
通常来说当用户发像服务器发起一个链接，则服务器会建立一个Session，并且保存这个Session的历史内容，并且向用户发送一个Session ID。通常来说本次Session在用户完成会话之后就关闭了，但是服务器并不会删除这些信息而是将其作为历史记录绑定到用户储存起来。当下一次用户再次连接服务器后，通常来说根据Cookie来再次验证用户，然后结合用户历史记录重新生成一个Session并且重新发送一个SessionID。 
但是还有一点需要说明。通常来说用户并不会通知服务器关闭Session。服务器通常来说会保持Sessioon一段时间，也需是几分钟，几个小时，几天都有可能。如果在此期间，依然用相同的SessionID去访问资源的话，那服务器同样是相应请求的。 
用户可以通过Session ID来实现有状态的会话，但是Session理论上说也可以时无状态的，但是一般不会这样用。

广义上说Session并不是必须再Http协议上，可以再很多层上实现：以OSI为标准：

• 应用层： 
  
  • HTTP session：
  • telnet：
• 会话层： 
  
  • 基于SIP（Session Initiation protocol）的网络电话

• 传输层：

  • TCP session

  对于没有实现正式的Session层的传送协议比如说（UDP）或者说存在时间非常短协议（HTTP），需要再更高层上实现Sesssion。典型的就是HTTP Cookie来帮助实现的状态初始化。

Token

有了Cookie和Session的知识，那token就比较好解释了，Token我理解的话就是Session ID的一种。

Cookie和Sesssion其实没有什么可以比较的东西，只能说通过Cookie，再更上一层次的设计上实现了为无状态的HTTP协议的Session机制。

token并不是cookie的一种，可以是cookie验证后的产物，但是token可以以cookie的形式储存，传递的时候也可以用cookie的形式来传送，也可以写入url里传送，也就时所谓的URL重写技术。另外Cookie通常是浏览器维护的，但是token不一定，可以以其他终端的形式维护。

唯一需要说明的是，为何有了Cookie还需要实现Session而不是只用Cookie：

一方面Cookie本身有一定的限制：

• 首先，cookie并不是万能的。cookie有很多限制，比如说不能跨域访问。跨域访问还有很多其他的问题需要考虑，这里不赘述了。此外token还是一种常用的防止CSRF的手段。
• 其次，cookie是明文传送的。除非你使用https的协议，http协议是明文传递的。明文传递cookie很容易被盗取，但是token就不会有这么明显的意义。
• 此外，即使不考虑安全的问题。每次都通过cookie来验证用户状态也是一个麻烦的问题。耗费了大量的资源且不必要。服务器验证之后给用户一个有一定时限的token，这样用户可以通过token免去验证的烦恼。
• 最后，Cookie本身时可以删除的。

另一方面Session并不只是实现了记录的内容。更多的时候用于标示和跟踪用户的作用。