Discovery of CVE-2022-35406
On 11th April 2022, it was a regular day for me. I went to the office & started my daily activities. I was doing the things that I do every day!
I observe an open redirection in the Repeater Tab while pen-testing one of the products. I was not very excited about this, as open redirection is not a critical finding unless I chained it with another issue. So I was trying to see if I could escalate this issue or chain it with something else. But when I tried this same case in the browser, this was not reproducible. I was like…
What’s going on here??
- I tried again after turning off the proxy & observed if it gets redirected! But no, it doesn’t.
- Then I decided to repeat the same steps that I did earlier. I captured the request, sent it to the repeater tab & hit send button. Now got the HTTP 302 response.
At this time, I had two observations.
- I was getting redirected in Repeater Tab
- I wasn’t getting redirected in the browser.
I started looking in the repeater tab where & why it was redirecting me. Repeater tab was redirecting me to javascript:alert('xss');
- Now I was looking at why I am redirected to
javascript:alert('xss');? - I paste this string in the response & I got seven similar matches.
- Let me tell you what was in the response.
As said earlier, I was pen-testing one of our products. Specifically, I was testing file upload functionality. I uploaded the file which contains XSS payloads, but mistakenly I uploaded it with a .txt extension.
When I visited this file from the browser, it was downloaded directly as a .txt file because of the Content-Disposition Header in the response.
I got this at the first moment XSS was not possible here. But now I was looking for the redirection.
- So the response contained XSS payloads.
- I quickly changed all the similar matches in my XSS file from
javascript:alert('xss1');tojavascript:alert('xss7');respectively. To see actually which XSS payload was responsible for redirection. - I uploaded the updated XSS.txt file. Captured request while downloading this file sent it to the repeater tab hit send button and observed, now it redirected me to
javascript:alert('xss3');I got the real culprit. It was the <meta> tag that was redirecting me.
<META HTTP-EQUIV="refresh" CONTENT="0; url=javascript:alert('xss3');">
- Right away, I updated the XSS.txt file again & set the value of the URL attribute to https://google.com.
- You can read more about meta tags here.
- In short, redirection via meta tag is common only when Content-Type is text/html. In the repeater tab, it was redirecting irrespective of the content type. It doesn’t matter if it is image/png or text/plain.
- Now in the repeater tab, I got redirected to https://google.com
- But the question was why I was not getting redirected in the browser.
At first, I thought this might not be a security issue as I am only getting redirected in the repeater tab & exploitation of this issue might be impossible.
- After thinking a while, I got one more question! Was it the issue with Burp Suite?
- I quickly started my python HTTP server with the following command to confirm this.
python3 -m http.server 8081
- And in the browser, I opened the XSS.txt file by visiting http://127.0.0.1:8081/Downloads/XSS.txt
- I captured the request in the Burp, sent it to the repeater tab, hit the send button & got the HTTP 302.
As I understand it, this was a Burp Suite issue. However, what is the impact?
As I considered the impact, HTTP Referer header leakage immediately came to mind. Sometimes, the Referer header will contain a sensitive token or key.
Because of the high level of user interaction, I reported this issue to PortSwigger on HackerOne with a Low severity.
The report is Partially Published Click Here to see the report.
The POC
Take Away: Observation is the Key
Thanks for reading. 😊
