How I Discovered Two RXSS Bugs on Two Microsoft Subdomains
In this article, I am going to cover two RXSS[1] bugs that I found on two different Microsoft subdomains. A few weeks ago, while browsing the create.microsoft.com subdomain, I discovered that the “fallbackUrl=” parameter was vulnerable to open redirect. As usual, I tried to escalate this to RXSS. After trying several payloads, I finally found an encoded payload that successfully escalated this Open redirect to RXSS.
Payload: java%0d%0ascript%0d%0a:alert(document.domain)
Vulnerable endpoint: https://create.microsoft.com/en-us/launch-app?fallbackUrl=java%0d%0ascript%0d%0a:alert(document.domain)
Timeline:
◘ 14th March 2024— Report Submitted through MSRC Portal
◘ 14th March 2024 — MSRC team confirmed and opened a case for this issue
◘ 3rd May 2024 — MSRC team changed the status Develop to Pre-Release
◘ 3rd May 2024— MSRC team changed the status Pre-Release to Complete.
POC Video:
The second bug is on a regional site at the visualstudio.microsoft.com subdomain. Last year, while browsing this website, I discovered a Self-XSS bug on their second search bar on the download page. To explore further, I accessed the website’s archived links using Archivefinder[2] and discovered another search parameter (q). I tested this parameter using different payloads and various encodings, but all the payloads were sanitized. Continuing my investigation, I attempted to test some payloads on the same parameter on one of their regional sites using different encodings, but all attempts failed. Finally, I experimented with a double URL-encoded payload on that regional website, which successfully executed a RXSS bug. Below are the steps I took to identify this vulnerability:
Payload: %253CsCrIpt%253Ealert(document.domain)%253C%252FScRipt%253E%250A
This year, I bypassed the previous fix again by using the double-encoded payload below.
%253Ciframe%253E%253Ctextarea%253E%253C%252Fiframe%253E%253Cimg%2520src%253D%2522%2522%2520onerror%253D%2522alert(document.domain)%2522%253E%2520%250A
Timeline:
◘ 2nd March 2023 — Report Submitted through MSRC Portal
◘ 2nd March 2023 — MSRC team confirmed and opened a case for this issue
◘ 10th March 2023 — MSRC team changed the status Review / Repro to Develop
◘ 15th March 2023 — MSRC team changed the status Develop to Fix.
◘ 4th March 2024 — Fix Bypass Report Submitted through MSRC Portal
◘ 3rd April 2024 — MSRC team confirmed and opened a case for this issue
◘ 25th April 2024 — MSRC team changed the status Review / Repro to Develop
◘ 25th April 2024 — MSRC team changed the status Develop to Complete.