3

I am trying to understand Cross Site Script Inclusion (XSSI) attacks. For this, I have read the recent paper about this kind of attack.

Now my main focus is on detecting dynamic javascript files from the targeted web page.

What I want to know is, is it really possible to get a different script by hitting the same script source twice (once with cookies, once without cookies)? Or am I misunderstanding the paper? So far I have tested several web pages and found no such case.

Any example dataset or any example JS that returns different output based on authentication cookies will be helpful for me.

Anders
  • 64,406
  • 24
  • 178
  • 215
Tasnim Fabiha
  • 133
  • 4
  • 2
    `So far I have tested several web pages and found no such case.` - Well, you can't expect to immediately find a vulnerable instance just by testing a few sites. – Arminius Oct 17 '17 at 15:20
  • Yes, I know and I am not expecting that either. But the fact that, whether it is actually possible or not- became the major concern for me. – Tasnim Fabiha Oct 17 '17 at 16:14

1 Answers1

3

The theory

99.9% of all JavaScript that is served on the web is static, e.g. the same no matter what values any cookies has or anything else. It's just a file that is served as-is from the server, just like say an ordinary JPG image.

For a few cases, though, the JavaScript might be generated dynamically (using a language like PHP), and a request could yield different results if it is made with or without cookies. In these rare cases there might be an XSSI vulnerability.

Generating dynamic JavaScript is a horrible design practise and not something you would expect well trained developers to do. So don't expect to find vulnerabilities like this easily. But sure, they are out there, somewhere... But if I knew where to find them, I would not be telling you - I would be disclosing the vulnerabilities responsibly to the owners of the sites.

An example

Let's say I am writing a webpage where users can pass secret messages to each other, hosted at secretmessage.com. The webpage checks for new messages by loading new_messages.js from the server. The content of that file is generated with PHP like this (note that the result will look different depending on the cookies in the request):

<?
session_start();
$user_id = $_SESSION["user_id"];
?>
var latestMessage = "<?= $database->getLatestMessage($user_id); ?>";

Running that script will put the latest message for the user making the request into a JS variable, that I then can convinently output somewhere. Great, isn't it? Well, no...

Now imagine the evil attacker creates a page (http://evil.com) that includes http://secretmessages.com/new_messages.js in a script tag. The browser will dutifully request the new_messages.js from secretmessages.com with cookies and all, including the session cookie. The content of latestMessage will then be readable from the code on evil.com. So all the attacker has to do to read peoples secret messages is to trick them into visiting evil.com.

Community
  • 1
Anders
  • 64,406
  • 24
  • 178
  • 215