摘要：禁止內(nèi)聯(lián)腳本執(zhí)行規(guī)則較嚴(yán)格，目前發(fā)現(xiàn)使用。典型的攻擊流程受害者登錄站點(diǎn)，并保留了登錄憑證。站點(diǎn)接收到請求后，對請求進(jìn)行驗(yàn)證，并確認(rèn)是受害者的憑證，誤以為是無辜的受害者發(fā)送的請求。攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者完成了攻擊。

隨著互聯(lián)網(wǎng)的發(fā)展，各種Web應(yīng)用變得越來越復(fù)雜，滿足了用戶的各種需求的同時，各種網(wǎng)絡(luò)安全問題也接踵而至。作為前端工程師的我們也逃不開這個問題，今天一起看一看Web前端有哪些安全問題以及我們?nèi)绾稳z測和防范這些問題。非前端的攻擊本文不會討論(如SQL注入，DDOS攻擊等)，畢竟后端也非本人擅長的領(lǐng)域。

QQ郵箱、新浪微博、YouTube、WordPress 和 百度 等知名網(wǎng)站都曾遭遇攻擊，如果你從未有過安全方面的問題，不是因?yàn)槟闼_發(fā)的網(wǎng)站很安全，更大的可能是你的網(wǎng)站的流量非常低或者沒有攻擊的價值。

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

希望大家在閱讀完本文之后，能夠很好的回答以下幾個面試題。

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

2.什么是XSS攻擊？XSS攻擊有幾種類型？如果防范XSS攻擊？

3.什么是CSRF攻擊？如何防范CSRF攻擊

4.如何檢測網(wǎng)站是否安全？

在開始之前，建議大家先clone代碼，我為大家準(zhǔn)備好了示例代碼，并且寫了詳細(xì)的注釋，大家可以對照代碼來理解每一種攻擊以及如何去防范攻擊，畢竟看再多的文字，都不如實(shí)操。(Readme中詳細(xì)得寫了操作步驟)：https://github.com/YvetteLau/...

更多優(yōu)質(zhì)文章可戳: https://github.com/YvetteLau/...

XSS(Cross-Site Scripting，跨站腳本攻擊)是一種代碼注入攻擊。攻擊者在目標(biāo)網(wǎng)站上注入惡意代碼，當(dāng)被攻擊者登陸網(wǎng)站時就會執(zhí)行這些惡意代碼，這些腳本可以讀取 cookie，session tokens，或者其它敏感的網(wǎng)站信息，對用戶進(jìn)行釣魚欺詐，甚至發(fā)起蠕蟲攻擊等。

XSS 的本質(zhì)是：惡意代碼未經(jīng)過濾，與網(wǎng)站正常的代碼混在一起；瀏覽器無法分辨哪些腳本是可信的，導(dǎo)致惡意腳本被執(zhí)行。由于直接在用戶的終端執(zhí)行，惡意代碼能夠直接獲取用戶的信息，利用這些信息冒充用戶向網(wǎng)站發(fā)起攻擊者定義的請求。

XSS分類

根據(jù)攻擊的來源，XSS攻擊可以分為存儲型(持久性)、反射型(非持久型)和DOM型三種。下面我們來詳細(xì)了解一下這三種XSS攻擊：

1.1 反射型XSS

當(dāng)用戶點(diǎn)擊一個惡意鏈接，或者提交一個表單，或者進(jìn)入一個惡意網(wǎng)站時，注入腳本進(jìn)入被攻擊者的網(wǎng)站。Web服務(wù)器將注入腳本，比如一個錯誤信息，搜索結(jié)果等，未進(jìn)行過濾直接返回到用戶的瀏覽器上。

反射型 XSS 的攻擊步驟：

攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。

用戶打開帶有惡意代碼的 URL 時，網(wǎng)站服務(wù)端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。

用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行。

惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

反射型 XSS 漏洞常見于通過 URL 傳遞參數(shù)的功能，如網(wǎng)站搜索、跳轉(zhuǎn)等。由于需要用戶主動打開惡意的 URL 才能生效，攻擊者往往會結(jié)合多種手段誘導(dǎo)用戶點(diǎn)擊。

POST 的內(nèi)容也可以觸發(fā)反射型 XSS，只不過其觸發(fā)條件比較苛刻（需要構(gòu)造表單提交頁面，并引導(dǎo)用戶點(diǎn)擊），所以非常少見。

查看反射型攻擊示例

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

根據(jù) README.md 的提示進(jìn)行操作(真實(shí)情況下是需要誘導(dǎo)用戶點(diǎn)擊的，上述代碼僅是用作演示)。

注意Chrome 和 Safari 能夠檢測到 url 上的xss攻擊，將網(wǎng)頁攔截掉，但是其它瀏覽器不行，如Firefox

如果不希望被前端拿到cookie，后端可以設(shè)置 httpOnly (不過這不是 XSS攻擊 的解決方案，只能降低受損范圍)

如何防范反射型XSS攻擊

對字符串進(jìn)行編碼。

對url的查詢參數(shù)進(jìn)行轉(zhuǎn)義后再輸出到頁面。

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

1.2 DOM 型 XSS

DOM 型 XSS 攻擊，實(shí)際上就是前端 JavaScript 代碼不夠嚴(yán)謹(jǐn)，把不可信的內(nèi)容插入到了頁面。在使用 .innerHTML、.outerHTML、.appendChild、document.write()等API時要特別小心，不要把不可信的數(shù)據(jù)作為 HTML 插到頁面上，盡量使用 .innerText、.textContent、.setAttribute() 等。

DOM 型 XSS 的攻擊步驟：

攻擊者構(gòu)造出特殊數(shù)據(jù)，其中包含惡意代碼。

用戶瀏覽器執(zhí)行了惡意代碼。

惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

如何防范 DOM 型 XSS 攻擊

防范 DOM 型 XSS 攻擊的核心就是對輸入內(nèi)容進(jìn)行轉(zhuǎn)義(DOM 中的內(nèi)聯(lián)事件監(jiān)聽器和鏈接跳轉(zhuǎn)都能把字符串作為代碼運(yùn)行，需要對其內(nèi)容進(jìn)行檢查)。

1.對于url鏈接(例如圖片的src屬性)，那么直接使用 encodeURIComponent 來轉(zhuǎn)義。

2.非url，我們可以這樣進(jìn)行編碼：

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

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

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

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

1.3 存儲型XSS

惡意腳本永久存儲在目標(biāo)服務(wù)器上。當(dāng)瀏覽器請求數(shù)據(jù)時，腳本從服務(wù)器傳回并執(zhí)行，影響范圍比反射型和DOM型XSS更大。存儲型XSS攻擊的原因仍然是沒有做好數(shù)據(jù)過濾：前端提交數(shù)據(jù)至服務(wù)端時，沒有做好過濾；服務(wù)端在接受到數(shù)據(jù)時，在存儲之前，沒有做過濾；前端從服務(wù)端請求到數(shù)據(jù)，沒有過濾輸出。

存儲型 XSS 的攻擊步驟：

攻擊者將惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫中。

用戶打開目標(biāo)網(wǎng)站時，網(wǎng)站服務(wù)端將惡意代碼從數(shù)據(jù)庫取出，拼接在 HTML 中返回給瀏覽器。

用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行。

惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

這種攻擊常見于帶有用戶保存數(shù)據(jù)的網(wǎng)站功能，如論壇發(fā)帖、商品評論、用戶私信等。

如何防范存儲型XSS攻擊：

前端數(shù)據(jù)傳遞給服務(wù)器之前，先轉(zhuǎn)義/過濾(防范不了抓包修改數(shù)據(jù)的情況)

服務(wù)器接收到數(shù)據(jù)，在存儲到數(shù)據(jù)庫之前，進(jìn)行轉(zhuǎn)義/過濾

前端接收到服務(wù)器傳遞過來的數(shù)據(jù)，在展示到頁面前，先進(jìn)行轉(zhuǎn)義/過濾

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

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

除了謹(jǐn)慎的轉(zhuǎn)義，我們還需要其他一些手段來防范XSS攻擊:

1.Content Security Policy

在服務(wù)端使用 HTTP的 Content-Security-Policy 頭部來指定策略，或者在前端設(shè)置 meta 標(biāo)簽。

例如下面的配置只允許加載同域下的資源：

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

前端和服務(wù)端設(shè)置 CSP 的效果相同，但是meta無法使用report

更多的設(shè)置可以查看 [Content-Security-Policy
](https://developer.mozilla.org...

嚴(yán)格的 CSP 在 XSS 的防范中可以起到以下的作用：

禁止加載外域代碼，防止復(fù)雜的攻擊邏輯。

禁止外域提交，網(wǎng)站被攻擊后，用戶的數(shù)據(jù)不會泄露到外域。

禁止內(nèi)聯(lián)腳本執(zhí)行（規(guī)則較嚴(yán)格，目前發(fā)現(xiàn) GitHub 使用）。

禁止未授權(quán)的腳本執(zhí)行（新特性，Google Map 移動版在使用）。

合理使用上報(bào)可以及時發(fā)現(xiàn) XSS，利于盡快修復(fù)問題。

2.輸入內(nèi)容長度控制

對于不受信任的輸入，都應(yīng)該限定一個合理的長度。雖然無法完全防止 XSS 發(fā)生，但可以增加 XSS 攻擊的難度。

3.輸入內(nèi)容限制

對于部分輸入，可以限定不能包含特殊字符或者僅能輸入數(shù)字等。

4.其他安全措施

HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入后也無法竊取此 Cookie。

驗(yàn)證碼：防止腳本冒充用戶提交危險(xiǎn)操作。

1.5 XSS 檢測

讀到這兒，相信大家已經(jīng)知道了什么是XSS攻擊，XSS攻擊的類型，以及如何去防范XSS攻擊。但是有一個非常重要的問題是：我們?nèi)绾稳z測XSS攻擊，怎么知道自己的頁面是否存在XSS漏洞？

很多大公司，都有專門的安全部門負(fù)責(zé)這個工作，但是如果沒有安全部門，作為開發(fā)者本身，該如何去檢測呢？

1.使用通用 XSS 攻擊字串手動檢測 XSS 漏洞

如: jaVasCript:/*-/*`/*`/*"/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//x3csVg/

能夠檢測到存在于 HTML 屬性、HTML 文字內(nèi)容、HTML 注釋、跳轉(zhuǎn)鏈接、內(nèi)聯(lián) JavaScript 字符串、內(nèi)聯(lián) CSS 樣式表等多種上下文中的 XSS 漏洞，也能檢測 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能繞過一些 XSS 過濾器。

2.使用第三方工具進(jìn)行掃描（詳見最后一個章節(jié)）

__

CSRF（Cross-site request forgery）跨站請求偽造：攻擊者誘導(dǎo)受害者進(jìn)入第三方網(wǎng)站，在第三方網(wǎng)站中，向被攻擊網(wǎng)站發(fā)送跨站請求。利用受害者在被攻擊網(wǎng)站已經(jīng)獲取的注冊憑證，繞過后臺的用戶驗(yàn)證，達(dá)到冒充用戶對被攻擊的網(wǎng)站執(zhí)行某項(xiàng)操作的目的。

典型的CSRF攻擊流程：

受害者登錄A站點(diǎn)，并保留了登錄憑證（Cookie）。

攻擊者誘導(dǎo)受害者訪問了站點(diǎn)B。

站點(diǎn)B向站點(diǎn)A發(fā)送了一個請求，瀏覽器會默認(rèn)攜帶站點(diǎn)A的Cookie信息。

站點(diǎn)A接收到請求后，對請求進(jìn)行驗(yàn)證，并確認(rèn)是受害者的憑證，誤以為是無辜的受害者發(fā)送的請求。

站點(diǎn)A以受害者的名義執(zhí)行了站點(diǎn)B的請求。

攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者完成了攻擊。

一圖勝千言：

CSRF的特點(diǎn)

1.攻擊通常在第三方網(wǎng)站發(fā)起，如圖上的站點(diǎn)B，站點(diǎn)A無法防止攻擊發(fā)生。

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

3.跨站請求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等(來源不明的鏈接，不要點(diǎn)擊)

運(yùn)行代碼，更直觀了解一下

用戶 loki 銀行存款 10W。

用戶 yvette 銀行存款 1000。

我們來看看 yvette 如何通過 CSRF 攻擊，將 loki 的錢偷偷轉(zhuǎn)到自己的賬戶中，并根據(jù)提示，查看如何去防御CSRF攻擊。

請戳： https://github.com/YvetteLau/... [根據(jù)readme中的CSRF部分進(jìn)行操作]

1. 添加驗(yàn)證碼(體驗(yàn)不好)

驗(yàn)證碼能夠防御CSRF攻擊，但是我們不可能每一次交互都需要驗(yàn)證碼，否則用戶的體驗(yàn)會非常差，但是我們可以在轉(zhuǎn)賬，交易等操作時，增加驗(yàn)證碼，確保我們的賬戶安全。

2. 判斷請求的來源：檢測Referer(并不安全，Referer可以被更改)

`Referer` 可以作為一種輔助手段，來判斷請求的來源是否是安全的，但是鑒于 `Referer` 本身是可以被修改的，因?yàn)椴荒軆H依賴于  `Referer`

3. 使用Token(主流)

CSRF攻擊之所以能夠成功，是因?yàn)榉?wù)器誤把攻擊者發(fā)送的請求當(dāng)成了用戶自己的請求。那么我們可以要求所有的用戶請求都攜帶一個CSRF攻擊者無法獲取到的Token。服務(wù)器通過校驗(yàn)請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區(qū)分開。跟驗(yàn)證碼類似，只是用戶無感知。

- 服務(wù)端給用戶生成一個token，加密后傳遞給用戶
- 用戶在提交請求時，需要攜帶這個token
- 服務(wù)端驗(yàn)證token是否正確

4. Samesite Cookie屬性

為了從源頭上解決這個問題，Google起草了一份草案來改進(jìn)HTTP協(xié)議，為Set-Cookie響應(yīng)頭新增Samesite屬性，它用來標(biāo)明這個 Cookie是個“同站 Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite 有兩個屬性值，分別是 Strict 和 Lax。

部署簡單，并能有效防御CSRF攻擊，但是存在兼容性問題。

Samesite=Strict

Samesite=Strict 被稱為是嚴(yán)格模式,表明這個 Cookie 在任何情況都不可能作為第三方的 Cookie，有能力阻止所有CSRF攻擊。此時，我們在B站點(diǎn)下發(fā)起對A站點(diǎn)的任何請求，A站點(diǎn)的 Cookie 都不會包含在cookie請求頭中。

**Samesite=Lax**

`Samesite=Lax` 被稱為是寬松模式，與 Strict 相比，放寬了限制，允許發(fā)送安全 HTTP 方法帶上 Cookie，如 `Get` / `OPTIONS` 、`HEAD` 請求.

但是不安全 HTTP 方法，如： `POST`, `PUT`, `DELETE` 請求時，不能作為第三方鏈接的 Cookie

為了更好的防御CSRF攻擊，我們可以組合使用以上防御手段。

點(diǎn)擊劫持是指在一個Web頁面中隱藏了一個透明的iframe，用外層假頁面誘導(dǎo)用戶點(diǎn)擊，實(shí)際上是在隱藏的frame上觸發(fā)了點(diǎn)擊事件進(jìn)行一些用戶不知情的操作。

攻擊者構(gòu)建了一個非常有吸引力的網(wǎng)頁【不知道哪些內(nèi)容對你們來說有吸引力，我就不寫頁面了，偷個懶】

將被攻擊的頁面放置在當(dāng)前頁面的 iframe 中

使用樣式將 iframe 疊加到非常有吸引力內(nèi)容的上方

將iframe設(shè)置為100%透明

你被誘導(dǎo)點(diǎn)擊了網(wǎng)頁內(nèi)容，你以為你點(diǎn)擊的是*，而實(shí)際上，你成功被攻擊了。

1. frame busting

Frame busting

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

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

2. X-Frame-Options

X-FRAME-OPTIONS是微軟提出的一個http頭，專門用來防御利用iframe嵌套的點(diǎn)擊劫持攻擊。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。

可以設(shè)置為以下值:

DENY: 拒絕任何域加載

SAMEORIGIN: 允許同源域下加載

ALLOW-FROM: 可以定義允許frame加載的頁面地址

URL 跳轉(zhuǎn)漏洞是指后臺服務(wù)器在告知瀏覽器跳轉(zhuǎn)時，未對客戶端傳入的重定向地址進(jìn)行合法性校驗(yàn)，導(dǎo)致用戶瀏覽器跳轉(zhuǎn)到釣魚頁面的一種漏洞。

URL跳轉(zhuǎn)一般有以下幾種實(shí)現(xiàn)方式

Header頭跳轉(zhuǎn)

Javascript跳轉(zhuǎn)

META標(biāo)簽跳轉(zhuǎn)

URL跳轉(zhuǎn)漏洞防御

之所以會出現(xiàn)跳轉(zhuǎn) URL 漏洞，就是因?yàn)榉?wù)端沒有對客戶端傳遞的跳轉(zhuǎn)地址進(jìn)行合法性校驗(yàn)，所以，預(yù)防這種攻擊的方式，就是對客戶端傳遞過來的跳轉(zhuǎn) URL 進(jìn)行校驗(yàn)。

1.referer的限制

如果確定傳遞URL參數(shù)進(jìn)入的來源，我們可以通過該方式實(shí)現(xiàn)安全限制，保證該URL的有效性，避免惡意用戶自己生成跳轉(zhuǎn)鏈接

2.加入有效性驗(yàn)證Token

保證所有生成的鏈接都是來自于可信域，通過在生成的鏈接里加入用戶不可控的token對生成的鏈接進(jìn)行校驗(yàn)，可以避免用戶生成自己的惡意鏈接從而被利用。

上面我們介紹了幾種常見的前端安全漏洞，也了解一些防范措施，那么我們?nèi)绾伟l(fā)現(xiàn)自己網(wǎng)站的安全問題呢？沒有安全部門的公司可以考慮下面幾款開源掃碼工具：

Arachni是基于Ruby的開源，功能全面，高性能的漏洞掃描框架，Arachni提供簡單快捷的掃描方式，只需要輸入目標(biāo)網(wǎng)站的網(wǎng)址即可開始掃描。它可以通過分析在掃描過程中獲得的信息，來評估漏洞識別的準(zhǔn)確性和避免誤判。

Arachni默認(rèn)集成大量的檢測工具，可以實(shí)施 代碼注入、CSRF、文件包含檢測、SQL注入、命令行注入、路徑遍歷等各種攻擊。

同時，它還提供了各種插件，可以實(shí)現(xiàn)表單爆破、HTTP爆破、防火墻探測等功能。

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

Mozilla HTTP Observatory，是Mozilla最近發(fā)布的一款名為Observatory的網(wǎng)站安全分析工具，意在鼓勵開發(fā)者和系統(tǒng)管理員增強(qiáng)自己網(wǎng)站的安全配置。用法非常簡單：輸入網(wǎng)站URL，即可訪問并分析網(wǎng)站HTTP標(biāo)頭，隨后可針對網(wǎng)站安全性提供數(shù)字形式的分?jǐn)?shù)和字母代表的安全級別。

檢查的主要范圍包括：

Cookie

跨源資源共享（CORS）

內(nèi)容安全策略（CSP）

HTTP公鑰固定（Public Key Pinning）

HTTP嚴(yán)格安全傳輸（HSTS）狀態(tài)

是否存在HTTP到HTTPs的自動重定向

子資源完整性（Subresource Integrity）

X-Frame-Options

X-XSS-Protection

W3af是一個基于Python的Web應(yīng)用安全掃描器?？蓭椭_發(fā)人員，有助于開發(fā)人員和測試人員識別Web應(yīng)用程序中的漏洞。

掃描器能夠識別200多個漏洞，包括跨站點(diǎn)腳本、SQL注入和操作系統(tǒng)命令。

參考文章:

[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...

后續(xù)寫作計(jì)劃(寫作順序不定)

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

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

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

4.《寒冬求職季之你必須要知道的性能優(yōu)化》

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

針對React技術(shù)棧:

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

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

編寫本文，雖然花費(fèi)了很多時間，但是在這個過程中，我也學(xué)習(xí)到了很多知識，謝謝各位小伙伴愿意花費(fèi)寶貴的時間閱讀本文，如果本文給了您一點(diǎn)幫助或者是啟發(fā)，請不要吝嗇你的贊和Star，您的肯定是我前進(jìn)的最大動力。https://github.com/YvetteLau/...

關(guān)注小姐姐的公眾號，和小姐姐一起學(xué)前端。