As you can see - it’s html document. As far, as we are able to control part of response content and it’s unescaped - it would render as normal html. That’s typical XSS.
JSON contains GET filename parameter unescaped, controlled by us. The Proof of Concept would look like this:

Those two XSS were duplicates. Also as you can notice, both are unexploitable without having CSRF token (in my case: uc52c5955b971de4d17729378417f305d). That’s why I want to introduce...

3) Same-Origin Policy bypass
I was working to find out how steal this token. At first I noticed, that the same CSRF token is used in multiple services (of course different tokens for different users ;)). One of places where this token appears in source code is Yandex Maps. After many days of trying to somehow get secret key - I checked crossdomain.xml. It's a special file used by Flash or Java for Same-Origin Policy purposes. Here’s how it looks for maps.yandex.com:

It means, that Flash application hosted on any domain from above is able to send requests (with credentials) to http://maps.yandex.com and also gain full response content (the same that browsers renders for authenticated user).
The problem was that I didn’t had possibility to upload my specially prepared SWF file to be hosted on any of this domains.
After lots of research and analysis of swf files hosted on those domains, I found one interesting:

...which is XML file. As far as this service (kraski) is not working anymore, I had to determine how the XML file should looks like, to execute my own flash :) Effect:<?xml version="1.0" encoding="UTF-8"?>
<card picturesTotal="1" v="1.0">
<visual type="Picture">
<content>Q1dTDgoFAAB42l1TzW7b(........)TxP9U4ZKU=</content>
</visual>
</card>

After running all - Chrome console showed me full content of maps.yandex.com:

The full attack scenario goes this way:1. Victim visits malicious site (ropchain.org)2. Attacker puts there <object> with kraski-universal-blogplayer 3. Victim click on ‘play’ button.4. Response from flash, through ExternalInterface.call() arrives to javascript console.log() on ropchain.org domain (SOP bypass) 5. Because attacker have access to javascript in ropchain.org origin - he can parse response for CSRF token.6. Attacker exploits both XSS issues, because now he know secret-key value :) (as far as first one is reflected XSS - it cannot be exploited on browsers that uses some Anti-XSS mechanism, but the second one works fine on all modern browsers. That is why on video I’ll show later only one alert will apear (as far as I'm Chrome user).

Of course - it’s not the end. :) Bypassing Same-Origin Policy can be exploited in worst scenario, because mail.yandex.com have the same crossdomain.xml file. ;-) So attacker is able to read sensitive data such as: user login, user phone number, list of contacts, e-mail subjects and content. Every domain that Yandex own and have similar crossdomain.xml file - is vulnerable to this attack. In mail.yandex.com there are two interactions that victim need to do - first is accept certificate for kraski-static.yandex.net, and second is to click “Play” button.