大概全中國的教務處網站都是一樣的,選課時期總是出去薛定諤的貓的狀態,因此使用爬蟲來選課對於計算機的學生來說就很正常了,在進行爬蟲爬取之前,我們首先需要對它進行抓包分析。
試探
首先登錄教務處網址,我們學校教務處的網址是10.5.2.80,在瀏覽器中輸入網址后你會發現進行了重定向,重定向后的網址是10.5.2.80/(uzcntciw0q5jisjv5ydagx45)/default2.aspx.你會發現中間用括號括起來了一個長度為24的字符串,我們再在瀏覽器中輸入一次10.5.2.80網址,再次進行重定向,發現中間的字符串再次進行了改變。這就很有意思,中間的字符串為甚每次登錄教務處網址都會改變呢,
當然我們首先進行抓包來看看,瀏覽器向服務器發送了什么
我們發現請求的地址正是我們每次重定向到的網址
再查看下我們發送的表單
TextBox1、TextBox2中分別存儲着我們的用戶名和密碼那么我們探索一下表單中另外三個參數的作用(PS:這命名隨意到難以置信).RadioButtonList1、Button1很明顯是url編碼的值,我們將RadioButtonList1、Button1中的值進行url解碼(注意此處url編碼使用了gb2312)。
結果分別為學生和登錄。可是另一個VIEWSTATE呢
VIEWSTATE
VIEWSTATE其實也算一個很古老的東西了,正是因為老舊的教務處也同樣的古老,我們才能夠發現他。正方是使用ASP開發的,而VIEWSTATE也算ASP一個特點(基本存在於已經廢棄webform),它起到的作用主要將整個頁面的控件的狀態用base64編碼傳給后端,具體可以看淺談viewstate
VIEWSATE是屬性type=hide的input標簽,我們按下f12查看它的值
於是我們試着用base64解碼VIEWSTATE試試,為了使大家清楚viewstate到底存儲了怎樣的信息,我們進入信息較多的課表頁然后讀取它隱藏的VIEWSTATE將其進行解碼
手動DOG臉
雖然http協議本身是無記憶的,但是VIEWSTATE能夠使它擁有記憶的能力,它能夠保留你之前的一系列操作。
注意viewstate是一路變化的,若想完全模擬瀏覽器,應當在寫爬蟲跳轉時都獲取當前頁面viewstate
模擬登錄的源碼
我們先模擬輸入10.5.2.80重定向的過程
#!/usr/bin/env python3 #-*- encoding:utf-8-*- import requests from bs4 import BeautifulSoup url = "http://10.5.2.80" res = requests.get(url) #無需添加header,教務處沒有檢查 print(res.url) #'http://10.5.2.80/(ekjnqwuvqxd5hq2whour5n45)/default2.aspx'
res.url就是我們等會登錄請求的地址,再模擬表單提交的過程
#我們使用Beautifulsoup來找到要提交的內容 redirect_url = res.url content = BeautifulSoup(res.content) payload = { "__VIEWSTATE":content.find(attrs={"name":"__VIEWSTATE"}["value"]), "TextBox1":"**",#輸入你的賬號 "TextBox2":"**",#輸入你的密碼 "RadioButtonList1":"%D1%A7%C9%FA",#代表你的身份為學生 "Button1":"+%B5%C7+%C2%BC+",#雖然我也不懂按鈕也要給value代表提交 } res = requests.post(redirect_url,data=payload) print(res.text)
你會發現你已經登錄進入了教務處
不存在cookies的會話保存
如果你之前用過requests一定不會陌生session,我們知道http協議是無記憶連接那么他是如何保存一個用戶的信息的呢?
答案在於cookies。
一般的登錄在登陸后會的響應頭中會有這么一行
Set-Cookie: *************
表示增加該cookie,瀏覽器收到這個響應后,會存儲這個cookie到本地,在請求這個網站時,頭部會自動攜帶這個cookie
后端會檢查瀏覽器的cookie判斷是否是用戶
因此我在最初使用時,就用了自動處理cookies的requests.session,但是我發現我根本是多此一舉
因為
它根本沒有保存任何cookies!!
於是我陷入了深深的沉思。
還記得前面我們提過的那個奇怪的長度為24的字符串嗎?
沒有錯,那個括號就是對你身份的標示。
不負責任的猜測:后台數據庫在你登錄后會隨機分配一個hash后的字符串,然后重定向,如果登錄成功,則在后台將這個字符與你賬號對應,一旦中間字符是這個則表示是你登錄
所以你將這個網址發給你的同學,直接連接這個網址就是你的登錄界面了。
奇怪的GET
順便提一句教務處不兼容現代瀏覽器的原因是因為它的下拉子菜單用了已經被廢棄的IE標簽,寫個JS腳本替換下就可以
以選課頁面為例子,你點擊它會彈出子標簽頁,而當我將彈出的子標簽頁的網址輸入在瀏覽器中發現它卻把我重定向回了登錄界面(瀏覽器的開發者工具不監聽彈出子頁面),難道不是get。
於是我打開了burpsuit比較了這兩個包的差異
你發現了有什么不同嗎?
就在於被我多標紅的那一欄Referer
最后的搶課請求
其實沒有好說的,搶課的請求頁面和你瀏覽課程的頁面是一樣的,網址都是
http://10.5.2.80/(×××××××)/xf_xsqxxxk.aspx?xh=××××××&xm=×××××××&gnmkdm=N121109
區別在於請求方式和referer
只要老實查看表單模擬表單提交就可以了
全部腳本
別想了,怎么可能給你全部的腳本,自己去寫吧!
或說寫這么長的文章早可以把教務處管理員JWC01的密碼爆破出來