使用時間戳防止會話劫持？

Question

我一直在尋找方法來防止會話劫持，其中有人竊取會話cookie並使用它來訪問系統。

諸如http://codebutler.com/firesheep之類的程序可以輕鬆地在開放式無線網絡上嗅探會話，其他獲取會話的方式包括跨站點腳本攻擊，或者只是將其從受害者的計算機上提取出來。

使用SSL來保護所有會話cookie /服務器通信對於防止Firesheep嗅探至關重要，並且在cookie上設置HTTPOnly有助於防止JavaScript在XSS攻擊中讀取會話cookie，但它仍然容易受到AJAX基於攻擊。

另一層是爲包括安全令牌或在會話cookie即得到對每個請求更新隨機數。將令牌存儲在服務器端數據存儲區和Cookie中，並且在比較每個請求時，Cookie中的令牌與數據存儲區中的令牌相匹配。

如果令牌不匹配，可能是某人偷走會話並嘗試使用它的指示符，因此您可以忽略請求或使會話無效並要求用戶重新進行身份驗證。但是，不匹配的標記也可能是由於緩慢/片狀連接造成的。

例如，你可以有當服務器收到來自真實用戶的請求，服務器數據存儲更新會話令牌和響應與包含更新的令牌的會話cookie的用戶的情況下。但是由於緩慢/片狀的連接，用戶沒有收到響應，所以用戶仍舊擁有舊的會話令牌，而新的會話令牌存儲在服務器上。當用戶重試請求時，令牌將不匹配。

緩解這個問題的一種方法是讓服務器保留最後幾個令牌的歷史記錄，並檢查它們是否匹配，然後它變成需要保留多少令牌的情況，並且取決於片狀連接是或如何使用戶點擊快樂，服務器可以在連接回來之前循環瀏覽歷史記錄，並且瀏覽器更新用戶的會話。

到保持令牌歷史另一種方法是時間戳每個會話，並檢查時間戳是一些短，規定的範圍內，例如30秒。如果用戶的會話cookie時間戳記在服務器存儲的會話時間戳記的30秒內，則會話視爲可信。

例僞

def authenticate_request(): 

    if (stored_session.timestamp - session.timestamp > 30 seconds): 
     return False 
    return True 

這避免了保持令牌歷史 - 時間戳記令牌 - 但攻擊者有機會就偷了之後劫持會話30秒的窗口。雖然這是真的，但令牌歷史選擇並不是更好，因爲它給攻擊者一個潛在的更長時間的機會。

檢查IP地址和用戶代理變化的其他方法也有問題。用戶代理很容易被欺騙，如果攻擊者能夠獲得用戶的會話，他們可以通過相同的XSS代碼或其他方式輕鬆確定用戶代理。

如果用戶在移動設備上，它們的IP地址可能會經常發生變化，這樣會導致許多誤報。此外，攻擊者可能位於同一公司防火牆之後，因此用戶和攻擊者的IP與外部Web服務器的IP相同。

是使用時間戳令牌正確的做法還是有更好的辦法？ 30秒的緩衝區是否正確？我缺少哪些優勢案例？

Answer 1

我看不到時間戳是如何工作的。這要求用戶在向服務器發送另一個請求之前，永遠不要在頁面上花費超過30秒的時間。我確定我花了超過30秒的時間閱讀此頁面並在按「發佈」之前輸入此響應。

在我看來，存在一個固有的問題，即通過線路發送的任何數據都可能被截取和複製。加密密碼並不能解決問題，因爲黑客可以攔截加密的值，然後發送加密的值。他不一定關心未加密的值是什麼。

您發送的任何令牌都是同樣的故事。黑客可以攔截令牌並複製它。

我聽到的似乎解決問題的唯一想法是使用公鑰和私鑰的質詢和響應系統：A創建一個隨機字符串，使用B的公鑰對其進行加密，並將其發送給B B使用他的私鑰解密該字符串，並將解密後的值與他的應用程序數據一起發回。 A然後驗證解密值與原始值相匹配。如果它沒有驗證，他拒絕相關的數據。

如果黑客不知道B的私鑰，黑客就不能攔截來自A的消息並欺騙響應。黑客不能使用B先前截獲的答覆，因爲隨機字符串每次都不相同。