关于前端:一道面试题牵出12个前端硬核知识点你能答出几个

一道面试题囊括多个高频知识点的的确不多，但的确有一个神奇的药引子——浏览器平安能串联起 12 个前端硬核知识点，一起来瞅瞅！！！

说到 Web 页面平安你会想到哪些问题呢？

什么是同源、什么是同源策略、同源策略的体现是什么？
浏览器出让了同源策略的哪些安全性？
跨域解决方案有哪些？
JSONP 如何实现？
CORS 你理解哪些？
针对 Web 页面平安有哪些常见的攻打伎俩 (XSS、CSRF)？

1.2 浏览器网络安全

说到浏览器网络安全你会想到哪些问题呢？
什么是申请报文？
什么是响应报文？
HTTP 毛病
HTTPS 根底知识点
HTTPS 流程

1.3 浏览器系统安全

说到浏览器系统安全你会想到哪些问题呢？
平安沙箱

跨域实质其实就是指两个地址不同源，不同源的背面不就是同源，同源指的是：如果两个 URL 的协定、域名和端口号都雷同，则就是两个同源的 URL。

// 非同源: 协定不同
http://www.baidu.com
https://www.baidu.com

// 同源: 协定、域名、端口号都雷同
http://www.baidu.com
http://www.baidu.com?query=1

同源策略是一个重要的安全策略，它用于限度一个 origin 的文档或者它加载的加载的脚本如何能与另一个源的资源进行交互。其次要是为了爱护用户信息的平安，避免歹意的网站窃取数据，是浏览器在 Web 页面层面做的平安爱护。

既然同源策略是浏览器在 Web 页面层面做的爱护，那么该层面哪些地位须要进行爱护呢？总结下来次要蕴含三个层面：DOM 层面、数据层面、网络层面。

DOM 层面

同源策略限度了来自不同源的 JavaScript 脚本对以后 DOM 对象读和写的操作。

数据层面

同源策略限度了不同源的站点读取以后站点的 Cookie、IndexedDB、localStorage 等数据。

网络层面

同源策略限度了通过 XMHttpRequest 等形式将站点的数据发送给不同源的站点。

同源策略保障了浏览器的平安，然而如果将这三个层面限度的死死的，则会让程序员的开发工作举步维艰，所以浏览器须要在最严格的同源策略限度下做一些退让，这些退让更多了是在安全性与便捷性的衡量。其实跨域的形式就能够认为是浏览器出让了一些安全性或在恪守浏览器同源策略前提下所采取的一种折中伎俩。

依据同源策略，如果两个页面不同源，无奈相互操作 DOM、拜访数据，然而两个不同源页面之间进行通信是比拟常见的情景，典型的例子就是 iframe 窗口与父窗口之间的通信。随着历史的车轮，实现 DOM 层面间通信的形式有多种，如下所示：

片段标识符

片段标识符其外围原理就是通过监听 url 中 hash 的扭转来实现数据的传递，想法真的很奇妙。

// 父页面 parentHtml.html
<!DOCTYPE html>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>
        我是父页面
        <button id='btn'> 父传给子 </button>
        <iframe src="./childHtml.html" id="childHtmlId"></iframe>
    </body>
    <script>
        window.onhashchange = function() {console.log(decodeURIComponent(window.location.hash));
        };
        document.getElementById('btn').addEventListener('click', () => {const iframeDom = document.getElementById('childHtmlId');
            iframeDom.src += '# 父传给子';
        });
    </script>
</html>

// 子页面 childHtml.html
<!DOCTYPE html>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>
        我是子页面
        <button id='btn'> 子传给父 </button>
    </body>
    <script>
        window.onhashchange = function() {console.log(decodeURIComponent(window.location.hash));
        };

        document.getElementById('btn').addEventListener('click', () => {parent.location.href += '# 子传给父';});
    </script>
</html>

window.name

浏览器窗口有 window.name 属性，这个属性的最大特点是，无论是否同源，只有在同一个窗口里，前一个网页设置了这个属性，后一个网页能够读取它。如果须要实现父页面和跨域的子页面之间的通信，须要一个和父页面同源的子页面作为中介，将跨域的子页面中的信息传递过去。（好麻烦呀，强烈不举荐应用，此处就不写对应的代码啦）

document.domain

document.domain 是寄存文档的服务器的主机名，可通过手动设置将其设置成以后域名或者下级的域名，当具备雷同 document.domain 的页面就相当于处于同域名的服务器上，如果其域名和端口号雷同就能够实现跨域拜访数据了。

postMessage（强烈推荐）

window.postMessage 是 HTML5 新增的跨文档通信 API，该 API，容许跨窗口通信，不管这两个窗口是否同源。

// 父页面
<!DOCTYPE html>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>
        我是父页面
        <button id='btn'> 父传给子 </button>
        <iframe src="http://127.0.0.1:5500/024/childHtml.html" id="childHtmlId"></iframe>
    </body>
    <script>
        window.addEventListener('message', function(event) {console.log('父页面接管到信息', event.data);
        });
        document.getElementById('btn').addEventListener('click', () => {const iframeDom = document.getElementById('childHtmlId');
            iframeDom.contentWindow.postMessage('我是执鸢者 1', 'http://127.0.0.1:5500/024/childHtml1.html');
        });
    </script>
</html>

// 子页面
<!DOCTYPE html>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>
        我是子页面
        <button id='btn'> 子传给父 </button>
    </body>
    <script>
        window.addEventListener('message', function(event) {console.log('子页面接管到信息', event.data);
        });

        document.getElementById('btn').addEventListener('click', () => {parent.postMessage('我是执鸢者 2', 'http://127.0.0.1:5500/024/parentHtml1.html');
        });
    </script>
</html>

依据同源策略，浏览器默认是不容许 XMLHttpRequest 对象拜访非同一站点的资源的，这会大大制约生产力，所以须要破解这种限度，实现跨域拜访资源。目前宽泛采纳的次要有三种形式（注：该出不给出具体代码，后续会有专门的百题斩进行具体论述）：

2.2.2.1 通过代理实现

同源策略是浏览器为了平安制订的策略，所以服务端不会存在这样的限度，这样咱们就能够将申请打到同源的服务器上，而后经由同源服务器代理至最终须要的服务器，从而实现跨域申请的目标。例如能够通过 Nginx、Node 中间件等。

2.2.2.2 JSONP 的形式

JSONP 是一种借助 script 元素实现跨域的技术，它并没有应用 XMLHttpRequest 对象，其可能实现跨域次要得益于 script 有两个特点：

（1）src 属性可能拜访任何 URL 资源，并不会受到同源策略的限度；

（2）如果拜访的资源蕴含 JavaScript 代码，其会在下载后主动执行。

上面一起来实现一下 JSONP

全局挂载一个接收数据的函数；
创立一个 script 标签，并在其标签的 onload 和 onerror 事件上挂载对应处理函数；
将 script 标签挂载到页面中，向服务端发动申请；
服务端接管传递过去的参数，而后将回调函数和数据以调用的模式输入；
当 script 元素接管到影响中的脚本代码后，就会主动执行它们。

function createScript(url, charset) {const script = document.createElement('script');
    script.setAttribute('type', 'text/javascript');
    charset && script.setAttribute('charset', charset);
    script.setAttribute('src', url);
    script.async = true;
    return script;
}

function jsonp(url, onsuccess, onerror, charset) {const hash = Math.random().toString().slice(2);
    window['jsonp' + hash] = function (data) {if (onsuccess && typeof(onsuccess) === 'function') {onsuccess(data);
        }
    }

    const script = createScript(url + '?callback=jsonp' + hash, charset);

    // 监听加载胜利的事件，获取数据，这个地位用了两个事件 onload 和 onreadystatechange 是为了兼容 IE，因为 IE9 之前不反对 onload 事件，只反对 onreadystatechange 事件
    script.onload = script.onreadystatechange = function() {
        // 若不存在 readyState 事件则证实不是 IE 浏览器，能够间接执行，若是的话，必须等到状态变为 loaded 或 complete 才能够执行
        if (!this.readyState || this.readyState === 'loaded' || this.readyState === 'complete') {
            script.onload = script.onreadystatechange = null;
            // 移除该 script 的 DOM 对象
            if (script.parentNode) {script.parentNode.removeChild(script);
            }

            // 删除函数或变量
            window['jsonp' + hash] = null;
        }
    };

    script.onerror = function() {if (onerror && typeof(onerror) === 'function') {onerror();
        }
    }

    // 增加标签，发送申请
    document.getElementsByTagName('head')[0].appendChild(script);
}

2.2.2.3 CORS 形式

跨域资源共享（CORS），该机制能够进行跨域访问控制，从而使跨域数据传输得以平安进行。(实现一个跨域申请的形式，其中 html 拜访网址为 http://127.0.0.1:8009; 服务器监听端口为：8010)
一、整体流程

CORS 的通信流程是浏览器主动实现，不须要用户参加，其外围点是服务器，只有服务器实现了 CORS 接口就能够实现跨源通信了。尽管是浏览器主动实现，然而浏览器其实还是依据申请时字段的不同分为简略申请和非简略申请的，上面对这两者进行简要介绍。

简略申请
(1) 定义

只有满足以下两个条件就属于简略申请：

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 三个中的一个）。

（2）流程

简略申请的整个流程能够归结为以下步骤：

1）浏览器间接收回 CORS 申请，具体来说就是在头信息之中减少一个 Origin 字段，该字段用来阐明申请来自哪个源（协定 + 域名 + 端口），服务器依据这个值决定是否批准这次申请；
2）当服务器接管到申请后，依据 Origin 断定指定的源是否在许可的范畴内。
3）如果不在许可范畴内，服务器会返回一个失常的 HTTP 回应，浏览器发现该回应的头信息没有蕴含 Access-Control-Allow-Origin 字段，就晓得出错了，从而抛出谬误，被 XML 的 onerror 回调函数捕捉。（留神：因为失常回应，其状态码为 200，所以该谬误不能通过状态码辨认）
4）如果 Origin 指定的域名在许可范畴内，服务器返回的响应中会多出几个头信息字段（Access-Control-Allow-Origin、Access-Control-Allow-Credentials、Access-Control-Expose-Header 等）。

（3）关键字段

1）Access-Control-Allow-Origin

必须字段，该值要么是申请的 Origin 字段值，要么是一个 *（示意承受任意域名的申请）。

2）Access-Control-Allow-Credentials

可选字段，其值是一个布尔值，示意是否容许发送 Cookie。默认是不发送 Cookie 值，当设置为 true 时，示意服务器明确许可，Cookie 能够蕴含在申请中发送给服务器。（留神：发送 Cookie 时要留神两点：一方面在 Ajax 申请中须要设置 withCredentials 属性；另一方面不能将 Access-Control-Allow-Origin 设置为 *, 须要指定明确的、与申请网页统一的域名）

3）Access-Control-Expose-Header

可选字段，当 CORS 申请时，XMLHttpRequest 对象的 getResponseHeader() 办法只能拿到 6 个根本字段（Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma），如果想获取其它字段必须在 Access-Control-Expose-Header 中指定。

非简略申请

（1）定义

不是简略申请的就是非简略申请，非简略申请是那种对服务器有特殊要求的申请，比方申请办法是 PUT 或 Delete，或者 Content-Type 字段的类型是 application/json.

（2）流程

非简略申请相比于简略申请较简单，在发动正式申请之前会进行一次预检申请，通过预检申请的后果来决定是否进行后续的正式通信。

1）浏览器发动预检申请，该申请的申请办法是 options，该申请是用来询问的；
2）服务器收到“预检”申请当前，查看了 Origin、Access-Control-Request-Method 和 Access-Control-Request-Headers 字段当前，确认容许跨源申请，就能够做出回应。
3）如果浏览器否定了“预检”申请，会返回一个失常的 HTTP 回应，然而没有任何 CORS 相干的头信息字段，这时浏览器就会认定服务器不批准预检申请，触发谬误；
4）如果浏览器通过了“预检”申请，当前每次浏览器失常的 CORS 申请就跟简略申请一样，会有一个 Origin 头信息字段，服务器的回应也会有一个 Access-Control-Allow-Origin 头信息字段；

（3）关键字段

1）Access-Control-Request-Method

必须字段，用来列出浏览器的 CORS 申请会用到哪些 HTTP 办法。

2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，用来指定浏览器 CORS 申请会额定发送的头信息字段。

3）Access-Control-Allow-Methods

必须字段，该值是一个逗号分隔的字符串，用来表明服务器反对的所有跨域申请的办法。

4）Access-Control-Allow-Headers

该值是一个逗号分隔的字符串，表明服务器反对的所有头信息字段。

5）Access-Control-Max-Age

用来申请预检申请的有效期，单位为秒。

简略实现

(1)html 页面内容

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>test CORS</title>
    </head>
    <body>
        CORS
        <script src="https://code.bdstatic.com/npm/axios@0.20.0/dist/axios.min.js"></script>
        <script>
            axios('http://127.0.0.1:8010', {method: 'get'}).then(console.log)
        </script>
    </body>
</html>

(2) 服务器端代码

const express = require('express');

const app = express();

app.get('/', (req, res) => {console.log('get 申请收到了！！！');
    res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:8009');
    res.send('get 申请曾经被解决');
})
app.listen(8010, () => {console.log('8010 is listening')
});

2.3.1.1 定义

跨站脚本攻打（XSS；Cross Site Scripting）是指黑客往 HTML 文件中或者 DOM 中注入歹意脚本，从而在用户浏览页面时利用注入的歹意脚本对用户施行攻打的一种伎俩。

2.3.1.2 产生的影响

XSS 攻打产生的影响次要有：盗取 Cookie 信息、监听用户行为、批改 DOM、在页面内生成浮窗广告等。

2.3.1.3 注入形式

XSS 注入形式有存储型 XSS 攻打、反射型 XSS 攻打、基于 DOM 的 XSS 攻打。

2.3.1.4 什么状况容易产生 XSS 攻打

容易产生 XSS 攻打的地位次要有两个：

数据从一个不牢靠的链接进入到一个 web 应用程序
没有过滤掉恶意代码的动静内容被发送给 Web 用户

2.3.1.5 如何阻止 XSS 攻打

阻止 XSS 攻打的形式次要有三种：

服务器对输出脚本进行过滤或转码；
充分利用 CSP；
应用 HttpOnly 属性

2.3.2.1 定义

跨站申请伪造（CSRF；Cross-site request forgery）指的是黑客诱惑用户关上黑客的网站，在黑客的网站中，利用用户的登录状态发动的跨站申请

2.3.2.2 产生影响

产生影响次要有以下几点：

2.3.2.3 攻打原理

2.3.2.4 攻打的前提条件

攻打的前提条件次要有以下三点：

2.3.2.5 攻击方式

施行 CSRF 攻打的形式次要有以下三点：

主动发动 Get 申请；
主动发动 POST 申请；
诱惑用户点击链接

2.3.2.6 避免 CSRF 攻打的策略

避免 CSRF 攻打的策略次要有以下三种：

充分利用好 Cookie 的 SameSite 属性；
在服务器端验证申请的起源站点；
CSRF Token。

HTTP 申请报文次要包含：申请行、申请头部以及申请的数据（实体）, 上面一起看看其组成内容：

申请行蕴含：办法字段、URI 字段和协定版本

办法字段

GET（申请获取内容）；

POST（提交表单）；

HEAD（申请资源响应消息报头）；

PUT（传输文件）；

DELETE（申请删除 URI 指向的资源）；

OPTIONS（查问针对申请 URI 指定的资源反对的办法）；

TRACE（追踪申请通过门路）；

CONNECT（要求用隧道协定连贯代理）。
URI 字段
协定版本

指的就是本次申请的 HTTP 协定版本，例如 HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2.0、HTTP/3.0.

常见标头有：Connection 标头（连贯治理）、Host 标头（指定申请资源的主机）、Range 标头（申请实体的字节范畴）、User-Agent 标头（蕴含发出请求的用户信息）、Accept 标头（首选的媒体类型）、Accept-Language(首选的自然语言)

HTTP 申请的 body 次要用于提交表单场景。实际上，http 申请的 body 是比拟自在的，只有浏览器端发送的 body 服务端认可就能够了。一些常见的 body 格局是：

application/json
application/x-www-form-urlencoded
multipart/form-data
text/xml

应用 html 的 form 标签提交产生的 html 申请，默认会产生 application/x-www-form-urlencoded 的数据格式，当有文件上传时，则会应用 multipart/form-data。

HTTP 响应报文分为三个局部：状态行、首部行和响应体.

状态行是由版本、状态码和起因语句组成，上面来看看一些罕用的状态码。

1xx：这一类型的状态码，代表申请已被承受，须要持续解决。这类响应是长期响应，只蕴含状态行和某些可选的响应头信息，并以空行完结
2xx：这一类型的状态码，代表申请已胜利被服务器接管、了解并承受

200—OK/ 申请曾经失常处理完毕;

204— 申请解决胜利，但没有资源返回;

206— 示意客户端进行了范畴申请，而服务器胜利执行了这部分的 GET 申请;

3xx：这类状态码代表须要客户端采取进一步的操作能力实现申请。通常，这些状态码用来重定向，后续的申请地址（重定向指标）在本次响应的 Location 域中指明

301— 申请永恒重定向被申请的资源已永恒挪动到新地位，并且未来任何对此资源的援用都应该应用本响应返回的若干个 URI 之一。如果可能，领有链接编辑性能的客户端该当主动把申请的地址批改为从服务器反馈回来的地址。

302— 申请长期重定向因为这样的重定向是长期的，客户端该当持续向原有地址发送当前的申请。只有在 Cache-Control 或 Expires 中进行了指定的状况下，这个响应才是可缓存的。

303— 示意因为申请对应的资源存在着另一个 URI，应应用 GET 办法定向获取申请的资源

304— 示意客户端发送附带条件的申请（指采纳 GET 办法的申请报文中蕴含 If-Match，If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since 中任一首部）时，服务端容许申请拜访资源，但未满足条件的状况

307— 长期重定向，与 302 含意雷同，然而 307 会遵循浏览器规范，不会从 POST 变成 GET

4xx：这类状态码代表客户端类的谬误

400— 客户端申请存在语法错误

401— 以后申请须要用户验证。

403— 服务器曾经了解申请，然而拒绝执行它。与 401 响应不同的是，身份验证并不能提供任何帮忙

404— 申请失败，申请所心愿失去的资源未被在服务器上发现。

405— 申请行中指定的申请办法不能被用于申请相应的资源。

5xx：服务器类的谬误

500— 服务器遇到了一个未曾意料的情况，导致了它无奈实现对申请的解决。

501— 服务器不反对以后申请所须要的某个性能。当服务器无奈辨认申请的办法，并且无奈反对其对任何资源的申请。

503— 因为长期的服务器保护或者过载，服务器以后无奈解决申请。

505— 服务器不反对，或者回绝反对在申请中应用的 HTTP 版本。

常见的响应首部有：Date（响应的工夫）、Via（报文通过的两头节点）、Last-Modified（上一次批改工夫）、Etag（与此实体相干的实体标记）、Connection（连贯状态）、Accept-Ranges（服务器可接管的范畴类型）、Content-Type（资源类型）

响应体就是响应的音讯体，如果是纯数据就是返回纯数据，如果申请的是 HTML 页面，那么返回的就是 HTML 代码，如果是 JS 就是 JS 代码等。

正是因为 HTTP 存在一系列的毛病，所以才会呈现 HTTPS，那么 HTTP 存在哪些毛病呢？该如何解决的呢？上面来进行简要概述

1.HTTP 通信应用明文（不加密），内容可能会被窃听；

TCP/IP 是可能被窃听的网络：按 TCP/IP 协定族的工作机制，通信内容在所有线路上都有可能受到窥视。所以须要加密解决避免被窃听，加密的对象如下：

（1）通信的加密

通过和 SSL(Secure Socket Layer，安全套接层) 或 TLS(Transport Layer Security，平安层传输协定) 的组合应用，加密 HTTP 的通信内容。用 SSL 建设平安通信线路之后，就能够在这条线路上进行 HTTP 通信了。与 SSL 组合应用的 HTTP 称为 HTTPS，通过这种形式将整个通信线路加密。

（2）内容的加密

因为 HTTP 协定中没有加密机制，那么就对 HTTP 协定传输的内容自身加密。为了做到无效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。该形式不同于将整个通信线路加密解决，内容仍有被篡改的危险。

2. 不验证通信方的身份，因而有可能遭逢假装；

（1）任何人都可发动申请

HTTP 协定不论是谁发送过去的申请都会返回响应，因而不确认通信方，会存在以下隐患：

1）无奈确定申请发送至指标的 Web 服务器是否是按真是用意返回响应的那台服务器，有可能是已假装的 Web 服务器；

2）无奈确定响应返回到的客户端是否是依照实在用意接管响应的那个客户端，有可能是假装的客户端；

3）无奈确定正在通信的对方是否具备拜访权限，因为某些 Web 服务器上保留着重要的信息，只想发给特定用户通信的权限；

4）无奈判断申请是来自何方、出自谁手，即便是无意义的申请也会照单全收，无奈阻止海量申请下的 Dos 攻打 (Denial of Service，拒绝服务攻打)。

（2）查明对手的证书

SSL 不仅提供加密解决，还应用了一种被称为证书的伎俩，可用于确定通信方。证书由值得信赖的第三方机构颁发，用以证实服务器和客户端是理论存在的。应用证书，以证实通信方就是意料中的服务器，对使用者集体来讲，也缩小了个人信息泄露的危险性。另外，客户端持有证书即可实现个人身份的确认，也可用于对 Web 网站的认证环节。

3. 无奈证实报文的完整性，所以有可能已遭逢篡改。

在申请或响应送出之后直到对方接管之前的这段时间内，即便申请或响应的内容受到篡改，也没有方法获悉。在申请或响应的传输途中，遭攻击者拦挡并篡改内容的攻打称为中间人攻打 (Man-in-the-Middle attack)。仅靠 HTTP 确保完整性是十分艰难的，便有赖于 HTTPS 来实现。SSL 提供认证和加密解决及摘要性能。

HTTPS 并非是应用层的一种新协定。只是 HTTP 通信接口局部用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协定代替而已，简言之就是 HTTP+ 通信加密 + 证书 + 完整性爱护形成 HTTPS，是身披 TLS/SSL 这层外壳的 HTTP。

TLS/SSL 性能

TLS/SSL 协定应用通信单方的客户证书以及 CA 根证书，容许客户 / 服务器利用以一种不能被偷听的形式通信，在通信单方间建设起了一条平安的、可信赖的通信通道。

对称加密和非对称加密（公开密钥加密）

（1）对称加密

对称加密指的是加密数据用的密钥，跟解密数据用的密钥是一样的，应用该办法的优缺点是：

1）长处：加密、解密效率通常比拟高、速度快。对称性加密通常在音讯发送方须要加密大量数据时应用，算法公开、计算量小、加密速度快、加密效率高。

2）毛病：数据发送方、数据接管方须要协商、共享同一把密钥，并确保密钥不泄露给其他人。此外，对于多个有数据交换需要的个体，两两之间须要调配并保护一把密钥，这个带来的老本根本是不可承受的。

（2）非对称加密

非对称加密指的是加密数据用的密钥（公钥），跟解密数据用的密钥（私钥）是不一样的。公钥就是公开的密钥，谁都能够查到；私钥就是非公开的密钥，个别是由网站的管理员持有。公钥与私钥之间有肯定分割：简略来说就是，通过公钥加密的数据，只能通过私钥解开；通过私钥加密的数据，只能通过公钥解开。

非对称加密（公开密钥加密）存在的问题

非对称加密其实是存在一些问题须要解决的，次要有以下两个：公钥如何获取、数据传输单向平安。

非对称加密中公钥如何获取

为了获取公钥，须要波及到两个重要概念：证书、CA（证书颁发机构），其主要用途如下：

（1）证书：能够临时把它了解为网站的身份证。这个身份证里蕴含了很多信息，其中就蕴含了下面提到的公钥。当拜访相应网站时，他就会把证书发给浏览器；

（2）CA：用于颁发证书，证书来自于 CA（证书颁发机构）。

证书可能存在的问题

（1）证书是伪造的：压根不是 CA 颁发的

（2）证书被篡改过：比方将 XX 网站的公钥给替换了

证书如何防伪

数字签名、摘要是证书防伪十分要害的武器。“摘要”就是对传输的内容，通过 hash 算法计算出一段固定长度的串。而后，在通过 CA 的私钥对这段摘要进行加密，加密后失去的后果就是“数字签名”（明文 –> hash 运算 –> 摘要 –> 私钥加密 –> 数字签名）；数字签名只有 CA 的公钥才可能解密。证书中蕴含了：颁发证书的机构的名字（CA）、证书内容自身的数字签名（用 CA 私钥加密）、证书持有者的公钥、证书签名用到的 hash 算法等。

（1）对于齐全伪造的证书

这种状况对证书进行查看

1）证书颁发的机构是伪造的：浏览器不意识，间接认为是危险证书

2）证书颁发的机构是的确存在的，于是依据 CA 名，找到对应内置的 CA 根证书、CA 的公钥。用 CA 的公钥，对伪造的证书的摘要进行解密，发现解不了。认为是危险证书

（2）篡改过的证书

1）查看证书，依据 CA 名，找到对应的 CA 根证书，以及 CA 的公钥。

2）用 CA 的公钥，对证书的数字签名进行解密，失去对应的证书摘要 AA

3）依据证书签名应用的 hash 算法，计算出以后证书的摘要 BB

4）比照 AA 跟 BB，发现不统一 –> 断定是危险证书

HTTPS 问题

（1）与纯文本相比，加密通信会耗费更多的 CPU 及内存资源

1）因为 HTTPS 还须要做服务器、客户端单方加密及解密解决，因而会耗费 CPU 和内存等硬件资源。

2）和 HTTP 通信相比，SSL 通信局部耗费网络资源，而 SSL 通信局部，由因为要对通信进行解决，所以工夫上又缩短了。SSL 慢分两种，一种是指通信慢；另一种是指因为大量耗费 CPU 及内存等资源，导致处理速度变慢。

（2）购买证书须要开销。

1. 客户端发动 HTTPS 申请

2. 服务端响应，下发证书（公开密钥证书）

3. 客户端查看证书，如果证书没问题，那么就生成一个随机值，而后用证书（公钥）对该随机值进行加密。

4. 将通过公钥加密的随机值发送到服务端 (非对称加密），当前客户端和服务器的通信就能够通过这个随机值进行加密解密了。

5. 服务端用私钥解密后，失去了客户端传过来的随机值，而后把内容通过该值进行对称加密。

6. 前期的数据传输都是基于该随机值进行加密解密。

注：图片来源于（https://blog.csdn.net/qq_3384…）

浏览器工作原理与实际_李兵 <br/>
阮一峰跨域资源共享 CORS 详解

一、概述

1.1 Web 页面平安

1.2 浏览器网络安全

1.3 浏览器系统安全

二、Web 页面平安

2.1 同源策略

2.1.1 同源

2.1.2 同源策略

2.1.3 同源策略的体现

2.1.4 浏览器出让了同源策略的哪些安全性？

2.2 跨域分类

2.2.1 DOM 层面和数据层面分类

2.2.2 网络层面

2.2.2.1 通过代理实现

2.2.2.2 JSONP 的形式

2.2.2.3 CORS 形式

2.3 两种攻击方式

2.3.1 XSS

2.3.1.1 定义

2.3.1.2 产生的影响

2.3.1.3 注入形式

2.3.1.4 什么状况容易产生 XSS 攻打

2.3.1.5 如何阻止 XSS 攻打

2.3.2 CSRF

2.3.2.1 定义

2.3.2.2 产生影响

2.3.2.3 攻打原理

2.3.2.4 攻打的前提条件

2.3.2.5 攻击方式

2.3.2.6 避免 CSRF 攻打的策略

三、浏览器平安

3.1 申请报文

3.1.1 申请行

3.1.2 申请头部

3.1.3 申请实体

3.2 响应报文

3.2.1 状态行

3.2.2 响应首部

3.2.3 响应体

3.2 HTTP 的毛病

3.3 HTTPS 根底知识点

3.4 HTTPS 流程

四、浏览器系统安全

参考内容