【面試篇】寒冬求職之你必需要懂的Web安全

隨着互聯網的發展，各類Web應用變得愈來愈複雜，知足了用戶的各類需求的同時，各類網絡安全問題也接踵而至。做爲前端工程師的咱們也逃不開這個問題，今天一塊兒看一看Web前端有哪些安全問題以及咱們如何去檢測和防範這些問題。非前端的攻擊本文不會討論(如SQL注入，DDOS攻擊等)，畢竟後端也非本人擅長的領域。

QQ郵箱、新浪微博、YouTube、WordPress 和 百度 等知名網站都曾遭遇攻擊，若是你從未有過安全方面的問題，不是由於你所開發的網站很安全，更大的多是你的網站的流量很是低或者沒有攻擊的價值。

本文主要討論如下幾種攻擊方式: XSS攻擊、CSRF攻擊、點擊劫持以及URL跳轉漏洞。

<font style="color: #ff302c"> 但願你們在閱讀完本文以後，可以很好的回答如下幾個面試題。</font>

1.前端有哪些攻擊方式？

2.什麼是XSS攻擊？XSS攻擊有幾種類型？若是防範XSS攻擊？

3.什麼是CSRF攻擊？如何防範CSRF攻擊

4.如何檢測網站是否安全？

在開始以前，建議你們先clone代碼，我爲你們準備好了示例代碼，而且寫了詳細的註釋，你們能夠對照代碼來理解每一種攻擊以及如何去防範攻擊，畢竟看再多的文字，都不如實操。(Readme中詳細得寫了操做步驟)：https://github.com/YvetteLau/...

更多優質文章可戳: https://github.com/YvetteLau/...

1. XSS攻擊

XSS(Cross-Site Scripting，跨站腳本攻擊)是一種代碼注入攻擊。攻擊者在目標網站上注入惡意代碼，當被攻擊者登錄網站時就會執行這些惡意代碼，這些腳本能夠讀取 cookie，session tokens，或者其它敏感的網站信息，對用戶進行釣魚欺詐，甚至發起蠕蟲攻擊等。

XSS 的本質是：惡意代碼未通過濾，與網站正常的代碼混在一塊兒；瀏覽器沒法分辨哪些腳本是可信的，致使惡意腳本被執行。因爲直接在用戶的終端執行，惡意代碼可以直接獲取用戶的信息，利用這些信息冒充用戶向網站發起攻擊者定義的請求。

XSS分類

根據攻擊的來源，XSS攻擊能夠分爲存儲型(持久性)、反射型(非持久型)和DOM型三種。下面咱們來詳細瞭解一下這三種XSS攻擊：

1.1 反射型XSS

當用戶點擊一個惡意連接，或者提交一個表單，或者進入一個惡意網站時，注入腳本進入被攻擊者的網站。Web服務器將注入腳本，好比一個錯誤信息，搜索結果等，未進行過濾直接返回到用戶的瀏覽器上。

反射型 XSS 的攻擊步驟：

1. 攻擊者構造出特殊的 URL，其中包含惡意代碼。
2. 用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
3. 用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
4. 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

反射型 XSS 漏洞常見於經過 URL 傳遞參數的功能，如網站搜索、跳轉等。因爲須要用戶主動打開惡意的 URL 才能生效，攻擊者每每會結合多種手段誘導用戶點擊。

POST 的內容也能夠觸發反射型 XSS，只不過其觸發條件比較苛刻（須要構造表單提交頁面，並引導用戶點擊），因此很是少見。

查看反射型攻擊示例

請戳： https://github.com/YvetteLau/...

根據 README.md 的提示進行操做(真實狀況下是須要誘導用戶點擊的，上述代碼僅是用做演示)。

注意Chrome 和 Safari 可以檢測到 url 上的xss攻擊，將網頁攔截掉，可是其它瀏覽器不行，如Firefox

若是不但願被前端拿到cookie，後端能夠設置 httpOnly (不過這不是 XSS攻擊 的解決方案，只能下降受損範圍)

如何防範反射型XSS攻擊

對字符串進行編碼。

對url的查詢參數進行轉義後再輸出到頁面。

app.get('/welcome', function(req, res) {
    //對查詢參數進行編碼，避免反射型 XSS攻擊
    res.send(`${encodeURIComponent(req.query.type)}`); 
});

1.2 DOM 型 XSS

DOM 型 XSS 攻擊，實際上就是前端 JavaScript 代碼不夠嚴謹，把不可信的內容插入到了頁面。在使用 .innerHTML、.outerHTML、.appendChild、document.write()等API時要特別當心，不要把不可信的數據做爲 HTML 插到頁面上，儘可能使用 .innerText、.textContent、.setAttribute() 等。

DOM 型 XSS 的攻擊步驟：

1. 攻擊者構造出特殊數據，其中包含惡意代碼。
2. 用戶瀏覽器執行了惡意代碼。
3. 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

如何防範 DOM 型 XSS 攻擊

防範 DOM 型 XSS 攻擊的核心就是對輸入內容進行轉義(DOM 中的內聯事件監聽器和連接跳轉都能把字符串做爲代碼運行，須要對其內容進行檢查)。

1.對於url連接(例如圖片的src屬性)，那麼直接使用 encodeURIComponent 來轉義。

2.非url，咱們能夠這樣進行編碼：

function encodeHtml(str) {
    return str.replace(/"/g, '"')
            .replace(/'/g, ''')
            .replace(/</g, '&lt;')
            .replace(/>/g, '&gt;');
}

DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端 JavaScript 自身的安全漏洞。

查看DOM型XSS攻擊示例(根據readme提示查看)

請戳： https://github.com/YvetteLau/...

1.3 存儲型XSS

惡意腳本永久存儲在目標服務器上。當瀏覽器請求數據時，腳本從服務器傳回並執行，影響範圍比反射型和DOM型XSS更大。存儲型XSS攻擊的緣由仍然是沒有作好數據過濾：前端提交數據至服務端時，沒有作好過濾；服務端在接受到數據時，在存儲以前，沒有作過濾；前端從服務端請求到數據，沒有過濾輸出。

存儲型 XSS 的攻擊步驟：

1. 攻擊者將惡意代碼提交到目標網站的數據庫中。
2. 用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
3. 用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
4. 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

這種攻擊常見於帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。

如何防範存儲型XSS攻擊：

1. 前端數據傳遞給服務器以前，先轉義/過濾(防範不了抓包修改數據的狀況)
2. 服務器接收到數據，在存儲到數據庫以前，進行轉義/過濾
3. 前端接收到服務器傳遞過來的數據，在展現到頁面前，先進行轉義/過濾

查看存儲型XSS攻擊示例(根據Readme提示查看)

請戳： https://github.com/YvetteLau/...

除了謹慎的轉義，咱們還須要其餘一些手段來防範XSS攻擊:

1.Content Security Policy

在服務端使用 HTTP的 Content-Security-Policy 頭部來指定策略，或者在前端設置 meta 標籤。

例以下面的配置只容許加載同域下的資源：

Content-Security-Policy: default-src 'self'

<meta http-equiv="Content-Security-Policy" content="form-action 'self';">

前端和服務端設置 CSP 的效果相同，可是meta沒法使用report

更多的設置能夠查看 [Content-Security-Policy
]( https://developer.mozilla.org...

嚴格的 CSP 在 XSS 的防範中能夠起到如下的做用：

1. 禁止加載外域代碼，防止複雜的攻擊邏輯。
2. 禁止外域提交，網站被攻擊後，用戶的數據不會泄露到外域。
3. 禁止內聯腳本執行（規則較嚴格，目前發現 GitHub 使用）。
4. 禁止未受權的腳本執行（新特性，Google Map 移動版在使用）。
5. 合理使用上報能夠及時發現 XSS，利於儘快修復問題。

2.輸入內容長度控制

對於不受信任的輸入，都應該限定一個合理的長度。雖然沒法徹底防止 XSS 發生，但能夠增長 XSS 攻擊的難度。

3.輸入內容限制

對於部分輸入，能夠限定不能包含特殊字符或者僅能輸入數字等。

4.其餘安全措施

• HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入後也沒法竊取此 Cookie。
• 驗證碼：防止腳本冒充用戶提交危險操做。

1.5 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.使用第三方工具進行掃描（詳見最後一個章節）

__

2. CSRF

CSRF（Cross-site request forgery）跨站請求僞造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞事後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操做的目的。

典型的CSRF攻擊流程：

1. 受害者登陸A站點，並保留了登陸憑證（Cookie）。
2. 攻擊者誘導受害者訪問了站點B。
3. 站點B向站點A發送了一個請求，瀏覽器會默認攜帶站點A的Cookie信息。
4. 站點A接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是無辜的受害者發送的請求。
5. 站點A以受害者的名義執行了站點B的請求。
6. 攻擊完成，攻擊者在受害者不知情的狀況下，冒充受害者完成了攻擊。

一圖勝千言：

CSRF的特色

1.攻擊一般在第三方網站發起，如圖上的站點B，站點A沒法防止攻擊發生。

2.攻擊利用受害者在被攻擊網站的登陸憑證，冒充受害者提交操做；並不會去獲取cookie信息(cookie有同源策略)

3.跨站請求能夠用各類方式：圖片URL、超連接、CORS、Form提交等等(來源不明的連接，不要點擊)

運行代碼，更直觀瞭解一下

用戶 loki 銀行存款 10W。

用戶 yvette 銀行存款 1000。

咱們來看看 yvette 如何經過 CSRF 攻擊，將 loki 的錢偷偷轉到本身的帳戶中，並根據提示，查看如何去防護CSRF攻擊。

請戳： https://github.com/YvetteLau/... [根據readme中的CSRF部分進行操做]

CSRF 攻擊防護

1. 添加驗證碼(體驗很差)

驗證碼可以防護CSRF攻擊，可是咱們不可能每一次交互都須要驗證碼，不然用戶的體驗會很是差，可是咱們能夠在轉帳，交易等操做時，增長驗證碼，確保咱們的帳戶安全。

2. 判斷請求的來源：檢測Referer(並不安全，Referer能夠被更改)

`Referer` 能夠做爲一種輔助手段，來判斷請求的來源是不是安全的，可是鑑於 `Referer` 自己是能夠被修改的，由於不能僅依賴於  `Referer`

3. 使用Token(主流)

CSRF攻擊之因此可以成功，是由於服務器誤把攻擊者發送的請求當成了用戶本身的請求。那麼咱們能夠要求全部的用戶請求都攜帶一個CSRF攻擊者沒法獲取到的Token。服務器經過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開。跟驗證碼相似，只是用戶無感知。

- 服務端給用戶生成一個token，加密後傳遞給用戶
- 用戶在提交請求時，須要攜帶這個token
- 服務端驗證token是否正確

4. Samesite Cookie屬性

爲了從源頭上解決這個問題，Google起草了一份草案來改進HTTP協議，爲Set-Cookie響應頭新增Samesite屬性，它用來標明這個 Cookie是個「同站 Cookie」，同站Cookie只能做爲第一方Cookie，不能做爲第三方Cookie，Samesite 有兩個屬性值，分別是 Strict 和 Lax。

部署簡單，並能有效防護CSRF攻擊，可是存在兼容性問題。

Samesite=Strict

Samesite=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攻擊，咱們能夠組合使用以上防護手段。

3. 點擊劫持

點擊劫持是指在一個Web頁面中隱藏了一個透明的iframe，用外層假頁面誘導用戶點擊，其實是在隱藏的frame上觸發了點擊事件進行一些用戶不知情的操做。

典型點擊劫持攻擊流程

1. 攻擊者構建了一個很是有吸引力的網頁【不知道哪些內容對大家來講有吸引力，我就不寫頁面了，偷個懶】
2. 將被攻擊的頁面放置在當前頁面的 iframe 中
3. 使用樣式將 iframe 疊加到很是有吸引力內容的上方
4. 將iframe設置爲100%透明
5. 你被誘導點擊了網頁內容，你覺得你點擊的是*，而實際上，你成功被攻擊了。

點擊劫持防護

1. frame busting

Frame busting

if ( top.location != window.location ){
    top.location = window.location
}

須要注意的是: HTML5中iframe的 sandbox 屬性、IE中iframe的security 屬性等，均可以限制iframe頁面中的JavaScript腳本執行，從而可使得 frame busting 失效。

2. X-Frame-Options

X-FRAME-OPTIONS是微軟提出的一個http頭，專門用來防護利用iframe嵌套的點擊劫持攻擊。而且在IE八、Firefox3.六、Chrome4以上的版本均能很好的支持。

能夠設置爲如下值:

• DENY: 拒絕任何域加載
• SAMEORIGIN: 容許同源域下加載
• ALLOW-FROM: 能夠定義容許frame加載的頁面地址

4. URL跳轉漏洞

URL 跳轉漏洞是指後臺服務器在告知瀏覽器跳轉時，未對客戶端傳入的重定向地址進行合法性校驗，致使用戶瀏覽器跳轉到釣魚頁面的一種漏洞。

URL跳轉通常有如下幾種實現方式

1. Header頭跳轉
2. Javascript跳轉
3. META標籤跳轉

URL跳轉漏洞防護

之因此會出現跳轉 URL 漏洞，就是由於服務端沒有對客戶端傳遞的跳轉地址進行合法性校驗，因此，預防這種攻擊的方式，就是對客戶端傳遞過來的跳轉 URL 進行校驗。

1.referer的限制

若是肯定傳遞URL參數進入的來源，咱們能夠經過該方式實現安全限制，保證該URL的有效性，避免惡意用戶本身生成跳轉連接

2.加入有效性驗證Token

保證全部生成的連接都是來自於可信域，經過在生成的連接里加入用戶不可控的token對生成的連接進行校驗，能夠避免用戶生成本身的惡意連接從而被利用。

安全掃描工具

上面咱們介紹了幾種常見的前端安全漏洞，也瞭解一些防範措施，那麼咱們如何發現本身網站的安全問題呢？沒有安所有門的公司能夠考慮下面幾款開源掃碼工具：

1. Arachni

Arachni是基於Ruby的開源，功能全面，高性能的漏洞掃描框架，Arachni提供簡單快捷的掃描方式，只須要輸入目標網站的網址便可開始掃描。它能夠經過分析在掃描過程當中得到的信息，來評估漏洞識別的準確性和避免誤判。

Arachni默認集成大量的檢測工具，能夠實施 代碼注入、CSRF、文件包含檢測、SQL注入、命令行注入、路徑遍歷等各類攻擊。

同時，它還提供了各類插件，能夠實現表單爆破、HTTP爆破、防火牆探測等功能。

針對大型網站，該工具支持會話保持、瀏覽器集羣、快照等功能，幫助用戶更好實施滲透測試。

2. Mozilla HTTP Observatory

Mozilla HTTP Observatory，是Mozilla最近發佈的一款名爲Observatory的網站安全分析工具，意在鼓勵開發者和系統管理員加強本身網站的安全配置。用法很是簡單：輸入網站URL，便可訪問並分析網站HTTP標頭，隨後可針對網站安全性提供數字形式的分數和字母表明的安全級別。

檢查的主要範圍包括：

• Cookie
• 跨源資源共享（CORS）
• 內容安全策略（CSP）
• HTTP公鑰固定（Public Key Pinning）
• HTTP嚴格安全傳輸（HSTS）狀態
• 是否存在HTTP到HTTPs的自動重定向
• 子資源完整性（Subresource Integrity）
• X-Frame-Options
• X-XSS-Protection

3. w3af

W3af是一個基於Python的Web應用安全掃描器。可幫助開發人員，有助於開發人員和測試人員識別Web應用程序中的漏洞。

掃描器可以識別200多個漏洞，包括跨站點腳本、SQL注入和操做系統命令。

參考文章:

[1] https://github.com/0xsobky/Ha...

[2] https://tech.meituan.com/2018...

[3] https://zhuanlan.zhihu.com/p/...

[4] https://mp.weixin.qq.com/s/up...

[5] https://juejin.im/post/5b4e0c...

[6] https://juejin.im/post/5c8a33...

[7] https://github.com/OWASP/Chea...

後續寫做計劃(寫做順序不定)

1.《寒冬求職季之你必需要懂的原生JS》(下)

2.《寒冬求職季之你必需要知道的CSS》

3.《寒冬求職季之你必需要懂的一些瀏覽器知識》

4.《寒冬求職季之你必需要知道的性能優化》

5.《寒冬求職季之你必需要懂的webpack原理》

針對React技術棧:

1.《寒冬求職季之你必需要懂的React》系列

2.《寒冬求職季之你必需要懂的ReactNative》系列

編寫本文，雖然花費了不少時間，可是在這個過程當中，我也學習到了不少知識，謝謝各位小夥伴願意花費寶貴的時間閱讀本文，若是本文給了您一點幫助或者是啓發，請不要吝嗇你的贊和Star，您的確定是我前進的最大動力。https://github.com/YvetteLau/...

推薦關注本人公衆號：