API  -  A. P.otentially I.diotic  - Threat

Happy Hanukkah and Marry Christmas to you all!

The end of the year is always a great time to wrap things up and set goals for the next year. And also to get super-drunk, of course.

In today’s holiday-special case-study we’ll examine a case where an attacker from one website can affect an entire other website, without accessing the second one at all. But before that, we need to talk a bit about Self XSS.

Basically, Self XSS is a stupid vulnerability. Usually, to be attacked, victims need to paste ‘malicious’ JS code into their browser’s Developer Console (F12), which will cause the code to execute on the context of the page the Developer Console is active on.
When Self XSS attacks have started, users were persuaded to paste the JS code in order to get a certain ‘hack’ on a website.
To deal with that, until this day Facebook prints an alert on every page’s Developer Console, in order to warn its users:

Because websites can’t avoid users to paste malicious JS code to the DC (developers console), Self XSS (SXSS) vulnerabilities are not considered high-risk vulnerabilities.

But today we’ll approach SXSS from a different angle

We are about to see how websites can innocently mislead victims into pasting ‘malicious’ JS code planted by an attacker.
Some websites allow users to plant HTML or other kind of code into their own websites or personal blogs. This HTML code is often generated by the websites themselves and being handed to the users as-is in a text box. All the users have to do is simply copy the code and paste it in their desired location.

Now, I know this is not the exact definition of an API, but in this case-study, this is my interpretation to it — a 3rd-party website is giving another website a code which provides a certain service.


Some very known company which hasn’t allowed me to disclose its name yet has allowed users to get an HTML code containing data from a group the users were part of — owned or participated.
When pasted in a website, the HTML represented the last top messages in the group — their title and the intro of the message’s body.

When ‘malicious’ code was placed in the title, like: "/><img src=x onerror=alert(1)/> – nothing happened on the company’s website – they correctly sanitized and escaped the whole malicious payload.

BUT! When the HTML was representing the last messages, there was no escaping at all, and suddenly, attackers could have run malicious JS code from website A onto the context of website B, just by planting the code in a title of the group’s message topic they’ve created.

Who’s to blame?

Well, both websites should get a no-no talk.
Website A is the one who supplied an ‘API’ — HTML code that shows last messages from a group hosted in itself, but the API does not escapes malicious payloads correctly.
But website B violated the number one rule — never trust a 3rd-party website to do your job. Website B added an unknown code (not as an iframe, but as a script) and didn’t stated any ground rules — it blindly executed the code it was given.

So how can we trust the untrustworthy?

A certain client has asked me regarding this a few weeks ago.
She said:

I must use a 3rd party code which is not an iframe, what can I do to keep my website safe?”

Executing 3rd-party JS code on your website is always a bad-practice (and I’m not talking of course on code like jQuery or javascript dependencies, although I am writing these days a very interesting article addressing this exact topic. Stay tuned).
My suggested solution is: Simply plant this code in a sandboxed page, and then open an iframe to that page. ITS THAT SIMPLE!

That way, even if website A will not escape its content as expected, the sandbox, Website C will be the one who take the hit.
This, of course, does not apply for scenarios where website B’s context is a must for website A, but it will work 95% of the time.

So why have I classified this case-study’s vulnerability as a Self-XSS?

Simply because I believe that when you put a 3rd-party code on your website you are Self-XSSing yourself, and all of your users.
The way I see it, Self-XSS is not just a stupid ‘paste-in-the-console’ vulnerability, its also using an unknown 3rd-party JS code in a your own environment.

This article was the last one of 2016.
I want to thank you all for a great year. Please don’t drink too much, and if you do — don’t drink and bug hunt! (Although, truth be told, that 10 Minutes XSS I’ve found on Soundcloud was after a night out. Oops.)

Happy holidays, and of course — happy & successful new year!