概述

上個星期根據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並不只是實現了記錄的內容。更多的時候用於標示和跟蹤使用者的作用。