Xss簡單滲透測試
責編：admin ｜2015-02-10 14:44:59前言
在web蓬勃發展的今天，xss毫無疑問已經變成最“流行”的漏洞，我曾經在安全公司的滲透測試報告里看到列為數十的高危xss漏洞，也看到越來越多的安 全研究人員將目標投向xss攻擊，發現100個甚至1000個之上的xss。
xss變得如此流行的原因我猜測有幾點，首先輸入輸出是一個應用程序最基本的 交互，一個提供服務的應用程序可以不操作數據庫，可以不與系統交互，但是肯定會將程序的處理結果返回給瀏覽器，加上程序員如果意識不到位，就必然發生 xss，對于一個互聯網公司，這兩方面的因素加起來就會導致這個漏洞數量就非常可觀，所以可以經常見到互聯網公司如騰訊，新浪，百度，搜狐等等的xss漏 洞報告。
但是，在談論xss的時候往往大家都會說這是一個xss漏洞，而不會提到這是個什么類型的xss漏洞，甚至這是個什么場景下的xss漏洞，包括有效的攻擊 方式上都不會去提，即使提到也是一些傳說的危害譬如蠕蟲，譬如掛馬，譬如竊取用戶信息，乃至釣魚攻擊。
甚至由于種種原因，大家往往關注漏洞兩個字甚于前面 的xss。作為安全研究人員，這是一種不負責任的行為，這種行為的后果就是網絡安全淡化為web安全，web安全淡化為xss，而xss淡化為 alert()，總有一天程序員會不再信任我們，真正的威脅依然停留在系統里。這方面也有國際上的原因，太多的安全研究人員將重點放在xss的研究上，我 不知道是否是國外的安全水平已經達到如此需要關注xss的水平，盡管xss是最普遍的漏洞，但是從黑客的利用程度上來看遠遠不如一個命令執行，一個文件上 傳漏洞來得實在。我相信Google已經達到這水平，但那只是Google，不是我們。
我這里不想談論如何防范xss漏洞，如果在你的系統里發現1000個之上的xss，那你就應該停止尋找更多的xss而該去想想如何從根源上杜絕xss，即 使杜絕不了xss那也應該想想xss在這里是不是有什么可預見的風險，如果有的話那有什么方式可以將xss的危害弱化乃至一段時期內可以接受的程度。作為 一個黑客實用主義者，我這里將描述一次xss滲透測試的簡單思想以及實現，與學院派不同，滲透測試不能只是說說而已，必須真實的獲取自己想要的東西才可以 是成功。
xss滲透測試基本思路
在談論具體的xss攻擊之前，我們一定要清楚地知道我們的xss所處的位置在哪以及我們的xss的類型，也就是我上面說的xss攻擊場景。反射型的xss 比起持久型的xss來效果是不同的，訪問量大的xss點與訪問量小的xss點是不同的，發生在http：//www.google.com和發生在https：//www.google.com的xss點是不同的（你應該知道為什么不同），發生在前臺的xss點與發生在后臺的xss點同樣不同。分析 應用程序我們可以很快確認我們的xss點的場景，這在開放的程序里比較好確認，后面我們將講述如何在一個黑盒的環境下分析出攻擊的場景。
在確認好xss點的場景之后，我們可以根據我們的目的來決定后續的攻擊方向和思路。如果發生的點是一個持久型的并且訪問量比較大，你可以依據自己的喜好是 否來引起一次混亂；如果你有幸發現發生的點是在管理員的后臺或者你可以通過某些方式和管理員的后臺進行交互，那么你可以考慮是否需要通過竊取管理員的 cookie來嘗試進入后臺，到目前為止，竊取cookie依然是最有效的攻擊方式，盡管某些xss攻擊平臺可以演示很炫的攻擊效果（前提是你的目標會在 一個頁面停留2個小時，這種情況比較少發生）；如果發生的點是一款開源的或者所有數據請求你都可以分析的程序，你可以考慮利用xss做一些數據提交，但是 前提是依賴于你的xss點發生的場景；或者大氣點，有瀏覽器0day的直接上瀏覽器0day吧，成本有點高，看收獲值不值得了，目前為止貌似這么說的比這 么做的多：）
攻擊方向和思路確定之后后面的就是一些常規的體力活了，編寫攻擊代碼，獲取最終想要的東西，但是這過程可能并不是一帆風順，甚至需要反復的調試攻擊代碼以保證最終的效果跟預期的一致。
一次黑盒的xss滲透測試
因為某些原因我們很想測試下國內一個比較有名的評論網站，我們簡單測試常規的安全漏洞之后我們沒有發現什么有意思的如SQL注射之類的安全漏洞，甚至我們 還沒有辦法找到它的后臺，但是我們發現了他們的一個xss漏洞，比較悲觀的是這是一個反射型的xss漏洞，所以我們不能直接把他頁面黑了（如果是持久類型 的xss，攻擊目的就是破壞或者測試的話就可以考慮這么做，當然，如果是為了YY也是可以的）。我們不要YY，我們要shell。
通過對站點的分析我們發 現系統有個投稿功能，通過審核之后就可以發表。既然會有審核那么就意味著應該有后臺之類的東西，同時我們實際上獲得了一個和管理員交互的平臺，因為我們寫 的內容他們肯定會看。于是我們將編寫好的xss exploit url寫到文章里，并且聲稱在他們的站點內發現了一個黃色的文章。這個xss exploit url會請求我的某個php文件，這個文件將記錄所有請求的referer，cookie，ip，瀏覽器類型和當前的location。
等待幾十分鐘之 后，我們順利獲得了這些基礎信息，但是我們發現這里的location和referer只能獲得我們的xss exploit url，這跟我們希望獲得的管理員后臺并不一致。分析管理員在后臺的操作我們大概可以知道他是點擊連接來訪問這個url的，那么我們是可以獲得 opener窗口的一些信息的，包括location等等。在獲得location之后我們還是很失望，這只是一個內容展現的窗口，并不是后臺的真正管理 的地址，后臺應該是有一個iframe類的東西，于是我們再次通過top.location獲得后臺的地址，這次對了，在我們的面前出現了后臺登陸的地 址，后面的利用竊取的cookie進入后臺很可行哦：）但是我們在嘗試利用cookie進入后臺時依然出了問題，我們的cookie看起來并不有效，這是 為什么呢？后來幾次測試之后才發現程序做了cdn，我們訪問到的登錄地址并不是cookie所在的服務器，做了個host之后我們順利登錄進后臺，后臺界 面出來的一瞬間讓人感覺真是幸福：）
后面的就簡單，找后臺的上傳，傳webshell，涂首頁：）
很明顯，在這樣一個場景下如果說到xss來做蠕蟲肯定是不現實的，對于一個評論網站來說釣魚也沒有什么實際意義，對一個連用戶機制都沒有或者有用戶機制但 是用戶交互比較低的應用程序來說偷取用戶cookie同樣也沒有價值。而真正攻擊的過程中也不是簡單的說說那么容易，應用程序有很多機會可以防止這種攻擊 的發生，包括cookie和ip綁定，cookie做httponly，后臺設置登錄ip限制等等（不要跟我說那些看起來很神仙可以反彈的xss工具，這 就跟物理學里面的理想環境里的實驗一樣不靠譜）。
在對未知的程序進行測試時，可能某些xss點發生在后臺等我們未知的地方，而如果我們直接提交敏感的語句 如[HTML_REMOVED]alert()[HTML_REMOVED]等過去的時候，我們是無法知道程序的返回結果的，而且一旦程序對輸入做了處 理，在后臺出現亂碼等字符時，很容易引起別人的警覺。這個時候我們引入類似于滲透測試中經常使用的掃描的手法，在xss滲透測試時我們可以利用
一次白盒的xss滲透測試
因為某些原因我們想黑掉某個人的blog，該blog系統的源碼我們可以從網上獲取到，在簡單審核一些代碼之后我們沒有發現明顯的SQL注射之類的漏洞， 但是發現了幾個非常有意思的xss漏洞，該漏洞同樣是反射型的xss，但是因為程序的原因可以使得exploit url變形得非常隱蔽。由于程序開源，我們通過本地搭建該環境可以輕松構造出可以加管理員，可以在后臺寫shell的小型exploit，并且將 exploit通過遠程的方式隱藏在前面的exploit url里。
通過分析該程序發現在評論回復時只有登錄才可以回復，而目標經常性回復別人的評論，所以我們發表了一個評論并且將exploit url寫在里面，通過一些手段誘使目標會訪問該url。在等待幾個小時之后，我們看到該評論已經被管理員回復，那么我們的exploit也應該是被順利執 行了。上后臺用定義好的賬戶登錄，很順利，shell也已經存在。OK，最后就是涂首頁：）
對于這部分沒有什么特別好說的，因為所有的數據和邏輯都是公開的，但是非常重要的一點依然是我們的場景。在某些應用程序里，因為前臺的交互比較多，發生 xss的點是前臺，大部分用戶的操作也都是前臺發生的，但是這部分的權限非常沒有意義，我們往往需要特定目標先訪問后臺，然后從后臺訪問我們的xss點才 能獲取相應的權限。這部分的攻擊就變得比較困難了，而上面的攻擊里，由于目標肯定會先訪問后臺然后訪問該xss點，所以xss變得有趣多了。
總結
xss的利用是一件非常有意思的事情，甚至可以獨立于xss的查找成為一門學問，最關鍵的一點是所有的xss都不要脫離場景，脫離場景地談論漏洞很不負責任。我給出的例子都是比較簡單的，希望可以與大家更多地討論更多的有意思的攻擊。
下一篇：SQL注入漏洞