Your Script in My Page What Could Possibly Go Wrong

What is XSSI:

XSSI is a form of XSS that takes advantage of the fact that browsers don’t prevent webpages from including resources like images and scripts, which are hosted on other domains and servers. An included script doesn’t have its own security context. It runs in the security context of the page that included it. For example, if www.evil.example.com includes a script hosted on www.google.com then that script runs in the evil context not in the google context. So any user data in that script will “leak.”

How to read someone else’s private data using XSSI:

For Example, A user is authenticated to his mail provider at webmail.com, thus his browser automatically attaches the corresponding session cookies to all requests targeting webmail.com, which utilizes session-state dependent dynamic scripts.

Thus, whenever a user is logged in, the script at webmail.com/script.js creates a global variable containing the current user’s email address. In the same browser, the user now navigates to an attackercontrolled Web site at attacker.org.

The attacker includes the dynamic script in his own Web page and subsequently, the browser requests the script with attached authentication cookies. Although the script originates from webmail.com, it is now executed in the context of attacker.org, creating the global variable with the user’s email in the corresponding context.

The global variable is now accessible to any other script executed by attacker.org. Hence, the attacker can simply access the value of this global variable, effectively leaking the user’s email address.

Leaking data via Global Variables:

By simply executing the script from a different origin, the variable gets created inside the global scope of the attacker-controlled page. After the execution of the script, the attacker can simply read the value by accessing the global variable.

Yes. I am getting the sensitive data leaked from another origin.

How do i Protect my website from XSSI:

There are various measures developers need to implement to defend against XSSI attacks. One is to pass a unique, unpredictable authorization token to the user and require that it gets sent back as an additional HTTP parameter before the server responds to any requests. Scripts should only respond to POST requests. This stops an authentication token being exposed as a URL parameter in a GET request, and it also prevents a script from being loaded via a script tag. Browsers may reissue GET requests, which can result in an action getting executed more than once, whereas reissued POST requests require the user’s consent.

Leave A Comment

Your email address will not be published. Required fields are marked *