關於更詳細的文檔資料，請回看第一部分
《網絡安全學習》第一部分-----初識OWASP
1、SS的常見攻擊方式：
- 反射型
- 存儲型
第一種：反射型XSS攻擊
發出請求時，XSS代碼出現在URL中，作爲輸入提交到服務器端，服務器端解析後響應，XSS代碼隨響應內容一起傳回給瀏覽器，最後瀏覽器解析執行XSS代碼。這個過程像一次反射，故叫反射型XSS。
模擬反射型XSS攻擊：
通過構建Node應用，演示反射型XSS攻擊。後臺框架位jfinal，頁面渲染也是jfinal，其他框架的話只需要修改方式即可，原理一樣。
前端頁面代碼
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>XSS腳本攻擊演示</title>
<body>
<hr>
瀏覽器的參數值是： <p>#(xss)</p>
</body>
</html>
後臺Controller代碼
package com.demo.web;
import com.demo.model.User;
import com.jfinal.core.Controller;
public class IndexController extends Controller {
public void index() {
// 獲得連接參數xss ,並渲染到前臺
String attr = getPara("xss");
setAttr("xss", attr);
render("index.html");
}
}
然後我們訪問我們的項目，加上xss的參數，機會得到如下效果。
接下來，我們將xss的值改爲具有攻擊性的腳本：
xss=<img src="null" onerror="alert(1)"/>
然後我們訪問這個地址，就會出現下圖，會彈出對話框。
http://127.0.0.1:8080/tomatocc/?xss=<img src="null" onerror="alert(1)"/>
如果沒有彈出對話框，而是下面的報錯，那是因爲現在的瀏覽器已經將這種低級的xss攻擊加入到的自身防護中，不過ie瀏覽器還沒有，因此本人用的是ie瀏覽器進行操作。
我們可以看到，這種方式的攻擊前提是，必須將地址中的參數在頁面解析，如果不進行解析的話，那麼這種攻擊方式也就毫無意義。
而這種攻擊方式下，又包含三種方式
- 主動攻擊：上述的加img標籤就是主動攻擊。
- 引誘攻擊：如果參數值爲：
<p onclick="alert('點我了')">點我</p>，這種引誘用戶去點擊的攻擊，則爲引誘攻擊。
![在這裏插入圖片描述]()
3.iframe方式：如果參數值爲：<iframe src="//baidu.com/t.html"></iframe>，那麼將會直接將某個網站渲染到該頁面。
第二種：存儲型XSS攻擊
模擬存儲型XSS攻擊：
- 首先，假設這是一個交流論壇，其中一個html頁面中有一個允許我們留言的文本輸入框，並且，我們的留言將會在該網站中被其他人所看到。然後，我們將具有攻擊性的腳本寫到文本框中，然後提交到服務端。（該腳本的含義表示，獲取客戶端的cookie，併發送到指定地址，攻擊係數*****）。
![在這裏插入圖片描述]()
2）這個時候，後臺服務其已經將我們提交的數據存儲到數據庫中。
3）當其他用戶在自己計算機中登陸這個網站的時候，服務端會將我們之前寫入具有攻擊性的XSS腳本留言渲染到HTML頁面，從而將該用戶頁面中的cookie信息發送到我們預留的網站中。
4）接下來，我們就可以用這個人的cookie信息在該網站中“替代”他進行一系列的操作。
5 ) 到這裏一個簡單的存儲型XSS攻擊(cookie欺騙)就完成。
如果或許的有亂碼，可以在攻擊腳本中使用編碼
![在這裏插入圖片描述]()
針對js獲取cookie的解決方案：
在cookie中設置了HttpOnly屬性爲true，那麼通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊，具體一點的介紹請google進行搜索
> 存儲型XSS和反射型XSS的差別僅在於，`提交的代碼會存儲在服務器端（數據庫，內存，文件系統等）`，下次請求目標頁面時不用在提交XSS代碼。 由於這種方式和上述方式的差別僅僅在於數據存儲，前端代碼無需任何變更，後端在獲取連接值後，進行存儲數據庫，然後在去渲染，因此不做代碼演示。
XSS的防禦措施：
上面掌握了XSS的攻擊方式，下面就來學習防禦措施。
- 編碼
- 過濾
- 校正
編碼
對用戶輸入的數據進行HTML Entity編碼
過濾
移除用戶上傳的DOM屬性，如onerror等
移除用戶上傳的Style節點、Script節點、Ifram節點等。
校正
避免直接對HMTL Entity解碼
使用DOM Parse轉換，校正不匹配對的DOM標籤
2、基於文檔模型（DOM）造成的XSS攻擊
由於文檔的某些輸入、輸出點沒有做過濾，攻擊者可以插入JavaScript代碼，從而在客戶端執行，造成了XSS跨站腳本攻擊。
常見的可控對象：
- doucument.location
- doucument.URL
- document.URLUnencoded
- document.referrer
- window.location
- window.location.hash
模擬XSS攻擊，使用AJAX異步，實現蠕蟲攻擊
攻擊前提：
- A網站：具有留言功能，並將留言顯示在頁面的功能
- B網站：用來放置我們的XSS
1） 首先我們創建一個ajax異步攻擊腳本，
2） 創建一個B網站的首頁，並將上述js在該頁面重新寫一遍。（可以實現，B站主動攻擊效果。）
3） 首先我們刷新B網站，就可以主動的完成一次主動攻擊。將我們的攻擊腳本植入到服務端的數據庫中，接下來只要有用戶登陸A網站，都會從數據庫中獲取一次攻擊腳本，並且顯示在A網站中，這樣就是先XSS蠕蟲攻擊（不停的繁衍）。
針對上述XSS蠕蟲攻擊的解決方案：
- 對用戶的所有輸入點和輸出點進行特殊字符過濾。
- 過濾<、>、&、#、"、‘、//、/*等等符號
CSRF（跨站請求僞造）解決方案 - 驗證碼
- 驗證referer（請求頭的一部分，該頁面從哪個請求過來）1
- Toket2（主流解決方案）
- 設置跨域權限
【網絡安全學習】系列教程
《網絡安全學習》第一部分-----初識OWASP
《網絡安全學習》第二部分-----SQL注入學習
《網絡安全學習》第三部分-----XSS攻擊系列學習
《網絡安全學習》第四部分-----SSRF服務器端請求僞造
《網絡安全學習》第五部分-----遠程代碼執行漏洞
《網絡安全學習》 第六部分-----文件上傳漏洞
《網絡安全學習》 第七部分-----跨域資源共享（CORS）漏洞
《網絡安全學習》 第八部分-----《網絡安全學習》 第八部分-----越權漏洞詳解
《網絡安全學習》 第九部分----CSRF（跨站請求僞造）漏洞詳解
歡迎關注本人個人公衆號，交流更多技術信息
