前言

隨著互聯(lián)網(wǎng)的高速發(fā)展佛猛，信息安全問題已經(jīng)成為企業(yè)最為關(guān)注的焦點(diǎn)之一缘眶，而前端又是引發(fā)企業(yè)安全問題的高危據(jù)點(diǎn)概说。在移動(dòng)互聯(lián)網(wǎng)時(shí)代面殖，特別是前端人員除了傳統(tǒng)的 XSS履澳、CSRF 等安全問題之外嘶窄，又時(shí)常遭遇網(wǎng)絡(luò)劫持、非法調(diào)用 Hybrid API 等新型安全問題距贷。當(dāng)然柄冲，瀏覽器自身也在不斷在進(jìn)化和發(fā)展，不斷引入 CSP忠蝗、SameSite现横、HttpOnly、Cookies 等新技術(shù)來增強(qiáng)安全性阁最，但是仍存在很多潛在的威脅戒祠，這需要我們不斷進(jìn)行“查漏補(bǔ)缺”

瀏覽器安全可以分為三大塊：Web頁面安全、瀏覽器網(wǎng)絡(luò)安全闽撤、瀏覽器系統(tǒng)安全

Web頁面安全主要就是同源策略限制

什么是同源策略

同源指的是我們?cè)L問站點(diǎn)的：協(xié)議得哆、域名、端口號(hào)必須一至哟旗，才叫同源贩据。

瀏覽器默認(rèn)同源之間的站點(diǎn)是可以相互訪問資源和操作DOM的，而不同源之間想要互相訪問資源或者操作DOM闸餐，那就需要加一些安全策略的限制饱亮，俗稱同源策略

同源策略主要限制了三個(gè)方面：

1. DOM層面：不同源站點(diǎn)之間不能相互訪問和操作DOM
2. 數(shù)據(jù)層面：不能獲取不同源站點(diǎn)的Cookie、LocalStorage舍沙、indexDB等數(shù)據(jù)
3. 網(wǎng)絡(luò)層面：不能通過XMLHttpRequest向不同源站點(diǎn)發(fā)送請(qǐng)求

當(dāng)然同源策略限制也不是絕對(duì)隔離不同源的站點(diǎn)近上，比如link、img拂铡、script標(biāo)簽都沒有跨域限制壹无，這讓我們開發(fā)更靈活了，但是也同樣帶來了一些安全問題感帅，也就是瀏覽器網(wǎng)絡(luò)安全問題斗锭，最典型的就是XSS攻擊和CSRF攻擊

說一下XSS攻擊

XSS攻擊是一種代碼注入攻擊，通過惡意注入腳本在瀏覽器運(yùn)行失球，然后盜取用戶信息

造成XSS攻擊其實(shí)本質(zhì)上還是因?yàn)榫W(wǎng)站沒有過濾惡意代碼岖是，與正常代碼混在一起之后，瀏覽器沒有辦法分辨哪些是可信的，然后導(dǎo)致惡意代碼也被執(zhí)行豺撑。然后可能導(dǎo)致以下情況：

• 頁面數(shù)據(jù)或用戶信息被竊取烈疚，如DOM、Cookie聪轿、LocalStorage
• 修改DOM爷肝，比如偽造登錄窗口或在頁面生成浮窗廣告
• 監(jiān)聽用戶行為，比如在登錄或銀行等站點(diǎn)用 addEventListener 監(jiān)聽鍵盤事件屹电，竊取賬號(hào)密碼等信息
• 流量被劫持向其他網(wǎng)站

XSS攻擊有三種類型：存儲(chǔ)型阶剑、反射型、DOM型

1. 存儲(chǔ)型：是在有發(fā)貼評(píng)論等帶有數(shù)據(jù)保存功能的網(wǎng)站的input危号、textarea將惡意代碼提交到網(wǎng)站數(shù)據(jù)庫中，如<script src="http://惡意網(wǎng)站"></script> 素邪，然后比如在顯示評(píng)論的頁面就會(huì)從數(shù)據(jù)獲取外莲，并直接執(zhí)行這個(gè)script標(biāo)簽里的惡意代碼

2. 反射型：是攻擊者將惡意JS腳本作為用戶發(fā)送給網(wǎng)站請(qǐng)求中的一部分，然后網(wǎng)站又把惡意腳本返回給用戶兔朦，這時(shí)候就會(huì)在頁面中被執(zhí)行偷线。比如打開包含帶惡意腳本的鏈接，當(dāng)打開后會(huì)向服務(wù)器請(qǐng)求后沽甥，服務(wù)器會(huì)獲取URL中的數(shù)據(jù)然后拼接在HTML上返回声邦，然后執(zhí)行。它和存儲(chǔ)型不同的是不會(huì)儲(chǔ)存在服務(wù)器里

3. 基于DOM型：就是攻擊者通過一些劫持手段摆舟，在頁面資源傳輸過程中劫持并修改頁面的數(shù)據(jù)亥曹，插入惡意代碼

怎么防范XSS攻擊，有什么解決辦法恨诱？

• 就是對(duì)輸入框的內(nèi)容進(jìn)行過濾或使用轉(zhuǎn)義符進(jìn)行轉(zhuǎn)碼

  字符	轉(zhuǎn)義后的字符
  <	&lt;
  >	&gt;
  "	&quot;
  '	&#x27;
  /	&#x2F
  &	&amp;

• 使用CSP媳瞪，就是白名單，告訴瀏覽器哪些外部資源可以加載執(zhí)行照宝，讓即使插入進(jìn)來惡意代碼的也不會(huì)執(zhí)行蛇受，或者可以向哪些第三方站點(diǎn)提交數(shù)據(jù)。開啟白名單的方式有兩種：

  • 使用 meta 標(biāo)簽 <meta http-equiv="Content-Security-Policy">
  • 設(shè)置http頭部的 Content-Security-Policy

• 對(duì)一些敏感信息進(jìn)行保護(hù)厕鹃，在Cookie信息中添加httpOnly兢仰，告訴瀏覽器在保存Cookie，且不要對(duì)客戶端腳本開放訪問權(quán)限剂碴，然后就不能通過document.cookie獲取cookie了

Set-Cookie: widget_session=123456; httpOnly

• 使用驗(yàn)證碼把将，避免腳本偽裝成用戶執(zhí)行一些操作

說一下CSRF攻擊

就是跨站請(qǐng)求偽造攻擊，主要就是利用用戶的登錄狀態(tài)發(fā)起跨站請(qǐng)求汗茄，比如郵箱里的亂七八糟的鏈接秸弛，打開鏈接的時(shí)候郵箱肯定是處于登錄狀態(tài)，然后黑客就可以用這個(gè)登錄狀態(tài)，偽造帶有正確 Cookie 的 http 請(qǐng)求递览，直接繞過后臺(tái)的登錄驗(yàn)證叼屠，然后冒充用戶執(zhí)行一些操作

發(fā)起CSRF攻擊有三個(gè)必要條件：

1. 目標(biāo)網(wǎng)站一定要有CSRF漏洞
2. 用戶登錄過目標(biāo)網(wǎng)站，并且瀏覽器保存了登錄狀態(tài)
3. 需要用戶主動(dòng)打開第三方站點(diǎn)

本質(zhì)是利用cookie在同源請(qǐng)求中攜帶發(fā)送給服務(wù)器的特點(diǎn)绞铃，來實(shí)現(xiàn)冒充用戶

CSRF攻擊也有三種類型：GET類型镜雨、POST類型、鏈接型

• 自動(dòng)發(fā)GET類型：比如img或iframe標(biāo)簽等儿捧，當(dāng)用戶打開這個(gè)網(wǎng)站時(shí)會(huì)自動(dòng)發(fā)起帶Cookie的資源請(qǐng)求

<img src="http://惡意網(wǎng)址" >

• 自動(dòng)發(fā)POST類型：比如整一個(gè)隱藏的表單荚坞，在用戶進(jìn)入頁面的時(shí)候自動(dòng)提交表單

<form id="hack" action="https://惡意網(wǎng)址" method="post">
    ...
</form>
<script>document.getElementById('hack').submit()</script>

• 誘導(dǎo)鏈接型：就是誘導(dǎo)用戶主動(dòng)點(diǎn)擊鏈接，比如a標(biāo)簽

<a href="https://惡意網(wǎng)址">點(diǎn)擊領(lǐng)取大禮包</a>
<a href="https://惡意網(wǎng)址">點(diǎn)擊下載美女視頻</a>

怎么防范CSRF攻擊菲盾，有什么解決辦法颓影？

1. 在Cookie信息中添加SameSite屬性，這個(gè)屬性有三個(gè)值：

   • strict：嚴(yán)格模式懒鉴，完全禁止使用Cookie
   • lax：寬松模式诡挂，允許部分情況使用Cookie，跨域的都行临谱，a標(biāo)簽跳轉(zhuǎn)璃俗，link標(biāo)簽，GET提交表單
   • none：任何情況下都會(huì)發(fā)送Cookie悉默，但必須同時(shí)設(shè)置Secure屬性城豁，意思是需要安全上下文，Cookie 只能通過https發(fā)送抄课，否則無效

   Chrome 80之前默認(rèn)值是none唱星，之后是lax

Set-Cookie: widget_session=123456; SameSite=None; Secure

2. 驗(yàn)證請(qǐng)求來源：服務(wù)器根據(jù)http請(qǐng)求頭中的Origin或Referer屬性判斷是否為允許訪問的站點(diǎn)，從而對(duì)請(qǐng)求進(jìn)行過濾剖膳。優(yōu)先判斷Origin魏颓，如果兩個(gè)都不存在的話就直接阻止。

• Referer：記錄了請(qǐng)求是從哪個(gè)鏈接跳過來的并且包含了路徑信息吱晒，也就是來源地址甸饱。不過這家伙不太可靠，所以后來又新增了Origin屬性

Referer: https://juejin.cn/editor/drafts/xxxx

• origin：記錄了域名信息仑濒，沒有具體的URL路徑

Origin: https://juejin.cn

3. Token驗(yàn)證：服務(wù)器向用戶返回一個(gè)隨機(jī)數(shù)Token叹话，再次請(qǐng)求時(shí)在請(qǐng)求頭中以參數(shù)的形式添加入這個(gè)Token，然后服務(wù)器驗(yàn)證這個(gè)Token墩瞳，如果沒有或者內(nèi)容不正確驼壶，就拒絕請(qǐng)求。缺點(diǎn)是

   • 每個(gè)請(qǐng)求都得添加比較繁瑣
   • 單方面驗(yàn)證Cookie可能會(huì)被冒用喉酌，
   • 如果網(wǎng)站不止一臺(tái)服務(wù)器热凹，通過負(fù)載均衡轉(zhuǎn)到了其他服務(wù)器的話泵喘，其他所有服務(wù)器中的Session中都得保留Token，不然就驗(yàn)證不了了

4. 雙重驗(yàn)證Cookie：利用攻擊者只能利用Cookie般妙，不能獲取Cookie的特點(diǎn)纪铺，用戶訪問頁面時(shí)，服務(wù)器向請(qǐng)求域名添加一個(gè)Cookie隨機(jī)字符串碟渺，然后鲜锚，用戶再次請(qǐng)求時(shí)從Cookie中取出這個(gè)字符串，添加到URL參數(shù)中苫拍，然后服務(wù)器通過對(duì)Cookie中的數(shù)據(jù)和參數(shù)中的數(shù)據(jù)對(duì)比驗(yàn)證芜繁，不一樣就拒絕請(qǐng)求。

   缺點(diǎn)是如果網(wǎng)站存在XSS漏洞绒极，這法子就會(huì)失效骏令，而且不能做到子域名的隔離

瀏覽器系統(tǒng)安全 - 安全沙箱

首先，我們?cè)O(shè)想一下集峦，如果我們下載了一個(gè)惡意程序伏社，但是沒有執(zhí)行它，對(duì)我們有沒有影響塔淤？

那肯定沒有，而瀏覽器也是一樣的

瀏覽器可以安全地下載各種網(wǎng)絡(luò)資源速妖，但是執(zhí)行的時(shí)候就需要謹(jǐn)慎了高蜂。比如解析HTML、CSS罕容、執(zhí)行JS等操作备恤，一不小心黑客就會(huì)利用這些操作對(duì)有漏洞的瀏覽器發(fā)起攻擊

所以需要在渲染進(jìn)程和操作系統(tǒng)之間建一堵墻，有這堵墻在擋著锦秒，黑客能黑進(jìn)來露泊，也只能獲取渲染進(jìn)的操作權(quán)限(如下圖)，不會(huì)影響到外面旅择，而這隔離操作系統(tǒng)和渲染進(jìn)程的一堵墻就是安全沙箱

安全沙箱最小的保護(hù)單位是進(jìn)程惭笑，并且能限制進(jìn)程對(duì)操作系統(tǒng)資源的訪問和修改，這就意味著生真，安全沙箱所在的進(jìn)程不能有讀寫操作系統(tǒng)的功能沉噩，比如讀寫本地文件、發(fā)起網(wǎng)絡(luò)請(qǐng)求柱蟀，調(diào)用GPU接口等

安全沙箱怎么影響各個(gè)模塊功能

• 持久存儲(chǔ)
  • 存儲(chǔ)Cookie的讀寫川蒙，瀏覽器內(nèi)核會(huì)維護(hù)一個(gè)存放所有Cookie的Cookie數(shù)據(jù)庫，在渲染進(jìn)程通過JS讀取Cookie時(shí)长已，渲染進(jìn)程會(huì)通過IPC將讀取Cookie的信息發(fā)送給內(nèi)核畜眨，瀏覽器內(nèi)核讀取Cookie之后再將內(nèi)容通過IPC返回給渲染進(jìn)程
  • 緩存文件的讀寫也是由瀏覽器內(nèi)核實(shí)現(xiàn)
• 網(wǎng)絡(luò)訪問：渲染進(jìn)程不能直接訪問網(wǎng)絡(luò)昼牛，也需要通過瀏覽器內(nèi)核，而瀏覽器內(nèi)核在處理URL請(qǐng)求之前康聂，會(huì)檢查渲染進(jìn)程有沒有權(quán)限請(qǐng)求該URL贰健，比如有沒有跨域
• 用戶交互
  • 輸入時(shí)：操作系統(tǒng)會(huì)將輸入事件傳給瀏覽器內(nèi)核，內(nèi)核判斷如果是地址欄輸入事件就直接在內(nèi)核處理早抠，如果是頁面里的就轉(zhuǎn)發(fā)給渲染進(jìn)程
  • 渲染時(shí)：渲染進(jìn)程渲染出位圖后霎烙，需要將生成好的位圖發(fā)送給瀏覽器內(nèi)核，再由內(nèi)核將位圖復(fù)制到屏幕上顯示

站點(diǎn)隔離你知道嗎

我們知道一個(gè)標(biāo)簽頁會(huì)有一個(gè)渲染進(jìn)程蕊连，假如這個(gè)標(biāo)簽頁里面有多個(gè)不同站點(diǎn)的 iframe 呢悬垃？ 這就會(huì)導(dǎo)致多個(gè)不同站點(diǎn)的內(nèi)容運(yùn)行在同一個(gè)渲染進(jìn)程中，這肯定不行

所有操作系統(tǒng)中都存在兩個(gè)A級(jí)漏洞：幽靈（Spectre）和熔毀（Meltdown）甘苍，這是處理器架構(gòu)導(dǎo)致的尝蠕，很難修補(bǔ)

如果銀行頁面中有一個(gè)惡意 iframe ，這個(gè)惡意站點(diǎn)利用兩個(gè)A級(jí)漏洞入侵渲染進(jìn)程载庭，那惡意程序就可以讀取銀行站點(diǎn)渲染進(jìn)程內(nèi)所有內(nèi)容了看彼，這對(duì)用戶來說風(fēng)險(xiǎn)就很大了，如果沒有沙箱保護(hù)囚聚，甚至還可以對(duì)操作系統(tǒng)發(fā)起攻擊

所以后來Chrome對(duì)渲染進(jìn)程進(jìn)行重構(gòu)靖榕，將標(biāo)簽級(jí)的渲染進(jìn)程改成 iframe 級(jí)渲染進(jìn)程，就是說一個(gè)標(biāo)簽頁內(nèi)可能運(yùn)行多個(gè)渲染進(jìn)程顽铸，并且相互隔離茁计，這樣惡意 iframe 就無法訪問頁面中其他的內(nèi)容了，也就無法攻擊其他站點(diǎn)了谓松，這就是站點(diǎn)隔離

中間人攻擊

在 http 數(shù)據(jù)提交給 TCP 層之后星压，會(huì)經(jīng)過用戶電腦、路由器鬼譬、運(yùn)營商娜膘、服務(wù)器，這中間每一個(gè)環(huán)節(jié)优质，都不是安全的

一句話就是：在 http 傳輸過程中容易被中間人竊取竣贪、偽造、篡改盆赤，這種攻擊方式稱為中間人攻擊贾富。

那怎么讓數(shù)據(jù)可以更安全的傳輸呢？

就是使用 https 牺六，利用 https 安全層對(duì)數(shù)據(jù)進(jìn)行加解密操作颤枪，以保證數(shù)據(jù)安全。

關(guān)于 https性能優(yōu)化淑际、版本畏纲、優(yōu)缺點(diǎn)扇住、SSL/TLS、握手(RSA盗胀、TLS1.2艘蹋、TLS1.3)三個(gè)版本及優(yōu)化等等，文章太長這里就不展開了票灰，可以看我另一篇文章有詳細(xì)介紹

那么 https 是如何對(duì)數(shù)據(jù)加解密的呢女阀？這要先說一下它的算法

對(duì)稱加密算法

就是加密和解密使用同一個(gè)密鑰。如AES屑迂、DES浸策。加解密過程：

1. 瀏覽器給服務(wù)器并發(fā)送一個(gè)隨機(jī)數(shù)client-random和加密套件(一個(gè)支持的加密方法列表)
2. 服務(wù)器生成給瀏覽器返回另一個(gè)隨機(jī)數(shù)server-random和加密套件
3. 兩邊分別返回確認(rèn)消息。然后兩者用加密方法將兩個(gè)隨機(jī)數(shù)混合生成密鑰惹盼，這就是通信雙上加解密的密鑰

有了密鑰之后就可以對(duì)數(shù)據(jù)進(jìn)行加密傳輸了

問題是client-random和server-random都是明文的庸汗，雙方如何安全的傳遞兩個(gè)隨機(jī)數(shù)和加密方法呢？直接傳給客戶端手报，那過程中就很可能被竊取蚯舱，中間人還是能解密拿到數(shù)據(jù)，往下看

不對(duì)稱加密算法

就是一對(duì)密鑰掩蛤，有公鑰(public key)和私鑰(private key)枉昏，其中一個(gè)密鑰加密后的數(shù)據(jù)，只能用另一個(gè)密鑰進(jìn)行解密揍鸟。如RSA凶掰、ECDHE。加解密過程：

1. 瀏覽器給服務(wù)器發(fā)送加密套件
2. 服務(wù)器選好支持的加密方法和公鑰(明文) 傳給瀏覽器
3. 兩邊分別返回確認(rèn)消息蜈亩。然后瀏覽器用公鑰對(duì)數(shù)據(jù)進(jìn)行加密，這個(gè)密鑰只能用私鑰解密

這是不是看上去很完美了

其實(shí)還存在很嚴(yán)重的問題

1. 使用公鑰反推出私鑰是非常困難前翎，但不是做不到稚配，隨著計(jì)算機(jī)運(yùn)算能力提高，非對(duì)稱密鑰至少要2048位才能保證安全性港华，這就導(dǎo)致加解密速度慢道川，效率太低
2. 無法保證服務(wù)器發(fā)送給瀏覽器的數(shù)據(jù)安全。因?yàn)闉g覽器可以用公鑰來加密立宜，而瀏覽器就只能用私鑰加密冒萄，公鑰是明文傳輸?shù)模虚g人可以獲取到橙数，這樣服務(wù)器端的數(shù)據(jù)安全就得不到保證了

所以尊流！

混合加密

TLS實(shí)際用的是兩種算法的混合加密。通過 非對(duì)稱加密算法 交換 對(duì)稱加密算法 的密鑰灯帮，交換完成后崖技，再使用對(duì)稱加密進(jìn)行加解密傳輸數(shù)據(jù)逻住。這樣就保證了會(huì)話的機(jī)密性。過程如下

1. 瀏覽器給服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)client-random迎献、對(duì)稱和非對(duì)稱加密套件
2. 服務(wù)器把另一個(gè)隨機(jī)數(shù)server-random瞎访、加密套件、公鑰傳給瀏覽器
3. 瀏覽器又生成另一個(gè)隨機(jī)數(shù)pre-random吁恍，并用公鑰對(duì) pre-random 加密后傳給服務(wù)器
4. 服務(wù)器再用私鑰解密扒秸，得到pre-random，并返回確認(rèn)消息
5. 這樣瀏覽器和服務(wù)器都有三個(gè)隨機(jī)數(shù)了冀瓦，然后各自將三個(gè)隨機(jī)數(shù)用加密方法混合生成最終的對(duì)稱密鑰

然后開始數(shù)據(jù)加密傳輸

這樣即便被截持伴奥，中間人沒有私鑰就拿不到pre-random，就無法生成最終密鑰

這樣就安全了嗎咕幻？

emmmm......還沒

因?yàn)閱栴}又來了渔伯，如果一開始DNS就被中間人劫持，那么請(qǐng)求被中間人截獲肄程，中間人把他自己的服務(wù)器公鑰給了瀏覽器锣吼，瀏覽器收到公鑰就把信息發(fā)給中間人了，中間人解密拿到數(shù)據(jù)蓝厌，并干了一些見不得人的勾當(dāng)之后玄叠，再請(qǐng)求實(shí)際服務(wù)器，拿到服務(wù)器公鑰拓提，再把加密處理過后的數(shù)據(jù)發(fā)給服務(wù)器

這樣不知不覺間信息就被人竊取了读恃，所以在結(jié)合對(duì)稱和非對(duì)稱加密的基礎(chǔ)上，還需要服務(wù)器向?yàn)g覽器證明身份代态，那怎么證明呢寺惫？

所以數(shù)字證書來了，往下看

如何保證數(shù)據(jù)是否被篡改蹦疑？

數(shù)字證書(數(shù)字簽名)

它可以幫我們驗(yàn)證服務(wù)器身份西雀，而且數(shù)字證書里包含了公鑰，而數(shù)字證書需要向有權(quán)威的認(rèn)證機(jī)構(gòu)(CA)獲取授權(quán)給服務(wù)器歉摧。

相比之前就變成了

• 服務(wù)器不直接返回公鑰給瀏覽器艇肴，而是返回?cái)?shù)字證書，而公鑰就在數(shù)字證書中
• 瀏覽器這邊多了一步證書驗(yàn)證叁温，驗(yàn)證成功才能繼續(xù)后續(xù)流程

那么如何申請(qǐng)數(shù)字證書呢再悼？

• 首先，服務(wù)器準(zhǔn)備一套公鑰和私鑰膝但，私鑰留著自己用
• 服務(wù)器將公鑰和站點(diǎn)等信息提交給CA認(rèn)證冲九，這個(gè)是要錢的
• CA驗(yàn)證服務(wù)器提供的信息
• 審核通過后簽發(fā)認(rèn)證的數(shù)字證書，包含了公鑰锰镀、CA信息娘侍、有效時(shí)間咖刃、證書序列等這些都是明文的，還有一個(gè)CA生成的簽名

CA的簽名過程

• CA也有一套公鑰和私鑰
• CA使用摘要算法計(jì)算服務(wù)器提交的明文信息并得出信息摘要
• 然后CA再用它的私鑰和特定的算法對(duì)信息摘要加密憾筏，生成簽名
• 把簽名嚎杨、服務(wù)器公鑰等信息打包放入數(shù)字證書，并返回給服務(wù)器
• 服務(wù)器配置好證書氧腰，以后瀏覽器連接服務(wù)器枫浙，都先把證書發(fā)給客戶端驗(yàn)證

摘要算法：主要用于保證信息的完整性。常見的MD5算法古拴、散列函數(shù)箩帚、hash函數(shù)都屬于這類算法，其特點(diǎn)就是單向性黄痪、無法反推原文

瀏覽器如何驗(yàn)證數(shù)字證書

• 瀏覽器連接服務(wù)器紧帕，都先把證書發(fā)給客戶端驗(yàn)證
• 使用CA公鑰和聲明的簽名算法對(duì)CA中的簽名進(jìn)行解密，得到服務(wù)器的摘要內(nèi)容和服務(wù)器公鑰
• 再用摘要算法對(duì)證書里的服務(wù)器公鑰生成摘要桅打，再把這個(gè)摘要和上一步得到的摘要對(duì)比
• 然后將兩個(gè)信息摘要對(duì)比是嗜，如果是一致的，就說明證書是合法的挺尾，即證明了服務(wù)器自己鹅搪，否則就是非法的

證書認(rèn)證又分為單向認(rèn)證和雙向認(rèn)證

單向認(rèn)證：服務(wù)器發(fā)送證書，客戶端驗(yàn)證證書
雙向認(rèn)證：服務(wù)器和客戶端分別提供證書給對(duì)方遭铺，并互相驗(yàn)證對(duì)方的證書

不過大多數(shù)https服務(wù)器都是單向認(rèn)證丽柿，如果服務(wù)器需要驗(yàn)證客戶端的身份，一般通過用戶名魂挂、密碼甫题、手機(jī)驗(yàn)證碼等之類的憑證來驗(yàn)證。只有更高級(jí)別的要求的系統(tǒng)涂召，比如大額網(wǎng)銀轉(zhuǎn)賬等幔睬，就會(huì)提供雙向認(rèn)證的場景，來確保對(duì)客戶身份提供認(rèn)證性

另外在申請(qǐng)和使用證書的過程中芹扭，需要注意

• 申請(qǐng)數(shù)字證書是不需要提供私鑰的，要確保私鑰永遠(yuǎn)只能由服務(wù)器掌握
• 數(shù)字證書最核心的是CA使用它的私鑰生成的數(shù)字簽名
• 內(nèi)置CA對(duì)應(yīng)的證書稱為根證書赦抖，根證書是最權(quán)威的機(jī)構(gòu)舱卡，它們自己為自己簽名，這稱為自簽名證書

有了這些之后就安全了嗎队萤？

emmmmm.....沒有

雖然不是絕對(duì)安全轮锥，但是現(xiàn)行架構(gòu)下最安全的解決文案了，大大增加了中間人的攻擊成本

結(jié)語

點(diǎn)贊支持要尔、手留余香舍杜、與有榮焉

參考

瀏覽器工作原理與實(shí)踐

HTTPS：網(wǎng)絡(luò)安全攻堅(jiān)戰(zhàn)