每個工程師都要學的安全測試，老闆不再用擔憂服務器被黑

本文由雲+社區發表

本篇包含了XSS漏洞攻擊及防護詳細介紹，包括漏洞基礎、XSS基礎、編碼基礎、XSS Payload、XSS攻擊防護。

---

第一部分：漏洞攻防基礎知識

XSS屬於漏洞攻防，咱們要研究它就要了解這個領域的一些行話，這樣纔好溝通交流。同時我創建了一個簡易的攻擊模型用於XSS漏洞學習。

1. 漏洞術語

瞭解一些簡單術語就好。

VUL

Vulnerability漏洞，指能對系統形成損壞或能借之攻擊系統的Bug。

POC

Proof of Concept，漏洞證實；能夠是能夠證實漏洞存在的文字描述和截圖，但更多的通常是證實漏洞存在的代碼；通常不會破壞存在漏洞的系統。

EXP

exploit，漏洞利用；利用漏洞攻擊系統的代碼。

Payload

（有效攻擊負載）是包含在你用於一次漏洞利用（exploit）中的攻擊代碼。

PWN

是一個黑客語法的俚語詞 ，是指攻破設備或者系統。

0DAY漏洞和0DAY攻擊

零日漏洞或零時差漏洞（Zero-dayexploit）一般是指尚未補丁的安全漏洞。

零日攻擊或零時差攻擊（Zero-dayattack）則是指利用這種漏洞進行的攻擊。

零日漏洞不可是黑客的最愛，掌握多少零日漏洞也成爲評價黑客技術水平的一個重要參數。

CVE漏洞編號

Common Vulnerabilities and Exposures,公共漏洞和暴露，爲普遍認同的信息安全漏洞或者已經暴露出來的弱點給出一個公共的名稱。

能夠在https://cve.mitre.org/網站根據漏洞的CVE編號搜索該漏洞的介紹。也能夠在中文社區http://www.scap.org.cn/上搜索...

2. 漏洞攻擊模型

1.png

上圖爲一個簡單的攻擊模型。攻擊就是將Payload經過注入點注入到執行點執行的過程。過程順暢就代表這個漏洞被利用了。

第二部分：XSS基礎知識

基礎知識看完，如今咱們能夠開始接觸瞭解XSS基礎了。XSS基礎很差就不用研究了，你們沒用共同語言。

1. 什麼是XSS？

XSS全稱Cross-site scripting，跨站腳本攻擊。攻擊者經過網站注入點注入惡意客戶端可執行解析的Payload，當被攻擊者訪問網站時Payload經過客戶端執行點執行來達到某些目的，好比獲取用戶權限、惡意傳播、釣魚等行爲。

2. XSS的分類

不瞭解分類其實很難學好XSS，你們對XSS分類有不少誤解，並且不少文章上都解釋錯的，這裏我給出一個相對好的XSS分類。

2.1 按照Payload來源劃分

存儲型XSS

Payload永久存在服務器上，因此也叫永久型XSS，當瀏覽器請求數據時，包含Payload的數據從服務器上傳回並執行。

過程如圖：

2.png

存儲型XSS例子：

發表帖子內容包含Payload->存入數據庫->被攻擊者訪問包含該帖子的頁面Payload被執行

反射型XSS

又稱非持久型XSS，第一種狀況：Payload來源在客戶端而後在客戶端直接執行。第二種狀況：客戶端傳給服務端的臨時數據，直接回顯到客戶端執行。

過程如圖：

3.png

反射型XSS例子 ：

1. 傳播一個連接，這個連接參數中包含Payload->被攻擊者訪問這個連接Payload在客戶端被執行。
2. 在客戶端搜索框輸入包含payload的內容->服務端回顯一個頁面提示搜索內容未找到，payload就被執行了。

2.2 按照Payload的位置劃分

DOM-based XSS

由客戶端JavaScript代碼操做DOM或者BOM形成Payload執行的漏洞。因爲主要是操做DOM形成的Payload執行，因此叫作DOM-based XSS,操做BOM一樣也能夠形成Payload執行，因此這個名詞有些不許確，其實叫JavaScript-based XSS更好。

DOM-based的Payload不在html代碼中因此給自動化漏洞檢測帶來了困難。

過程如圖：

4.png

反射型DOM-based XSS的例子：

在客戶端搜索框輸入包含payload的內容->服務端回顯一個頁面提示搜索內容未找到，payload就被執行了。

存儲型DOM-based XSS的例子：

從服務端接口中獲取包含Payload的內容->JavaScript經過操做DOM、BOM形成Payload執行

HTML-based XSS

Payload包含在服務端返回的HTML中，在瀏覽器解析HTML的時候執行。這樣的漏洞易於作自動化漏洞檢測，由於Payload就在HTML裏面。固然HTML-based XSS也有反射型和存儲型的。

過程如圖：

5.png

反射型HTML-based XSS的例子：

在客戶端搜索框輸入包含payload的內容->服務端回顯一個頁面提示搜索內容未找到，payload包含在HTML被執行。

存儲型HTML-based XSS的例子：

發表帖子內容包含Payload->存入數據庫->被攻擊者訪問包含該帖子的頁面Payload在HTML頁面中被執行

3. XSS的攻擊目的及危害

不少寫出不安全代碼的人都是對漏洞的危害沒有清晰的認識，下圖是2017 OWASP 網絡威脅Top10：

6_頭圖 自截取.jpg

能夠看到XSS在網絡威脅中的地位舉足輕重。

3.1 目的

1. cookie劫持
2. 篡改網頁，進行釣魚或者惡意傳播
3. 網站重定向
4. 獲取用戶信息

3.2 危害

1. 傳播類危害
2. 系統安全威脅

第三部分：XSS攻擊的Payload

這部分咱們分析下攻擊模型中的Payload,瞭解Payload必須瞭解編碼，學習好JS也必需要了解好編碼。要想真正作好網絡安全編碼是最基本的。

1. 編碼基礎

編碼部分是最重要的雖然枯燥但必需要會。後面不少變形的Payload都創建在你的編碼基礎。這裏通16進制編碼工具讓你完全學會編碼。

1.1 編碼工具

16進制查看器：方便查看文件16進制編碼

MAC:HEx Friend

windows: HxD

編輯器Sublime：能夠經過Sublime將文件保存不一樣編碼類型

7.jpg

1.2 ASCII

定義：美國信息交換標準代碼，是基於拉丁字母的一套計算機編碼系統，主要用於顯示現代英語和其餘西歐語言。

編碼方式：屬於單子節編碼。ASCII碼一共規定了128個字符的編碼，只佔用了一個字節的後面7位，最前面的1位統一規定爲0。0～31及127(共33個)是控制字符或通訊專用字符。32～126(共95個)是字符(32是空格。

1.3 ISO-8859-1(Latin1)

定義：Latin1是ISO-8859-1的別名,ISO-8859-1收錄的字符除ASCII收錄的字符外，還包括西歐語言、希臘語、泰語、阿拉伯語、希伯來語對應的文字符號。歐元符號出現的比較晚，沒有被收錄在ISO-8859-1當中。

編碼方式：ISO-8859-1編碼是單字節編碼，向下兼容ASCII，其編碼範圍是0x00-0xFF，0x00-0x7F之間徹底和ASCII一致，0x80-0x9F之間是控制字符，0xA0-0xFF之間是文字符號。

注意：ISO-8859-1編碼表示的字符範圍很窄，沒法表示中文字符。可是，因爲是單字節編碼，和計算機最基礎的表示單位一致，因此不少時候，仍舊使用ISO-8859-1編碼來表示。好比，雖然」中文」兩個字不存在iso8859-1編碼，以gb2312編碼爲例，應該是」d6d0 cec4」兩個字符，使用iso8859-1編碼的時候則將它拆開爲4個字節來表示：」d6 d0 ce c4」（事實上，在進行存儲的時候，也是以字節爲單位處理的）。因此mysql中latin1能夠表示任何編碼的字符。

Latin1與ASCII編碼的關係：徹底兼容ASCII。

1.4 Unicode編碼(UCS-2)

Code Point: 碼點，簡單理解就是字符的數字表示。一個字符集通常能夠用一張或多張由多個行和多個列所構成的二維表來表示。二維表中行與列交叉的點稱之爲碼點，每一個碼點分配一個惟一的編號，稱之爲碼點值或碼點編號。

BOM（Byte Order Mark）：字節序，出如今文件頭部，表示字節的順序，第一個字節在前，就是」大端方式」（Big-Endian），第二個字節在前就是」小端方式」（Little-Endian）。

在Unicode字符集中有一個叫作」ZERO WIDTH NO-BREAK SPACE「的字符，它的碼點是FEFF。而FFFE在Unicode中是不存在的字符，因此不該該出如今實際傳輸中。在傳輸字節流前，咱們能夠傳字符」ZERO WIDTH NO-BREAK SPACE「表示大小端，所以字符」ZERO WIDTH NO-BREAK SPACE「又被稱做BOM。

BOM還能夠用來表示文本編碼方式，Windows就是使用BOM來標記文本文件的編碼方式的。Mac上文件有沒有BOM均可以。

例如：u00FF :00是第一個字節，FF是第二個字節。和碼點表示方式同樣屬於大端方式。

Unicode編碼字符集：旨在收集全球全部的字符，爲每一個字符分配惟一的字符編號即代碼點（Code Point），用 U+緊跟着十六進制數表示。全部字符按照使用上的頻繁度劃分爲 17 個平面（編號爲 0-16），即基本的多語言平面和增補平面。基本的多語言平面又稱平面 0，收集了使用最普遍的字符，代碼點從 U+0000 到 U+FFFF，每一個平面有 216=65536 個碼點；

Unicode編碼：Unicode 字符集中的字符能夠有多種不一樣的編碼方式，如 UTF-八、UTF-1六、UTF-3二、壓縮轉換等。咱們一般所說的Unicode編碼是UCS-2 將字符編號（同 Unicode 中的碼點）直接映射爲字符編碼，亦即字符編號就是字符編碼，中間沒有通過特別的編碼算法轉換。是定長雙字節編碼：由於咱們UCS-2只包括本的多語言平面（U+0000 到 U+FFFF)。

UCS-2的BOM：大端模式：FEFF。小端模式：FFFE。

文件保存成UTF-16 BE with BOM至關於UCS-2的大端模式，能夠看到16進制開頭爲FEFF

Latin1與Unicode編碼的關係：Latin1對應於Unicode的前256個碼位。

8.png

1.5 UTF-16

定義及編碼：UTF-16是Unicode的其中一個使用方式,在Unicode基本多文種平面定義的字符（不管是拉丁字母、漢字或其餘文字或符號），一概使用2字節儲存。而在輔助平面定義的字符，會以代理對（surrogate pair）的形式，以兩個2字節的值來儲存。是雙字節編碼。

UTF-16與UCS-2的關係：UTF-16可當作是UCS-2的父集。在沒有輔助平面字符（surrogate code points）前，UTF-16與UCS-2所指的是同一的意思。但當引入輔助平面字符後，就稱爲UTF-16了。如今如有軟件聲稱本身支援UCS-2編碼，那實際上是暗指它不能支援在UTF-16中超過2bytes的字集。對於小於0x10000的UCS碼，UTF-16編碼就等於UCS碼。

UTF-16的BOM：大端模式：FEFF。小端模式：FFFE。

1.6 UTF-8

定義及編碼：UTF-8就是在互聯網上使用最廣的一種Unicode的實現方式，這是爲傳輸而設計的編碼，並使編碼無國界，這樣就能夠顯示全世界上全部文化的字符了。UTF-8最大的一個特色，就是它是一種變長的編碼方式。它可使用1~4個字節表示一個符號，根據不一樣的符號而變化字節長度，當字符在ASCII碼的範圍時，就用一個字節表示，保留了ASCII字符一個字節的編碼做爲它的一部分，注意的是unicode一箇中文字符佔2個字節，而UTF-8一箇中文字符佔3個字節）。從unicode到utf-8並非直接的對應，而是要過一些算法和規則來轉換。

Unicode符號範圍	UTF-8編碼方式(十六進制)
0000 0000-0000 007F	0xxxxxxx
0000 0080-0000 07FF	110xxxxx 10xxxxxx
0000 0800-0000 FFFF	1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

UTF8的BOM：EFBBBF。UTF-8不存在字符序列的問題，可是能夠用用BOM表示這個文件是一個UTF-8文件。

文件保存成UTF-8 BE with BOM，能夠看到16進制開頭爲EFBBBF

9.png

1.7 GBK/GB2312

定義及編碼：GB2312是最先一版的漢字編碼只包含6763漢字，GB2312只支持簡體字並且不全，顯然不夠用。GBK編碼，是對GB2312編碼的擴展，徹底兼容GB2312標準，支持簡體字繁體字，包含所有中文字符。GBK編碼採用單雙字節編碼方案，單字節和Latin1一致，雙字節是漢字部分，其編碼範圍：8140－FEFE，剔除xx7F碼位，共23940個碼位。

GBK與Latin1的關係：GBK單字節編碼區和Latin1編碼一致。

GBK與Unicode的關係：GBK與Unicode字符集編碼不一樣可是兼容的。如＂漢＂的Unicode值與GBK雖然是不同的，假設Unicode爲a040，GBK爲b030，可是能夠對應轉化的。漢字的Unicode區：4E00-u9FA5。

GBK與UTF-8：GBK漢字採用雙字節編碼比在UTF-8中的三字節要小。可是UTF-8更通用。GBK與UTF-8轉化：GBK—> Unicode —> UTF8

2. 前端中的編碼

有了編碼基礎就能夠來認識一下前端中的編碼，這樣你才能真正認識Payload。我這裏的應該是總結最全的。

2.1 Base64

Base64能夠用來將binary的字節序列數據編碼成ASCII字符序列構成的文本。使用時，在傳輸編碼方式中指定Base64。使用的字符包括大小寫拉丁字母各26個、數字10個、加號+和斜槓/，共64個字符及等號=用來做爲後綴用途。因此總共65個字符。

將3字節的數據，前後放入一個24位的緩衝區中，先來的字節佔高位。數據不足3字節的話，於緩衝器中剩下的比特用0補足。每次取出6bit對原有數據用Base64字符做爲編碼後的輸出。編碼若原數據長度不是3的倍數時且剩下1個輸入數據，則在編碼結果後加2個=；若剩下2個輸入數據，則在編碼結果後加1個=。能夠看出Base64編碼數據大約是原來數據的3/4。

標準的Base64並不適合直接放在URL裏傳輸，由於URL編碼器會把標準Base64中的/和+字符變爲形如%XX的形式，而這些%號在存入數據庫時還須要再進行轉換，由於ANSI SQL中已將%號用做通配符。爲解決此問題，可採用一種用於URL的改進Base64編碼，它不在末尾填充=號，並將標準Base64中的+和/分別改爲了-和_，這樣就免去了在URL編解碼和數據庫存儲時所要作的轉換，避免了編碼信息長度在此過程當中的增長，並統一了數據庫、表單等處對象標識符的格式。

window.btoa/window.atob base64編碼(binary to ascii)和解碼僅支持Latin1字符集。

2.2 JS轉義字符

js字符字符串中包含一些反斜槓開頭的特殊轉義字符，用來表示非打印符、其餘用途的字符還能夠轉義表示unicode、Latin1字符。

轉義字符	含義
’	單引號
」	雙引號
&	和號
\	反斜槓
n	換行符
r	回車符
t	製表符
b	退格符
f	換頁符
n … nnn	由一位到三位八進制數（1到377）指定的Latin-1字符
xnn	以16進制nn（n:0~F)表示一個Latin1字符。x41表示字符A
unnnn	以16進制nnnn(n:0~F)表示一個Unicode字符。只限於碼點在u0000~uFFFF範圍內
u{n} … u{nnnnnn}	Unicode碼點值表示一個Unicode字符

特別注意：

1. 換行符n在innerHTML使用只會展現一個空格並不會換行。
2. 經過n、u和x能夠表明任意unicode字符和Latin1字符。經過這個能夠對js加密保證js安全和進行隱蔽攻擊。

例子：

function toUnicode(theString) {  //字符串轉換爲unicode編碼字符串，切記這個字符串是複製用的，不是讓你拿來直接執行的。
 var unicodeString = '';
 for (var i = 0; i < theString.length; i++) {
  var theUnicode = theString.charCodeAt(i).toString(16).toUpperCase();
  while (theUnicode.length < 4) {
    theUnicode = '0' + theUnicode;
  }
  theUnicode = '\\u' + theUnicode;
  unicodeString += theUnicode;
 }
 return unicodeString;
}
var xssStr = "alert('xss')";
var xssStrUnicode = toUnicode(xssStr);
//輸出："\u0061\u006C\u0065\u0072\u0074\u0028\u0027\u0078\u0073\u0073\u0027\u002"
eval("\u0061\u006C\u0065\u0072\u0074\u0028\u0027\u0078\u0073\u0073\u0027\u002"); //彈出xss彈窗

2.3 URL編碼

RFC 1738作出規定」只有字母和數字0-9a-zA-Z、一些特殊符號」$-_.+!*’(),」不包括雙引號、以及某些保留字，才能夠不通過編碼直接用於URL」。因此當連接中包含中文或者其餘不符合規定的字符的時候都須要通過編碼的。然而因爲瀏覽器廠商衆多，對url進行編碼的形式多種多樣，若是不對編碼進行統一處理，會對代碼開發形成很大的影響，出現亂碼現象。

URL編碼規則：須要編碼的字符轉換爲UTF-8編碼，而後在每一個字節前面加上%。

例如：

'牛'-->UTF-8編碼E7899B-->URL編碼是%E7%89%9B

JS爲咱們提供了3個對字符串進行URL編碼的方法：escape ，encodeURI，encodeURIComponent

escape：因爲eccape已經被建議放棄因此你們就不要用了

encodeURI：encodeURI不編碼的82個字符：!#$&’()*+,/:;=?@-._~0-9a-zA-Z，從中能夠看不會對url中的保留字符進行編碼，因此適合url總體編碼

encodeURIComponent：這個對於咱們來講是最有用的一個編碼函數，encodeURIComponent不編碼的字符有71個：!， ‘，(，)，*，-，.，_，~，0-9，a-z，A-Z。

能夠看出對url中的保留字進行的編碼，因此當傳遞的參數中

包含這些url中的保留字（@，&,=)，就能夠經過這個方法編碼後傳輸

這三個方法對應的解碼方法： unescape、decodeURI、decodeURIComponent

2.4 HTML字符實體

HTML中的預留字符必須被替換爲字符實體。這樣才能當成字符展現，不然會當成HTML解析。

字符實體編碼規則：轉義字符 = +ascii碼; = &實體名稱;

XSS字符串須要防護字符的實體轉換表：

10.png

轉化方法：

function encodeHTML (a) {
 return String(a)
   .replace(/&/g, "&")
   .replace(/</g, "<")
   .replace(/>/g, ">")
   .replace(/"/g, """)
   .replace(/'/g, "'");
};

2.5 頁面編碼

頁面編碼設置：

<meta charset="UTF-8">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

腳本編碼設置：

<script type="text/javascript" src="myscripts.js" charset="UTF-8"></script>

注意：要想JS便可在UTF-8中正常使用又能夠在GBK中正常使用，能夠對JS中全部包含中文的字符串作字符轉義。

例子：

alert("網絡錯誤");     //彈出網絡錯誤

alert("\u7f51\u7edc\u9519\u8bef"); //彈出網絡錯誤

3. Payload的分類

如今能夠認識Payload的了，我不得不說這裏對Payload的分類能夠很好的讓你認識Payload。也幫助你更好的對應到執行點。

3.1 原子Payload

最低層級的Payload。

javascript代碼片斷

可在eval、setTimeout、setInterval中直接執行，也可經過HTML等構成高階Payload

javascript：javascript僞協議

結構：javascript:+js代碼。能夠在a標籤的href屬性被點擊和window.location.href賦值的時候執行。

DATA URI協議

DATA URI結構：data:, 。DATA URI數據在包含在iframe的src屬性和object data屬性中將會變成可執行的Payload.

字符串轉義變種javascript代碼片斷

unicode或者Latin-1表示字符串。

eval("\u0061\u006C\u0065\u0072\u0074\u0028\u0027\u0078\u0073\u0073\u0027\u002"); //可執行的JS

3.2 純HTMLPayload

這種Payload特色不具備可執行的JS，可是存在傳播風險，能夠把別的站點注入到被攻擊網站。

包含連接跳轉的HTML片斷

主要是傳播危害

<a href="http://ha.ck">哈哈，我來釣魚了</a>

3.3 包含原子Payload的HTML片斷Payload

script標籤片斷

script標籤片斷這種Payload能夠引入外部JS或者可直接執行的script。這種Payload通常不能經過直接複製給innerHTML執行，不過在IE上能夠。不過經過document.write是能夠執行。

例子：

// Payload原始值:data:text/html,<script>alert('xss');</script>

var inputStr ="<script>alert('xss');<\/script>";

document.write(inputStr);

包含事件處理的HTML片斷

例如：包含img的onerror, svg的onload,input的onfocus等的HTML片斷，均可以變成可執行的Payload。

var inputStr ="<img src=x onerror=alert('xss');>";

var inputStr ="<svg/onload=alert('xss')>";

var inputStr ="<input autofocus onfocus=alert('xss')>";

xssDom.innerHTML = inputStr;

包含可執行JS屬性的HTML片斷

1. javascript僞協議

xssLink.setAttribute("href","javascript:alert('xss')")//點擊可觸發

var inputStr = "javascript:alert('xss')";

window.location.href = inputStr;

1. DATA URI

例子：

// Payload原始值:data:text/html,<script>alert('xss');</script>

//var inputStr = '<iframe src="data:text/html,<script>alert("xss");</script>"></iframe>';

// var inputStr = '<object data="data:text/html;base64,ZGF0YTp0ZXh0L2h0bWwsPHNjcmlwdD5hbGVydCgneHNzJyk7PC9zY3JpcHQ+"></object>';

xssDom.innerHTML = inputStr; //彈出alert("xss")

這裏只是介紹了主要的Payload，還有不少不常見的Payload。

第四部分：XSS攻擊模型分析

這部分咱們根據漏洞攻擊模型分析一下XSS的執行點和注入點。分析這兩點其實就是找漏洞的過程。

1. XSS漏洞執行點

1. 頁面直出Dom
2. 客戶端跳轉連接： location.href / location.replace() / location.assign()
3. 取值寫入頁面：innerHTML、document.write及各類變種。這裏主要會寫入攜帶可執行Payload的HTML片斷。
4. 腳本動態執行：eval、setTimeout()、setInterval()
5. 不安全屬性設置：setAttribute。不安全屬性前面見過：a標籤的href、iframe的src、object的data
6. HTML5 postMessage來自不安全域名的數據。
7. 有缺陷的第三方庫。

2. XSS漏洞注入點

看看咱們能夠在哪些位置注入咱們的Payload

1. 服務端返回數據
2. 用戶輸入的數據
3. 連接參數：window.location對象三個屬性href、search、search
4. 客戶端存儲:cookie、localStorage、sessionStorage
5. 跨域調用：postMessage數據、Referer、window.name

上面內容基本包含了全部的執行點和注入點。對你們進行XSS漏洞攻防頗有幫助。

第五部分 XSS攻擊防護策略

1. 騰訊內部公共安全防護及應急響應

1. 接入公共的DOM XSS防護JS
2. 內部漏洞掃描系統掃描
3. 騰訊安全應急響應中心：安全工做者能夠經過這個平臺提交騰訊相關的漏洞，並根據漏洞評級得到獎勵。
4. 重大故障應急響應制度。

2. 安全編碼

2.1 執行點防護方法

執行點	防護
頁面直出Dom	服務端XSS過濾
客戶端跳轉連接	域名白名單（例如：只容許qq.com域）、連接地址XSS過濾
取值寫入頁面	客戶端XSS過濾
腳本動態執行	確保執行Js字符串來源可信

|

| 不安全屬性設置 | 內容XSS過濾，包含連接同客戶端跳轉連接 |

|HTML5 postMessage|origin限制來源|

| 有缺陷的第三方庫 | 不使用

2.2 其餘安全防護手段

1. 對於Cookie使用httpOnly
2. 在HTTP Header中使用Content Security Policy

3. 代碼審查

總結XSS檢查表作代碼自測和檢視

4. 自動化檢測XSS漏洞的工具

手工檢測XSS漏洞是一件比較費時間的事情，咱們能不能寫一套自動檢測XSS自動檢測工具。居然我知道了注入點、執行點、Payload自動化過程是徹底有可能的。

XSS自動化檢測的難點就在於DOM型XSS的檢測。由於前端JS複雜性較高，包括靜態代碼分析、動態執行分析都不容易等。

第六部分 總結

上面內容文字比較多，看完仍是很累的，總結起來就一句話：安全大於一切，不要心存僥倖，但願以上內容對您有幫助，不過以上內容僅表明我的理解，若有不對歡迎指正討論。

此文已由做者受權騰訊雲+社區發佈