It’s not often that a single interview question includes more than one high frequency topic, but there is one magic recipe — browser security can connect 12 front-end core topics.

An overview,

1.1 Web Page Security

What questions come to mind when it comes to Web page security?

  1. What is the same origin, what is the same origin policy, and what are the manifestations of the same origin policy?
  2. What security does the browser give away from the same origin policy?
  3. What are the cross-domain solutions?
  4. How is JSONP implemented?
  5. What do you know about CORS?
  6. What are the common attacks against Web page security (XSS, CSRF)?

1.2 Browser Network Security

What questions come to mind when it comes to browser security?

  1. What is a request message?
  2. What is a response message?
  3. HTTP shortcomings
  4. HTTPS Basics
  5. HTTPS process

1.3 Browser System Security

What do you think of when it comes to browser security?

  1. Security sandbox

Second, Web page security

2.1 Same Origin Policy

2.1.1 homologous

Cross-domain essentially means that two urls have different IP addresses from different sources. The reverse side of different IP addresses is same-origin. Same-origin means that if two urls have the same protocol, domain name, and port number, they are two urls of the same origin.

// Non-same-origin: different protocols http://www.baidu.com https://www.baidu.com // Same-origin: the protocol, domain name, and port number are the same http://www.baidu.com http://www.baidu.com?query=1Copy the code

2.1.2 Same-origin Policy

The same origin policy is an important security policy that restricts how an Origin document or loaded script it loads can interact with resources from another source. It is mainly to protect the security of user information and prevent malicious websites from stealing data. It is the security protection done by the browser at the level of Web pages.

2.1.3 Same-origin Policy

Since the same origin policy is protected by the browser at the Web page level, where on that level should be protected? It mainly includes three levels: DOM level, data level and network level.

  1. The DOM level

The same origin policy restricts how JavaScript scripts from different sources can read and write to the current DOM object.

  1. Data level

The same origin policy restricts the sites from reading cookies, IndexedDB, and localStorage of the current site.

  1. The network layer

The same origin policy restricts the sending of a site’s data to a site of different sources through methods such as XMHttpRequest.

2.1.4 What security does the Browser provide for the Same Origin Policy?

2.2 Cross-domain classification

The same origin policy ensures the security of the browser. However, if the three levels are strictly restricted, it will make the programmer’s development work difficult. Therefore, the browser needs to make some concessions under the strictest same-origin policy, which is more a trade-off between security and convenience. The cross-domain approach can be thought of as a compromise between the browser giving up some security or complying with the browser’s same-origin policy.

2.2.1 DOM level and data Level Classification

According to the same origin policy, it is common for two pages with different sources to communicate with each other if they cannot manipulate DOM and access data. A typical example is the communication between an IFrame window and its parent window. Over the course of history, there are several ways to implement communication between DOM layers, as follows:

  1. Fragment identifier

The core idea of a fragment identifier is to listen for changes in the HASH in the URL to pass the data, which is a really neat idea.

// The parent page parentHtml<! DOCTYPEhtml>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>I am the parent page<button id='btn'>Father to son</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 += '# father to son ';
        });
    </script>
</html>
Copy the code
// Child pages childhmt.html<! DOCTYPEhtml>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>I'm a child page<button id='btn'>Son to father</button>
    </body>
    <script>
        window.onhashchange = function() {
            console.log(decodeURIComponent(window.location.hash));
        };

        document.getElementById('btn').addEventListener('click'.() = > {
            parent.location.href += '# child to father ';
        });
    </script>
</html>
Copy the code
  1. window.name

The browser window has the window.name attribute. The biggest feature of this attribute is that, regardless of whether the same source, as long as the previous page in the same window set this attribute, the next page can read it. If the communication between the parent page and the cross-domain child page is needed, a child page with the same origin as the parent page is used as an intermediary to transfer the information in the cross-domain child page. (Very troublesome ah, strongly not recommended to use, here will not write the corresponding code)

  1. document.domain

Document.domain is the host name of the server where the document is stored. It can be manually set to the current domain name or the superior domain name. When the same document.domain page is equivalent to being on the server with the same domain name.

  1. PostMessage (highly recommended)

Window. postMessage is a new CROSS-document communication API for HTML5 that allows cross-window communication regardless of whether the two Windows are homologous or not.

/ / the parent page<! DOCTYPEhtml>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>I am the parent page<button id='btn'>Father to son</button>
        <iframe src="http://127.0.0.1:5500/024/childHtml.html" id="childHtmlId"></iframe>
    </body>
    <script>
        window.addEventListener('message'.function(event) {
            console.log('Parent page receives message', event.data);
        });
        document.getElementById('btn').addEventListener('click'.() = > {
            const iframeDom = document.getElementById('childHtmlId');
            iframeDom.contentWindow.postMessage('I am the Kite Bearer 1'.'http://127.0.0.1:5500/024/childHtml1.html');
        });
    </script>
</html>
Copy the code
/ / child pages<! DOCTYPEhtml>
<html lang="zh">
    <head>
        <title></title>
    </head>
    <body>I'm a child page<button id='btn'>Son to father</button>
    </body>
    <script>
        window.addEventListener('message'.function(event) {
            console.log('Child page receives message', event.data);
        });

        document.getElementById('btn').addEventListener('click'.() = > {
            parent.postMessage('I am the Kite Bearer 2'.'http://127.0.0.1:5500/024/parentHtml1.html');
        });
    </script>
</html>
Copy the code

2.2.2 Network Layer

By default, browsers do not allow XMLHttpRequest objects to access resources on different sites, according to the same origin policy. This can greatly limit productivity, so you need to overcome this restriction and achieve cross-domain access to resources. At present, there are three main methods widely used (note: the specific code is not given in this paper, there will be a special 100 questions cut for detailed elaboration) :

2.2.2.1 Through proxy

The same origin policy is set by the browser for security, so there is no such restriction on the server side. In this way, we can send requests to the same origin server, and then the same origin server proxy to the final required server, thus realizing the purpose of cross-domain request. For example, Nginx, Node middleware, etc.

2.2.2.2 JSONP mode

JSONP is a technology that uses script elements to achieve cross-domain implementation. It does not use XMLHttpRequest objects. It can achieve cross-domain implementation mainly because script has two characteristics:

(1) The SRC attribute can access any URL resources and is not restricted by the same origin policy;

(2) If the accessed resource contains JavaScript code, it will be automatically executed after downloading.

Let’s implement JSONP

  1. Globally mount a function that receives data.
  2. Create a script tag and mount handlers on its onload and onError events;
  3. Mount the script tag to the page to initiate a request to the server;
  4. The server receives the passed arguments and outputs the callback function and data as calls.
  5. When script elements receive script code under influence, they are automatically executed.
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 and onReadyStatechange are used for compatibility with IE, because Internet Explorer 9 previously did not support onLoad events, only onReadyStatechange events
    script.onload = script.onreadystatechange = function() {
        // If there is no readyState event, it is not Internet Explorer and can be executed directly. Otherwise, it must wait until the state changes to Loaded or complete
        if (!this.readyState || this.readyState === 'loaded' || this.readyState === 'complete') {
            script.onload = script.onreadystatechange = null;
            // Remove the script DOM object
            if (script.parentNode) {
                script.parentNode.removeChild(script);
            }

            // Delete a function or variable
            window['jsonp' + hash] = null; }}; script.onerror =function() {
        if (onerror && typeof(onerror) === 'function') { onerror(); }}// Add a label and send the request
    document.getElementsByTagName('head') [0].appendChild(script);
}
Copy the code
2.2.2.3 CORS way

Cross-domain resource sharing (CORS), a mechanism that enables cross-domain access control to secure cross-domain data transfer. A way to implement a cross-domain request in which HTML accesses the url http://127.0.0.1:8009; Server listening port: 8010)

First, the overall process

The communication process of CORS is automatically completed by the browser without user participation. Its core point is the server. As long as the server implements THE CORS interface, cross-source communication can be realized. Although this is done automatically by the browser, the browser is actually divided into simple requests and non-simple requests based on the difference in the field of the request. The following is a brief description of both.

  1. A simple request

(1) the definition

A simple request is one that meets the following two conditions:

  1. The request method is one of three methods: HEAD, GET, and POST.
  2. HTTP headers do not exceed the following fields: Accept, accept-language, Content-language, last-event-id, Content-Type (its values are Application/X-www-form-urlencoded, multipart/form-d) Ata, text/plain).

(2) Process

The entire process of a simple request can be summed up in the following steps:

1) The browser directly sends the CORS request. Specifically, it adds an Origin field in the header information, which indicates the source (protocol + domain name + port) from which the request comes. The server decides whether to approve the request according to this value. 2) When the server receives the request, Origin determines whether the specified source is within the licensed range. 3) If it is not, the server returns a normal HTTP response, and the browser knows it is wrong when it finds that the header does not contain the Access-Control-Allow-Origin field, and throws an error that is caught by XML’s onError callback function. (note: This error is not recognized by the status code because the status code is 200.) 4) If Origin specifies a domain name within the license, Several Header fields (access-Control-allow-Origin, access-Control-allow-credentials, access-Control-expose-header, etc.) are added to the response returned by the server.

(3) Key fields

1) Access – Control – Allow – Origin

Required field, which is either the Origin field value of the request or an * (to accept requests for any domain name).

2) Access – Control – Allow – Credentials

Optional field whose value is a Boolean value indicating whether cookies are allowed to be sent. The default is not to send a Cookie value. When set to true, the server explicitly allows cookies to be included in the request and sent to the server. (Note: When sending cookies, note that the withCredentials attribute needs to be set in the Ajax request. Access-control-allow-origin cannot be set to *. You need to specify a specific domain name that corresponds to the requested page.

3) the Access – Control – Expose – the Header

Optional field, when CORS requests, The getResponseHeader() method of the XMLHttpRequest object takes only six basic fields (cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragm) A), if you want to obtain other fields must be specified in access-Control-expose-header.

  1. Non-simple request

(1) Definition

Non-simple requests are non-simple requests. Non-simple requests are requests that have special requirements on the server, for example, the request method is PUT or Delete, or the content-Type field is application/ JSON.

(2) Process

A non-simple request is more complex than a simple request. A pre-check request is performed before a formal request is sent. The result of the pre-check request is used to determine whether to conduct subsequent formal communication.

1) The browser initiates a precheck request, and the request method is options, which is used to ask; 2) After receiving the pre-check Request, the server checks the Origin, access-Control-request-method, and access-Control-request-headers fields, and confirms that cross-source requests are allowed. 3) If the browser denies the “precheck” request, it will return a normal HTTP response without any CORS related header fields. In this case, the browser will assume that the server does not approve the precheck request and trigger an error. 4) If the browser passes the “precheck” request, every normal CORS request from the browser will have the same Origin header field as the simple request, and the server will also have an Access-Control-Allow-Origin header field.

(3) Key fields

1) Access – Control – Request – Method

A required field that lists which HTTP methods are used for the browser’s CORS request.

2) Access – Control – Request – Headers

This field is a comma-separated string that specifies the additional header fields that the browser will send for CORS requests.

3) the Access – Control – Allow – the Methods

Required field, the value of which is a comma-separated string that identifies all methods supported by the server for cross-domain requests.

4) Access – Control – Allow – Headers

The value is a comma-separated string indicating all header information fields supported by the server.

5) Access – Control – Max – Age

Used to request the validity period of a precheck request, in seconds.

  1. Simple implementation

(1) HTML page content

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

(2) Server-side code

const express = require('express');

const app = express();

app.get('/'.(req, res) = > {
    console.log('Get request received!! ');
    res.setHeader('Access-Control-Allow-Origin'.'http://127.0.0.1:8009');
    res.send('Get request already processed');
})
app.listen(8010.() = > {
    console.log('8010 is listening')});Copy the code

2.3 Two Attack Modes

2.3.1 XSS

2.3.1.1 definition

Cross-site scripting attacks (XSS; Cross Site Scripting is a method for hackers to inject malicious scripts into HTML files or DOM to attack users when they browse the page.

2.3.1.2 Impact

The main impacts of XSS attacks include: stealing Cookie information, monitoring user behavior, modifying DOM, generating floating window advertisements in the page, etc.

2.3.1.3 Injection Mode

XSS injection modes include storage TYPE XSS attack, reflection type XSS attack and DOM based XSS attack.

2.3.1.4 What are the conditions for XSS attacks

There are two main locations for XSS attacks:

  1. Data enters a Web application from an unreliable link
  2. Dynamic content without filtering out malicious code is sent to Web users

2.3.1.5 How do I Prevent XSS Attacks

There are three main ways to prevent XSS attacks:

  1. The server filters or transcodes the input script;
  2. Make full use of CSP;
  3. Use the HttpOnly attribute

2.3.2 CSRF

2.3.2.1 definition

Cross-site request forgery (CSRF; Cross-site request forgery refers to a cross-site request initiated by a hacker who lures a user to open a hacker’s website, utilizing the user’s login status in the hacker’s website

2.3.2.2 Impact

The main influences are as follows:

2.3.2.3 Attack Mechanism

2.3.2.4 Prerequisites of the attack

The preconditions of attack are as follows:

2.3.2.5 Attack Mode

CSRF attacks can be implemented in the following three ways:

  1. Automatically initiate Get requests.
  2. Automatically initiate POST requests.
  3. Entice users to click on links

2.3.2.6 Policies for Preventing CSRF Attacks

The following three strategies are used to prevent CSRF attacks:

  1. Take full advantage of the SameSite property of cookies;
  2. Verify the source site of the request on the server side;
  3. CSRF Token.

Third, browser security

3.1 Request Packet

HTTP request packets mainly include: request lines, request headers, and requested data (entity). The following is a look at the contents:

3.1.1 request line

The request line contains: method field, URI field, and protocol version

  1. Methods field

    GET (request for content);

    POST (submit the form);

    HEAD (request resource response message header);

    PUT (transfer files);

    DELETE (request to DELETE the resource pointed to by the URI);

    OPTIONS (queries methods supported for the resource specified by the request URI);

    TRACE (tracing the path of the request);

    CONNECT (requires tunnel protocol connection to proxy).

  2. URI field

  3. Protocol version

    Indicates the HTTP version of the request, such as HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0, and HTTP/3.0.

3.1.2 Request headers

Common headers are: The Connection header (Connection management), Host header (specifying the Host for the requested resource), Range header (Range of bytes for the requesting entity), User-Agent header (containing information about the User making the request), Accept header (preferred media type), Accept-Language(preferred from But language)

3.1.3 Requesting Entities

The body of the HTTP request is primarily used in the submission form scenario. In fact, the BODY of the HTTP request is quite free, as long as the body server that the browser sends accepts it. Some common body formats are:

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

HTML requests submitted using HTML form tags will generate application/ X-www-form-urlencoded data format by default, and multipart/form-data will be used when files are uploaded.

3.2 Response Packets

An HTTP response packet consists of three parts: the status line, the header line, and the response body.

3.2.1 the status line

Status lines are made up of version, status codes, and reason statements. Here’s a look at some commonly used status codes.

  1. 1XX: This type of status code indicates that the request has been accepted and needs to be processed. This type of response is a temporary response, containing only the status line and some optional response header information, and ending with an empty line
  2. 2XX: Indicates that the request is successfully received, understood, and accepted by the server

200– OK/ Request has been processed normally;

204– The request was processed successfully, but no resources were returned;

206- indicates that the client made a range request and the server successfully executed this part of the GET request;

  1. 3XX: This type of status code indicates that the client needs to take further action to complete the request. Typically, these status codes are used for redirection, and subsequent request addresses (redirect targets) are specified in the Location field of this response

301– Request permanent redirection The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the urIs returned by this response. If possible, clients with link editing capabilities should automatically change the requested address to the one that is returned from the server.

Since such redirects are temporary, the client should continue to send future requests to the original address. The response is cacheable only if specified in cache-Control or Expires.

303– Indicates that the requested resource should be obtained using the GET method because another URI exists for the resource corresponding to the request

304- Indicates that the client sends a conditional request (If the request using the GET method contains if-match, if-modified-since, if-none-match, if-range, or if-unmodified-since header). A condition in which a server allows a request to access a resource, but the condition is not met

307- Temporary redirect, same meaning as 302, but 307 does not change from POST to GET according to browser standards

  1. 4XX: This type of status code represents an error of the client class

400- The client request has a syntax error

401– The current request requires user authentication.

403– The server understands the request, but refuses to execute it. Unlike the 401 response, authentication does not help

404– The request failed. The requested resource was not found on the server.

405– The request method specified in the request line cannot be used to request the corresponding resource.

  1. 5xx: Server class error

500- The server encountered an unexpected condition that prevented it from completing processing the request.

501- The server does not support a feature required for the current request. When the server does not recognize the requested method and cannot support its request for any resource.

503- The server is currently unable to process requests due to temporary server maintenance or overload.

505– The server does not support, or refuses to support, the HTTP version used in the request.

3.2.2 Response header

Common response headers are: Date, Via, Last-Modified, Etag, Connection, Accept-Ranges, And Content- Type (Resource Type)

3.2.3 response body

The response body is the message body of the response. If it is pure data, it will return pure data. If it is an HTML page, it will return HTML code.

3.2 Disadvantages of HTTP

HTTP has a number of drawbacks that lead to HTTPS, so what are some of the drawbacks of HTTP? How to solve it? Here’s a brief overview

1.HTTP communication uses plaintext (not encryption), so the content may be eavesdropped;

TCP/IP is a network that can be eavesdropped: according to the working mechanism of the TCP/IP protocol family, communication content can be snooped on all lines. Therefore, encryption is needed to prevent eavesdropping, and the encrypted objects are as follows:

(1) Communication encryption

Encrypts HTTP traffic using the Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocol. After establishing a secure communication line with SSL, HTTP communication can be carried out over this line. The HTTP used in combination with SSL, called HTTPS, encrypts the entire communication line in this way.

(2) Content encryption

Since there is no encryption mechanism in HTTP, the content transmitted over HTTP is encrypted. In order to achieve effective content encryption, both the client and server are required to have encryption and decryption mechanisms. This method is different from encrypting the entire communication line, and the content still has the risk of tampering.

2. The identity of the communication party is not verified and therefore may be disguised;

(1) Anyone can initiate a request

The HTTP protocol returns a response no matter who sends the request. Therefore, the following risks may occur if the communication party is not identified:

1) It is not possible to determine whether the Web server to which the request is sent is the one that returns the response according to the real intention, and it may be a disguised Web server;

2) It is impossible to determine whether the client to which the response is returned is the client that received the response according to the real intention, and it may be a disguised client;

3) It is impossible to determine whether the other party who is communicating has access permission, because some Web servers store important information and only want to give specific users the permission to communicate;

4) Denial of Service (Dos) attacks when you cannot determine where or from whom a request is received, even if it is meaningless.

(2) Find out the opponent’s certificate

SSL not only provides encryption, but also uses a device called a certificate that can be used to determine the communication party. The certificate is issued by a trusted third-party organization to prove that the server and client actually exist. Using certificates to prove that the communicator is the intended server also reduces the risk of personal information disclosure for the individual user. In addition, the client can complete the confirmation of personal identity by holding the certificate, and can also be used for the authentication of Web sites.

3. The integrity of the packet cannot be verified, so it may be tampered with.

Even if the contents of a request or response have been tampered with, there is no way of knowing for a period of time after the request or response is sent until it is received. In transit of a request or response, an attacker intercepts and modifies the content, known as a man-in-the-middle attack. It is difficult to ensure integrity through HTTP alone, and HTTPS is required to do so. SSL provides authentication, encryption, and summary functions.

3.3 HTTPS Basics

HTTPS is not a new protocol at the application layer. However, the HTTP communication interface is replaced by SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols. In short, HTTP+ communication encryption + certificate + integrity protection constitute HTTPS. HTTP is a TLS/SSL shell.

  1. The TLS/SSL functionality

The TLS/SSL protocol uses the client certificate and CA root certificate of the communication parties to allow client/server applications to communicate in a way that cannot be eavesdroped, establishing a secure and trusted communication channel between the communication parties.

  1. Symmetric and asymmetric encryption (public-key encryption)

(1) Symmetric encryption

Symmetric encryption means that the key used to encrypt data is the same as the key used to decrypt data. Advantages and disadvantages of this method are as follows:

1) Advantages: Encryption, decryption efficiency is usually relatively high, fast. Symmetric encryption is usually used when the sender needs to encrypt a large amount of data. The algorithm is open, the computation is small, the encryption speed is fast, and the encryption efficiency is high.

2) Disadvantages: The data sender and the data receiver need to negotiate and share the same key, and ensure that the key is not leaked to others. In addition, for multiple individuals with data exchange requirements, the cost of allocating and maintaining a key between two individuals is basically unacceptable.

(2) asymmetric encryption

Asymmetric encryption refers to the fact that the key used to encrypt data (the public key) is different from the key used to decrypt data (the private key). A public key is a public key that anyone can look up. A private key is a private key, usually held by the administrator of a web site. There is a certain connection between the public key and the private key. Simply put, the data encrypted through the public key can only be unlocked through the private key. Data encrypted with the private key can only be unlocked using the public key.

  1. Problems with asymmetric encryption (public-key encryption)

In fact, asymmetric encryption has some problems to be solved, mainly including the following two: how to obtain the public key and one-way data transmission security.

  1. How to obtain the public key in asymmetric encryption

To obtain a public key, two important concepts are involved: certificate and CERTIFICATE Authority (CA). They are used as follows:

(1) Certificate: it can be temporarily understood as the id card of the website. The ID card contains a lot of information, including the public key mentioned above. When he visits the site, he sends the certificate to the browser;

(2) CA: used to issue certificates from CA (certificate authority).

  1. Possible certificate problems

(1) The certificate is forged: it was not issued by the CA at all

(2) The certificate has been tampered: for example, the public key of XX website has been replaced

  1. How to prevent the certificate from counterfeiting

Digital signature and digest are the key weapons of certificate security. A digest is a fixed length string calculated using a hash algorithm for the transmitted content. Then, through the CA private key to encrypt this abstract, the result of encryption is “digital signature” (plaintext > hash operation > abstract > private key encryption > digital signature); Only the CA’s public key can decrypt a digital signature. A certificate contains the CA name, digital signature of the certificate (encrypted with the CA private key), public key of the certificate holder, and hash algorithm used to sign the certificate.

(1) For completely forged certificates

In this case, the certificate is checked

1) The certificate issuing authority is forged: the browser does not recognize the certificate and directly considers it as a dangerous certificate

2) The certificate issuing authority does exist. Locate the built-in CA root certificate and the CA public key according to the CA name. The CA public key is used to decrypt the summary of the forged certificate, but it cannot be solved. Considered a hazard certificate

(2) Tampered certificates

1) Check the certificate and find the corresponding CA root certificate and the CA public key according to the CA name.

2) Use CA’s public key to decrypt the digital signature of the certificate and obtain the corresponding certificate abstract AA

3) Calculate the summary BB of the current certificate based on the hash algorithm used for the certificate signature

4) Comparing AA and BB, it is found to be inconsistent –> It is judged to be a dangerous certificate

  1. HTTPS problem

(1) Compared with plain text, encrypted communication consumes more CPU and memory resources

1) HTTPS needs to be encrypted and decrypted by both the server and client, consuming hardware resources such as CPU and memory.

2) Compared to HTTP communication, SSL communication consumes network resources, while SSL communication takes longer due to the processing of the communication. SSL slow is classified into two types: slow communication. On the other hand, the processing speed slows down due to the large consumption of CPU and memory resources.

(2) The cost of purchasing a certificate.

3.4 the HTTPS process

1. The client initiates an HTTPS request

2. The server responds and delivers a certificate (public key certificate).

3. The client checks the certificate. If the certificate is ok, it generates a random value and encrypts the random value with the certificate (public key).

4. Send the random value encrypted with the public key to the server (asymmetric encryption). Then the communication between the client and server can be encrypted and decrypted using the random value.

5. After decrypting with the private key, the server gets the random value sent by the client, and then encrypts the content symmetrically through the value.

6. Later data transmission is encrypted and decrypted based on the random value.

Note: Images are from blog.csdn.net/qq_33840251…

4. Browser system security

Refer to the content

The working principle and practice of browser _ Li Bing ruan Yifeng cross domain resource sharing CORS detailed explanation