常見六大 Web 安全攻防解析 - 技術頭條

者 | 浪里行舟

責編 | 胡巍巍

在互聯網時代，數據安全與個人隱私受到了前所未有的挑戰，各種新奇的攻擊技術層出不窮。如何才能更好地保護我們的數據？本文主要側重于分析幾種常見的攻擊的類型以及防御的方法。

XSS

XSS (Cross-Site Scripting)，跨站腳本攻擊，因為縮寫和 CSS重疊，所以只能叫 XSS。跨站腳本攻擊是指通過存在安全漏洞的Web網站注冊用戶的瀏覽器內運行非法的HTML標簽或JavaScript進行的一種攻擊。

跨站腳本攻擊有可能造成以下影響:

利用虛假輸入表單騙取用戶個人信息。
利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助攻擊者發送惡意請求。
顯示偽造的文章或圖片。

XSS 的原理是惡意攻擊者往 Web 頁面里插入惡意可執行網頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中 Web 里面的腳本代碼會被執行，從而可以達到攻擊者盜取用戶信息或其他侵犯用戶安全隱私的目的。

XSS 的攻擊方式千變萬化，但還是可以大致細分為幾種類型。

1.非持久型 XSS（反射型 XSS ）

非持久型 XSS 漏洞，一般是通過給別人發送帶有惡意腳本代碼參數的 URL，當 URL 地址被打開時，特有的惡意代碼參數被 HTML 解析、執行。

舉一個例子，比如頁面中包含有以下代碼：

 1<select>
 2 <script>
 3 document.write(''
 4 + '<option value=1>'
 5 + location.href.substring(location.href.indexOf('default=') + 8)
 6 + '</option>'
 7 );
 8 document.write('<option value=2>English</option>');
 9 </script>
10</select>

攻擊者可直接通過URL (類似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) 注入可執行的腳本代碼。不過一些瀏覽器如Chrome其內置了一些XSS過濾器，可以防止大部分反射型XSS攻擊。

非持久型 XSS 漏洞攻擊有以下幾點特征：

即時性，不經過服務器存儲，直接通過 HTTP 的 GET 和 POST 請求就能完成一次攻擊，拿到用戶隱私數據。
攻擊者需要誘騙點擊,必須要通過用戶點擊鏈接才能發起
反饋率低，所以較難發現和響應修復
盜取用戶敏感保密信息

為了防止出現非持久型 XSS 漏洞，需要確保這么幾件事情：

Web 頁面渲染的所有內容或者渲染的數據都必須來自于服務端。
盡量不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數據直接渲染。
盡量不要使用eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可執行字符串的方法。
如果做不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字符串參數做 escape 轉義。
前端渲染的時候對任何的字段都需要做 escape 轉義編碼。

2.持久型 XSS（存儲型 XSS）

持久型 XSS 漏洞，一般存在于 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面獲得后端從數據庫中讀出的注入代碼時，恰好將其渲染執行。

舉個例子，對于評論功能來說，就得防范持久型 XSS 攻擊，因為我可以在評論中輸入以下內容

主要注入頁面方式和非持久型 XSS 漏洞類似，只不過持久型的不是來源于 URL，referer，forms 等，而是來源于后端從數據庫中讀出來的數據。持久型 XSS 攻擊不需要誘騙點擊，黑客只需要在提交表單的地方完成注入即可，但是這種 XSS 攻擊的成本相對還是很高。

攻擊成功需要同時滿足以下幾個條件：

POST 請求提交表單后端沒做轉義直接入庫。
后端從數據庫中取出數據沒做轉義直接輸出給前端。
前端拿到后端數據沒做轉義直接渲染成 DOM。

持久型 XSS 有以下幾個特點：

持久性，植入在數據庫中
盜取用戶敏感私密信息
危害面廣

3.如何防御

對于 XSS 攻擊來說，通常有兩種方式可以用來防御。

1) CSP

CSP 本質上就是建立白名單，開發者明確告訴瀏覽器哪些外部資源可以加載和執行。我們只需要配置規則，如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來盡量減少 XSS 攻擊。

通常可以通過兩種方式來開啟 CSP：

設置 HTTP Header 中的 Content-Security-Policy
設置 meta 標簽的方式

這里以設置 HTTP Header 來舉例：

只允許加載本站資源

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

只允許加載 HTTPS 協議圖片

1Content-Security-Policy: img-src https://*

允許加載任何來源框架

1Content-Security-Policy: child-src 'none'

如需了解更多屬性，請查看Content-Security-Policy文檔

對于這種方式來說，只要開發者配置了正確的規則，那么即使網站存在漏洞，攻擊者也不能執行它的攻擊代碼，并且 CSP 的兼容性也不錯。

2) 轉義字符

用戶的輸入永遠不可信任的，最普遍的做法就是轉義輸入輸出的內容，對于引號、尖括號、斜杠進行轉義

 1function escape(str) {
 2 str = str.replace(/&/g, '&')
 3 str = str.replace(/</g, '<')
 4 str = str.replace(/>/g, '>')
 5 str = str.replace(/"/g, '&quto;')
 6 str = str.replace(/'/g, ''')
 7 str = str.replace(/`/g, '`')
 8 str = str.replace(/\//g, '/')
 9 return str
10}

但是對于顯示富文本來說，顯然不能通過上面的辦法來轉義所有字符，因為這樣會把需要的格式也過濾掉。對于這種情況，通常采用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標簽和標簽屬性實在太多，更加推薦使用白名單的方式。

1const xss = require('xss')
2let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
3// -> <h1>XSS Demo</h1><script>alert("xss");</script>
4console.log(html)

以上示例使用了 js-xss 來實現，可以看到在輸出中保留了 h1 標簽且過濾了 script 標簽。

3) HttpOnly Cookie。

這是預防XSS攻擊竊取用戶cookie最有效的防御手段。Web應用程序在設置cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。

CSRF

CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，它利用用戶已登錄的身份，在用戶毫不知情的情況下，以用戶的名義完成非法操作。

1.CSRF攻擊的原理

下面先介紹一下CSRF攻擊的原理：

完成 CSRF 攻擊必須要有三個條件：

用戶已經登錄了站點 A，并在本地記錄了 cookie
在用戶沒有登出站點 A 的情況下（也就是 cookie 生效的情況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。
站點 A 沒有做任何 CSRF 防御

我們來看一個例子：當我們登入轉賬頁面后，突然眼前一亮驚現"XXX隱私照片，不看后悔一輩子"的鏈接，耐不住內心躁動，立馬點擊了該危險的網站（頁面代碼如下圖所示），但當這頁面一加載，便會執行submitForm這個方法來提交轉賬請求，從而將10塊轉給黑客。

2.如何防御

防范 CSRF 攻擊可以遵循以下幾種規則：

Get 請求不對數據進行修改
不讓第三方網站訪問到用戶 Cookie
阻止第三方網站請求接口
請求時附帶驗證信息，比如驗證碼或者 Token

1) SameSite

可以對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求發送，可以很大程度減少 CSRF 的攻擊，但是該屬性目前并不是所有瀏覽器都兼容。

2) Referer Check

HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求時，一般會帶上Referer信息告訴服務器是從哪個頁面鏈接過來的，服務器籍此可以獲得一些信息用于處理。可以通過檢查請求的來源來防御CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。

但在某些情況下如從https跳轉到http，瀏覽器處于安全考慮，不會發送referer，服務器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那么攻擊者可以在其他網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出于以上原因，無法完全依賴Referer Check作為防御CSRF的主要手段。但是可以通過Referer Check來監控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 設置為透明，在頁面中透出一個按鈕誘導用戶點擊。

1. 特點

隱蔽性較高，騙取用戶操作
"UI-覆蓋攻擊"
利用iframe或者其它標簽的屬性

2. 點擊劫持的原理

用戶在登陸 A 網站的系統后，被攻擊者誘惑打開第三方網站，而第三方網站通過 iframe 引入了 A 網站的頁面內容，用戶在第三方網站中點擊某個按鈕（被裝飾的按鈕），實際上是點擊了 A 網站的按鈕。

接下來我們舉個例子：我在優酷發布了很多視頻，想讓更多的人關注它，就可以通過點擊劫持來實現

 1iframe {
 2width: 1440px;
 3height: 900px;
 4position: absolute;
 5top: -0px;
 6left: -0px;
 7z-index: 2;
 8-moz-opacity: 0;
 9opacity: 0;
10filter: alpha(opacity=0);
11}
12button {
13position: absolute;
14top: 270px;
15left: 1150px;
16z-index: 1;
17width: 90px;
18height:40px;
19}
20</style>
21......
22<button>點擊脫衣</button>
23<img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg">
24<iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe>

從上圖可知，攻擊者通過圖片作為頁面背景，隱藏了用戶操作的真實界面，當你按耐不住好奇點擊按鈕以后，真正的點擊的其實是隱藏的那個頁面的訂閱按鈕，然后就會在你不知情的情況下訂閱了。

3. 如何防御

1）X-FRAME-OPTIONS

X-FRAME-OPTIONS是一個 HTTP 響應頭，在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭就是為了防御用 iframe 嵌套的點擊劫持攻擊。

該響應頭有三個值可選，分別是

DENY，表示頁面不允許通過 iframe 的方式展示
SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示
ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示

2）JavaScript 防御

對于某些遠古瀏覽器來說，并不能支持上面的這種方式，那我們只有通過 JS 的方式來防御點擊劫持了。

 1<head>
 2 <style id="click-jack">
 3 html {
 4 display: none !important;
 5 }
 6 </style>
 7</head>
 8<body>
 9 <script>
10 if (self == top) {
11 var style = document.getElementById('click-jack')
12 document.body.removeChild(style)
13 } else {
14 top.location = self.location
15 }
16 </script>
17</body>
以上代碼的作用就是當通過 iframe 的方式加載頁面時，攻擊者的網頁直接不顯示所有內容了。

URL跳轉漏洞

定義：借助未驗證的URL跳轉，將應用程序引導到不安全的第三方區域，從而導致的安全問題。

1.URL跳轉漏洞原理

黑客利用URL跳轉漏洞來誘導安全意識低的用戶點擊，導致用戶信息泄露或者資金的流失。其原理是黑客構建惡意鏈接(鏈接需要進行偽裝,盡可能迷惑),發在QQ群或者是瀏覽量多的貼吧/論壇中。

安全意識低的用戶點擊后,經過服務器或者瀏覽器解析后，跳到惡意的網站中。

惡意鏈接需要進行偽裝,經常的做法是熟悉的鏈接后面加上一個惡意的網址，這樣才迷惑用戶。

諸如偽裝成像如下的網址，你是否能夠識別出來是惡意網址呢？

1http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd
2http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd
3http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd

2.實現方式：

Header頭跳轉
Javascript跳轉
META標簽跳轉

這里我們舉個Header頭跳轉實現方式：

1<?php
2$url=$_GET['jumpto'];
3header("Location: $url");
4?>
1http://www.wooyun.org/login.php?jumpto=http://www.evil.com

這里用戶會認為www.wooyun.org都是可信的，但是點擊上述鏈接將導致用戶最終訪問www.evil.com這個惡意網址。

3.如何防御

1)referer的限制

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

2)加入有效性驗證Token

我們保證所有生成的鏈接都是來自于我們可信域的，通過在生成的鏈接里加入用戶不可控的Token對生成的鏈接進行校驗，可以避免用戶生成自己的惡意鏈接從而被利用，但是如果功能本身要求比較開放，可能導致有一定的限制。

SQL注入

SQL注入是一種常見的Web安全漏洞，攻擊者利用這個漏洞，可以訪問或修改數據，或者利用潛在的數據庫漏洞進行攻擊。

1.SQL注入的原理

我們先舉一個萬能鑰匙的例子來說明其原理：

1<form action="/login" method="POST">
2 <p>Username: <input type="text" name="username" /></p>
3 <p>Password: <input type="password" name="password" /></p>
4 <p><input type="submit" value="登陸" /></p>
5</form>

后端的 SQL 語句可能是如下這樣的：

1let querySQL = `
2 SELECT *
3 FROM user
4 WHERE username='${username}'
5 AND psw='${password}'
6`;
7// 接下來就是執行 sql 語句...
8

這是我們經常見到的登錄頁面，但如果有一個惡意攻擊者輸入的用戶名是 admin' --，密碼隨意輸入，就可以直接登入系統了。why! ----這就是SQL注入。

我們之前預想的SQL 語句是:

1SELECT * FROM user WHERE username='admin' AND psw='password'

但是惡意攻擊者用奇怪用戶名將你的 SQL 語句變成了如下形式：

1SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'

在 SQL 中,' --是閉合和注釋的意思，-- 是注釋后面的內容的意思，所以查詢語句就變成了：

1SELECT * FROM user WHERE username='admin'

所謂的萬能密碼,本質上就是SQL注入的一種利用方式。

一次SQL注入的過程包括以下幾個過程：

獲取用戶請求參數
拼接到代碼當中
SQL語句按照我們構造參數的語義執行成功

SQL注入的必備條件： 1.可以控制輸入的數據 2.服務器要執行的代碼拼接了控制的數據。

我們會發現SQL注入流程中與正常請求服務器類似，只是黑客控制了數據，構造了SQL查詢，而正常的請求不會SQL查詢這一步，SQL注入的本質:數據和代碼未分離，即數據當做了代碼來執行。

2.危害

獲取數據庫信息
管理員后臺用戶名和密碼
獲取其他數據庫敏感信息：用戶名、密碼、手機號碼、身份證、銀行卡信息……
整個數據庫：脫褲
獲取服務器權限
植入Webshell，獲取服務器后門
讀取服務器敏感文件

3.如何防御

嚴格限制Web應用的數據庫的操作權限，給此用戶提供僅僅能夠滿足其工作的最低權限，從而最大限度的減少注入攻擊對數據庫的危害
后端代碼檢查輸入的數據是否符合預期，嚴格限制變量的類型，例如使用正則表達式進行一些匹配處理。
對進入數據庫的特殊字符（'，"，\，<，>，&，*，; 等）進行轉義處理，或編碼轉換。基本上所有的后端語言都有對字符串進行轉義處理的方法，比如 lodash 的 lodash._escapehtmlchar 庫。
所有的查詢語句建議使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 占位參數。

OS命令注入攻擊

OS命令注入和SQL注入差不多，只不過SQL注入是針對數據庫的，而OS命令注入是針對操作系統的。OS命令注入攻擊指通過Web應用，執行非法的操作系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。倘若調用Shell時存在疏漏，就可以執行插入的非法命令。

命令注入攻擊可以向Shell發送命令，讓Windows或Linux操作系統的命令行啟動程序。也就是說，通過命令注入攻擊可執行操作系統上安裝著的各種程序。

1.原理

黑客構造命令提交給web應用程序，web應用程序提取黑客構造的命令，拼接到被執行的命令中，因黑客注入的命令打破了原有命令結構，導致web應用執行了額外的命令，最后web應用程序將執行的結果輸出到響應頁面中。

我們通過一個例子來說明其原理，假如需要實現一個需求：用戶提交一些內容到服務器，然后在服務器執行一些系統命令去返回一個結果給用戶

1// 以 Node.js 為例，假如在接口中需要從 github 下載用戶指定的 repo
2const exec = require('mz/child_process').exec;
3let params = {/* 用戶輸入的參數 */};
4exec(`git clone ${params.repo} /some/path`);
params.repo傳入的是 https://github.com/admin/admin.github.io.git 確實能從指定的 git repo 上下載到想要的代碼。

但是如果 params.repo 傳入的是 https://github.com/xx/xx.git && rm -rf /* && 恰好你的服務是用 root 權限起的就糟糕了。

2.如何防御

后端對前端提交內容進行規則限制（比如正則表達式）。
在調用系統命令前對所有傳入參數進行命令行參數轉義過濾。
不要直接拼接命令語句，借助一些工具做拼接、轉義預處理，例如 Node.js 的 shell-escape npm包

參考資料

常見Web 安全攻防總結
前端面試之道
圖解Http
Web安全知多少
web安全之點擊劫持(clickjacking)
URL重定向/跳轉漏洞
網易web白帽子

景

SpringBoot提供了一個頁面，嵌入到前端的iframe頁面中，打開才菜單后瀏覽器的控制臺報錯，如下：

frame because it set 'X-Frame-Options' to 'deny'.

頁面嵌入iframe：

VUE，嵌入iframe，實現iframe的100%高度和寬度

HTTP響應頭X-Frame-Options：

1、取值：DENY，頁面不能被嵌入到任何iframe或者frame中。

2、取值：SAMEORIGIN：頁面只能被本站頁面嵌入到iframe或者frame中。

3、取值：ALLOW-FROM uri：頁面只能被嵌入到指定域名的框架中。

X-Frame-Options的安全問題：

點擊劫持（ClickJacking），一種視覺上的欺騙手段，攻擊者使用一個透明的iframe，覆蓋在一個網頁上，然后誘使用戶在網頁上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面，通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。

HTTP響應頭信息中的X-Frame-Options，可以指示瀏覽器是否應該加載一個iframe中的頁面，如果服務器響應頭信息中沒有X-Frame-Options，則該網站存在ClickJacking攻擊風險。網站可以通過設置X-Frame-Options阻止站點內的頁面被其他頁面嵌入從而防止點擊劫持。

SpringSecurity配置允許嵌入iframe

配置類：

public class SpringSecurityConfig extends WebSecurityConfigurerAdapter

配置方法：

protected void configure(HttpSecurity http) throws Exception

配置代碼：

????????????此賬號為華為云開發者社區官方運營賬號，提供全面深入的云計算前景分析、豐富的技術干貨、程序樣例，分享華為云前沿資訊動態

本文分享自華為云社區《Web安全和瀏覽器跨域訪問》，原文作者：kg-follower 。

今天說一說和前端相關的 Web 安全問題和開發過程中經常遇到的跨域問題。

1．Web 安全

1.1 XSS

基本原理

XSS(Cross-Site Scripting)，跨站腳本攻擊通過在用戶的瀏覽器內運行非法的 HTML 標簽或 JavaScript 進行的一種攻擊。

攻擊手段

攻擊者往 Web 頁面里插入惡意網頁腳本代碼，當用戶瀏覽該頁面時，嵌入 Web 頁面里面的腳本代碼會被執行，從而達到攻擊者盜取用戶信息或其他侵犯用戶安全隱私的目的。

XSS 攻擊分類

反射型 xss 攻擊。通過給被攻擊者發送帶有惡意腳本的 URL 或將不可信內容插入頁面，當 URL 地址被打開或頁面被執行時，瀏覽器解析、執行惡意腳本。

反射型 xss 的攻擊步驟：1. 攻擊者構造出特殊的 URL 或特殊數據；2. 用戶打開帶有惡意代碼的 URL 時，Web 服務器將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器；3. 用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行；4. 惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。

防御：1.Web 頁面渲染的所有內容或數據都必須來自服務端；2. 客戶端對用戶輸入的內容進行安全符轉義，服務端對上交內容進行安全轉義；3.避免拼接 html。

存儲型 xss。惡意腳本被存儲在目標服務器上。當瀏覽器請求數據時，腳本從服務器傳回瀏覽器去執行。

存儲型 xss 的攻擊步驟：1. 攻擊者將惡意代碼提交到目標網站的數據庫中；2.用戶瀏覽到目標網站時，前端頁面獲得數據庫中讀出的惡意腳本時將其渲染執行。

防御：防范存儲型 XSS 攻擊，需要我們增加字符串的過濾：前端輸入時過濾；服務端增加過濾；前端輸出時過濾。

通常有三種方式防御 XSS 攻擊：1. ContentSecurity Policy（CSP）。CSP 本質上就是建立白名單，開發者明確告訴瀏覽器哪些外部資源可以加載和執行。我們只需要配置規則，如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來盡量減少 XSS 攻擊。通常可以通過兩種方式開啟，例如只允許加載相同域下的資源：

設置 HTTP Header 中的 CSP（Content-Security-Policy: default-src 'self'）

設置 meta 標簽的方式（<meta http-equiv="Content-Security-Policy"content="form-action 'self';">）

轉義字符

用戶的輸入永遠不可信任的，最普遍的做法就是轉義輸入輸出的內容，對于引號、尖括號、斜杠進行轉義：

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
}

但是對于顯示富文本來說，顯然不能通過上面的辦法來轉義所有字符，因為這樣會把需要的格式也過濾掉。對于這種情況，通常采用白名單過濾的辦法：

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
console.log(html)
<h1>XSS Demo</h1><script>alert("xss");</script>

經過白名單過濾，dom 中包含的<script>標簽將不會被執行。

HTTP-only Cookie

禁止 JavaScript 讀取某些敏感 cookie，使得 cookie 只有 http 能夠訪問。

1.2 CSRF

基本概念

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

CSRF 攻擊類型

主動型攻擊。用戶訪問網站 A 并在瀏覽器保存 A 的登錄狀態（cookie 等信息），攻擊者誘導受害者訪問網站 B，網站 B 含有訪問 A 接口的惡意代碼，受害者訪問 B 時帶著 A 的登錄狀態，攻擊者便可以冒充用戶執行對 A 的惡意操作。

被動型攻擊。攻擊者在網站 A 發布帶有惡意鏈接的評論或內容（提交對 A 帶有增刪改的誘導型標簽），當其他擁有登錄狀態的受害者點擊評論的惡意鏈接時，就會冒用受害者登錄憑證發起攻擊。

CSRF 攻擊防范

驗證 HTTP Referer 字段。在 HTTP 頭中有 Referer 字段，他記錄該 HTTP 請求的來源地址，如果跳轉的網站與來源地址相符，那就是合法的，如果不符則可能是 csrf 攻擊，拒絕該請求。

SameSite。可以對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求發送，可以很大程度減少 CSRF 的攻擊。

請求中加入 token。服務端給用戶生成一個 token，加密后傳遞給用戶，用戶在提交請求時，需要攜帶這個 token，服務端發現 token 不存在或者 token 校驗不成功，那么就拒絕該請求。

1.3 流量劫持

DNS 劫持

DNS 劫持就是通過劫持了 DNS 服務器，通過某些手段來取得某個域名的解析控制權，進而修改此域名的解析結果，導致對該域名的訪問由原 IP 地址轉入到修改后的 IP，其結果就是對特定的網站不能訪問或訪問的是假網址。

防御：使用 https 校驗通信雙方身份和數據完整性。

點擊劫持

攻擊者構建了一個非常有吸引力的網頁，將被攻擊的頁面放置在當前頁面的 iframe 中，使用樣式將 iframe 疊加到非常有吸引力內容的上方，將 iframe 設置為 100%透明，其實就是通過覆蓋不可見的頁面，誘導用戶點擊而造成的攻擊行為。

防御措施。1. X-FRAME-OPTIONS 設置允許 iframe 加載的域 2. 限制 iframe 頁面中的 JavaScript 腳本執行。

無論是 xss、csrf 還是點擊劫持，上面討論的這幾種攻擊屬于前端攻擊，原因大多是開發者的腳本或模板代碼存在不安全的隱患或是沒有考慮網絡傳輸安全問題。下面簡單說一說惡意攻擊利用網站后臺漏洞發起的攻擊。

1.4 SQL 注入

SQL 注入漏洞存在的原因，就是拼接 SQL 參數。也就是將用于輸入的查詢參數，直接拼接在 SQL 語句中，惡意攻擊者可以構造特殊的 sql 語句繞過安全驗證。

SQL 注入條件：1.攻擊者可以控制輸入的數據；2.服務器要執行的代碼拼接了被控制的數據。

SQL 注入防御。1. 嚴格限制 Web 應用的數據庫的操作權限；2. 對進入數據庫的特殊字符（’，”，，<，>，&，*，; 等）進行轉義處理，或編碼轉換，類似防御 xss 攻擊時對輸入轉義；3. 所有的查詢語句建議使用數據庫提供的參數化查詢接口，如使用占位參數或對象關系映射 ORM。

1.5 DDOS 攻擊

DOS 攻擊通過在網站的各個環節進行攻擊，使得整個流程跑不起來，以達到癱瘓服務為目的。最常見的就是發送大量請求導致服務器過載宕機。DDOS 攻擊的原理就是利用分布式的客戶端，向目標發起大量看上去合法的請求，消耗/占用大量資源，從而達到拒絕服務的目的。

攻擊方式：1.端口掃描；2.ping 洪水；3.SYN 洪水；4.FTP 跳轉攻擊；

DDOS 防范。1.在服務器上刪除未使用的服務，關閉未使用的端口。2. 進行實時監控，封禁某些惡意密集型請求 IP 段；3. 進行靜態資源緩存，隔離源文件的訪問，比如 CDN 加速；4. 隱藏服務器的真實 IP 地址

2. 跨域和同源策略

同源策略是一個重要的安全策略，它用于限制一個源的文檔或者它加載的腳本如何能與另一個源的資源進行交互。它能幫助阻隔惡意文檔，減少可能被攻擊的媒介。所謂同源是指“協議+域名+端口”三者均相同。

同源策略限制了客戶端 js 代碼的以下行為：

1.Cookie、LocalStorage 和 IndexDB 無法讀取；

2.DOM 節點。來自一個源的 js 只能讀寫自己源的 DOM 樹不能讀取其他源的 DOM 樹。如果兩個網頁不同源，就無法拿到對方的 DOM。典型的例子是 iframe 窗口和 window.open 方法打開的窗口，它們與父窗口無法通信。

網站不開啟同源策略，釣魚網站便可以使用 iframe 標簽加載中國銀行登錄界面，執行腳本進而拿到用戶名密碼。

當設置了同源策略，父子窗口執行獲取對方 DOM 時會報錯。

3.AJAX 請求限制

跨域并不是請求發不出去，請求能發出去，服務端能收到請求并正常返回結果，只是結果被瀏覽器攔截了。

除了架設服務器代理，還有以下幾種方法規避同源限制：JSONP，WebSocket，CORS，本文詳細討論下后兩種方法的實現。

WebSocket。WebSocket 是一種通信協議，使用 ws://（非加密）和 wss://（加密）作為協議前綴。該協議不實行同源政策，只要服務器支持，就可以通過它進行跨源通信。WebSocket 是一種雙向通信協議，在建立連接之后，WebSocket 的 server 與 client 都能主動向對方發送或接收數據。Websocket 請求頭信息包含一個 origin 字段，服務器根據這個字段判斷是否允許本次通信。

CORS。CORS 跨域資源共享是 W3C 標準，是解決跨域 Ajax 請求的最常見解決方法。整個 CORS 通信過程，都是瀏覽器自動完成，不需要用戶參與。對于開發者來說，CORS 通信與同源的 AJAX 通信沒有差別，代碼完全一樣。瀏覽器一旦發現 AJAX 請求跨源，就會自動添加一些附加的頭信息，有時還會多出一次附加的請求，但用戶不會有感覺。

瀏覽器將 CORS 請求分成兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。只要同時滿足以下兩大條件，就屬于簡單請求：

（1) 請求方法是以下三種方法之一：HEAD、GET、POST

（2）HTTP 的頭信息不超出以下幾種字段：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type：只限于三個值 application/x-www-form-urlencoded、multipart/form-data、text/plain

對于簡單請求，瀏覽器直接發出 CORS 請求。具體來說，就是在頭信息之中，增加一個 Origin 字段，該字段用來說明，本次請求來自哪個源。服務器根據這個值，決定是否同意這次請求。如果 Origin 指定的源，不在許可范圍內，服務器會返回一個正常的 HTTP 回應。若該響應的頭信息沒有包含 Access-Control-Allow-Origin 字段，就拋出一個錯誤，被 XMLHttpRequest 的 onerror 回調函數捕獲。若 Origin 指定的域名在許可范圍內，服務器返回的響應，會多出幾個頭信息字段。其中 Access-Control-Allow-Origin 字段是必須的。它的值要么是請求時 Origin 字段的值，要么是一個*，表示接受任意域名的請求。

對于非簡單請求，在正式通信之前，會增加一次 HTTP 查詢請求，稱為"預檢"請求（preflight）。瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可以使用哪些 HTTP 方法和頭信息字段。只有得到肯定答復，瀏覽器才會發出正式的 XMLHttpRequest 請求，否則就報錯。

"預檢"請求用的請求方法是 OPTIONS，表示這個請求是用來詢問的。頭信息里面，關鍵字段是 Origin，表示請求來自哪個源。

除了 Origin 字段，"預檢"請求的頭信息包括兩個特殊字段。

（1）Access-Control-Request-Method。該字段是必須的，用來列出瀏覽器的 CORS 請求會用到哪些 HTTP 方法

（2）Access-Control-Request-Headers。該字段是一個逗號分隔的字符串，指定瀏覽器 CORS 請求會額外發送的頭信息字段。

預檢請求的回應。

服務器收到"預檢"請求以后，檢查了 Origin、Access-Control-Request-Method 和 Access-Control-Request-Headers 字段以后，確認允許跨源請求，就可以做出回應。回應最關鍵的是 Access-Control-Allow-Origin 字段，表示允許該源的請求，若沒有任何 CORS 相關頭信息字段則說明服務器否認該請求。若服務器允許，則 Access-Control-Allow-Methods 字段是必須的，它的值是一個逗號分隔的字符串，表明服務器支持的方法。如果預檢請求包含 Access-Control-Request-Headers 字段，則返回體中該字段也是必須的，它也是一個逗號分隔的字符串，表明服務器支持的所有頭信息字段，不限于瀏覽器在"預檢"中請求的字段。預檢請求得到允許回應后，瀏覽器便發送正常 CORS 請求。

最近在開發一個前端 poc 項目時遇到了跨域資源訪問被限制的問題，在本地啟動 angular 項目，其他人可以通過 ip 訪問到靜態資源，發送 ajax 請求時被限制。于是想通過配置代理的方式解決這個跨域問題：在和 package.json 同級的目錄中新建 proxy.conf.json 文件，target 字段是后端服務真實的 ip，changeOrigin 字段設置為 true，關閉 secure 字段。

{
    "/": {
      "target": "http://10.173.99.224:8081/",
      "changeOrigin": true,
      "secure": false,
      "loglevel": "debug"
    }
}

?在 package.json 的啟動命令中添加

 "scripts": {
    "ng": "ng",
    "start": "ng serve --proxy-config proxy.conf.json --host 0.0.0.0",
    "build": "ng build",
    "watch": "ng build --watch --configuration development",
    "test": "ng test"
  },

--host0.0.0.0 表示監聽所有來源的主機。解決

點擊關注，第一時間了解華為云新鮮技術~

在線咨詢

上一篇：HTML表單標簽詳解：如何用HTML標簽打造互動網頁？
下一篇：想要成為最好的Web開發人員？十種方式測試你的HTML和CSS編程技能

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商

常見六大 Web 安全攻防解析 - 技術頭條

景

SpringSecurity配置允許嵌入iframe

1．Web 安全

1.1 XSS

1.2 CSRF

1.3 流量劫持

1.4 SQL 注入

1.5 DDOS 攻擊

2. 跨域和同源策略

您的項目需求