The security in the browser can be understood in terms of system security, network security, and page security.

Browser System Security

No one can guarantee that the browser itself does not have vulnerabilities, and the browser cannot distinguish whether the resources obtained from the network are safe before execution, and the various permissions of the operating system make it risky to contact the network resources, so all network resources are untrusted by default.

Modern browsers have already embraced multi-process architecture, from the input the url to the page, the browser multiple processes work together to let the user see a desired image, one of the most important process, rendering process, is the key to implement network resources process, so the browser by security sandbox, wrapped the rendering process.

Security sandbox

The minimum protection unit of a security sandbox is a process. The security sandbox limits the access or modification of operating system resources by processes.

Note that the TAB and render processes are not one-to-one:

The same site means that the protocol and the root domain name are the same. The connection relationship means that page B is in page A through window.open — in this case, you can use the return of window.open in page A to control page B; Or a target=”_blank” — which can be opened in b via window.opener control a –.

Network security

HTTP was born to transmit HTML, but with the development of web, THE function of HTTP is less and less useful. With the improvement of function, network security has become an important research object.

There are three risks to HTTP:

  • Eavesdropping risk: third parties can gain access to the contents of communications
  • Tampering risk: Third parties may modify communications
  • Impersonation risk: Third parties may impersonate others to participate in communications

To this end, a security layer is inserted between TCP and HTTP, and all passing data is encrypted/decrypted.

HTTP becomes HTTPS after access to the security layer. It has the following features:

  • All information is transmitted encrypted, so third parties cannot eavesdrop.
  • With verification mechanism, once tampered, communication parties will immediately find.
  • Equipped with an identity certificate to prevent identity from being impersonated.

How do you do that?

HTTPS Encryption Process

An important rule is that only the private key can decrypt data encrypted by the public key.

The public key is in plain text and easy for hackers to crack, but the private key is only available on the server, while the pre-master is generated by public key encryption, so only the server can crack. With the participation of pre-master in the final Master Secret, data sending and receiving are very safe.

Moreover, only one asymmetric encryption is needed, and the transmission efficiency is relatively high.

Of course, the hacker server produces its own public and private keys, and the client may go to a fake page. How does a server prove that it is real and legitimate? Digital certificate.

The CA certificate

A CA is an organization that issues digital certificates to companies and individuals.

You need to apply for a digital certificate. The process is as follows:

CA audit is a combination of online and offline. In many cases, offline audit depends on local policies. Therefore, hierarchical governance is needed in reality, thus forming a CA chain. The browser validates by looking up the CA chain to the root CA:

Even if the hacker forged the server, there is no way to forge the certificate and deceive the user.

Security page

The page is rendered through HTTPS request resources and security sandbox. When executing scripts, some malicious scripts may be executed. Or what might happen when a user is tempted to click on a link to a malicious site?

  • DOM and CSSOM are modified
  • User behavior is monitored
  • Sensitive information has been hijacked
  • Data such as cookies and indexDB are read, uploaded, and used
  • The user request was forged

The Web world without security is scary, chaotic and full of pitfalls. What is the most basic and core security policy in the page?

Same-origin policy.

Javascript from different sources cannot read or write the DOM of the current page. Js scripts from different sources cannot read the Cookie, IndexDB, LocalStorage of the current page. XMLHttpRequest access from different sources cannot be performed.

As a result, many normal things become less convenient, such as CDN resource requests. So for some convenience, the same origin policy gives a pass to third-party resources, which creates a security problem.

Typical security attacks include cross-site Script (XSS) and cross-site request forgery (CSRF).

As the name suggests, the former is sensitive to insert script reads, while the latter illegally uses cookies to forge user requests for hidden purposes.

XSS attacks

Three common XSS attack methods.

Storage, which may have exploited vulnerabilities in the content management system, sent malicious code to the server:

Reflective, unlike stored XSS attacks, the server does not store malicious code:

Dom-based attacks:

So how do you prevent XSS attacks?

  • The server filters/transcodes the script
  • Use CSP (Content Security Policy) to let the server decide which resources the browser can load and which scripts to execute.

CSP can specify resource sources, prohibit scripts from submitting data to third parties, and report exceptions to maintenance personnel in a timely manner.

CSRF attacks

CSRF attacks do not need to inject scripts into the page, but take advantage of the login status of the user and the vulnerabilities of the server to do some bad things through the third-party site, such as automatic mail forwarding, transfer, etc., but there are two premises:

1. The server has loopholes; 2. The user has to click the link on the hacker page.

For example, when a page is loaded with the following code, the browser automatically initiates an IMG resource request. If the server does not determine the type of request, the image resource is treated as an XHR request and the money is transferred:

<! DOCTYPE HTML > < HTML > < body > < img SRC = "https://www.pay.com/sendmoney?user=badbuys&number=1 $" / > < / body > < / HTML >Copy the code

Or click the malicious link, and the form will be automatically submitted when the following code’s page loads:

<! DOCTYPE HTML > < HTML > < body > < form id = "terrible - form" action = "" https://www.pay.com/sendmoney" method = "POST" > < input Type = "hidden" name= "user" value= "badbuys" /> <input type= "hidden" name= "number" value= "100 million" /> </form> < script > document. GetElementById (" terrible - form "). The submit (); </script> </body> </html>Copy the code

Or a temptation link:

<! DOCTYPE HTML > < HTML > <body> <img SRC = "a very sexy beauty" /> <a $href = "https://www.pay.com/sendmoney?user=badbuys&number=1" > click to download the beautiful picture < / a > < a $href = "https://www.pay.com/sendmoney?user=badbuys&number=2" > click and beauty video chat < / a > < / body > < / HTML >Copy the code

How to prevent CSRF attacks?

We need to improve server security.

  • When a request is sent from a third-party site, cookies cannot be sent. — SameSite in set-cookie is Strict
  • The source of the authentication Request site – through the Request Header: Referer | | Origin
  • CSRF Token authentication, the server requires that all requests must carry the CSRF Token, the third party cannot get the Token, forged requests will be denied access

–end–