XSS跨站脚本（web应用）——会话管理（一）
本章目的
普及SESSION，COOKIE會話管理和代碼實現掌握Token會話管理了解會話管理的安全問題
Web會話管理概述
會話管理
在人機交互時，會話管理是保持用戶的整個會話活動的互動與計算機系統跟蹤過程。
會話管理分類：桌面會話管理、瀏覽器會話管理、Web服務器的會話管理。
為什么需要會話管理
HTTP是一種無狀態協議，一次請求結束，客戶端與服務端的連接就會斷開，服務器再次收到請求時，無法識別此次請求是哪個用戶發過來的，需要重新建立連接。為了判斷發送請求的用戶，需要一種記錄用戶的方式，也就是Web應用會話管理
Web會話管理方式
常見的Web應用會話管理的方式
基于server端session的管理方式
cookie-based的管理方式
token-based的管理方式
Web會話管理安全問題
基于server端session的管理的方式
在早期的Web應用中，通常使用服務端session來管理用戶的會話服務端session是用戶第一次訪問應用時，服務器就會創建的對象，代表用戶的一次會話過程，可以用來存放數據。服務器為每一個session都分配一個唯一的sessionID，以保證每個用戶都有一個不同的session對象。
服務器在創建完session后，會把sessionID通過cookie返回給用戶所在的瀏覽器，這樣當用戶第二次及以后向服務器發送請求的時候，就會通過cookie把sessionID傳回給服務器，以便服務器能夠根據sessionID找到與該用戶對應的session對象。
基于server端session的管理的方式
session通常設定有有效時間，比如1個小時。當時間失效后，服務器會銷毀之前的session，并創建新的session返回給用戶。但是只要用戶在失效時間內，有發送新的請求給服務器，通常服務器都會把他對應的session的有效時間根據當前的請求時間再重新刷新。
session在一開始并不具備會話管理的作用。它只有在用戶登錄認證成功之后，并且往session對象里面放入了用戶登錄成功的憑證，才能用來管理會話。管理會話的邏輯也很簡單，只要拿到用戶的session對象，看它里面有沒有登錄成功的憑證，就能判斷這個用戶是否已經登錄。當用戶主動退出的時候，會把它的session對象里的登錄憑證清掉。所以在用戶登錄前或退出后或者session對象失效時，肯定都是拿不到需要的登錄憑證的。
基于server端session的管理的方式
session實現會話管理的流程：
瀏覽器第一次請求
服務器創建sessio:msessonid:xxxyy
cookie:sessionid=xxxyy
瀏覽器登錄：username&passwd
服務器根據sessionid拿到sesston:sesslonid.xoxyy并往其中放入登錄憑證userf
cookie:sessionid=xxxyy
瀏覽器需登錄才能訪問的請求
服務器拿到session后，判斷其中是否有登錄憑證
cookie:sessionid=xxxyy
基于server端session的管理的方式
優點：
1、某些地方使用可以簡化Web開發：如果在諸多Web頁面間傳遞一個變量，那么用session變量要比通過QueryString傳遞變量可使問題簡化。
2、安全性好：客戶端與服務端保持會話狀態的媒介始終只是一個sessionID串，只要這個串夠隨機，攻擊者就不能輕易冒充他人的sessionID進行操作；除非通過CSRF或http劫持的方式，才有可能冒充別人進行操作；即使冒充成功，也必須被冒充的用戶session里面包含有效的登錄憑證才行。
基于server端session的管理的方式
缺點：
1、這種方式將會話信息存儲在Web服務器里面，當用戶同時在線量比較多時，這些會話信息會占據比較多的內存；
2、當應用采用集群部署的時候，會遇到多臺web服務器之間如何做session共享的問題。
3、多個應用要共享session時，還會遇到跨域問題。不同的應用可能部署的主機不一樣，需要在各個應用做好cookie跨域的處理。
基于server端session的管理的方式
實驗代碼邏輯
請求網頁
判斷有無SESSIONID
有SESSIONID?????????????????????????????????????????????????????????????????????? 無SESSIONID?
???????????????????????????????????????????????????????????????????????????????????????????? ONID中無數捷
SESSIONID中有數
根據SESSIONID調取數據查詢?????????????????????????????????????????????? 登陸界面
??????????????????????????????????????????????????????????????????????????? ? ? ? ? ? ? ? ? ?
基于server端session的管理的方式
前端代碼
<html><meta charset="utf-8">
<form action="login.php"method="POST">
username:<br>
<input type="text"name="username"><br>
password:<br>
<input type="text"name="password"><br>
<input type="submit"value="Submit">
</form>
</html>
基于server端session的管理的方式
后端代碼(login.php)
<?php
session start(;
Susr =POST['username'];
Spwd =POST['password'];
if(Susr==='admin'&&$pwd==='admin'){
echo'登錄成功';
SESSION["admin"]=1;
var dump($SESSION);
}elsef
echo'登錄失敗';
}?>
基于server端session的管理的方式
后端代碼(check.php)
<?php
session start();
var dump($SESSION);
if($SESSION["admin"]==1){
echo"沒錯你就是管理員";
}else{
echo"我不知道你是誰";
}?>
基于serveri端session的管理的方式
后端代碼(unset..php)
<?php
session start();
unset($SESSION['user'])
session destroy()
?>
cookie-based的管理方式
流程區別主要是不僅中間加了層加密，數字簽字
session的管理方式會增加服務器的負擔和架構的復雜性,所以后來就提出把用戶
的登錄憑證直接存到客戶端的方案,當用戶登錄成功之后,把登錄憑證寫到cookie.里面,
并給cookie設置有效期,后續請求直接驗證存有登錄憑證的cookie是否存在以及憑證
是否有效,即可判斷用戶的登錄狀態。
Cookie與Session最大的區別
Cookie:將數據存儲在客戶端
Session將數據存儲在服務端
cookie-based的管理方式
用戶發起登錄請求,服務端根據傳入的用戶密碼之類的身份信息,驗證用戶是否滿
足登錄條件,如果滿足,就根據用戶信息創建一個登錄憑證,這個登錄憑證簡單來說就
是一個對象,最簡單的形式可以只包含用戶d、憑證創建時間和過期時間三個值。
服務端把上一步創建好的登錄憑證,先對它做數字簽名,然后再用對稱加密算法做
加密處理,將簽名、加密后的字串,寫入cookie。cookie的名字必須固定(如
ticket),因為后面再獲取的時候,還得根據這個名字來獲取cookie值。這一步添加數
字簽名的目的是防止登錄憑證里的信息被篡改,因為一旦信息被篡改,那么下一步做簽
名驗證的時候肯定會失敗。做加密的目的,是防止cookie被別人截取的時候,無法輕易
讀到其中的用戶信息。
cookie-based的管理方式
用戶登錄后發起后續請求,服務端根據上一步存登錄憑證的cookie名字,獲取到相
關的cookie值。然后先做解密處理,再做數字簽名的認證,如果這兩步都失敗,說明這
個登錄憑證非法;如果這兩步成功,接著就可以拿到原始存入的登錄憑證了。然后用這
個憑證的過期時間和當前時間做對比,判斷憑證是否過期,如果過期,就需要用戶再重
新登錄;如果未過期,則允許請求繼續。
cookie-based的管理方式
優點:
1、實現了服務端的無狀態化(最大的優點),服務端只需要負責創建和驗證登錄
cookiel即可,無需保持用戶的狀態信息。
2、cookie可以跨越同域名下的的多個網頁,但不能跨越多個域名使用
3、可以設置有效期限,控制cookie的生命周期,使之不會永遠有效(攻擊者可能
拿到的是過期的cookie)
cookie-based的管理方式
缺點:
1、cookie有大小限制,存儲不了太多數據。
2、每次傳送cookie,增加了請求的數量,對訪問性能也有影響。
3、同樣存在跨域問題(不同域名無法互相讀取cookie)
token-based的管理方式
Session和Cookie兩種會話管理方式由于都要用到Cookie,不適合用在native
app里面,因為native app不是瀏覽器,不好管理Cookie,因此都不適合做純API服務
的登錄認證。要實現API服務的登錄認證,就需要用到token-based的會話管理方式。
token-based的管理方式從流程上和實現上跟cookie-based的管理方式沒有太多
區別,只不過cookie-based的管理方式中寫到cookie.里面的ticket在這種方式下稱為
token,這個token在返回給客戶端之后,后續請求都必須通過url參數或者是http
headerf的形式,主動帶上token,這樣服務端接收到請求之后就能直接從http header
或者url里面取到token進行驗證。
token-based的管理方式
流程區別主要是不僅中間加了層加密，數字簽字，還有后續請求
優點:
1、支持跨域訪問:Cookie是不支持跨域訪問的,Token支持
2、無狀態:Token:無狀態,Session有狀態(有狀態和無狀態最大的區別就是服務
端會不會保存客戶端的信息)
3、支持移動設備:Token更適用于移動應用,Cookie不支持手機端訪問
token-based的管理方式
缺點:
1、占帶寬:正常情況下Token要比session ID更大,需要消耗更多的流量,擠占
更多帶寬
2、無法在服務端注銷,很難解決劫持問題
安全問題
在Wb應用里,會話管理的安全性始終是最重要的安全問題,對用戶的影響極大。從會話管理憑證來說,Session會話管理的會話憑證僅僅是一個session ID,所以只要這個session ID足夠隨機,那么攻擊者就不會輕易地冒充別人的session ID進行操作;Cookie會話管理的憑證(ticket)以及Token會話管理憑證(token)都是一個在服務端做了數字簽名和加密處理的串,所以只要密鑰不泄露,攻擊者也無法輕易拿到這個串中有效信息并對它進行篡改。總之,這三種會話管理方式的憑證本身是比較安全的。從客戶端和服務端的HTTP過程來說,當攻擊者截獲到客戶端請求中的會話憑證,就能拿這個憑證冒充原用戶,做一些非法操作,而服務器也認不出來。這種安全問題,可以簡單采用HTTPS來解決,雖然可能還有HTTP劫持這種更高程度的威脅存在,但是從代碼能做的防范,確實也就是這個層次了。
總結
以上是生活随笔為你收集整理的XSS跨站脚本（web应用）——会话管理（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： win 2003 联网
- 下一篇： XSS跨站脚本（web应用）——XSS跨