想要求职Web安全相关的岗位，你就必须要懂的知识
隨著互聯網的發展，各種Web應用變得越來越復雜，滿足了用戶的各種需求的同時，各種網絡安全問題也接踵而至。作為前端工程師也逃不開這個問題，今天一起看一看Web前端有哪些安全問題以及我們如何去檢測和防范這些問題。（非前端的攻擊如SQL注入，DDOS攻擊等本文不會討論）
QQ郵箱、新浪微博、YouTube、WordPress 和 百度 等知名網站都曾遭遇攻擊，如果你從未有過安全方面的問題，不是因為你所開發的網站很安全，更大的可能是你的網站的流量非常低或者沒有攻擊的價值。
1. XSS攻擊
XSS(Cross-Site Scripting，跨站腳本攻擊)是一種代碼注入攻擊。攻擊者在目標網站上注入惡意代碼，當被攻擊者登陸網站時就會執行這些惡意代碼，這些腳本可以讀取 cookie，session tokens，或者其它敏感的網站信息，對用戶進行釣魚欺詐，甚至發起蠕蟲攻擊等。
XSS 的本質是：惡意代碼未經過濾，與網站正常的代碼混在一起；瀏覽器無法分辨哪些腳本是可信的，導致惡意腳本被執行。由于直接在用戶的終端執行，惡意代碼能夠直接獲取用戶的信息，利用這些信息冒充用戶向網站發起攻擊者定義的請求。
根據攻擊的來源，XSS攻擊可以分為存儲型(持久性)、反射型(非持久型)和DOM型三種。下面我們來詳細了解一下這三種XSS攻擊：
1.1 反射型XSS
當用戶點擊一個惡意鏈接，或者提交一個表單，或者進入一個惡意網站時，注入腳本進入被攻擊者的網站。Web服務器將注入腳本，比如一個錯誤信息，搜索結果等，未進行過濾直接返回到用戶的瀏覽器上。
反射型 XSS 的攻擊步驟：
攻擊者構造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
反射型 XSS 漏洞常見于通過 URL 傳遞參數的功能，如網站搜索、跳轉等。由于需要用戶主動打開惡意的 URL 才能生效，攻擊者往往會結合多種手段誘導用戶點擊。
POST 的內容也可以觸發反射型 XSS，只不過其觸發條件比較苛刻（需要構造表單提交頁面，并引導用戶點擊），所以非常少見。
1.2 DOM 型 XSS
DOM 型 XSS 攻擊，實際上就是前端 JavaScript 代碼不夠嚴謹，把不可信的內容插入到了頁面。在使用 .innerHTML、.outerHTML、.appendChild、document.write()等API時要特別小心，不要把不可信的數據作為 HTML 插到頁面上，盡量使用 .innerText、.textContent、.setAttribute() 等。
DOM 型 XSS 的攻擊步驟：
攻擊者構造出特殊數據，其中包含惡意代碼。
用戶瀏覽器執行了惡意代碼。
惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
如何防范 DOM 型 XSS 攻擊
防范 DOM 型 XSS 攻擊的核心就是對輸入內容進行轉義(DOM
中的內聯事件監聽器和鏈接跳轉都能把字符串作為代碼運行，需要對其內容進行檢查)。
對于url鏈接(例如圖片的src屬性)，那么直接使用 encodeURIComponent 來轉義。
非url，我們可以這樣進行編碼：
> return str.replace(/"/g, '"') > .replace(/'/g, ''') > .replace(/</g, '<') > .replace(/>/g, '>'); } ```DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞。
1.3 存儲型XSS
惡意腳本永久存儲在目標服務器上。當瀏覽器請求數據時，腳本從服務器傳回并執行，影響范圍比反射型和DOM型XSS更大。存儲型XSS攻擊的原因仍然是沒有做好數據過濾：前端提交數據至服務端時，沒有做好過濾；服務端在接受到數據時，在存儲之前，沒有做過濾；前端從服務端請求到數據，沒有過濾輸出。
存儲型 XSS 的攻擊步驟：
攻擊者將惡意代碼提交到目標網站的數據庫中。
用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
這種攻擊常見于帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。
如何防范存儲型XSS攻擊：
前端數據傳遞給服務器之前，先轉義/過濾(防范不了抓包修改數據的情況)
服務器接收到數據，在存儲到數據庫之前，進行轉義/過濾
前端接收到服務器傳遞過來的數據，在展示到頁面前，先進行轉義/過濾
除了謹慎的轉義，我們還需要其他一些手段來防范XSS攻擊:
1.Content Security Policy
在服務端使用 HTTP的 Content-Security-Policy 頭部來指定策略，或者在前端設置 meta 標簽。
2.輸入內容長度控制
對于不受信任的輸入，都應該限定一個合理的長度。雖然無法完全防止 XSS 發生，但可以增加 XSS 攻擊的難度。
3.輸入內容限制
對于部分輸入，可以限定不能包含特殊字符或者僅能輸入數字等。
4.其他安全措施
HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入后也無法竊取此 Cookie。
驗證碼：防止腳本冒充用戶提交危險操作。
XSS 檢測
讀到這兒，相信大家已經知道了什么是XSS攻擊，XSS攻擊的類型，以及如何去防范XSS攻擊。但是有一個非常重要的問題是：我們如何去檢測XSS攻擊，怎么知道自己的頁面是否存在XSS漏洞？
很多大公司，都有專門的安全部門負責這個工作，但是如果沒有安全部門，作為開發者本身，該如何去檢測呢？
1.使用通用 XSS 攻擊字串手動檢測 XSS 漏洞
如: jaVasCript:/-//*\/’/"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/–!>\x3csVg/<sVg/oNloAd=alert()//>\x3e
能夠檢測到存在于 HTML 屬性、HTML 文字內容、HTML 注釋、跳轉鏈接、內聯 JavaScript 字符串、內聯 CSS 樣式表等多種上下文中的 XSS 漏洞，也能檢測 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能繞過一些 XSS 過濾器。
<img src=1 onerror=alert(1)>2.使用第三方工具進行掃描
CSRF（Cross-site request forgery）跨站請求偽造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的注冊憑證，繞過后臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。
典型的CSRF攻擊流程：
受害者登錄A站點，并保留了登錄憑證（Cookie）。
攻擊者誘導受害者訪問了站點B。
站點B向站點A發送了一個請求，瀏覽器會默認攜帶站點A的Cookie信息。
站點A接收到請求后，對請求進行驗證，并確認是受害者的憑證，誤以為是無辜的受害者發送的請求。
站點A以受害者的名義執行了站點B的請求。
攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者完成了攻擊。
一圖勝千言：
CSRF的特點：
攻擊通常在第三方網站發起，如圖上的站點B，站點A無法防止攻擊發生。
攻擊利用受害者在被攻擊網站的登錄憑證，冒充受害者提交操作；并不會去獲取cookie信息(cookie有同源策略)
跨站請求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等(來源不明的鏈接，不要點擊)
運行代碼，更直觀了解一下
用戶 loki 銀行存款 10W。
用戶 yvette 銀行存款 1000。
我們來看看 yvette 如何通過 CSRF 攻擊，將 loki 的錢偷偷轉到自己的賬戶中，并根據提示，查看如何去防御CSRF攻擊。
**CSRF 攻擊防御**驗證碼能夠防御CSRF攻擊，但是我們不可能每一次交互都需要驗證碼，否則用戶的體驗會非常差，但是我們可以在轉賬，交易等操作時，增加驗證碼，確保我們的賬戶安全。
Referer 可以作為一種輔助手段，來判斷請求的來源是否是安全的，但是鑒于 Referer 本身是可以被修改的，因為不能僅依賴于 Referer
CSRF攻擊之所以能夠成功，是因為服務器誤把攻擊者發送的請求當成了用戶自己的請求。那么我們可以要求所有的用戶請求都攜帶一個CSRF攻擊者無法獲取到的Token。服務器通過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開。跟驗證碼類似，只是用戶無感知。
- 服務端給用戶生成一個token，加密后傳遞給用戶
- 用戶在提交請求時，需要攜帶這個token
- 服務端驗證token是否正確
為了從源頭上解決這個問題，Google起草了一份草案來改進HTTP協議，為Set-Cookie響應頭新增Samesite屬性，它用來標明這個 Cookie是個“同站 Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite 有兩個屬性值，分別是 Strict 和 Lax。
部署簡單，并能有效防御CSRF攻擊，但是存在兼容性問題。
Samesite=StrictSamesite=Strict 被稱為是嚴格模式,表明這個 Cookie 在任何情況都不可能作為第三方的 Cookie，有能力阻止所有CSRF攻擊。此時，我們在B站點下發起對A站點的任何請求，A站點的 Cookie 都不會包含在cookie請求頭中。
Samesite=Lax
Samesite=Lax 被稱為是寬松模式，與 Strict 相比，放寬了限制，允許發送安全 HTTP 方法帶上 Cookie，如 Get / OPTIONS 、HEAD 請求.
但是不安全 HTTP 方法，如： POST, PUT, DELETE 請求時，不能作為第三方鏈接的 Cookie
為了更好的防御CSRF攻擊，我們可以組合使用以上防御手段。
點擊劫持是指在一個Web頁面中隱藏了一個透明的iframe，用外層假頁面誘導用戶點擊，實際上是在隱藏的frame上觸發了點擊事件進行一些用戶不知情的操作。
典型點擊劫持攻擊流程
攻擊者構建了一個非常有吸引力的網頁【不知道哪些內容對你們來說有吸引力，我就不寫頁面了，偷個懶】
將被攻擊的頁面放置在當前頁面的 iframe 中
使用樣式將 iframe 疊加到非常有吸引力內容的上方
將iframe設置為100%透明
你被誘導點擊了網頁內容，你以為你點擊的是*，而實際上，你成功被攻擊了。
點擊劫持防御
Frame busting
if ( top.location != window.location ){top.location = window.location}需要注意的是: HTML5中iframe的 sandbox 屬性、IE中iframe的security 屬性等，都可以限制iframe頁面中的JavaScript腳本執行，從而可以使得 frame busting 失效。
X-FRAME-OPTIONS是微軟提出的一個http頭，專門用來防御利用iframe嵌套的點擊劫持攻擊。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。
可以設置為以下值:
DENY: 拒絕任何域加載
SAMEORIGIN: 允許同源域下加載
ALLOW-FROM: 可以定義允許frame加載的頁面地址
URL 跳轉漏洞是指后臺服務器在告知瀏覽器跳轉時，未對客戶端傳入的重定向地址進行合法性校驗，導致用戶瀏覽器跳轉到釣魚頁面的一種漏洞。
URL跳轉一般有以下幾種實現方式
·Header頭跳轉
·Javascript跳轉
·META標簽跳轉
URL跳轉漏洞防御
之所以會出現跳轉 URL 漏洞，就是因為服務端沒有對客戶端傳遞的跳轉地址進行合法性校驗，所以，預防這種攻擊的方式，就是對客戶端傳遞過來的跳轉 URL 進行校驗。
1.referer的限制
如果確定傳遞URL參數進入的來源，我們可以通過該方式實現安全限制，保證該URL的有效性，避免惡意用戶自己生成跳轉鏈接
2.加入有效性驗證Token
保證所有生成的鏈接都是來自于可信域，通過在生成的鏈接里加入用戶不可控的token對生成的鏈接進行校驗，可以避免用戶生成自己的惡意鏈接從而被利用。
安全掃描工具
上面我們介紹了幾種常見的前端安全漏洞，也了解一些防范措施，那么我們如何發現自己網站的安全問題呢？沒有安全部門的公司可以考慮下面幾款開源掃碼工具：
Arachni是基于Ruby的開源，功能全面，高性能的漏洞掃描框架，Arachni提供簡單快捷的掃描方式，只需要輸入目標網站的網址即可開始掃描。它可以通過分析在掃描過程中獲得的信息，來評估漏洞識別的準確性和避免誤判。
Arachni默認集成大量的檢測工具，可以實施 代碼注入、CSRF、文件包含檢測、SQL注入、命令行注入、路徑遍歷等各種攻擊。
同時，它還提供了各種插件，可以實現表單爆破、HTTP爆破、防火墻探測等功能。
針對大型網站，該工具支持會話保持、瀏覽器集群、快照等功能，幫助用戶更好實施滲透測試。
Mozilla HTTP Observatory，是Mozilla最近發布的一款名為Observatory的網站安全分析工具，意在鼓勵開發者和系統管理員增強自己網站的安全配置。用法非常簡單：輸入網站URL，即可訪問并分析網站HTTP標頭，隨后可針對網站安全性提供數字形式的分數和字母代表的安全級別。
檢查的主要范圍包括：
Cookie
跨源資源共享（CORS）
內容安全策略（CSP）
HTTP公鑰固定（Public Key Pinning）
HTTP嚴格安全傳輸（HSTS）狀態
是否存在HTTP到HTTPs的自動重定向
子資源完整性（Subresource Integrity）
X-Frame-OptionsX-XSS-ProtectionW3af是一個基于Python的Web應用安全掃描器。可幫助開發人員，有助于開發人員和測試人員識別Web應用程序中的漏洞。
掃描器能夠識別200多個漏洞，包括跨站點腳本、SQL注入和操作系統命令。
總結
以上是生活随笔為你收集整理的想要求职Web安全相关的岗位，你就必须要懂的知识的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 这安全测试的面试题目也太简单了吧，分分钟
- 下一篇： 透露抖音、腾讯、阿里、美团招开发岗位硬核