[browser working principle and practice] Day11 | browser security – security Web page: XSS attacks & CSRF attacks

Browser security is divided into three parts:

• Web Page Security
• Browser Network Security
• Browser System Security

This article focuses on analyzing Web page security based on the same-Origin policy.

The same-origin policy

concept

If the protocol, domain name, and port of two urls are the same, they are said to be of the same origin.

By default, browsers can access resources and manipulate the DOM between two identical sources. If two different sources want to access each other’s resources and manipulate the DOM, they are constrained by a basic set of security policies, which we call the same-origin policy.

The specific performance

Specifically, the same origin policy isolates the DOM, page data, and network traffic from different sources, thereby securing Web pages.

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

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

Third, the network level. The same origin policy restricts the sending of a site’s data to a site from a different source through, for example, XMLHttpRequest.

Security and convenience trade-offs

However, you can’t have your cake and eat it. Absolute security requires the sacrifice of convenience, so we need to strike a balance between the two and find a middle point, which is the current page security strategy prototype. To sum up, it has the following three characteristics:

1. Pages can reference third-party resources, but this exposes many security issues such as XSS, so CSP was introduced on top of this openness to limit its freedom.

   • The browser can’t tell whether the inserted file is malicious or normal, and the malicious script can parasitically populate the page, modifying the user’s search results, changing the link direction of some content, and so on when the page is launched.

• It also sends sensitive data such as cookies, IndexDB and LoacalStorage to the server via XSS.

2. Cross-domain requests cannot be made directly with XMLHttpRequest or Fetch, so browsers have introduced cross-domain resource Sharing policies (CORS) on top of this strict policy to make it safe for cross-domain operations.
3. The DOM of two different sources cannot be manipulated with each other, so cross-document messaging is implemented in browsers to allow them to communicate more securely. You can communicate with the DOM of different sources through the JavaScript interface of window.postMessage.

To summarize the relationship between the same origin policy, CSP, and CORS:

1. Use CSP to reference third-party resources
2. Cross-domain requests use the CORS mechanism
3. Read data and manipulate the DOM using a cross-document mechanism

Cross-site scripting (XSS)

Third-party resource references and CORS in support pages also cause a number of problems, the most typical of which is XSS attacks.

XSS stands for Cross Site Scripting, which is called XSS for short in order to distinguish it from “CSS”, which translates as “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. Such as:

• canStealing Cookie information.
  • Malicious JavaScript can obtain cookie information through “document.cookie” and send the data to the malicious server using XMLHttpRequest or Fetch plus CORS. Once the malicious server gets hold of the user’s Cookie information, it can simulate the user’s login on other computers and perform operations such as transferring money.
• canMonitoring user behavior.
  • Malicious JavaScript can use the “addEventListener” interface to listen for keyboard events, such as credit card information entered by the user, and send it to a malicious server. With that information, hackers can do a lot of illegal things.
• The DOM can be modified to forge a fake login window to trick users into entering information such as user names and passwords.
• You can also generate floating window ads within the page, which can seriously affect the user experience

Attack mode

There are three common XSS attack modes: storage XSS attack, reflection XSS attack and DOM based XSS attack.

1. Storage XSS attack

Here’s how a stored XSS attack injects malicious scripts into HTML files:

From the figure above, we can see that stored XSS attack generally needs to go through the following steps:

• First, the hacker took advantage of the vulnerability to submit a piece of malicious JavaScript code to the site’s database.
• The user then requests a page from the site that contains a malicious JavaScript script;
• When the user browses the page, the malicious script uploads the user’s Cookie information and other data to the server.

After obtaining the user’s Cookie information, the hacker can use the Cookie information to log in to the user’s account on other machines (as shown in the following figure) and conduct some malicious operations by using the user account.

2. Reflex XSS attack

In a reflexive XSS attack, a malicious JavaScript script is part of a request sent by a user to a web site, which then sends the malicious JavaScript script back to the user. When a malicious JavaScript script is executed in a user’s page, the hacker can use the script to do something malicious.

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. This is a reflective XSS attack.

In real life, hackers often induce users to click on these malicious links through QQ groups or emails, so we must be very careful about some links.

It is also important to note that the Web server does not store malicious scripts for reflective XSS attacks, which is different from stored XSS attacks.

3. DOM based XSS attack

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

Specifically, hackers inject malicious scripts into users’ pages through various means, such as network hijacking to modify the content of HTML pages during page transmission. There are many types of hijacking, including WiFi router hijacking, local malware hijacking. What they have in common is modifying the data of a Web page during the transfer of Web resources or during the user’s use of the page.

Prevention strategies

Server-side security vulnerabilities:

• Both storage XSS attacks and reflection XSS attacks need to be processed by the Web server.

Front-end security holes:

• Dom-based XSS attacks are all done on the browser side

Regardless of the type of attack, the common thread is that the malicious script is first injected into the browser, and then the malicious script sends user information to the malicious server deployed by the hacker.

Let’s take a look at some common strategies for preventing XSS attacks.

1. The server filters or transcodes the input script

2. Take full advantage of CSP

The core idea of CSP content security is to let the server decide what resources the browser can load and whether the browser can execute inline JavaScript code.

Implementing strict CSP can effectively defend against XSS attacks. Specifically, CSP has the following functions:

• 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;
• It also provides a reporting mechanism, which helps us discover XSS attacks as quickly as possible so that problems can be fixed as quickly as possible.

Therefore, good use of CSP can effectively reduce the probability of XSS attack.

Use the HttpOnly attribute to protect important Cookie information

The HttpOnly flag is set by the server via the HTTP response header. The following is a section of the HTTP response header when Google is opened:

set-cookie: NID=189=M8q2FtWbsR8RlcldPVt7qkrqR38LmFY9jUxkKo3-4Bi6Qu_ocNOat7nkYZUTzolHjFnwBw0izgsATSI7TZyiiiaV94qGh-BzEYsNVa7TZmjAYTxYTOM9L_- 0CN9ipL6cXi8l6-z41asXtm2uEwcOC5oh9djkffOMhWqQrlnCtOI; expires=Sat,18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly
Copy the code

As you can see, the set-cookie attribute value ends up marking the cookie with HttpOnly. As the name implies, cookies that use the HttpOnly tag can only be used during an HTTP request, so they cannot be read by JavaScript. We can also use Chrome developer tools to see which cookies are marked HttpOnly, as shown below:

As can be seen from the figure, the HttpOlny property of the NID Cookie is checked, so the contents of the NID cannot be read through the document. Cookie.

JavaScript cannot read Cookie data with HttpOnly set, so even if a page is injected with malicious JavaScript scripts, it cannot get data with HttpOnly set. So for some important data we recommend setting the HttpOnly flag.

CSRF attacks

English full name is cross-site request forgery, also known as “cross-site request forgery”, refers to the hacker to entice the user to open the hacker’s website, in the hacker’s website, using the user’s login status to initiate cross-site request. 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.

Attack mode

Let’s take geek Time as an example to see how all three attacks are carried out. Here, it is assumed that Geek Time has the transfer function, which can be realized through POST or Get. The transfer interface is as follows:

# Support both POST and Gethttps://time.geekbang.org/sendcoin## target user ## target amount numberCopy the code

1. Automatically initiates a Get request

The easiest way to attack a hacker is to automatically initiate a Get request. For details, you can refer to the following code:

<! DOCTYPE html><html>
  <body>
    <h1>Hacker's Site: CSRF attack demo</h1>
    <img src="https://time.geekbang.org/sendcoin?user=hacker&number=100">
  </body>
</html>
Copy the code

This is the HTML code of the hacker’s page. In this code, the hacker hides the transfer request interface inside the IMG tag, fooling the browser that it is an image resource. When the page is loaded, the browser automatically initiates an IMG resource request. If the server does not make a judgment on the request, the server will assume that the request is a transfer request, and the 100 geek coins from the user’s account will be transferred to the hacker’s account.

2. Automatically sends a POST request

In addition to automatically sending Get requests, some server interfaces use the POST method, so the hacker also needs to forge a POST request on his site. When the user opens the hacker’s site, it will automatically submit a POST request.

<! DOCTYPE html><html>
<body>
  <h1>Hacker's Site: CSRF attack demo</h1>
  <form id='hacker-form' action="https://time.geekbang.org/sendcoin" method=POST>
    <input type="hidden" name="user" value="hacker" />
    <input type="hidden" name="number" value="100" />
  </form>
  <script> document.getElementById('hacker-form').submit(); </script>
</body>
</html>
Copy the code

In this code, we can see that the hacker has built a hidden form on his page that is the geek Time transfer interface. When the user opens the site, the form is automatically submitted; When the form is submitted, the server performs the transfer. So by building an auto-submit form, you can automatically POST data across sites.

3. Entice users to click on links

In addition to automatically making Get and Post requests, another way to entice users to click on a link on a hacker’s site is usually on a forum or in a malicious email. Hackers can use a number of methods to entice users to click on links, as shown in the following code:

<div>
  <img width=150 src=http://images.xuejuzi.cn/1612/1_161230185104_1.jpg> </img> </div> <div>
  <a href="https://time.geekbang.org/sendcoin?user=hacker&number=100" taget="_blank">Click to download photos of beautiful women</a>
</div>
Copy the code

The code for the hacker’s site, which features a picture of a beautiful woman and a download address below, is actually a link the hacker uses to transfer money. Once the user clicks on the link, his geek money is transferred to the hacker’s account.

The above three attacks are often used by hackers. If any of the three CSRF attacks occur when the user logs in to Geek Time, the server sends a certain amount of geek money to the hacker’s account.

At this point, I’m sure you already know what a CSRF attack is. Unlike XSS, CSRF attacks do not require the injection of malicious code into a user’s page, but simply exploit the vulnerability of the server and the user’s login status to carry out the attack.

Prevention strategies

There are three requirements for launching a CSRF attack:

1. First, the target site must have CSRF vulnerability;
2. Second, the user must have logged in to the target site and remain logged in to that site on the browser.
3. Third, the user needs to open a third party site, which can be a hacker’s site, or some forum.

After the above three conditions are met, the hacker can launch a CSRF attack on the user. It is also important to note that, unlike XSS attacks, CSRF attacks do not inject malicious scripts into the page, so hackers cannot obtain user page data through CSRF attacks. The most critical point is to find the vulnerability of the server, so the main means of protection against CSRF attack is to improve the security of the server.

There are usually several ways to protect a server from CSRF attacks.

1. Take full advantage of the SameSite property of cookies

Cookies are a key part of maintaining login status between the browser and the server, so to prevent CSRF attacks, we should consider cookies in the first place.

Generally, CSRF attacks are initiated from third-party sites. To prevent CSRF attacks, it is better to prevent Cookie sending when a request is sent from a third-party site. Therefore, the browser sends HTTP requests from different sources with the following differences:

• If the request is from a third party site, you need the browser to prohibit sending certain critical Cookie data to the server.
• If the request is from the same site, you need to ensure that the Cookie data is sent properly.

The SameSite attribute in the Cookie is designed to solve this problem. Using SameSite can effectively reduce the risk of CSRF attacks.

How does SameSite protect against CSRF attacks?

In the HTTP response header, when setting a cookie via the set-cookie field, you can add the SameSite option as follows:

set-cookie: 1P_JAR=2019-10-20-06; expires=Tue, 19-Nov-2019 06:36:21 GMT; path=/; domain=.google.com; SameSite=none
Copy the code

The SameSite option usually has Strict, Lax, and None values.

• Strict is the strictest. If the value of SameSite is Strict, the browser completely disallows third-party cookies. In short, if you access an InfoQ resource from a Geektime page, and some of InfoQ’s cookies have SameSite = Strict set, they will not be sent to InfoQ’s server. These cookies are only carried when you request an InfoQ resource from an InfoQ site.
• 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.
• Using None sends Cookie data in any case.

To prevent CSRF attacks, we can set some critical cookies to Strict or Lax mode according to the actual situation. In this way, these critical cookies will not be sent to the server during cross-site requests, thus disabling the CSRF attacks of hackers.

2. Verify the source site of the request

Next, let’s look at another strategy for preventing CSRF attacks, which is to validate the site from which the request comes on the server side. Since most CSRF attacks come from third-party sites, the server can block requests from third-party sites. So how do you tell if a request is coming from a third-party site?

This brings us to the Referer and Origin attributes in the HTTP request header.

2.1 Referer properties

Referer is a field in the HTTP request header that records the source address of the HTTP request. For example, if I open the InfoQ site from geektime, the Referer value in the request header is the GeekTime URL, as shown below:Although it is possible to use the Referer to tell the server the source of the HTTP request, there are some scenarios where it is not appropriate to expose the source URL to the server, so the browser provides the developer with an option not to upload the Referer valueReferrer Policy.

2.2 Origin attribute

The Referer in the request header was not reliable enough to validate on the server side, so the standards committee reworked itOrigin attributeThe Origin attribute is used in important situations, such as when making cross-site requests via XMLHttpRequest, Fecth, or Post, as shown in the following figure:

As can be seen from the figure above, the Origin attribute only contains domain name information, and does not contain the specific URL path, which is a major difference between Origin and Referer. It should be added here that the Origin value does not contain detailed path information because some sites do not want to expose the detailed path of the source site to the server for security reasons.

Therefore, the server’s policy is to determine Origin first, and if the request header does not contain the Origin attribute, then determine whether to use the Referer value according to the actual situation.

3. CSRF Token

In addition to using the above two methods to prevent CSRF attacks, you can also use THE CSRF Token to authenticate. This process is easy to understand and can be roughly divided into two steps.

First, when the browser makes a request to the server, the server generates a CSRF Token. The CSRF Token is essentially a string generated by the server, which is then implanted into the returned page. You can refer to the following sample code:

<! DOCTYPE html> <html> <body> <form action="https://time.geekbang.org/sendcoin" method="POST"> <input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn"> <input type="text" name="user"> <input type="text" name="number"> <input type="submit"> </form> </body> </html>Copy the code

Step 2: If you want to initiate a transfer request on the browser side, you need to bring the CSRF Token in the page, and then the server will verify whether the Token is valid. If a request is made from a third-party site, the value of the CSRF Token will not be available, so even if a request is made, the server will reject the request because the CSRF Token is incorrect.

conclusion

The main causes of Web page security problems are two “back doors” opened by browsers for same-origin policies:

1. You can refer to any third-party resource on the page
2. Let XMLHttpRequest and Fetch request resources across domains using the cross-domain resource sharing policy CORS.

How to solve

1. Introduce a CSP to restrict pages from importing arbitrary external resources
2. Introduce an HttpOnly mechanism to prevent XMLHttpRequest or Fetch from sending some critical cookies
3. SameSite and Origin are introduced to protect against CSRF attacks

Write in the last

Learning resources from Geek Time – Teacher Li Bing “Browser working principle and Practice”. Next, let’s check in every day

• Day 01 Chrome architecture: Why 4 processes with only 1 page open?
• Day 02 TCP: How to ensure that a page file can be delivered to the browser in its entirety?
• Day 03 HTTP Request Flow: Why do many sites open quickly the second time?
• Day 04 Navigation flow: What happens between entering the URL and presenting the page?
• Day 05 Rendering Flow: How do HTML, CSS, and JavaScript become pages?
• JavaScript execution mechanisms in the Day 06 browser
• Day 07 V8 how it works
• Page loop system in Day08 browser
• Page in the Day09 browser
• Day10 learn the history of HTTP
• Day11 Browser Security for Web page security: XSS attack & CSRF Attack