Homologous strategy

Homology policy is a famous security policy proposed by Netscape. Now all browsers that support JavaScript will use this strategy. The so-called homology refers to the same domain name, protocol and port. Client scripts of different sources (JavaScript, ActionScript) cannot read or write the resources of the other party without explicit authorization.

JavaScript javascript、ActionScript

Homology strategy of JavaScript

There are two points worth noting about the homology strategy of javascript:

JSON hijacking: also known as JavaScript hijacking (as shown in the figure below)

Can we find other ways to make the personal data of the website leaked?

The ideas are as follows:

First check the dynamic JavaScript file

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

JavaScript files from 150 websites were tested - did they contain user data?

The following are the test results:

Xssi (cross site script included)

Cross site script inclusion (xssi) cross site script inclusion is an attack technique that allows an attacker to steal information by bypassing the boundary through malicious JS.

An attacker can include JavaScript files that can reveal user information:

(1) User data leaked in JavaScript is stored in global variables

JavaScript has two kinds of variables: local variable and global variable. Local variable refers to the variable that can only be called inside the function declared by this variable, while global variable refers to the variable that can be called in the whole code. (extended reading: http://www.jb51.net/article/61442.htm)

(2) Leaked data in JavaScript comes from global functions

Dynamic JS

Attacker's JS

Statistics are made on whether JS files with information disclosure risk in 150 websites can be used. The results are as follows:

Case study - Case Study

1. Global variables cause data disclosure

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 the script is included, and the attacker can easily read the data by accessing the global variable.

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

There is a global variable, secret

(read http://blog.csdn.net/limlimlimlim/article/details/9198111)

Look at the attacker again

First introduce the leak1.js

Then the secret variable enters the local environment

Finally, get the value of this variable through window.secret

2. Data leakage caused by global functional parameters (1)

Many web sites split their functions to write to different script files. Common functions are usually concentrated in one basic library, while the actual business logic functions are included in another separate file. In general, scripts that contain business logic call those basic functions that have been registered globally. When the attacker includes these scripts, he can control the leaked data by rewriting the global functions in the scripts.

First, look at the script file lak2.js that generates data disclosure

Here is a globalfunction function that will pass in the secret parameter to get the value of the variable by overriding the function

Look at the attacker

Override the globalfunction function to output the value of the variable

And then introduce the script file that generates data disclosure

Finally, the globalfunction function is executed to output data

3. Data disclosure due to global function parameters (2)

Similar to the previous example, the vulnerability code calls a global function and passes some data to it. However, the data passed to the function this time is a callback function containing the data we want. The attacker can obtain the data in the callback function by using toString method.

(extended reading: tostring() http://www.nowamagic.net/libraries/veda/detail/1743)

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

The data we want is in the callback () function

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

Look at the attacker

First rewrite the globalFunction function, the parameter is callback, and then call the toString () method to transform the callback function into the character type. (for example)

Then read the secret value through regular

Finally, this script file is introduced to generate data disclosure

3. Data leakage caused by prototype chain (1)

With prototype based inheritance in JavaScript, objects can form so-called prototype chains by pointing to inherited objects. For example, the prototype attribute of an array instance points to the global object array.prototype, which once again points to the object.prototype.

When an object makes a property query, the JavaScript engine checks whether the object has so-called custom properties. If the object itself does not contain the requested property, the JavaScript engine will query the same property up to the parent node. When an object has the required properties, the corresponding value will be returned and no longer be queried to the parent node. If this property is not found after recursive query to the parent node, the engine will return the property undefined.

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

This behavior makes the data inaccessible, but it can be called by a function. For example, we can override the 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. (the translation here may be more obscure. It is suggested to read the original)

(extended reading: Javascript prototype http://www.cnblogs.com/helpinx/p/3286177.html JavaScript must know must know prototypehttp://www.cnblogs.com/mindsbook/archive/2009/09/19/javascript youmustknowprototype. HTML)

After reading the obscure, read the example directly:

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

Secret is an array containing data, and then the forEach traversal function of the browser is called.

Look at the attacker again

Because secret is an array, we directly rewrite the foreach function of the array through the prototype property to manipulate the data

Finally, the script file of leaking data is introduced

The key point of this idea lies in the understanding of prototype and its utilization!

3. Data leakage caused by prototype chain (2)

As in the previous example, but a function and toString method are used.

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

Look at the attacker again

Through prototype, all call methods of functional are rewritten, and then. Tostring() method is called to convert the function to string type and read the content. Finally, the script file generating data leakage is introduced for execution.

3. Data disclosure caused by global function call

If a function is called, it can be referenced by the caller's properties. For example, a function named "affunction" can be referenced by the caller through affunction.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, the attacker can easily access the data by parsing the string representation.

Similar to 3

summary

So how to prevent xssi vulnerabilities?

Several points need to be emphasized:

CSP is a mechanism for preventing cross site scripting (XSS), which loads trusted JavaScript in the form of a white list and requires all embedded scripts to be independent of external files. The dynamic embedded script itself is not easy to be xssi, but after externalization, xssi vulnerability will easily appear, so do not blindly separate the script to external files, otherwise it will make the problem worse.

WeChat official account: PHP Technology

It's not hard to upgrade PHPer to a god!