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

Securitum. Leading european penetration testing company 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 . CLOSE Insights Art of bug bounty: a way from JS file analysis to XSS Jakub Żoczek 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 end, which includes: > In depth analysis of vulnerability, > Proof of Concept for consent.cmp.oath.com domain, > Proof of Concept for tumblr.com. 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 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);" "javascript:alert(document.domain);" > isSafeUrl(url) false > url="ja\nvascript:alert(document.domain);" "ja vascript:alert(document.domain);" > isSafeUrl(url) true 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: 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 tumblr.com 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: Click me Impact: 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. Timeline: 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 MICHAŁ BENTKOWSKI 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. READ pentest chronicle 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... READ pentest chronicle Art of bug bounty a way from JS file analysis to XSS jAKUB żOCZEK 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 ... READ pentest chronicle Any questions? Happy to get a call or email and help! CONTACT US Services Pricing Resources Company Partnership Terms and conditions © 2023 Securitum. All rights reserved.