瀏覽器常見攻擊方式（XSS和CSRF）

常見的瀏覽器攻擊分爲兩種，一種爲XSS（跨站腳本攻擊），另外一種則爲CSRF（跨站請求僞造）。

XSS（跨站腳本攻擊）

定義

XSS 全稱是 Cross Site Scripting，爲了與「CSS」區分開來，故簡稱 XSS，翻譯過來就是「跨站腳本」。XSS 攻擊是指黑客往 HTML 文件中或者 DOM 中注入惡意腳本，從而在用戶瀏覽頁面時利用注入的惡意腳本對用戶實施攻擊的一種手段。

存在緣由

瀏覽器爲了在安全和自由之間找到一個平衡點。支持了頁面中的引用第三方資源和 跨域資源共享（CORS），這樣作帶來了不少安全問題，其中最典型的就是 XSS 攻擊。

攻擊方式

• 存儲型 XSS 攻擊

1. 首先黑客利用站點漏洞將一段惡意 JavaScript 代碼提交到網站的數據庫中；
2. 而後用戶向網站請求包含了惡意 JavaScript 腳本的頁面；
3. 當用戶瀏覽該頁面的時候，惡意腳本就會執行

• 反射型 XSS 攻擊

1. 惡意 JavaScript 腳本屬於用戶發送給網站請求中的一部分。
2. 隨後網站又把惡意 JavaScript 腳本返回給用戶。
3. 惡意 JavaScript 腳本就能夠在用戶頁面中被執行

• 基於 DOM 的 XSS 攻擊

　　基於 DOM 的 XSS 攻擊是不牽涉到頁面 Web 服務器的。黑客經過各類手段將惡意腳本注入用戶的頁面中，好比經過網絡劫持在頁面傳輸過程當中修改 HTML 頁面的內容，這種劫持類型不少，有經過 WiFi 路由器劫持的，有經過本地惡意軟件來劫持的，它們的共同點是在 Web 資源傳輸過程或者在用戶使用頁面的過程當中修改 Web 頁面的數據。

危害

• 竊取 Cookie 信息

　　竊取到Cookie後，就能夠在其餘電腦上模擬用戶的登陸。

• 監聽用戶行爲

　　可使用「addEventListener」接口來監聽鍵盤事件

• 修改 DOM

　　能夠經過修改 DOM 僞造假的登陸窗口，用來欺騙用戶輸入用戶名和密碼等信息

防護

• 服務器對輸入腳本進行過濾或轉碼
• 充分利用 CSP

　　實施嚴格的 CSP 能夠有效地防範 XSS 攻擊，具體來說 CSP 有以下幾個功能：

1. 限制加載其餘域下的資源文件
2. 禁止向第三方域提交數據，這樣用戶數據也不會外泄；
3. 禁止執行內聯腳本和未受權的腳本；
4. 還提供了上報機制，這樣能夠幫助咱們儘快發現有哪些 XSS 攻擊，以便儘快修復問題。

• 防止Cookie被盜用,使用 HttpOnly 屬性

　　使用 HttpOnly 標記的 Cookie 只能使用在 HTTP 請求過程當中，因此沒法經過 JavaScript 來讀取這段 Cookie。

 

CSRF

定義

CSRF 英文全稱是 Cross-site request forgery，是指黑客引誘用戶打開黑客的網站，在黑客的網站中，利用用戶的登陸狀態發起的跨站請求。簡單來說，CSRF 攻擊就是利用了用戶的登陸狀態，並經過第三方的站點來作一些壞事。並且CSRF 攻擊並不須要將惡意代碼注入用戶的頁面，僅僅是利用服務器的漏洞和用戶的登陸狀態來實施攻擊

存在緣由

利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求自己是用戶自願發出的。

攻擊方式

• 自動發起 Get 請求
• 自動發起 POST 請求
• 引誘用戶點擊連接

　　這幾種攻擊方式的前提

• 目標站點必定要有 CSRF 漏洞；
• 用戶要登陸過目標站點，而且在瀏覽器上保持有該站點的登陸狀態；
• 須要用戶打開一個第三方站點，能夠是黑客的站點，也能夠是一些論壇。

具體流程參考下圖

危害

利用登錄態，能夠作任何你登錄某網站後的操做，例如轉帳，更改信息等等

防護

• 充分利用好 Cookie 的 SameSite 屬性

Cookie 的SameSite屬性用來限制第三方 Cookie，從而減小安全風險。他能夠設置三個值

1.Strict

瀏覽器會徹底禁止第三方 Cookie，跨站點時，任何狀況下都不會發送 Cookie。換言之，只有當前網頁的 URL 與請求目標一致，纔會帶上 Cookie。

2.Lax

在跨站點的狀況下Lax規則稍稍放寬，大多數狀況也是不發送第三方 Cookie，可是導航到目標網址的 Get 請求除外。包括連接，預加載請求，GET 表單。而若是在第三方站點中使用 Post 方法，或者經過 img、iframe 等標籤加載的 URL，這些場景都不會攜帶 Cookie。

3.None

在任何狀況下都會發送 Cookie 數據，最新版本的Chrome中Lax變爲默認設置。這時，網站能夠選擇顯式關閉SameSite屬性，將其設爲None。不過，前提是必須同時設置Secure屬性（Cookie 只能經過 HTTPS 協議發送），不然無效。

更多：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-Cookie/SameSite

• 驗證請求的來源站點

　　根據HTTP 請求頭中的 Referer 和 Origin 屬性在服務器端驗證請求來源的站點。Referer和Origin 都是 HTTP 請求頭中的一個字段，

1. Referer記錄了該 HTTP 請求的來源地址。
2. Origin屬性只包含了域名信息，並無包含具體的 URL 路徑。
3. 服務器的策略是優先判斷 Origin，若是請求頭中沒有包含 Origin 屬性，再根據實際狀況判斷是否使用 Referer 值。

• CSRF Token

1. 在瀏覽器向服務器發起請求時，服務器生成一個 CSRF Token。CSRF Token 其實就是服務器生成的字符串，而後將該字符串植入到返回的頁面中。
2. 在瀏覽器端若是要發起某些請求，那麼須要帶上頁面中的 CSRF Token，而後服務器會驗證該 Token 是否合法。若是是從第三方站點發出的請求，那麼將沒法獲取到 CSRF Token 的值，因此即便發出了請求，服務器也會由於 CSRF Token 不正確而拒絕請求。

語雀文檔地址

https://www.yuque.com/suihangadam/liulanqi

 參考

極客時間瀏覽器原理與實踐

https://www.cnblogs.com/itsuibi/p/10752868.html

MDN： https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-Cookie/SameSite