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應用掃描器，惡意用戶可能采用的攻擊模式和手段很多，
因此，只有嚴密地驗證用戶輸入的合法性，才能有效地抵抗黑客的攻擊
應用程式可以用多種方法（甚至是驗證范圍重疊的方法）執行驗證
例如:在認可用戶輸入之前執行驗證,確保用戶輸入只包含合法的字符,而且所有輸入域的內容長度都沒有超過范圍
（以防范可能出現的緩沖區溢位攻擊），在此基礎上再執行其他驗證，確保用戶輸入的資料不僅合法，而且合理
必要時不僅可以采取強制性的長度限制策略，而且還可以對輸入內容按照明確定義的特征集執行驗證
下面幾點建議將幫助你正確驗證用戶輸入資料：
⑴ 始終對所有的用戶輸入執行驗證，且驗證必須在一個可靠的平臺上進行，應當在應用的多個層上進行，
⑵ 除了輸入、輸出功能必需的資料之外，不要允許其他任何內容，
⑶ 設立“信任代碼基地”，允許資料進入信任環境之前執行徹底的驗證，
⑷ 登錄資料之前先檢查資料型別，
⑸ 詳盡地定義每一種資料格式，例如緩沖區長度、整數型別等，
⑹ 嚴格定義合法的用戶請求，拒絕所有其他請求，
⑺ 測驗資料是否滿足合法的條件，而不是測驗不合法的條件，這是因為資料不合法的情況很多，難以詳盡列舉，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/253050.html
標籤：其他