At a recent Black Hat, there was an interesting presentation about the possibility of obtaining various information from third-party sites using a simple attack – Cross Site Scripting Inclusion (XSSI).
If you read Easy Hack systematically, then you are probably already familiar with the Same Origin Policy (SOP), we often return to it. Because of the SOP, the ability to interact between the two “sites” is very limited. But since the task of receiving and sending information on one site from another arises often, various methods have been introduced to “soften” the policy and organize interaction. For example, such as CORS or crossdomain.xml. One of the older methods is to load JavaScript from another domain via the <script>. SOP does not limit us here: you can specify an almost arbitrary location.
For example, there is an attacker’s host evil.ru and a victim’s website – victim.com. We can put an HTML file on evil.ru and refer to any script from the victim:
<script src="http://victim.com/any_script_.js"></script>When a user enters the attacking site, the browser will load and run JS from victim.com, but in the context of SOP evil.ru. This means that from the JS of the attacker itself, we will be able to access data (not all) JS from the victim’s server.
For example, the JS content from the victim site ( http://victim.com/any_script_.js ):
var a = "12345";Then on the attacker’s website we can get the value of the variable:
<script src="http://victim.com/any_script_.js"></script>
<script>console.log(a);</script>The idea of work is as simple as an aluminum teapot.
In fact, the ability to load static JS from other sites poses no more problems for the victim site than loading an image.
Problems can arise when JS is generated dynamically, that is, when the content of the JS script changes based on the data from the cookie, depending on which user accesses it. For example, some “critical” information is stored in JS: personal information (email, username on the victim site) or technical information (anti-CSRF tokens).
But, as we know, when the script is loaded through the tag <script>, the user’s browser automatically sends the user’s cookie. Adding these facts, we get the opportunity to obtain information about any user who has visited the attacker’s site and is logged in to the victim site.
What can we find out? Global variables and results of global functions. Unfortunately, we cannot get access to internal variables / functions (although, perhaps, someone will find a way to do this too).
function test(){
return "private data frm function";
}Such an attack looks possible, but it seems that it is too simple and should not be common. This is what makes the Black Hat presentation interesting. The researchers analyzed 150 popular sites and found that a third of them are vulnerable to some extent. Such statistics make us look at the problem a little more closely.
Another regularity was also revealed. Content Security Policy is becoming more and more common. As you know, with it we can specify from which domains this or that resource can be loaded. For example, you can say to execute JS only from the same resource. In addition, the best practices for configuring CSP imply a ban on running inline JS (that is, code that is directly in HTML, and not loaded from a JS file).
However, transferring inline to files can be done with crutches and in a hurry – that is, through dynamically generated scripts. Since CSP does not affect XSSI in any way, we can still carry out our attacks. Here is such a bad practice.