XSS基礎
XSS概念：
通常情況下，在Web應用的網頁中，有些部分的顯示內容會根據外屆輸入值而發生變化（會反彈惡意代碼），而如果生成這些HTML的程序中存在問題，就會滋生名爲跨站腳本（Cross-Site Scripting）的安全隱患。由於它和知名的CSS（層疊樣式表）縮寫衝突，所以經常縮寫爲XSS。
XSS的實質其實是HTML代碼與Javscript代碼的注入。但由於XSS的攻擊對象是與客戶對等的Browser端，因此常常不被開發者所重視。
一般意義上的XSS通常可以用簡單的方法檢測出來：當用戶輸入中某個參數的全部或其中一部分，原封不動地在源代碼裏出現時，我們就可以認爲這個參數存在XSS漏洞。
XSS的風險：
Web應用若存在XSS漏洞，就會有如下風險：
- 用戶的瀏覽器中運行攻擊者的惡意腳本，從而導致Cookie信息被竊取，用戶身份被報名頂替。
- 攻擊者能獲得用戶的權限來惡意使用Web應用的功能。
- 向用戶顯示僞造的輸入表單，通過釣魚式攻擊竊取用戶的個人信息。
XSS漏洞總覽：
- 產生地點：Web應用中南生成HTML和JavaScript的地方。
- 影響範圍：Web應用全體
- 影響類型：在網站用戶的瀏覽器中執行JavaScript，顯示僞造的網站內容。
- 影響程度：中~大。
- 用戶參與程度：需要—> 瀏覽惡意網站、點擊郵件內的附屬連接、瀏覽已被入侵的網站等。
- 對策概要：用雙引號括起來屬性對，轉義HTML中的特殊字符。
XSS被惡意使用的三種方法：
- 竊取Cookie值
- 通過JavaScript攻擊
- 篡改網頁
同源策略：
- 同源策略：來自相同網站的頁面。
- 不同源策略：來自不同網站的頁面。
跨站腳本類型：
XSS分類：可根據不同分類方式，分爲不同類型。
- 按形式分：反射型XSS 存儲型XSS
- 按介質分：JSXSS FlashXSS
- 按接口分：DOM base XSS , 非DOM XSS
注：因此沒有反射型XSS、存儲型XSS、DOM XSS這種分類，因爲分類依據都不同…
反射型XSS：
如果攻擊用JavaScript代碼位於攻擊目標網站之外的其他網站（惡意網站或者郵件中的URL），就 稱爲反射型的XSS（Reflected XSS）。
竊取Cookie實例中用到的XSS攻擊模式就屬於反射型XSS。
**反射型XSS多發生於網頁將用戶輸入值原封不動地顯示出來的情況。**其中，輸入值確定頁面就是一個典型的例子。
存儲型XSS：
有時攻擊者也會將攻擊用JavaScript代碼保存至攻擊對象的數據庫中。這種模式的XSS就被稱爲存儲型的XSS（Stored XSS）或持久性的XSS（Presistent XSS）。
存儲型的XSS的典型攻擊對象爲Web郵箱客戶端以及社交網站（Social Networking Service，簡稱SNS）。
存儲型XSS無需攻擊者費勁心思將用戶引誘至惡意網站，而且即使是戒心很重的用戶也會有很大的機率中招，因此對攻擊者來說益處多多。
存儲型XSS：
- 長期存儲與服務器端
- 每次用戶訪問都會被執行JS腳本
客戶端表單長度限制：
- 客戶端源碼修改限制
- 代理截斷
DOM型XSS：
- DOMXSS漏洞是基於文檔對象模型（Document Object Model）的一種漏洞。
- DOM是一套JS和其他語言課調用的API（遍歷、獲取、修改）。
- 根據XSS在DOM中輸出點的不同，DOM XSS機有可能是反射型，也有可能是存儲型。
注意：‘#’，它告訴瀏覽器所有在它後面的東西都是個片段，也就是不作爲查詢的一部分。IE（6.0）和Mozilla不會把這個片段發送到服務器，因此服務器端看到的只是#號前面提交的參數。這樣如果#號後面填充了惡意腳本，就不會被服務器端看到。
如果服務器端直接讀取客戶端提交參數的所有，重寫改寫頁面，就會將惡意腳本寫到頁面。在寫頁面時，需要先使用URL解碼。
兩種典型的DOM過程：
**反射型DOM base XSS： **
- 用戶輸入帶有參數的URL
- JavaScript處理URL並獲取參數
- 通過DOM調用參數對頁面進行排版。
- 通過DOM動態輸出到頁面上。
存儲型DOM base XSS：
- 用戶輸入帶有參數的URL或者Body域數據
- 服務器將參數存入數據庫
- 通過JSON格式返回參數到頁面
- 通過DOM調用參數進行排版
- 通過DOM動態輸出到頁面上。
XSS產生的根源：
XSS漏洞產生的原因爲，生成HTML的過程中，HTML語法中含有特殊意義的字符（元字符）沒有被正確處理，結果導致HTML或JavaScript被肆意注入，從而使得原先的HTML結構產生變化。爲了消除元字符的特殊意義，將其轉化爲普通字符，就需要用到轉義（Escape）處理。HTML的轉義處理對消除XSS至關重要。
HTML轉義：
在HTML中顯示< 時，必須按照字符實體引用（Character Entity Reference）將其轉義記載爲 <；而如果忽略這一步驟直接生成HTML的話，瀏覽器會將 < 解釋爲標籤的開始。從而就或招致惡意利用此漏洞進行的XSS攻擊。
在HTML中，根據字符所處位置的不同，應當轉義的元字符也會發生變化。
元素內容轉義：
- 特徵：能解釋Tag和字符實體；結束邊界字符爲<。
- 轉義：< 和 & 使用字符實體轉義。
PHP轉義函數：
htmlspecialchars($String, $quote_style, $charset)
$string ：轉換對象字符串
$quote_style：轉換方法。
轉換前 轉換後 ENT_NOQUOTES ENT_COMPAT ENT_QUOTES < <； 支持 支持 支持 > >； 支持 支持 支持 & &； 支持 支持 支持 " "； 不支持 支持 支持 ’ '； 不支持 不支持 支持 一般使用最後一種即可：ENT_QUOTES
$charset：字符編碼。如UTF-8、GBK。
屬性值（雙引號中南的內容）轉義：
- 特徵：能解釋字符實體；結束邊界字符爲雙引號。
- 轉義：屬性值用雙引號括起來，< 和 & 和 " 使用字符實體轉義。
XSS的輔助性對策：
-
輸入校驗：通過檢驗輸入值的有效性，當輸入值不符和條件是就顯示錯誤消息，並促使用戶重新輸入，有時也能夠防禦XSS攻擊。
-
給Cookie添加HttpOnly屬性：Cookie中有名爲HttpOnly屬性，該屬性能禁止JavaScript讀取Cookie值。
通過給Cookie添加HttpOnly屬性，能夠杜絕XSS中竊取會話ID這一典型的攻擊手段。但需要注意的是其他攻擊手段依然有效，所以這樣只能是限制了攻擊者的選擇範圍，並不能杜絕所有的XSS攻擊。
php.init:session.cookie_httponly=On
XSS對策總結：
根本性對策（個別對策）
- HTML的元組內容：使用htmlspecialchars函數轉義。
- 屬性值：使用htmlspecialchars函數轉義並用雙引號括起來。
根本性對策（共通對策）
- 明確設置HTTL響應的字符編碼。
輔助對策
- 輸入校驗
- 給Cookie添加HttpOnly屬性。
XSS進階
HTML組成元素
- 腳本（事件綁定）
- 事件綁定函數中的字符串字面量
- 屬性值/（URL），屬性位置防止雙引號。
- 元素內容，元素位置防止尖角符號。
- script元素中南的字符串字面量
JavaScript問題：
之所以會混入安全隱患，是因爲沒有將JavaScript字符串字面量進行轉義。因此，輸入參數中的單引號沒有被識別爲字符，而是被當成了JavaScript中南字符串的結束符。
爲了避免這種情況，理論上應採取如下措施：
- 首先，將數據作爲JavaScript字符串字面量進行轉義。
- 將得到的結果再次進行HTML轉義。
JS字符串字面量中南應被轉義的字符：
| 原字符 | JavaScript轉義後 | HTML轉義後 |
|---|---|---|
| <>’ " \ | < > \’ \" \\ | <； >；'；"； \\ |
<?php
function escape_js($s){
return mb_ereg_replace('([\\\\\'])', '\\\1', $s);
}
?>
<body onload="init('<?php echo htmlspecialchars(escape_js($_GET('name')), ENT_QUOTES, "UTF-8"); ?>')">
</body>
JS字符串字面量動態生成的對策：
按照JavaScript語法，將引號（單引號及雙引號）和斜槓\及換行符等進行轉義。"\"" 。如果是事件綁定函數，將JS執行結果按照字符實體進行HTML轉義， 並用雙引號括起來。
如果是在script元素中，執行JS後，確保字符串中不存在</ 。
雖然理論上如此，但JavaScript的轉義規則相當複雜，執行起來很容易產生疏漏，因此一直以來都是安全隱患誕生的溫牀。鑑於這種情況，最好的辦法可能是避免動態生成JavaScript。然而，現實中又會經常需要傳給JavaScript的參數是動態的。此時，一般使用Unicode轉義的解決方案。
Unicode轉義：
爲了避免動態生成JavaScript帶來的風險，可以採取將字母和數字以外的其他所有字符都進行轉義的方法。這種方法利用了JavaScript能將Unicode代碼點U+XXXX字符轉義爲\uXXXX的功能。
輔助方案：錯誤消息導致的信息泄露。
- 錯誤消息中包含對攻擊者有幫助應用程序內部信息。
- 通過蓄意攻擊使錯誤信息中顯示隱私信息（如用戶個人信息等。）
應用程序內部信息是指，發生錯誤的函數名、數據庫的表名、列名等，這些信息都可能成爲攻擊的突破口。
爲了解決以上問題，當應用程序發生錯誤時，應該僅在頁面上顯示“此時訪問量太大，請稍後再試”等提示用戶的消息。
PHP的情況下，禁止顯示詳細錯誤信息，只需要在php.ini中做如下設置：
display_errors = Off
HTML轉義概要：
| 位置 | 說明 | 轉義概要 |
|---|---|---|
| 元素內容（普通文本） | 能解釋Tag和字符實體。結束邊界符爲 <。 | < 和 & 使用字符實體轉義。 |
| 屬性值 | 能及時字符實體。結束邊界字符爲雙引號 | 屬性值用雙引號括起來，< 和 & 和 ”使用字符實體轉義 |
| 屬性值（URL） | 同上 | 檢驗URL格式正確後按照屬性值的規則轉義。 |
| 時間綁定函數 | 同上 | 轉義JavaScript後按照屬性值的規則轉義 |
| script元素中字符串字面量 | 不能解釋Tag和字符實體。結束邊界字符爲</ | 轉義JavaScript並避免出現"</" |
XSSer簡介-確認XSS存在的工具
XSSer概述：
跨站點“Scripter”（又名XSSer）是一個自動化框架，用於檢測、利用以及報告基於Web應用程序
中的XSS漏洞。
XSS是Web應用常見的漏洞。利用該漏洞，安全人員在網站注入惡意腳本，控制用戶瀏覽器，併發起其他滲透操作。XSSer是Kali Linux提供的一款自動化XSS攻擊框架。該工具可以同時探測多個網址。如果發現XSS漏洞，可以生成報告，並直接進行利用，如建立反向連接。爲了提供攻擊效率，該工具支持各種規避措施，如判斷XSS過濾器、規避特定的防火牆、編碼規避。同時，該工具提供豐富的選項，供用戶自定義攻擊，如指定攻擊載荷、設置漏洞利用代碼等。
一個自動框架、檢測，利用和報告基於Web應用的XSS漏洞。
支持命令行、圖形化界面。
提供繞過服務器過濾的選項，以及一些特殊的代碼注入技術。
XSSer經典命令：
-u URL, --url=URL 添加URL
-g Getdata 使用GET提交數據
-p POSTdata 使用post提交數據
--cookie=COOKIE 提供cookie信息
-s, --statistics 顯示統計信息
-v, --verbose 展示詳細結果
--reverse-check 反向連接檢查
BeEF攻擊簡介
BeEF概述：
通過XSS漏洞，將hook.js腳本注入，可將中招的客戶端掛起。
如果客戶端瀏覽器關掉，則連接會斷開。
可以做持久化連接。不讓用戶關閉瀏覽器，或者後臺開一個小窗。
BeEF（Brower exploitation framerwork）：
- 生成，交付Payload
- Ruby語言編寫
- 服務器端：管理Hooked客戶端
- 客戶端：運行與客戶端瀏覽器的JS腳本（hook）
降低白帽子對JS代碼的要求。
BeEF主要針對瀏覽器（客戶）進行攻擊。
- 應用普遍轉移到B/S架構，瀏覽器稱爲唯一客戶端程序。
- 結合社會工程學方法對瀏覽器進行攻擊。
- 攻擊瀏覽器用戶
- 通過注入的JS腳本，劉勇瀏覽器工具其他網站
BeEF攻擊手段：
- 利用網站XSS漏洞實現攻擊
- 誘使客戶端訪問包含hook的僞造網站
- 結合中間人攻擊注入hook腳本
軟件攻擊模塊顏色介紹：
- 綠色模塊：表示模塊適合目標瀏覽器，並且執行結果客戶端不可見
- 紅色模塊：表示模塊不適合目標瀏覽器，有些紅色模塊也可正常運行
- 橙色模塊：模塊可用，但是結果對用戶可見（例如：彈窗申請全新等）
- 灰色模塊：模塊未在目標瀏覽器測試過
BeEF常見用途：
- 鍵盤記錄器
- 網絡掃描
- 瀏覽器信息收集
- 綁定shell
- 與Metasploit集成
學習筆記記錄。與相關資料整理。
參考資料：