preface

With the rapid development of the Internet, information security has become one of the focus of attention of enterprises, and the front end is a high-risk stronghold to cause enterprise security problems. In the era of mobile Internet, in particular, in addition to traditional XSS, CSRF and other security problems, front-end personnel often encounter new security problems such as network hijacking and illegal invocation of Hybrid API. Of course, the browser itself is constantly evolving and developing, constantly introducing CSP, SameSite, HttpOnly, Cookies and other new technologies to enhance security, but there are still a lot of potential threats, which we need to continue to “fill in the gaps”

Browser security can be divided into three parts: Web page security, browser network security, and browser system security

Web page security is primarily about same-origin policy restrictions

What is the same origin policy

Homology refers to the protocol, domain name, and port number that we access to the site.

By default, sites of the same origin can access resources and operate DOM with each other. If different sources want to access resources or operate DOM with each other, they need to add some security policies, commonly known as same-origin policies

The same origin policy has three main limitations:

  1. DOM layer: Different source sites cannot access and manipulate the DOM
  2. Data layer: Data such as cookies, LocalStorage, and indexDB of different source sites cannot be obtained
  3. Network layer: You cannot send requests to different source sites using XMLHttpRequest

Of course, the same origin policy does not absolutely isolate different source sites, such as link, IMG, script tags are not cross-domain restrictions, which makes us more flexible development, but also brings some security issues, namely browser network security issues, the most typical is XSS attacks and CSRF attacks

Let’s talk about XSS attacks

An XSS attack is a code injection attack that uses malicious injection scripts to run in a browser and steal user information

XSS attacks are essentially caused by websites that do not filter for malicious code. When it is mixed with normal code, the browser has no way to tell what is trusted, and the malicious code is executed as well. This can then lead to the following:

  • Page data or user information is stolen, such as DOM, Cookie, LocalStorage
  • Modify the DOM, such as forging a login window or generating a float window AD on a page
  • Listen to user behavior, such as logging in or banking sites with addEventListener listening keyboard events, steal account password and other information
  • Traffic is hijacked to other sites

There are three types of XSS attacks: storage, reflection, and DOM

  1. Storage type: And directly execute the malicious code in the script tag

  2. Reflection type: it is the attacker sends malicious JS script to the website as a part of the user’s request, and then the website returns the malicious script to the user, which will be executed in the page at this time. For example, open a link that contains a malicious script. When opened, the server will request it, and the server will take the data in the URL and return it in HTML, and then execute. Unlike the storage type, it is not stored on the server

  3. Dom-based: the attacker hijacks and modifies the page data during the transmission of page resources and inserts malicious code through some hijacking methods

How to prevent XSS attack, what is the solution?

  • This is to filter or escape the content of the input box

    character Escaped characters
    < &lt;
    > &gt;
    “ &quot;
    ‘ &#x27;
    / &#x2F
    & &amp;

  • Using CSP is a whitelist that tells the browser which external resources can be loaded and executed, so that even if malicious code is inserted, it will not be executed, or which third-party sites to submit data to. You can enable the whitelist in either of the following ways:

    • Using meta tags<meta http-equiv="Content-Security-Policy">
    • Set the HTTP headerContent-Security-Policy

  • To protect some sensitive information, add httpOnly to the Cookie information, tell the browser to save the Cookie, and do not open access to the client script, and then cannot obtain the Cookie through document. Cookie

Set-Cookie: widget_session=123456; httpOnly
Copy the code
  • useVerification codeTo avoid the script masquerading as the user to perform some operations

Talk about CSRF attacks

Is cross-site request forgery attacks, mainly is the state from the user’s login cross-site request, such as the mailbox at sixes and sevens link, link to the email address must be logged in and then hackers can use this login status, forged with the HTTP request cookies, right directly to bypass the backend login authentication, Then impersonate the user to perform some operations

There are three necessary conditions for launching a CSRF attack:

  1. The target site must have CSRF vulnerabilities
  2. The user has logged in to the target website, and the browser saves the login status
  3. Users are required to open third-party sites

The essence is to use the cookie in the same origin request to carry the characteristics of sending to the server, to achieve impersonating users

There are three types of CSRF attacks: GET, POST, and link

  • The GET type is automatically sent: for instance,imgoriframeWhen the user opens the site, it automatically initiates a resource request with cookies
<img src="Http://malicious Website" >
Copy the code
  • The POST type is automatically sent: Like a whole hidden oneThe form, which automatically submits the form when the user enters the page
<form id="hack" action="Https:// malicious Url" method="post">.</form>
<script>document.getElementById('hack').submit()</script>
Copy the code
  • Induced link type: is to induce the user to click on the link, for exampleA label
<a href="Https:// malicious Url">Click to receive the gift package</a>
<a href="Https:// malicious Url">Click to download the beauty video</a>
Copy the code

How to prevent CSRF attack, what is the solution?

  1. Add a SameSite attribute to Cookie information. This attribute has three values:

    • Strict: In strict mode, cookies are completely forbidden
    • lax:Loose pattern, allowing partial use of cookies,Cross domain is fine, a TAB jump, link TAB, GET submit form
    • None: Cookies are sent in any case, but the Secure attribute must be set at the same time. This means that the security context is required. Cookies can only be sent over HTTPS, otherwise they are invalid

    Chrome 80 defaults to None, followed by lax

    Set-Cookie: widget_session=123456; SameSite=None; Secure
Copy the code

  2. Validate the source of the request: The server filters requests based on the Origin or Referer attributes in the HTTP request header to determine whether the site is an accessible site. Determine Origin first and block it if neither of them exists.

    • Referer: Records which link the request jumped from and contains the path information, which is the source address. However, this guy is not very reliable, so we added Origin later 
      Referer: https://juejin.cn/editor/drafts/xxxx
Copy the code
    • Origin: Records domain name information, no specific URL path 
      Origin: https://juejin.cn
Copy the code

  3. Token authentication: The server returns a random number Token to the user and adds the Token as a parameter to the request header when the request is repeated. Then the server authenticates the Token and rejects the request if it does not have the Token or the content is incorrect. The disadvantage is that

    • Each request has to be added a bit tedious
    • Unilateral authentication cookies can be used fraudulently,
    • If the site has more than one server and is transferred to other servers through load balancing, all the other servers must retain the Token in the Session, otherwise authentication will fail

  4. Dual validation Cookie: Taking advantage of the fact that the attacker can only use cookies but cannot get cookies, when the user visits the page, the server adds a random Cookie string to the requesting domain name, and then, when the user requests again, it takes out this string from the Cookie and adds it to the URL parameter. The server then verifies the data in the Cookie and the data in the parameter, and rejects the request if it is not the same.

    The disadvantage is that if the site has AN XSS vulnerability, this method will be invalid, and can not achieve subdomain isolation

Browser system security – Security sandbox

First, let’s think about what happens if we download a malicious program and don’t execute it.

Certainly not, and the browser is the same

Browsers can safely download all kinds of web resources, but you need to be careful when doing so. Such as parsing HTML, CSS, performing JS and other operations, the careless hacker will use these operations to launch attacks on the vulnerability of the browser

Therefore, we need to build a wall between the render process and the operating system. With this wall in the block, hackers can only get access to render in (as shown below), without affecting the outside, and this wall between the operating system and the render process is the security sandbox

The minimum protection unit of the security sandbox is the process, and the access and modification of the operating system resources can be restricted by the process. This means that the process where the security sandbox resides cannot read or write the operating system, for example, read or write local files, initiate network requests, or call the GPU interface

How does the safety sandbox affect the functions of each module

  • Persistent storage
    • The browser kernel will maintain a Cookie database that stores all cookies. When the rendering process reads cookies through JS, the rendering process will send the read Cookie information to the kernel through IPC. The browser kernel reads the Cookie and then returns the content to the rendering process via IPC
    • Cache files are also read and written by the browser kernel
  • Network access: The rendering process does not have direct access to the network, but needs to go through the browser kernel. The browser kernel checks whether the rendering process has permission to request the URL, such as cross-domain, before processing the URL request
  • The user interaction
    • Input: The operating system sends the input event to the browser kernel. The kernel determines that if the input event is from the address bar, it will be processed directly by the kernel. If the input event is from the page, it will be forwarded to the rendering process
    • Render: After rendering the bitmap, the rendering process sends the generated bitmap to the browser kernel, which then copies the bitmap to the screen for display

Site quarantine Do you know

We know that a TAB has a rendering process, but what if the TAB has multiple iframes for different sites? This would result in content from multiple different sites running in the same rendering process, which is definitely not possible

There are two Level A vulnerabilities in all operating systems: Spectre and Meltdown, which are caused by the processor architecture and are difficult to fix

If there is A malicious iframe in the bank’s page, and the malicious site exploits two Level A vulnerabilities to break into the rendering process, the malicious program can read everything in the rendering process of the bank’s site, which is very risky for the user, and can even launch an attack on the operating system without sandbox protection

This means that multiple rendering processes may be running on a single TAB page and are isolated from each other. In this way, malicious iframes cannot access other content on the page and therefore cannot attack other sites. This is called site isolation

Man-in-the-middle attack

After the HTTP data is submitted to the TCP layer, it passes through the user’s computer, router, carrier, server, and every link in between is not secure

In a word: in the PROCESS of HTTP transmission is easy to be stolen, forged, tampered with by the middleman, this attack is called a man-in-the-middle attack.

So how do you make the data more secure?

The HTTPS security layer is used to encrypt and decrypt data to ensure data security.

About HTTPS performance optimization, version, advantages and disadvantages, SSL/TLS, handshake (RSA, TLS1.2, TLS1.3) three versions and optimization, etc., the article is too long to expand here, you can see my another article has a detailed introduction

So how does HTTPS encrypt and decrypt data? Let’s start with the algorithm

Symmetric encryption algorithm

Encryption and decryption using the same key. For example, AES and DES. Encryption and decryption process:

  1. The browser sends a random number to the serverclient-randomandEncryption suite(A list of supported encryption methods)
  2. The server generates another random number for the browser to returnserver-randomandEncryption suite
  3. Each side returns a confirmation message. Then the two random numbers are mixed with encryption methods to generate a key, which is the key for communication double encryption and decryption

Once you have the key, you can encrypt the data for transmission

The problem is that both client-random and server-random are plaintext. How can both parties securely pass the two random numbers and encryption methods? It goes straight to the client, where it’s likely to be stolen in the process, but the middleman can still decrypt it and get it. Read on

Asymmetric encryption algorithm

It is a pair of keys, including a public key and a private key. Data encrypted by one key can be decrypted only by the other key. Such as RSA and ECDHE. Encryption and decryption process:

  1. The browser sends it to the serverEncryption suite
  2. Select supported serversEncryption methodsandThe public key(in plain text) to the browser
  3. Each side returns a confirmation message. The browser then encrypts the data with a public key that can only be usedThe private keydecryption

Doesn’t that look perfect

There are serious problems

  1. Using public keys to backderive private keys is very difficult, but not impossible, as computing power increases with asymmetric keysAt least 2048 bits is required to ensure security, which leads to slow encryption and decryption speed, low efficiency
  2. The data sent by the server to the browser cannot be secured. Because the browser can be encrypted with a public key, the browser can only be encrypted with a private key. The public key is transmitted in plain text and can be obtained by a middleman, so the data security on the server cannot be guaranteed

So!

Mixed encryption

TLS actually uses a mixture of the two algorithms. The asymmetric encryption algorithm is used to exchange the keys of the symmetric encryption algorithm. After the exchange, the symmetric encryption algorithm is used to encrypt and decrypt the data. This ensures the confidentiality of the session. The process is as follows

  1. The browser sends a random number to the serverclient-random,Symmetric and asymmetric encryption suites
  2. The server puts another random numberserver-random,Encryption suite,The public keySend to the browser
  3. The browser generates another random numberpre-randomAnd use the public key to pairpre-randomEncrypt it and send it to the server
  4. The server decrypts it with the private keypre-randomAnd return a confirmation message
  5. So the browser and the server each have three random numbers, and they each encrypt the three numbers together to produce the final symmetric key

Then the encrypted data transmission begins

In this way, even if it is intercepted, the middleman cannot get pre-random without the private key and cannot generate the final key

Is that safe?

emmmm…… Haven’t

Because the problem again, if a broker began to DNS is hijacked, then the request is intercepted middleman, middlemen gave his own public key server to the browser, the browser receives the public key can send information to middlemen, middlemen decryption to get the data, and do some shady business deals, and request the actual server, to get the server public key, And then send the encrypted data to the server

The information can be stolen without anyone knowing it, so in addition to symmetric and asymmetric encryption, the server needs to prove the identity to the browser. How?

So here comes the digital certificate. Look down

How to ensure that the data is not tampered with?

Digital Certificate (Digital Signature)

It helps verify the identity of the server, and the digital certificate contains the public key, and the digital certificate needs to be authorized to the server from an authoritative Certification Authority (CA).

Compared to before, it becomes

  • Instead of returning the public key directly to the browser, the server returns the digital certificate, and the public key is in the digital certificate
  • In the browser, an additional certificate verification step is required. Only after the verification succeeds, the following process can proceed

So how do you apply for a digital certificate?

  • First, prepare a set of serversThe public keyandThe private keyKeep the private key for yourself
  • The server submits information such as the public key and site to the CA for authenticationFor the moneythe
  • CAvalidationInformation provided by the server
  • The certified digital certificate is issued after verification, includingThe public key,CA information,Valid time,Certificate of the sequenceSo this is all plain text, and there’s a CA generatedThe signature

CA signature process

  • CA has oneThe public keyandThe private key
  • The CA uses the digest algorithm to compute the plaintext information submitted by the server and obtainsThe information in this paper,
  • The CA then encrypts the digest using its private key and a specific algorithm to generateThe signature
  • theThe signature,Server Public keyEquiinformation packagingInsert digital certificateAnd return it to the server
  • The certificate is configured on the server. After the browser connects to the server, the certificate is sent to the client for verification

Algorithm: mainly used to ensure the integrity of information. Common MD5 algorithms, hash functions, and hash functions belong to this type of algorithms. They are unidirectional and cannot be reversed

How does the browser verify digital certificates

  • When the browser connects to the server, it first sends the certificate to the client for verification
  • useThe CA’s public keyAnd the declared signature algorithmdecryptionTo get the serverIn this paper, the contentAnd the server public key
  • Then use the digest algorithm to generate a digest of the server public key in the certificate, and then combine this digest with the digest obtained in the previous stepcontrast
  • The two information summaries are then compared. If they are consistent, the certificate is valid, which proves the server itself; otherwise, the certificate is illegal

Certificate authentication is divided into one-way authentication and two-way authentication

Unidirectional authentication: The server sends the certificate and the client verifies the certificate. Bidirectional authentication: The server and client respectively provide certificates to each other and verify each other’s certificates

However, most HTTPS servers use one-way authentication. If a server needs to authenticate a client, it uses credentials such as the user name, password, and mobile phone verification code to authenticate the client. Only systems with higher level requirements, such as large online banking transfers, will provide a two-way authentication scenario to ensure authentication of the customer’s identity

In addition, you need to pay attention to the application and use of certificates

  • You do not need to provide a private key to apply for a digital certificate. Ensure that the private key can only be held by the server
  • The core of a digital certificate is the digital signature generated by the CA using its private key
  • The certificate corresponding to the internal CA is called the root certificate. The root certificate is the most authoritative authoritySelf-signed certificate

Is it safe with that?

emmmmm….. There is no

Although not absolutely secure, but under the current architecture the most secure solution copywriting, greatly increasing the cost of man-in-the-middle attack

conclusion

Praise support, hand stay fragrance, and have glory yan

Thanks for seeing this, come on!

reference

How browsers work and practice

HTTPS: A tough battle for network security