XSS攻擊的類型

XSS攻擊的類型

---

XSS攻擊分成兩類

一類是來自內部的攻擊，主要指的是利用程序自身的漏洞，構造跨站語句
另一類則是來自外部的攻擊，主要指的自己構造XSS跨站漏洞網頁或者尋找非目標機以外的有跨站漏洞的網頁
如當我們要滲透一個站點，我們自己構造一個有跨站漏洞的網頁，然後構造跨站語句，通過結合其它技術
如社會工程學等，欺騙目標服務器的管理員打開

反射型XSS

反射型XSS是非持久性、參數型的跨站腳本
反射型XSS的JS代碼在Web應用的參數(變量)中，如搜索框的反射型XSS
在搜索框中，提交
PoC[<script>alert(/xss/)</script>]
點擊搜索，即可出發反射型XSS
注意到，我們提交的poc會出現在search.php頁面中的keywords參數中

當今的網站中包含大量的動態內容以提高用戶體驗，比過去要複雜得多
所謂動態內容，就是根據用戶環境和需要，Web應用程序能夠輸出相應的內容
動態站點會受到一種名爲“跨站腳本攻擊”
(Cross Site Scripting 安全專家們通常將其縮寫成XSS
原本應當是css,但爲了和層疊樣式表(Cascading Style Sheet,CSS)有所區分，故稱XSS)
的威脅，而靜態站點則完全不受其影響。

用戶在瀏覽網站、使用即時通訊軟件、甚至在閱讀電子郵件時，通常會點擊其中的鏈接
攻擊者通過在鏈接中插入惡意代碼，就能夠盜取用戶信息
攻擊者通常會用十六進制（或其他編碼方式）將鏈接編碼，以免用戶懷疑它的合法性
網站在接收到包含惡意代碼的請求之後會產成一個包含惡意代碼的頁面
而這個頁面看起來就像是那個網站應當生成的合法頁面一樣
許多流行的留言本和論壇程序允許用戶發表包含HTML和javascript的帖子
假設用戶甲發表了一篇包含惡意腳本的帖子，那麼用戶乙在瀏覽這篇帖子時，惡意腳本就會執行，盜取用戶乙的session信息
有關攻擊方法的詳細情況將在下面闡述。

利用此漏洞，還可以實現一種攻擊叫做CSRF，CSRF（Cross-site request forgery）跨站請求僞造
也被稱爲“One Click Attack”或者Session Riding，通常縮寫爲CSRF或者XSRF，是一種對網站的惡意利用
儘管聽起來像跨站腳本（XSS），但它與XSS非常不同，並且攻擊方式幾乎相左
XSS利用站點內的信任用戶，而CSRF則通過僞裝來自受信任用戶的請求來利用受信任的網站
與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認爲比XSS更具危險性。

也就是說，黑客如果向論壇中注入如下代碼：

<script>

document.location="http://shopping.taobao.com/ShoppingProcess.php?goods=cpu&quantity=1000";

</script>

加入論壇的用戶同時也是網站http://shopping.taobao.com/的合法用戶，其客戶端登錄http://shopping.taobao.com/網站後具有該網站的
Cookie如果這時該用戶打開論壇，顯示論壇內容時候，則執行了這段代碼，於是在購物網站時結賬時，賬面上多扣除了1000枚CPU的價格

存儲型XSS

存儲型XSS：存儲型XSS，持久化，代碼是存儲在服務器中的
如在個人信息或發表文章等地方，加入代碼，如果沒有過濾或過濾不嚴，那麼這些代碼將儲存到服務器中
用戶訪問該頁面的時候觸發代碼執行。
這種XSS比較危險，容易造成蠕蟲，盜竊cookie（雖然還有種DOM型XSS，但是也還是包括在存儲型XSS內）

DOM XSS比較特殊。owasp關於DOM型號XSS的定義是基於DOM的XSS是一種XSS攻擊
其中攻擊的payload由於修改受害者瀏覽器頁面的DOM樹而執行的
其特殊的地方就是payload比較難以檢測
如下面的例子：
[#message=<script>alert(/xss/)</script>]

我們以描點的方式提交PoC
PoC並不會發送給服務器，但是已經觸發了XSS
查看提交參數後的HTML頁面(DOM樹)，會形成鮮明的對比

#應對方法

在Web 應用開發中，開發者最大的失誤往往是無條件地信任用戶輸入
假定用戶（即使是惡意用戶）總是受到瀏覽器的限制，總是通過瀏覽器和服務器交互
從而打開了攻擊Web應用的大門。實際上，黑客們攻擊和操作Web網站的工具很多，根本不必侷限於瀏覽器
從最低級的字符模式的原始界面（例如telnet）
到 CGI腳本掃描器、Web代理、Web應用掃描器，惡意用戶可能採用的攻擊模式和手段很多。

因此，只有嚴密地驗證用戶輸入的合法性，纔能有效地抵抗黑客的攻擊
應用程序可以用多種方法（甚至是驗證範圍重疊的方法）執行驗證
例如:在認可用戶輸入之前執行驗證,確保用戶輸入只包含合法的字符,而且所有輸入域的內容長度都沒有超過範圍
（以防範可能出現的緩衝區溢出攻擊），在此基礎上再執行其他驗證，確保用戶輸入的數據不僅合法，而且合理
必要時不僅可以採取強制性的長度限制策略，而且還可以對輸入內容按照明確定義的特徵集執行驗證

下面幾點建議將幫助你正確驗證用戶輸入數據：

⑴ 始終對所有的用戶輸入執行驗證，且驗證必須在一個可靠的平臺上進行，應當在應用的多個層上進行。

⑵ 除了輸入、輸出功能必需的數據之外，不要允許其他任何內容。

⑶ 設立“信任代碼基地”，允許數據進入信任環境之前執行徹底的驗證。

⑷ 登錄數據之前先檢查數據類型。

⑸ 詳盡地定義每一種數據格式，例如緩衝區長度、整數類型等。

⑹ 嚴格定義合法的用戶請求，拒絕所有其他請求。

⑺ 測試數據是否滿足合法的條件，而不是測試不合法的條件。這是因爲數據不合法的情況很多，難以詳盡列舉。