This is the continuation of my first write of Stored XSS Via Alternate Text At Zendesk Support.
So let's get back to business..As i was investing the XSS issue on the platform i noticed that the XSS Popup was triggered TWO times on the homepage. So i searched for the endpoint where the XSS payload got executed.
But no luck, So i removed my payload from the first vulnerable endpoint that is the Alternate Url Text and checked the homepage. To my suprise the XSS pop triggered as usual but this time it pop’d up only ONCE.
So i look up the macro if i had entered the payload anywhere else and of course i had entered a payload on the macro description field. So i found an another vulnerable endpoint. Time for POC.
For POC purposes i created a fresh macro and entered the payload on the macro description field and click on save…A Web Application Firewall(WAF) came smiling upon me Saying “YOU HAVE BEEN BLOCKED”.
WAF BYPASS TIME!!!!!!!!!!!!!!!
After learning about the working of the WAF i found out a “Not so Complicated” Method to bypass It.
Don't Enter the payload in beginning itself while creating the macro. Instead while creating the macro just enter random things in the description and after creating the macro edit the description and enter the payload.
Shorter version : WAF only scans the content that is entered the first time and does not care what you enter afterwards.
After this BYE BYE WAF. The payload got saved successfully and also got triggered on the homepage.
Report Timeline :
- Aug 10th- Report Submitted
- Aug 11th- Closed as duplicate of my first report
- Aug 17th- Report reopened after providing info that the two xss issues are different
- Aug 23rd- Bounty Time $$$
- Aug 26th- Resolved and Got listed on their HOF
Few Things to Say..
- Check the number of XSS triggers ( Number of XSS triggers = Number of Vulnerable endpoints)
- Try to Bypass the WAF by not only changing the payload.
3. The payload that i used is <img src=x onerror=alert(document.cookie)>
MAY THE BUGS BE WITH YOU,