On 9 February 2016 I was reading an excellent post by Ashar Javed on a persistent XSS in Mozilla Add-ons.
Reference: https://respectxss.blogspot.de/2016/01/persistent-xss-in-mozilla-add-ons-site.html
Inspired by this idea, I decided to challenge myself with the same target: addons.mozilla.org, but this time focusing specifically on its mobile interface. I chose the mobile version because these pages frequently receive less attention and care when it comes to implementing robust security measures and protections.
My mobile user-agent of choice:Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Scoping the Attack Surface
I quickly narrowed my focus to the review section of each add-on, e.g.: https://addons.mozilla.org/en-US/AddonName/addon/addonNames/reviews/
If you’re logged in, you can submit a star rating and a comment.
The Payload (& 2-Minute Win)
I picked a random add-on, gave it star and submitted this “review”: <img src=x onerror=alert(document.domain)>
the alert popped immediately when I revisited the page. A classic stored XSS in under two minutes.
Thinking Bigger: CSRF via XSS
A stored XSS on a review page is already bad, but I realised it also let me bypass CSRF protection elsewhere on the same site:
- Fetch the target form via
XMLHttpRequest. - Parse out the fresh CSRF token.
- Re-submit the form with malicious data, token included.
Handy references I leaned on:
- MDN
XMLHttpRequestdocs - Riley Kidd’s write-up on XSS-enabled CSRF https://rileykidd.com/2013/09/09/using-xss-to-csrf/
Disclosure & Response
I reported the bug to Mozilla via Bugzilla.
To their credit:
- Issue confirmed: ~12 hours after report
- Fix deployed: ~48 hours later
Bounty
A few days later I received my very first Mozilla bounty.
Lessons Learned
- Mobile views aren’t second-class targets—they can be a gold mine.
- Even simple payloads work when input isn’t sanitised.