散列會話指紋真的有必要嗎？

Question

請投票前操作裝配閱讀本...

所以我已經看到了很多通過用戶代理的級聯和兩個IP塊或任何建立指紋會話管理類。他們似乎還添加了一個鹽，然後在將該指紋存儲在會話變量中之前對其進行哈希處理。

這種指紋產生通常發生在每個請求上，以便驗證會話的當前用戶是否爲原始會話用戶。這就是爲什麼我想知道，是鹽和散列真的需要這樣的東西？

如果黑客可以進入文件系統查看會話文件內容，那麼您是不是已經在那個時候洗過？

任何信息非常感謝。

Answer 1

其中大部分是有道理的，但散列和醃製是沒有意義的。

如果您將會話綁定到IP地址，那麼劫持會話變得困難得多。這是我推薦做的事情，但是你不需要對此嚴格要求。你可以只綁定IPv4的前三部分。這是你的選擇。越嚴格的IP檢查越安全，但對用戶來說不太方便。

至於綁定基於用戶代理的會話，這也可能有所幫助。必須認識到，如果你工作在一個未加密的通道上（例如HTTP），那麼用戶代理檢查就不那麼有用了，因爲它也可以被入侵者重現。

說到醃製和散列，這是沒用的。他們沒有加強你的身份檢查。他們做的唯一事情就是讓你的設計複雜化。對於這個問題，我相信他們會降低你的安全水平。

與往常一樣，一些規則要牢記：

• 使用強效的會話標識符。這意味着使用好的隨機源並確保有足夠的位。
• 將會話綁定到IP，至少在某種程度上。
• 如果可能，將會話綁定到用戶代理。
• 使用SSL/TLS。沒有它，理論上所有的會話系統都是不安全的。
• 確保您的會話存儲。無論是基於文件系統還是基於數據庫。

Answer 2

我能想到的兩種情況下，這將是有益的：

1. 當會話數據存儲的客戶端。 （就像在一個cookie中一樣。）所以，我會被阻止把我的cookie帶到另一臺計算機上，並且會阻止我製作自己的cookie內容。 （好的，所以這不是一個很可能的場景......）
2. 當會話數據存儲在某些共享服務器端資源（即/ tmp）中並且容易被窺探時。在這種情況下，如果窺探者能夠看到會話的內容，他們仍然不能僞造該會話的連接，因爲他們不知道指紋中有哪些數據。

Answer 3

我可以想象，指紋信息的哈希點是存儲空間，因爲生成的哈希具有固定的長度。

但也使用鹽對我沒有多大意義。因爲正如你所說的那樣，由於數據存儲在會話數據存儲位置，因此如果某人能夠獲得該數據，則會比會話修復/劫持造成更大的問題。

Answer 4

你可以在這裏找到一個合理的解決方案： http://shiflett.org/articles/the-truth-about-sessions

指紋對抗會話劫持。 攻擊者不僅需要你的session_id，他還需要任何敏感的HTTP頭。 這爲攻擊者增添了另一個障礙，儘管可以輕鬆克服。

散列在那裏使數據統一。鹽在那裏模糊散列過程 - 所以攻擊者不能爲自己的HTTP頭組合生成有效的指紋。

如果黑客是在文件系統中，你有更大的問題：d

Answer 5

很多人誰不很瞭解有關安全，希望結合流傳在Internet建議比特他們實際將會「足夠好」。將會話ID綁定到U-A會中斷瀏覽器升級（Chrome經常會這樣做），並綁定到IP地址會導致移動性下降（任何人使用Wi-Fi的筆記本電腦），而且許多ISP沒有連續的分配。任何能夠嗅探cookie的人都可以嗅出U-A，並且可能會訪問相同的IP地址，因爲他們將Cookie置於NAT後面的不安全Wi-Fi上。

你可能做想要做的是改變一個登錄嘗試，這是爲了防止「會話固定」攻擊（其中，攻擊者使受影響的負載http://example.com/?SESSIONID=foo例如通過<img>的可靠途徑會話ID，等待讓你登錄，現在知道受害者的會話ID）。沒有理由通過登錄保留會話，並且您可以複製需要保留的少數內容（例如購物車）。

Answer 6

如果黑客能獲得到你 文件系統來發現你的會話文件 內容，是不是已經在該區在 這一點？

如果你使用PHP作爲CGI（就像nginx一樣），那麼我認爲不是。如果您設置了權限，那麼會話文件必須對PHP用戶具有讀/寫權限，而您的PHP文件應該只具有讀權限。因此，如果您將鹽從Web服務器傳遞到PHP，那麼PHP用戶無法訪問它（他不能創建任何新的/更改可以由您的Web服務器運行的現有PHP文件，並且他不能訪問網絡服務器，因爲它在另一個用戶上運行），所以他不能真正破解（更改）cookie（只刪除它們），因爲他不能得到鹽。當然，你也必須通過web服務器傳遞數據庫設置。

我從來沒有真正嘗試過，所以請糾正我，如果我錯了。

Answer 7

在補充，其中包含如何保護您的會話存儲我想補充一些想法不是可以在一些特定的應用解釋哈希&鹽一些很好的提示@Kai Sellgren（+1）的響應。

我不是在討論使用cookie作爲會話存儲的應用程序，我們仍然會在Prestashop電子商務解決方案上看到這一點，並加密了cookie內容（爲什麼他們決定將會話存儲在cookie？）。我明白我們談論服務器端會話存儲。

關鍵的一點是分層安全性和縱深防禦：

Compromissions從來布爾的事情，你不「完全地破壞」或「完全地安全的」。我喜歡的真實歷史之一是mySpace worm explanation，它顯示了真正的攻擊和防守步驟必須如何突破。總是有一堵新牆。僅舉一個例子，當我在辦公室時，我與我的老闆分享了相同的IP，也許是同一瀏覽器，這可能會破壞僅基於IP +用戶代理的安全性。

因此，在會話戳記的鹽問題中，我們顯然是在幾個牆壁倒塌之後採取行動的&。凱向我們展示了這些牆壁。當他談到保護會話存儲我想補充兩兩件事：

• 它改變session.save_path每個PHP應用程序的open_basedir（並獲得一個單獨的虛擬主機的每個）一個很好的主意。很少完成。
• 如果您的應用程序安裝路徑（如/ MYAPP）上，加上會話cookie一個prefix_path（和解決它的任何其他應用程序在同一臺服務器上）

現在讓我們想象一下一個現實compromission。你已經幾種方法可以在服務器端妥協會話：

• 的應用與在其他路徑運行（或者在同一服務器上的其他域）其他一些應用程序在網站上運行。至少在這些申請中是相當不安全的。在最壞的情況下，服務器端代碼可以注入到這個應用程序中，但是一些安全牆（如open_basedir或其他chrooting技術）可能會阻止此注入的代碼影響您的單獨應用程序（或數據）。
• 一些JavaScript庫帶有一些包含高度不安全腳本的測試子目錄，不僅會議信息很好，而且可能會提供一些會話固定或預測。
• 該應用程序是共享的，並且討論類似wordpress的軟件，您可以想象一些平臺共享許多不同的安裝，具有不同的模塊和可能的一些自定義代碼。在這樣的平臺上，你會發現可以改變每個消費者的鹽的設置，這是有原因的。其中一個網站可能會影響其他人的安全，如果應用程序想要管理一體化網站，清理分離將變得更加困難。

你的目標應用可以通過環境遭到襲擊，如果會話存儲可以與其他應用程序的某些腳本共享，或者從腳本在自己的應用程序，你甚至did'nt發現（這樣的F * **在JavaScript庫中的例子，爲什麼你沒有暫停PHP靜態文件目錄執行！）

從compromission，攻擊者可以potentialy的第一步（和嚴重程度增加）：

• 閱讀會議郵票，也許覺得他應該假以獲得該信息相同的印花稅
• 共建包含對其配置有效的會話戳的新會話，然後在您的應用程序中使用此新會話標識符。你的應用程序將找到會話文件，並接受他。
• 改變您的有效會話的一個修改的郵票以同樣的方式

郵票的簡單哈希將讓他的生活困難，但它也只是一堵牆折斷，鹽使這面牆更難以打破。

重要的一點是，從你的問題，如果一個人可以改變會議存儲中的東西，我已經心情不好了嗎？。好吧，也許不完整。如果它是應用程序的chroot/separation/securization允許他做的唯一的東西，鹽對他來說將是一場噩夢。

而第二個重點是：我應該在每個Web應用程序上對此級別的深度安全性進行操作嗎？。答案是否定的。 過度工程是一件壞事，它可以通過簡單的事實來降低應用程序的安全性，它變得更難理解和理解。你並不需要complexify您的應用程序，如果：

• 你有會話存儲分離的一個相當不錯的水平
• 你孤單你的服務器上，只有一個人報名，並且沒有任何形式的多點處理
• 您的應用程序的安全級別是如此之弱，一個簡單的代碼注入可以應用，所以不需要會話固定攻擊者:-)

Answer 8

是真正需要的鹽和散列某事李關於這個[http客戶端指紋]？

該散列可能有助於減少會話數據中指紋所消耗的字節數。所以只要散列指紋的尺寸小於指紋本身的尺寸，這在減少空間方面就是有意義的。價格是消耗系統資源來生成散列。

它真的有意義嗎？你需要以此爲基準來說明。

那麼鹽怎麼會有幫助呢？我必須承認，我沒有看到鹽的理由。只有使從哈希中猜出指紋更加困難纔有意義。但是，由於我沒有看到哈希指紋（它只保存在服務器端並且已經相當安全）的安全性好處，鹽醃不會增加任何東西。

如果會話存儲本身不被認爲是安全的（如果這是參數），那麼whole session should be encrypted不僅僅是指紋。

因此，特別是對於指紋，我沒有看到用於哈希和醃製它的很多用途。