最近在刷面經，遇到web安全問題總是一知半解，說不清楚，針對面試集中復習了web安全攻擊與防御手段，一直想總結下，今日開坑。
博主參加過幾次網絡安全比賽，除了MISC主要就是web方向，遇到過一些web安全漏洞問題，發現安全漏洞也區分前后端。
首先我們要區分一下web的前后端安全問題：
前端安全：發生在瀏覽器、單頁面應用、Web頁面的安全問題，比如：跨站腳本攻擊XSS、CSRF攻擊、點擊劫持、iframe帶來的風險、不安全的第三方依賴包。
后端安全：發生在后端服務器、應用、服務當中的安全問題，比如SQL注入漏洞。
前端安全攻擊手段
（一）XSS（Cross-Site Scripting），跨站腳本攻擊。
一種代碼注入方式, 為了與 CSS 區分所以被稱作 XSS，其注入方式很簡單包括但不限於 JavaScript / VBScript / CSS / Flash 等。原理：惡意攻擊者在web頁面中插入一些惡意代碼。當目標網站、目標用戶瀏覽器渲染HTML文檔的過程中，出現了不被預期的腳本指令並執行時，XSS發生，從而達到惡意攻擊用戶的目的。
跨站腳本攻擊有可能造成以下影響:
- 利用虛假輸入表單騙取用戶個人信息。
- 利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助攻擊者發送惡意請求。
- 顯示偽造的文章或圖片。
根據攻擊的來源，XSS 攻擊可分為反射型、存儲型和 DOM 型三種：
反射型XSS：發出請求時，XSS代碼出現在URL中，作為輸入提交到服務器端，服務器端解析后響應，XSS代碼隨響應內容一起傳回給瀏覽器，最后瀏覽器解析執行XSS代碼。這個過程像一次反射，故叫反射型XSS。
1、攻擊者給用戶發送一個惡意構造了Web的URL。
2、用戶點擊並查看這個URL時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器
3、用戶獲取到一個具有漏洞的HTML頁面並顯示在本地瀏覽器中，惡意代碼也被執行。
4、漏洞HTML頁面執行惡意JavaScript腳本，將用戶信息盜取發送給攻擊者，或者篡改用戶看到的數據，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
1. Web 頁面渲染的所有內容或者渲染的數據都必須來自於服務端。
2. 盡量不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數據直接渲染。
3. 盡量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可執行字符串的方法。
4. 如果做不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字符串參數做 escape 轉義。
5. 前端渲染的時候對任何的字段都需要做 escape 轉義編碼。
function escape(str) { str = str.replace(/&/g, '&') str = str.replace(/</g, '<') str = str.replace(/>/g, '>') str = str.replace(/"/g, '&quto;') str = str.replace(/'/g, ''') str = str.replace(/`/g, '`') str = str.replace(/\//g, '/') return str }
存儲型XSS：存儲型XSS和反射型XSS的差別僅在於，提交的代碼會存儲在服務器端，下次請求目標頁面時不用再提交XSS代碼，這樣，每一個訪問特定網頁的用戶都會被攻擊。
持久型 XSS 漏洞，一般存在於 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面獲得后端從數據庫中讀出的注入代碼時，恰好將其渲染執行。具體攻擊過程如下：
1、攻擊者將惡意代碼提交到目標網站的數據庫中。
2、用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
3、用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
4、惡意代碼竊取用戶數據並發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
攻擊成功需要同時滿足以下幾個條件：
- POST 請求提交表單后端沒做轉義直接入庫。
- 后端從數據庫中取出數據沒做轉義直接輸出給前端。
- 前端拿到后端數據沒做轉義直接渲染成 DOM。
存儲型XSS防御：
1. 后端需要對提交的數據進行過濾。
2. 前端也可以做一下處理方式，比如對script標簽，將特殊字符替換成HTML編碼這些等。
3. 純前端渲，把代碼和數據分隔開。渲染過程：瀏覽器先加載一個靜態 HTML，此 HTML 中不包含任何跟業務相關的數據；然后瀏覽器執行 HTML 中的 JavaScript；JavaScript 通過 Ajax 加載業務數據，調用 DOM API 更新到頁面上。
在純前端渲染中，我們會明確的告訴瀏覽器：下面要設置的內容是文本（.innerText），還是屬性（.setAttribute），還是樣式（.style）等等。瀏覽器不會被輕易的被欺騙，執行預期外的代碼了。
但純前端渲染還需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，請參考下文”預防 DOM 型 XSS 攻擊“部分）。
在很多內部、管理系統中，采用純前端渲染是非常合適的。但對於性能要求高，或有 SEO 需求的頁面，我們仍然要面對拼接 HTML 的問題。
DOM型XSS：DOM型XSS是基於DOM文檔對象模型的一種漏洞,通過 HTML DOM，通過植入js代碼，造成dom的更改，因此造成了XSS-DOM漏洞，所以DOM類型的XSS可能是反射型也可能是儲存型。
DOM 型 XSS 跟前兩種 XSS 的區別：DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端 JavaScript 自身的安全漏洞，而其他兩種 XSS 都屬於服務端的安全漏洞。攻擊過程如下：
- 攻擊者構造出特殊的 URL，其中包含惡意代碼。
- 用戶打開帶有惡意代碼的 URL。
- 用戶瀏覽器接收到響應后解析執行，前端 JavaScript 取出 URL 中的惡意代碼並執行。
- 惡意代碼竊取用戶數據並發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
DOM型XSS防御：
1、在使用 .innerHTML、.outerHTML、document.write() 時要特別小心，不要把不可信的數據作為 HTML 插到頁面上，而應盡量使用 .textContent、.setAttribute() 等。
2、在使用 .innerHTML、.outerHTML、document.write() 時要特別小心，不要把不可信的數據作為 HTML 插到頁面上，而應盡量使用 .textContent、.setAttribute() 等。
3、在使用 .innerHTML、.outerHTML、document.write() 時要特別小心，不要把不可信的數據作為 HTML 插到頁面上，而應盡量使用 .textContent、.setAttribute() 等。
4、Http Only cookie：預防XSS攻擊竊取用戶cookie最有效的防御手段。Web應用程序在設置cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。
5、對產品輸入要求格式嚴謹檢查過濾。
其他防御方式：
CSP（ Content-Security-Policy）
CSP 本質上就是建立白名單，開發者明確告訴瀏覽器哪些外部資源可以加載和執行。我們只需要配置規則，如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來盡量減少 XSS 攻擊。
通常可以通過兩種方式來開啟 CSP：
- 設置 HTTP Header 中的 Content-Security-Policy
- 設置 meta 標簽的方式
- 只允許加載本站資源
Content-Security-Policy: default-src 'self'
- 只允許加載 HTTPS 協議圖片
Content-Security-Policy: img-src https://*
- 允許加載任何來源框架
Content-Security-Policy: child-src 'none'
（二）CSRF攻擊（Cross-Site Request Forgeries），跨站點請求偽造。
它利用用戶已登錄的身份，在用戶毫不知情的情況下，以用戶的名義完成非法操作。指攻擊者通過設置好的陷阱，強制對已完成認證的用戶進行非預期的個人信息或設定信息等某些狀態更新，屬於被動攻擊。
一個典型的CSRF攻擊有着如下的流程：
- 受害者登錄
a.com，並保留了登錄憑證（Cookie） - 攻擊者引誘受害者訪問了
b.com b.com向a.com發送了一個請求：a.com/act=xx瀏覽器會默認攜帶a.com的Cookie- a.com接收到請求后，對請求進行驗證，並確認是受害者的憑證，誤以為是受害者自己發送的請求
- a.com以受害者的名義執行了act=xx
- 攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者，讓a.com執行了自己定義的操作
CSRF攻擊防御：
1、驗證 HTTP Referer 字段。
2、不讓第三方網站訪問到用戶 Cookie。
3、使用 token驗證。
4、顯示驗證方式：添加驗證碼、密碼等。
5、涉及到數據修改操作嚴格使用 post 請求而不是 get 請求。
1) Referer Check
HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求時，一般會帶上Referer信息告訴服務器是從哪個頁面鏈接過來的，服務器籍此可以獲得一些信息用於處理。可以通過檢查請求的來源來防御CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。
但在某些情況下如從https跳轉到http，瀏覽器處於安全考慮，不會發送referer，服務器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那么攻擊者可以在其他網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出於以上原因，無法完全依賴Referer Check作為防御CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。
2) SameSite
可以對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨着跨域請求發送，可以很大程度減少 CSRF 的攻擊，但是該屬性目前並不是所有瀏覽器都兼容。
3) Anti CSRF Token
目前比較完善的解決方案是加入Anti-CSRF-Token。即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，並在服務器建立一個攔截器來驗證這個token。服務器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。
這種方法相比Referer檢查要安全很多，token可以在用戶登陸后產生並放於session或cookie中，然后在每次請求時服務器把token從session或cookie中拿出，與本次請求中的token 進行比對。由於token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token后，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出現token錯誤。
4) 驗證碼
應用程序和用戶進行交互過程中，特別是賬戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗，網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業務點設置驗證碼。
（三）點擊劫持攻擊
點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌套的方式嵌入自己的網頁中，並將 iframe 設置為透明，在頁面中透出一個按鈕誘導用戶點擊。即攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，然后誘使用戶在網頁上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面。通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。
網絡劫持一般分為兩種:
-
DNS劫持: (輸入京東被強制跳轉到淘寶這就屬於dns劫持)
- DNS強制解析: 通過修改運營商的本地DNS記錄，來引導用戶流量到緩存服務器；
- 302跳轉的方式: 通過監控網絡出口的流量，分析判斷哪些內容是可以進行劫持處理的,再對劫持的內存發起302跳轉的回復，引導用戶獲取內容。
-
HTTP劫持: (訪問谷歌但是一直有貪玩藍月的廣告)，由於http明文傳輸，運營商會修改你的http響應內容(即加廣告)。
點擊劫持攻擊防御：
DNS劫持由於涉嫌違法,已經被監管起來,現在很少會有DNS劫持,而http劫持依然非常盛行。最有效的辦法就是全站HTTPS,將HTTP加密,這使得運營商無法獲取明文,就無法劫持你的響應內容。
1、X-Frame-Options瀏覽器機制：X-Frame-Options HTTP響應頭是用來給瀏覽器指示允許一個頁面能否在<frame>、<iframe>、<object>中展現的標記，有三個可選的值：DENY：瀏覽器會拒絕當前頁面加載任何frame頁面（即使是相同域名的頁面也不允許）SAMEORIGIN：允許加載frame頁面，但是frame頁面的地址只能為同源域名下的頁面ALLOW-FROM：可以加載指定來源的frame頁面（可以定義frame頁面的地址）但這個缺陷就是chrome、Safari是不支持ALLOW-FROM語法！
2、使用認證碼認證用戶：點擊劫持漏洞通過偽造網站界面進行攻擊，網站開發人員可以通過認證碼識別用戶，確定是用戶發出的點擊命令才執行相應操作。識別用戶的方法中最有效的方法是認證碼認證。例如，在網站上廣泛存在的發帖認證碼，要求用戶輸入圖形中的字符，輸入某些圖形的特征等。
3、 使用 FrameBusting 代碼：使用 JavaScript 腳本阻止惡意網站載入網頁。如果檢測到網頁被非法網頁載入，就執行自動跳轉功能。如果用戶瀏覽器禁用JavaScript腳本，那么FrameBusting代碼也無法正常運行。所以，該類代碼只能提供部分保障功能。
<head> <style id="click-jack"> html { display: none !important; } </style> </head> <body> <script> if (self == top) { var style = document.getElementById('click-jack') document.body.removeChild(style) } else { top.location = self.location } </script> </body>
（四）iframe帶來的風險
iframe中的內容是由第三方來提供的，默認情況下他們不受我們的控制，他們可以在iframe中運行JavaScirpt腳本、Flash插件、彈出對話框等等，這可能會破壞前端用戶體驗。frame本身不受我們控制，那么如果iframe中的域名因為過期而被惡意攻擊者搶注，或者第三方被黑客攻破，iframe中的內容被替換掉了，從而利用用戶瀏覽器中的安全漏洞下載安裝木馬、惡意勒索軟件等等。
iframe防御：
iframe有了一個叫做sandbox的安全屬性，通過它可以對iframe的行為進行各種限制，在 iframe 元素中添加上這個關鍵詞就行，另外，sandbox也提供了豐富的配置參數，我們可以進行較為細粒度的控制。一些典型的參數如下：
allow-forms：允許iframe中提交form表單
allow-popups：允許iframe中彈出新的窗口或者標簽頁（例如，window.open()，showModalDialog()，target=”_blank”等等）
allow-scripts：允許iframe中執行JavaScript
allow-same-origin：允許iframe中的網頁開啟同源策略
如果你只是添加上這個屬性而保持屬性值為空，那么瀏覽器將會對 iframe 實施史上最嚴厲的調控限制。
（五）不安全的第三方依賴
項目里面使用了很多第三方的依賴，不論應用自己的代碼的安全性有多高，如果這些來自第三方的代碼有安全漏洞，那么對應用整體的安全性依然會造成嚴峻的挑戰。jQuery就存在多個已知安全漏洞，Node.js也有一些已知的安全漏洞。
第三方依賴包防御：
手動檢查這些第三方代碼有沒有安全問題是個苦差事，主要是因為應用依賴的這些組件數量眾多，手工檢查太耗時，有自動化的工具可以使用，比如NSP(Node Security Platform)，Snyk、sonarQubej檢測工具等等。
VUE對前端安全的處理：VUE的安全措施
當然還存在很多別的攻擊手段，比如：
Https 也可能存在的風險（強制讓HTTPS降級回HTTP，從而繼續進行中間人攻擊）
本地存儲數據泄露（盡可能不在前端存儲任何敏感、機密的數據）
cdn劫持（攻擊者劫持了CDN，或者對CDN中的資源進行了污染）
后端安全攻擊手段
SQL注入
SQL注入是一種常見的Web安全漏洞，攻擊者利用這個漏洞，可以訪問或修改數據，或者利用潛在的數據庫漏洞進行攻擊。