Unveil the secrets of XSSI attacks

Unveil the secrets of XSSI attacks

Same-origin policy

The same-origin policy is a well-known security policy proposed by Netscape. All supported nowJavaScriptAll browsers use this policy. The so-called same source means that the domain name, protocol, and port are the same. Client scripts of different sources (javascript、ActionScript) You cannot read or write resources of the other party without explicit authorization.

 

Same-source JavaScript Policy

The same-source policy of JavaScript has two points worth noting:

1. It is necessary to include third-party scripts (such as advertisements and jQuery) 2. The same-origin policy relaxed the script code that inherits from the source website (the two work within the same global scope ).

Json hijacking: Also known as JavaScript hijacking (as shown in)

 

Can we find other ways to expose personal data on the website?

The idea is as follows:

1. Is there any dynamic JavaScript file? 2. If yes, do these files contain user data? 3. May the data be leaked in a similar way?

First, check for dynamic JavaScript files.

 

Here we made a practical exploration. We tried to register a test account in 150 popular websites and then use personal data to fill in the account data, then we use our browser extension to thoroughly interact with the website to obtain these scripts, and finally manually study these dynamic scripts.

Detected JavaScript files on 150 websites-does it contain user data?

The following are the test results:

 

XSSI (Cross-Site Scripting)

Cross Site Script transfer Sion (XSSI) is an attack technology that allows attackers to steal information through malicious JavaScript code bypass the border.

 

Attackers can include JavaScript files that may leak user information in the following code:

(1) User Data leaked in JavaScript is stored in global variables.

 

Javascript has two types of variables: local variables and global variables. Local variables are variables that can only be called within the function declared in this variable, while global variables are variables that can be called throughout the Code.

(2) The data leaked in JavaScript comes from global functions.

Dynamic JS

 

Attackers JS

 

Check whether JavaScript files with information leakage risks in 150 websites can be used. The results are as follows:

 

Case Study

1. data leakage caused by global variables

When the leaked data is stored in the global variable of the script, the attacker can add the variable to the current environment as long as it contains the script, attackers can easily read data by accessing the global variable.

First look at the script file leak1.js that generates data leaks

 

Here there is a global variable secret

Look at the attacker again

 

Introduce leak1.js first

Then the secret variable enters the local environment.

Finally, the value of this variable is obtained through window. secret.

2. data leakage caused by global function parameters (1)

Many websites split functions to write them into different script files. Common Function functions are usually concentrated in a basic library, while actual business logic functions are contained in another separate file. Generally, scripts that contain business logic call the registered basic functions in the global scope. When attackers include these scripts, they can rewrite the global functions in the script to manipulate the leaked data.

First look at the script file lack2.js that generates data leaks

 

Here, a globalFunction will pass in the secret parameter. by rewriting this function, we can get the value of the variable.

View attackers

 

First, rewrite the globalFunction to output the value of this variable.

Then introduce the script file that causes data leakage.

Finally, this globalFunction is executed to output data.

3. data leakage caused by global function parameters (2)

Similar to the same example, the vulnerability code calls a global function and passes some data to it. However, the data passed to the function is a callback function that contains the desired data. Attackers can use the toString method to obtain the data in the callback function.

First look at the script file lack3.js that generates data leaks

 

The data we want is in the callback () function.

The globalFunction uses callback as a parameter. If we can rewrite the globalFunction and call the toString () method, we can get the secret value in the callback () function.

View attackers

 

First, rewrite the globalFunction. The parameter is callback, and then call the toString () method to convert the callback function to the character type. (Example below)

 

Then read the secret value through regular expressions.

Finally, introduce the script file that causes data leakage.

3. data leakage caused by prototype chain (1)

Using JavaScript prototype-based inheritance, an object can point to an inherited object to form a so-called prototype chain. For example, the prototype attribute of an array instance points to the Global Object Array. prototype, that is, it points to Object. prototype again.

When an object performs an attribute query, the JavaScript engine checks whether the object has a custom attribute. If the object itself does not contain the requested attributes, the JavaScript engine queries the parent node at the upper level for the same attributes. When an object has the required attributes, the corresponding values are returned and no longer queried from the parent node at the upper level. If this attribute is still not found after recursive query to the parent node at the upper level, the engine will return an undefined attribute.

Compared with standard variables in the static range, the key here is the dynamic range. In essence, this means that if a function is called by an object, it actually means that it is called by one of the object prototypes, not necessarily the object.

This behavior can prevent direct data access, but can be called by a function. For example, we can rewrite Array. prototype. forEach and attacker-controlled functions. If some code containing sensitive data is called by the forEach function, the attacker-controlled function will be called by an object in the object prototype containing sensitive data.

After reading it, You can directly look at the example:

First look at the script file leak4.js that generates data leaks

 

Secret is an array containing data, and then calls the browser's forEach traversal Function

Look at the attacker again

 

Because secret is an array, we use the prototype attribute to rewrite the forEach function of the array to manipulate the data.

Finally, introduce the script file for data leakage.

This idea focuses on understanding prototype and its use!

3. data leakage caused by prototype chain (2)

Like the previous example, a function and the toString method are used.

First look at the script file leak5.js that generates data leaks

 

Look at the attacker again

 

Use prototype to override all the call methods of Functiorn, call the. toString () method to convert the function to the string type, then read the content, and finally introduce the script file that produces data leakage for execution.

3. data leakage caused by global function calls

If a function is called, it can be referenced by the caller's attributes. For example, a function named "aFunction" can be referenced by the caller through aFunction. caller. When a function is referenced, we can use the toString method to return the source code of the function. If the called function contains any hard-coded sensitive data, attackers can easily access the data by parsing string representation.

Similar to 3

Summary

So how can we prevent XSSI vulnerabilities?

1. This attack is not based on a browser, so it cannot be protected by a browser. 2. prevent a third party from containing script files. solution: strict call review and token identification; 3. JavaScript code is separated from sensitive data to create static JS files and dynamic loading of data during runtime. The service can be protected through SOP.

Highlights:

1. It is widely used to dynamically generate JS files. Many dynamic JS files contain the user's session information, and the data contained in these script files can be accessed. 2. 150 of the 1/3 popular websites use dynamic scripts, and 80% are vulnerable to XSSI attacks. They can completely intrude into their accounts to gain personal privacy. 3. At last, we need to emphasize that XSSI is in conflict with Content Security Policy (CSP.

CSP is a mechanism to prevent cross-site scripting (XSS). It loads trusted JavaScript in the form of a whitelist and requires that all embedded scripts be independent from external files. Dynamic embedded scripts are not easily identified by XSSI, but XSSI vulnerabilities may easily occur after being externalized. Therefore, do not blindly separate scripts from external files, otherwise, the problem will become worse.