94 lines
4.9 KiB
Markdown
94 lines
4.9 KiB
Markdown
# 6.4 預防session劫持
|
||
session劫持是一種廣泛存在的比較嚴重的安全威脅，在session技術中，客戶端和伺服器端透過session的識別符號來維護會話， 但這個識別符號很容易就能被嗅探到，從而被其他人利用。它是中間人攻擊的一種型別。
|
||
|
||
本節將透過一個例項來示範會話劫持，希望透過這個例項，能讓讀者更好地理解session的本質。
|
||
## session劫持過程
|
||
我們寫了如下的程式碼來展示一個count計數器：
|
||
```Go
|
||
|
||
func count(w http.ResponseWriter, r *http.Request) {
|
||
sess := globalSessions.SessionStart(w, r)
|
||
ct := sess.Get("countnum")
|
||
if ct == nil {
|
||
sess.Set("countnum", 1)
|
||
} else {
|
||
sess.Set("countnum", (ct.(int) + 1))
|
||
}
|
||
t, _ := template.ParseFiles("count.gtpl")
|
||
w.Header().Set("Content-Type", "text/html")
|
||
t.Execute(w, sess.Get("countnum"))
|
||
}
|
||
|
||
```
|
||
count.gtpl的程式碼如下所示：
|
||
```Go
|
||
|
||
Hi. Now count:{{.}}
|
||
```
|
||
然後我們在瀏覽器裡面重新整理可以看到如下內容：
|
||
|
||
|
||
|
||
圖6.4 瀏覽器端顯示count數
|
||
|
||
隨著重新整理，數字將不斷增長，當數字顯示為6的時候，開啟瀏覽器(以chrome為例）的cookie管理器，可以看到類似如下的資訊：
|
||
|
||
|
||
|
||
|
||
圖6.5 取得瀏覽器端儲存的cookie
|
||
|
||
下面這個步驟最為關鍵: 開啟另一個瀏覽器(這裡我打開了firefox瀏覽器),複製chrome位址列裡的地址到新開啟的瀏覽器的位址列中。然後開啟firefox的cookie模擬外掛，新建一個cookie，把按上圖中cookie內容原樣在firefox中重建一份:
|
||
|
||
|
||
|
||
圖6.6 模擬cookie
|
||
|
||
Enter後，你將看到如下內容：
|
||
|
||
|
||
|
||
圖6.7 劫持session成功
|
||
|
||
可以看到雖然換了瀏覽器，但是我們卻獲得了sessionID，然後模擬了cookie儲存的過程。這個例子是在同一臺計算機上做的，不過即使換用兩臺來做，其結果仍然一樣。此時如果交替點選兩個瀏覽器裡的連結你會發現它們其實操縱的是同一個計數器。不必驚訝，此處firefox盜用了chrome和goserver之間的維持會話的鑰匙，即gosessionid，這是一種型別的“會話劫持”。在goserver看來，它從http請求中得到了一個gosessionid，由於HTTP協議的無狀態性，它無法得知這個gosessionid是從chrome那裡“劫持”來的，它依然會去查詢對應的session，並執行相關計算。與此同時 chrome也無法得知自己保持的會話已經被“劫持”。
|
||
## session劫持防範
|
||
### cookieonly和token
|
||
透過上面session劫持的簡單示範可以瞭解到session一旦被其他人劫持，就非常危險，劫持者可以假裝成被劫持者進行很多非法操作。那麼如何有效的防止session劫持呢？
|
||
|
||
其中一個解決方案就是sessionID的值只允許cookie設定，而不是透過URL重置方式設定，同時設定cookie的httponly為true,這個屬性是設定是否可透過客戶端指令碼訪問這個設定的cookie，第一這個可以防止這個cookie被XSS讀取從而引起session劫持，第二cookie設定不會像URL重置方式那麼容易取得sessionID。
|
||
|
||
第二步就是在每個請求裡面加上token，實現類似前面章節裡面講的防止form重複遞交類似的功能，我們在每個請求裡面加上一個隱藏的token，然後每次驗證這個token，從而保證使用者的請求都是唯一性。
|
||
```Go
|
||
|
||
h := md5.New()
|
||
salt:="astaxie%^7&8888"
|
||
io.WriteString(h,salt+time.Now().String())
|
||
token:=fmt.Sprintf("%x",h.Sum(nil))
|
||
if r.Form["token"]!=token{
|
||
//提示登入
|
||
}
|
||
sess.Set("token",token)
|
||
|
||
```
|
||
### 間隔產生新的SID
|
||
還有一個解決方案就是，我們給session額外設定一個建立時間的值，一旦過了一定的時間，我們銷燬這個sessionID，重新產生新的session，這樣可以一定程度上防止session劫持的問題。
|
||
```Go
|
||
|
||
createtime := sess.Get("createtime")
|
||
if createtime == nil {
|
||
sess.Set("createtime", time.Now().Unix())
|
||
} else if (createtime.(int64) + 60) < (time.Now().Unix()) {
|
||
globalSessions.SessionDestroy(w, r)
|
||
sess = globalSessions.SessionStart(w, r)
|
||
}
|
||
```
|
||
session啟動後，我們設定了一個值，用於記錄產生sessionID的時間。透過判斷每次請求是否過期(這裡設定了60秒)定期產生新的ID，這樣使得攻擊者取得有效sessionID的機會大大降低。
|
||
|
||
上面兩個手段的組合可以在實踐中消除session劫持的風險，一方面， 由於sessionID頻繁改變，使攻擊者難有機會取得有效的sessionID；另一方面，因為sessionID只能在cookie中傳遞，然後設定了httponly，所以基於URL攻擊的可能性為零，同時被XSS取得sessionID也不可能。最後，由於我們還設定了MaxAge=0，這樣就相當於session cookie不會留在瀏覽器的歷史記錄裡面。
|
||
|
||
|
||
## links
|
||
* [目錄](<preface.md>)
|
||
* 上一節: [session儲存](<06.3.md>)
|
||
* 下一節: [小結](<06.5.md>)
|