會話劫持工具

『壹』 常見WEB攻擊之Session攻擊(會話劫持)

Session對於Web應用無疑是最重要的，也是最復雜的。對於web應用程序來說，加強安全性的第一條原則就是 – 不要信任來自客戶端的數據，一定要進行數據驗證以及過濾，才能在程序中使用，進而保存到數據層。 然而，為了維持來自同一個用戶的不同請求之間的狀態， 客戶端必須要給伺服器端發送一個唯一的身份標識符(Session ID)。 很顯然，這和前面提到的安全原則是矛盾的，但是沒有辦法，http協議是無狀態的，為了維持狀態，我們別無選擇。 可以看出，web應用程序中最脆弱的環節就是session，因為伺服器端是通過來自客戶端的一個身份標識來認證用戶的， 所以session是web應用程序中最需要加強安全性的環節。

基於session的攻擊有很多種方式。大部分的手段都是首先通過捕獲合法用戶的session, 然後冒充該用戶來訪問系統。也就是說，攻擊者至少必須要獲取到一個有效的session標識符，用於接下來的身份驗證。

在Session攻擊中又分為會話劫持和會話固定兩種，篇幅原因下面簡單介紹會話劫持攻擊的攻擊方式和防禦措施

會話劫持（Session hijacking），這是一種通過獲取用戶Session ID後，使用該Session ID登錄目標賬號的攻擊方法，此時攻擊者實際上是使用了目標賬戶的有效Session。會話劫持的第一步是取得一個合法的會話標識來偽裝成合法用戶，因此需要保證會話標識不被泄漏。

1、 目標用戶需要先登錄站點；

2、 登錄成功後，該用戶會得到站點提供的一個會話標識SessionID；

3、 攻擊者通過某種攻擊手段捕獲Session ID；

4、 攻擊者通過捕獲到的Session ID訪問站點即可獲得目標用戶合法會話。

1、 暴力破解：嘗試各種Session ID，直到破解為止；

2、 預測：如果Session ID使用非隨機的方式產生，那麼就有可能計算出來；

3、 竊取：使用網路嗅探，XSS攻擊等方法獲得。

確保User-Agent頭部信息一致的確是有效的，如果會話標識通過cookie傳遞，攻擊者能取得會話標識，他同時也能取得其它HTTP頭部。由於cookie暴露與瀏覽器漏洞或跨站腳本漏洞相關，受害者需要訪問攻擊者的網站並暴露所有頭部信息。則攻擊者只需重建頭部即可進行攻擊了。

因此前提需要做好XSS防禦

對於常用框架來說，其內部Session的實現機制雖然不是很安全，但是關於生成Session ID的環節還是比較安全的，這個隨機的Session ID往往是極其復雜的並且難於被預測出來，所以，對於第一、第二種攻擊方式基本上是不太可能成功的。

對於第三種方式大多使用網路數據通訊層進行攻擊獲取，可以使用SSL進行防禦。

在應用層上也可以做出相應的防禦措施：

目前有三種廣泛使用的在Web環境中維護會話（傳遞Session ID）的方法：URL參數，隱藏域和Cookie。其中每一種都各有利弊，Cookie已經被證明是三種方法中最方便最安全的。從安全的觀點，如果不是全部也是絕大多數針對基於Cookie的會話管理機制的攻擊對於URL或是隱藏域機制同樣適用，但是反過來卻不一定，這就讓Cookie成為從安全考慮的最佳選擇。

1、 更改Session名稱。PHP中Session的默認名稱是PHPSESSID，此變數會保存在Cookie中，如果攻擊者不分析站點，就不能猜到Session名稱，阻擋部分攻擊。

2、 關閉透明化Session ID。透明化Session ID指當瀏覽器中的Http請求沒有使用Cookie來存放Session ID時，Session ID則使用URL來傳遞。

3、 設置HttpOnly。通過設置Cookie的HttpOnly為true，可以防止客戶端腳本訪問這個Cookie，從而有效的防止XSS攻擊。

4、 關閉所有phpinfo類mp request信息的頁面。

5、驗證HTTP頭部信息

在http訪問頭文件：[Accept-Charset、Accept-Encoding、Accept-Language、User-Agent]，瀏覽器一般發出的頭部不會改使用User-Agent檢測請求的一致性。

『貳』 怎樣應對會話劫持：以Firesheep為例

黑客用這個工具就可以訪問用戶訪問流行網站時所使用的賬戶，如大名鼎鼎的Facebook賬戶等。其實，該工具就是利用了一個業內人士都熟知的一個漏洞：會話支持。因為到目前為止，還沒有完全解決這個漏洞。 WEB認證基礎知識 1、用戶訪問需要認證的網站。 2、用戶提供一個用戶名和口令進行驗證。 3、網站驗證用戶口令，如果通過，則准許用戶登錄進入，並將一個cookie提供給用戶的瀏覽器。此cookie用於唯一的標識會話。 4、用戶繼續訪問網站。在用戶請求一個新網頁時，瀏覽器都會發送cookie和用戶請求，提醒Web伺服器：該請求是前面的認證連接的一部分。 在多數情況下，Web開發人員和網站管理員都會使用HTTPS加密來保護這個過程的第二步，他們都知道如果其它人員能夠訪問其他用戶的用戶名和口令，就可以輕易地獲得訪問權。在許多情況下，他們會轉而使用一個不加密的HTTP連接，以便於實現Web通信的其餘部分，其中也包括cookie的交換。 會話劫持攻擊和Firesheep 下面談談會話劫持攻擊。如果竊聽者成功地截獲了發生在第四步的任何通信，他就可以輕易地訪問cookie。一旦知道了cookie的內容，竊聽者就可以偽造一個HTTP請求，使用cookie訪問用戶的賬戶。 防禦Firesheep等會話劫持攻擊 防禦Firesheep及其它會話劫持攻擊的最佳防線在於WEB開發人員和WEB伺服器的管理人員。如果你開發的WEB應用程序依賴於cookie來實現會話管理，就要確保以一種安全方式來管理會話。下面介紹幾個方法： 1、僅通過SSL來發送cookie。如果你要求瀏覽器在傳輸之前加密cookie，在傳輸中就不易遭受攻擊。 2、要限制能夠利用cookie的應用程序。你還應當設置cookie，要盡可能地限制其使用。至少，要將cookie設置為僅對可信域中的系統可用。理想情況下，還應僅允許可信域中的特定伺服器訪問這些cookie，還有設置路徑(path)選項，僅准許特定的應用程序可以訪問cookie。 3、限制cookies僅能使用HTTPS。你還可以使用httponly標記，要求瀏覽器僅能通過HTTP/HTTPS直接將cookie提交給伺服器。這會防止攻擊者通過JavaScript攻擊訪問cookie。 如果你是一位終端用戶，你可能無法控制cookies的配置方法，但你可選擇下面的一些措施： 1、限制不提供HTTPS連接的網站的使用。 2、通過VPN建立連接。如果你在一個有風險的地方上網，並且擔心竊聽者會執行會話劫持攻擊，可以試著連接到工作場所的VPN(虛擬私有網路)，並使用此連接來加密你的網路通信。 結束語Firesheep所代表的絕不僅僅是一種軟體威脅。它以一種WEB應用程序執行會話管理的方式突顯了一種底層漏洞。雖然有一些臨時的解決方案可以幫助企業限制這種工具所造成的短期損害，但WEB應用程序社團應當緊密協作，並開發可以解決會話劫持攻擊的長期解決方案。否則，在下一個黑客工具出現之後，我們依舊容易遭受攻擊。

『叄』 中間人攻擊的會話劫持

會話劫持」（SessionHijack）是一種結合了嗅探以及欺騙技術在內的攻擊手段。廣義上說，會話劫持就是在一次正常的通信過程中，攻擊者作為第三方參與到其中，或者是在數據里加入其他信息，甚至將雙方的通信模式暗中改變，即從直接聯系變成有攻擊者參與的聯系。簡單地說，就是攻擊者把自己插入到受害者和目標機器之間，並設法讓受害者和目標機器之間的數據通道變為受害者和目標機器之間存在一個看起來像「中轉站」的代理機器（攻擊者的機器）的數據通道，從而干涉兩台機器之間的數據傳輸，例如監聽敏感數據、替換數據等。由於攻擊者已經介入其中，他能輕易知道雙方傳輸的數據內容，還能根據自己的意願去左右它。這個「中轉站」可以是邏輯上的，也可以是物理上的，關鍵在於它能否獲取到通信雙方的數據。
典型的會話劫持是利用TCP/IP的工作原理來設計攻擊的。在談TCP/IP會話劫持前先解釋一下TCP/IP用於確認數據傳輸的判斷機制。許多人一定都有過這樣的疑問：TCP/IP是使用點對點（PointtoPoint）連接進行數據傳輸的，但是它是如何知道上一條數據和下一條數據存在的聯系的呢。如果發送數據後不慎掉線，恰好另一個人接著IP地址連接到了Internet，那他會不會收到伺服器返回數據。其實只要看過TCP/IP協議的書籍就會明白，TCP協議採用了兩種條件來確認每條已經建立連接的TCP通道，第一個是基礎連接確認，即TCP連接中的四大必備條件：源IP、源TCP埠、目標IP、目標TCP埠；第二個條件是「序號標識」（Sequencenumbers，SEQ），它們是成對出現的，分為「Sequence」（SEQ，序號欄位）和「AcknowledgementSequence」（ACKSEQ，確認序號欄位），TCP每次建立一個連接時，會給雙方指定這樣一條規則：序號欄位指出了本報文中傳送的數據在發送主機所要傳送的整個數據流中的順序號，而確認序號欄位指出了發送本報文的主機希望接收的對方主機中下一個八位組的順序號。（這里可能比較難理解，可以舉個不專業的例子解釋：流水線上的工人被規定好了每人負責安裝8個不同的零件，則每次傳輸到他們手上的都應該是只留下給他們安裝的8個零件位置，這就是序號欄位；而下一個工人則被規定在前一個工人的基礎上安裝另一個部分的8個零件，這就是確認序號欄位，如果這個工人發現傳到自己手上的產品多了或少了零件，則說明前一個工人出錯，這個產品就被從流水線提取出來返工，這就是TCP對序號的嚴密審查和丟棄制度）。TCP如此謹慎，就是為了避免出現前面提到的假設，雖然這種假設發生的幾率很小（需要滿足TCP的基礎連接確認條件），但是它總有機會發生的。然而不幸的是，這對序號是可以預測的，因為TCP必須遵從以下守則：一台主機即將發出的報文中的SEQ值應等於它所剛收到的報文中的ACKSEQ值，而它所要發送報文中的ACKSEQ值應為它所收到報文中的SEQ值加上該報文中所發送的TCP數據的長度，即兩者存在「本次發送的SEQ=上次收到的ACKSEQ；本次發送的ACKSEQ=上次收到的SEQ+本次發送的TCP數據長度」的聯系。知道這個規律後，攻擊者就不難發起「中間人攻擊」了，他只需要設法監聽到受害者TCP連接中的第一個條件（源IP、源TCP埠、目標IP、目標TCP埠），就可以得知其中一台主機對將要收到的下一個TCP報文段中SEQ和ACKSEQ值的要求，這樣攻擊者就能在原來的合法主機收到另一台合法主機發送的TCP報文前根據所截獲的信息向該主機發出一個符合條件二（序號標識）的TCP報文，如果該主機先收到攻擊報文，就會受到欺騙而把合法的TCP會話建立在攻擊主機與被攻擊主機之間，而且攻擊報文會讓被攻擊主機對下一次要收到的TCP報文中的確認序號值的要求發生變化，最終使另一台合法的主機向被攻擊主機發出的報文被拒絕，這種模式被稱為「主動劫持」。換句話說，就是其中一方合法主機被攻擊者掠奪了連接的許可權，而攻擊者卻成為了合法的連接方之一。這種會話劫持讓攻擊者避開了被攻擊主機對訪問者的身份驗證和安全認證，從而使攻擊者直接進入對被攻擊主機的的訪問狀態，因而危害嚴重。例如，你剛向某站點發送完賬戶密碼，就被攻擊者搶先冒充你的TCP連接上了，那你的損失可就難預料了。不過，會話劫持對網路環境的一點要求可以讓大家鬆口氣，它必須在使用MAC定址的網路環境中才能發揮作用，必要時還要配合ARP協議欺騙，能同時滿足這兩個條件的只有區域網。而廣域網不是靠MAC地址來查找計算機的，因此攻擊者很難從現有的廣域網結構里插入到某兩台計算機之間。