一、XSS
（一）XSS 原理
Xss(cross-site scripting) 攻擊：全稱跨站腳本攻擊，通過向某網站寫入 js 腳本或插入惡意 html 標籤來實現攻擊。
比如：攻擊者在論壇中放一個看似安全的鏈接，騙取用戶點擊後，竊取 cookie 中的用戶私密信息；
或者攻擊者在論壇中加一個惡意表單，當用戶提交表單的時候，卻把信息傳送到攻擊者的服務器中，而不是用戶原本以爲的信任站點。
（二）主要危害
- 盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號
- 控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力
- 盜竊企業重要的具有商業價值的資料
- 非法轉賬
- 強制發送電子郵件
- 網站木馬
- 控制受害者機器向其它網站發起攻擊
（三）XSS 攻擊的類型
分爲存儲性（持久型）、反射型（非持久型）、基於 DOM
1、存儲性（持久型）
存儲型 XSS，也叫持久型 XSS，主要是將 XSS 代碼發送到服務器（不管是數據庫、內存還是文件系統等。），然後在下次請求頁面的時候就不用帶上 XSS 代碼了。用戶輸入的帶有惡意腳本的數據存儲在服務器端。當瀏覽器請求數據時，服務器返回腳本並執行。
最典型的就是留言板 XSS。用戶提交了一條包含 XSS 代碼的留言到數據庫。當目標用戶查詢留言時，那些留言的內容會從服務器解析之後加載出來。瀏覽器發現有 XSS 代碼，就當做正常的 HTML 和 JS 解析執行。XSS 攻擊就發生了。
常見的場景：
- 竊取用戶信息，如 cookie，token，賬號密碼等。例如：張三發了一篇帖子，李四進行回覆，但內容卻是一段 js 腳本，這篇帖子被他人瀏覽的時候就會中招，盜用用戶 cookie 等等操作
- 除了這種 hacker 還有個很慣用的伎倆，例如存儲型 XSS 生成一些誘人的圖片，文字（你懂的！），然後用戶去點擊的時候就可以執行某些壞事，竊取信息或者誘導到釣魚網站。
- 劫持流量實現惡意跳轉
用戶打開的網址，會默認跳轉至指定網站
2、反射型（非持久型）
反射型 XSS，也叫非持久型 XSS，把用戶輸入的數據 “反射” 給瀏覽器。通常是，用戶點擊鏈接或提交表單時，攻擊者向用戶訪問的網站注入惡意腳本。XSS 代碼出現在請求 URL 中，作爲參數提交到服務器，服務器解析並響應。響應結果中包含 XSS 代碼，最後瀏覽器解析並執行。從概念上可以看出，反射型 XSS 代碼是首先出現在 URL 中的，然後需要服務端解析，最後需要瀏覽器解析之後 XSS 代碼才能夠攻擊。
常見的場景：
-
在正常頁面上添加一個惡意鏈接。惡意鏈接的地址指向 localhost:8080。然後攻擊者有一個 node 服務來處理對 localhost:8080 的請求:
-
當用戶點擊惡意鏈接時，頁面跳轉到攻擊者預先準備的 localhost:8080 頁面，執行了 惡意的 js 腳本，產生攻擊。
舉例：
- Alice 給 Bob 發送一個惡意構造了 Web 的 URL。
- Bob 點擊並查看了這個 URL。
- 惡意頁面中的 JavaScript 打開一個具有漏洞的 HTML 頁面並將其安裝在 Bob 電腦上。
- 具有漏洞的 HTML 頁面包含了在 Bob 電腦本地域執行的 JavaScript。
- Alice 的惡意腳本可以在 Bob 的電腦上執行 Bob 所持有的權限下的命令。
3、基於 DOM
基於 DOM 的 XSS 是指通過惡意腳本修改頁面的 DOM 結構。是純粹發生在 客戶端的攻擊。
（四）XSS 防範方法
1. 內容安全策略 (CSP)
它是一個額外的安全層，用於檢測並削弱某些特定類型的攻擊，包括跨站腳本 (XSS) 和數據注入攻擊等。無論是數據盜取、網站內容污染還是散發惡意軟件，這些攻擊都是主要的手段。
其實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源可以加載和執行，等同於提供白名單。它的實現和執行全部由瀏覽器完成，開發者只需提供配置。
常見的策略：
- 入參字符過濾，在源頭控制，把輸入的一些不合法的東西都過濾掉，從而保證安全性。
- 出參進行編碼，如果源頭沒控制好，就得後期補救了：像一些常見的符號，如 <> 在輸出的時候要對其進行轉換編碼，這樣做瀏覽器是不會對該標籤進行解釋執行的，同時也不影響顯示效果。
- 入參長度限制，通過以上的案例我們不難發現 xss 攻擊要能達成往往需要較長的字符串，因此對於一些可以預期的輸入可以通過限制長度強制截斷來進行防禦。
兩種方法可以啓用 CSP：
- 設置 HTTP 的 Content-Security-Policy 頭部字段
- 設置網頁的<meta> 標籤。
2.HttpOnly 阻止 Cookie 劫持攻擊
服務器端 Set-Cookie 字段設置 HttpOnly 參數，這樣可以避免。這時候，客戶端的 Document.cookie API 無法訪問帶有 HttpOnly 標記的 Cookie, 但可以設置 cookie。
注：發起 XSS 的攻擊者既然可以通過注入惡意腳本獲取用戶的 Cookie 信息。所以，嚴格來說，HttpOnly 並非阻止 XSS 攻擊，而是能阻止 XSS 攻擊後的 Cookie 劫持攻擊。
二、CSRF
（一）原理
CSRF (Cross Site Request Forgery)，跨站請求僞造。
CSRF 攻擊是攻擊者藉助用戶的 Cookie 騙取服務器的信任，以用戶名義僞造請求發送給服務器。如：在請求的 url 後加入一些惡意的參數
換句話說，CSRF 就是利用用戶的登錄態發起惡意請求。
（二）攻擊過程
-
用戶 C 打開瀏覽器，訪問受信任網站 A，輸入用戶名和密碼請求登錄網站 A；
-
在用戶信息通過驗證後，網站 A 產生 Cookie 信息並返回給瀏覽器，此時用戶登錄網站 A 成功，可以正常發送請求到網站 A；
-
用戶未退出網站 A 之前，在同一瀏覽器中，打開一個新的標籤頁訪問網站 B；
-
網站 B 接收到用戶請求後，返回一些攻擊性代碼，併發出一個請求要求訪問站點 A；
-
瀏覽器在接收到這些攻擊性代碼後，根據網站 B 的請求，在用戶不知情的情況下攜帶 Cookie 信息，向網站 A 發出請求。網站 A 並不知道該請求其實是由 B 發起的，所以會根據用戶 C 的 Cookie 信息以 C 的權限處理該請求，導致來自網站 B 的惡意代碼被執行。
（三）場景
假設某銀行網站 A 以 GET 請求來發起轉賬操作，轉賬的地址爲 www.xxx.com/transfer.do?accountNum=l000l&money=10000，參數 accountNum 表示轉賬的賬戶，參數 money 表示轉賬金額。
而某大型論壇 B 上，一個惡意用戶上傳了一張圖片，而圖片的地址欄中填的並不是圖片的地址，而是前而所說的轉賬地址：<img src="http://www.xxx.com/transfer.do?accountNum=l000l&money=10000">
當你登錄網站 A 後，沒有及時登出，這時你訪問了論壇 B，不幸的事情發生了，你會發現你的賬號裏面少了 10000 塊…
注：上述只是舉例呦，轉賬怎麼可能是 get 請求，爲了保險，肯定是 post 請求，更何況銀行的交易付款會有登錄密碼和支付密碼等一系列屏障，流程複雜得多，安全係數也高得多
（四）防範措施
1、Referer Check
在 HTTP 頭中有一個字段叫做 Referer, 它記錄了該 HTTP 請求的來源地址。通過 Referer Check, 可以檢查是否來自合法的 “源”.
例如：
從 www.user.com 發起的刪帖請求，那麼 Referer 值是 http://www.user.com, 刪帖請求應該被允許；
而如果是從 CSRF 攻擊者構造的頁面 www.attack.com 發起刪帖請求， 那麼 Referer 值是 http://www.attack.com, 刪帖請求應該被阻止。
缺點：
Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對於 Referer 的具體實現可能有差別，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，從理論上來講，這樣並不安全。事實上，對於某些瀏覽器，比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值。如果 bank.example 網站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設爲以 bank.example 域名開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。
2、添加 token 驗證
在 HTTP 請求中以參數的形式加入一個隨機產生的 token，並在服務器端建立一個攔截器來驗證這個 token，若請求無 token 或者 token 不正確，則認爲可能是 CSRF 攻擊而拒絕該請求。
缺點：
在一個網站中，可以接受請求的地方非常多，要對於每一個請求都加上 token 是很麻煩的，並且很容易漏掉，通常使用的方法就是在每次頁面加載時，使用 javascript 遍歷整個 dom 樹，對於 dom 中所有的 a 和 form 標籤後加入 token。這樣可以解決大部分的請求，但是對於在頁面加載之後動態生成的 html 代碼，這種方法就沒有作用，還需要程序員在編碼時手動添加 token。
該方法還有一個缺點是難以保證 token 本身的安全。特別是在一些論壇之類支持用戶自己發表內容的網站，黑客可以在上面發佈自己個人網站的地址。由於系統也會在這個地址後面加上 token，黑客可以在自己的網站上得到這個 token，並馬上就可以發動 CSRF 攻擊。爲了避免這一點，系統可以在添加 token 的時候增加一個判斷，如果這個鏈接是鏈到自己本站的，就在後面添加 token，如果是通向外網則不加。不過，即使這個 csrftoken 不以參數的形式附加在請求之中，黑客的網站也同樣可以通過 Referer 來得到這個 token 值以發動 CSRF 攻擊。這也是一些用戶喜歡手動關閉瀏覽器 Referer 功能的原因。
3、驗證碼
驗證碼會強制用戶必須與應用進行交互，才能完成最終請求，但是也不能給網站所有的操作都加上驗證碼，所以只能作爲防禦 CSRF 的一種輔助手段，而不能作爲最終的解決方案
三、XSS 和 CSRF 區別：
- XSS 是利用用戶對指定網站的信任
- CSRF 是利用網站對用戶的信任
