cc:ing Mike since he runs sumo.
Assignee: nobody → mcooper
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: sec-high, wsec-xss
PR: https://github.com/mozilla/kitsune/pull/2723 Deployed to prod.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Glad to see it's fixed, great work all involved! Was this worthy of credit and/or bug bounty?
Please email firstname.lastname@example.org if you would like this bug to be considered for a Bounty. More info at: https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/#what-next
Mike: this bug and the dupe both manually entered the payload into the search field, which SUMO magically whisks off and process. As an attack this is less interesting than a search that can be forced on a victim through a GET, like https://support.mozilla.org/en-US/search?q=blahblah&w=3&qs=plugin The page I get from that is slightly different, but would that have also been susceptible to this attack?
Daniel: the search that can be accessed directly from the url like that is different, and wasn't vulnerable to this XSS. Specifically, the problem was in Nunjucks templates used on the client side that lacked proper escaping. On the other hand, the /en-US/search?q=... page is rendered server side with a different set of templates rendered with Jinja2.
This issue is a self-XSS then and is not eligible for the bounty because other users are not vulnerable.
Flags: sec-bounty? → sec-bounty-
These bugs are all resolved, so I'm removing the security flag from them.
You need to log in before you can comment on or make changes to this bug.