This is the second day of my participation in the August More Text Challenge

Browser security includes Web page security, browser network security and browser system security.

1. Why do you need a security policy

Consider this scenario: Before you open a bank web site and logged in, then accidentally open a malicious web site, because there is no security policy, can completely malicious sites to bank website for any operation, such as change the DOM elements bank website, even get the information such as cookies, forge interface request, etc., it is very horrible. So in the Web world without security, we have no privacy, so we need security policies to protect our privacy and data security.

2. Same-origin policy

When it comes to security policies, we have to mention the same-origin policy. What is the same-origin policy? To understand the same-origin policy, understand the concept of same-origin:

Two urls are said to be homologous if they share the same protocol, domain name, and port.

For example, the following two urls belong to the same origin, with the same protocol HTTPS, the same domain name juejin. Cn, and the same port

https://juejin.cn/books
https://juejin.cn/events/all
Copy the code

If two different sources want to access each other’s resources or manipulate the DOM, they are constrained by a basic set of security policies, which we call the same-origin policy. Specifically, the same origin policy is mainly manifested in DOM, Web data and network.

2.1 DOM Level

The same origin policy restricts how JavaScript scripts from different sources can read and write to the current DOM object. For example, if you window.open a website, if the website and the current website belong to the same origin, you can operate the original website DOM elements on the newly opened website, otherwise you can not modify

2.2. Web Data

The same-origin policy prevents sites from accessing data such as cookies, IndexDB, and LocalStorage of the current site

2.3, network

Unable to access cross-domain resources

3. Security policy

The same origin policy is certainly the safest, but it can make Web projects difficult to develop and use. So you need some security to accommodate flexibility, and this is the current page security policy prototype.

3.1. Third-party resources can be embedded in the page

The same origin policy requires that all resources of a page come from the same source, that is, all HTML files, JavaScript files, CSS files, images and other resources of the page are deployed on the same server. This is obviously unreasonable. For example, it is impossible to obtain some static resources from THE CDN. Therefore, the same origin policy needs to be relaxed to allow arbitrary references to external files. However, because of this scheme, malicious script files will be injected into the page, leading to XSS attacks, which will be discussed later.

3.2 Cross-domain resource sharing

Same-origin policies restrict access to resources across domains, which can greatly limit productivity. Therefore, cross-domain resource sharing (CORS) is introduced, which can be used for cross-domain access control, so that cross-domain data transmission can be carried out safely. For example, the response header is set as follows

access-control-allow-origin: *
Copy the code

3.3. Cross-document messaging mechanisms

The same-origin policy restricts DOM operations between two different sources, but sometimes communication between the DOM of two different sources is required, so cross-document messaging is introduced in browsers.

For example, if a page uses iframe to embed another page from a different source, the two sides need to communicate with each other using window.postMessage.

4, XSS

There are many security issues due to third-party resource references and CORS in support pages, the most typical of which is XSS attacks.

4.1. What is XSS

XSS is full name for Cross Site Scripting, so it’s called XSS for short to distinguish it from CSS, which translates to cross-site Scripting. XSS attack refers to a method by which hackers inject malicious scripts into HTML files or DOM to attack users when they browse pages.

4.2 Harm of XSS attack

  • Cookie theft: Malicious scripts passdocument.cookieThe method of obtainingcookieAnd upload cookie information to the malicious server using CORS.
  • Monitoring user behavior: useaddEventListenerInterface to listen for keyboard events, such as credit card information entered by the user, and upload to a malicious server.
  • DOM modification: Forges the login window to trick users into entering their accounts and passwords
  • Generate floating window ads within the page

4.3 XSS attack mode

4.3.1 Storage XSS attack

The procedure for generating storage XSS is as follows:

  1. The hacker saves form submissions with malicious scripts to the database
  2. The user requests the page that contains the script
  3. When the user browses the page, the malicious script uploads data such as cookies to the malicious server

4.3.2 Reflex XSS attack

A user submits a request containing malicious code to the Web server. When the Web server receives the request, the malicious code is reflected back to the browser.

For example: http://localhost:3000/? XSS =

Hackers often induce users to click on these malicious links through QQ groups or emails, so be cautious about links from unknown sources.

4.3.3 DOM based XSS attack

Dom-based XSS attacks do not involve the page Web server.

Modify the data of a Web page during the transfer of Web resources or while the user is using the page.

4.4 how do I prevent XSS attacks

Whatever the type of XSS attacks, they all have one thing in common: they first inject malicious scripts into the browser, which then send user information to the malicious server deployed by the hacker.

So you can prevent XSS attacks by preventing the injection of malicious JavaScript scripts and the sending of malicious messages.

4.4.1 pure front-end rendering

Instead of server-side rendering, request through the interface, and then use innerText, setAttribute, etc., to set the content or attribute

4.4.2 The server filters or transcodes the input script

Transcoding key characters on the server, such as

4.4.3 Use CSP

The full name of CSP is Content-security-policy, which translates to Content Security Policy

  • Restrict the loading of resource files in other domains, so that even if a hacker inserts a JavaScript file, the JavaScript file cannot be loaded;
  • Do not submit data to third-party domains, so that user data is not leaked.
  • Prohibit execution of inline scripts and unauthorized scripts;

Such as

  • Only resources of this site are allowed to be loaded:
Content-Security-Policy: default- the SRC 'self'Copy the code
  • Only HTTPS images are allowed to be loaded:
Content-Security-Policy: img-src https:/ / *
Copy the code
  • Allows loading of any source frame:
Content-Security-Policy: child-src 'none'
Copy the code

4.4.4 Use the HttpOnly attribute

Cookies that use the HttpOnly tag can only be used during HTTP requests, so they cannot be read by JavaScript.

5, CSRF

5.1 What is CSRF

The full name of CSRF is Cross-site request Forgery, so it is also called “cross-site request forgery”. It refers to a cross-site request initiated by a hacker who lures a user to open a hacker’s website and uses the user’s login status in the hacker’s website. Simply put, a CSRF attack is when a hacker takes advantage of a user’s login status and uses a third party’s site to do something bad.

5.2 CSRF Attack mode

There are three requirements for launching a CSRF attack:

  • Target site should have CSRF vulnerability;
  • The user must have logged in to the target site, and keep the login status of the site on the browser;
  • The user needs to open a third party site, either a hacker’s site or some forum.

Generally, when a user opens a hacker’s page, the hacker has three ways to carry out a CSRF attack.

  • Automatically initiate a Get request for example, a hacker page has an image, the page as soon as the image is loaded to initiate a request
 <img src="xxx">
Copy the code

  • Automatically initiates a POST request

    Build a hidden form that triggers form submission when the page loads

  • Entice users to click on links

5.3. How do I prevent CSRF Attacks

CSRF is mainly caused by server vulnerabilities, so the main protection measures are to improve server security

5.3.1 Make use of the SameSite attribute of cookies

  • Strict is the strictest. If the value of SameSite is Strict, the browser completely disallows third-party cookies.
  • Lax is a little looser. In the cross-site scenario, cookies are carried both by opening a link from a third-party site and by submitting a Get form from a third-party site. However, if you use the Post method in a third-party site, or if you load urls through tags like IMG or IFrame, these scenarios do not carry cookies.
  • None: Sends Cookie data in any case.

Set some critical cookies to Strict or Lax mode so that they are not carried by third-party sites when they make requests, thus failing login authentication and rendering CSRF attacks ineffective.

5.3.2 Verify the source site of the request

Attacks come from section 3 sites, so you can prevent CSRF attacks by looking at the source. How do you get the source? Use the Referer and Origin attributes in the HTTP request header.If the request header does not contain the Origin attribute, then determine whether to use the Referer value according to the actual situation.

5.3.3, CSRF Token

The server returns the page with an identity and calls the interface with that identity. Since third-party sites cannot obtain the identity, even if a request is made, the server will reject the request because the identity is incorrect.

6. Relevant interview questions

  1. Just to make a little bit of sense of what you think the same origin policy is
  2. The difference between same-origin and same-site
  3. The difference between storage and reflection attacks in XSS attacks
  4. How do I prevent XSS attacks
  5. What is a CSRF
  6. How do I prevent CSRF attacks
  7. Talk about your understanding of XSS and CSRF attacks
  8. Why XSS and CSRF attacks

Suggest oneself first according to above content answer below.

Answer:

  1. To clarify your understanding of the same origin policy:

A: The same protocol, the same domain name, and the same port are called homology, and any operation can be carried out between homology, while there will be some restrictions between different sources, which can be divided into DOM, Web data and network three levels. Different sources in DOM cannot be modified, and cookies and other data cannot be obtained from different sources. You cannot invoke interfaces from different sources using XML or FETCH.

  1. The difference between same-origin and same-site

A: The same protocol, domain name, and port must be the same. The same site requires only the protocol and the same root domain name. For example, the following urls belong to the same site.

https://shop.example.com
https://www.example.com
Copy the code
  1. The difference between storage and reflection attacks in XSS attacks

A: Web servers do not store malicious scripts for reflective XSS attacks, which is different from stored XSS attacks

  1. How do I prevent XSS attacks

A: See 4.3

  1. What is a CSRF

A: Cross-domain request forgery, which simulates user request behavior through third-party sites

  1. How do I prevent CSRF attacks

A: See 5.3

  1. Talk about your understanding of XSS and CSRF attacks

A: XSS works by injecting malicious scripts into the user’s page, and then uploading the data of the user’s page to the hacker’s server through the malicious scripts. The hacker then uses the data for some malicious operations. CSRF attacks do not need to inject malicious code into the user’s page, but only exploit the vulnerability of the server and the user’s login status to carry out the attack. XSS exploits the user’s trust in a website, while CSRF exploits the user’s trust in a website.

  1. Why XSS and CSRF attacks

A: Browsers have two “back doors” for the same origin policy: one allows you to reference any third-party resource in the page, and the other allows XMLHttpRequest and Fetch to request resources across domains through the CORS policy.

Refer to the link

Working principle and practice of browser