Page MenuHomePhabricator

Trivial Quarry XSS: Tabular data CSV / TSV are not escaped and sent as text/html
Closed, ResolvedPublic

Description

https://quarry.wmflabs.org/run/424170/output/0/tsv

The link renders fine.

$ curl -s -I https://quarry.wmflabs.org/run/424170/output/0/tsv | grep Content-Type
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff

You only need an account to do

SELECT "<script>alert(1)</script>";

And you get an HTML page with the payload.

Suggest changing the MIME type.

Event Timeline

sbassett triaged this task as High priority.Jan 9 2020, 9:04 PM
sbassett moved this task from Backlog / Other to Other WMF team on the acl*security board.
sbassett moved this task from Incoming to Watching on the Security-Team board.

The following patch should fix this issue:

The following patch should fix this issue:

Thanks for the patch.
Line 27: I don't see why using str.join() with only to items in the list, so I purpose content_type = mime_type + '; charset=utf-8'.
Otherwise +1

Line 27: I don't see why using str.join() with only to items in the list, so I purpose content_type = mime_type + '; charset=utf-8'.
Otherwise +1

For two strs (which will probably always be the case here) I agree that the + operator is fine. I'm just in the habit of always using str.join(). Second revision of the patch using the + operator here:

Applied. https://quarry.wmflabs.org/run/424170/output/0/tsv https://quarry.wmflabs.org/run/424170/output/0/csv LGTM.

Shall we make the ticket public and put the patch on gerrit?

Those URLs are now forcing downloads for me in Chrome and Firefox so that looks good. We can definitely push the patch through gerrit and backport it to master now. For wmflabs applications like this, I think the Security-Team would leave it to the maintainers if they'd wish to request a CVE for this vulnerability.

sbassett lowered the priority of this task from High to Medium.Jan 14 2020, 3:32 PM
sbassett removed a project: Patch-For-Review.
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".

Change 564707 had a related patch set uploaded (by SBassett; owner: SBassett):
[analytics/quarry/web@master] SECURITY: Update mime and content types downloads

https://gerrit.wikimedia.org/r/564707

Change 564707 merged by jenkins-bot:
[analytics/quarry/web@master] SECURITY: Update mime and content types downloads

https://gerrit.wikimedia.org/r/564707

sbassett claimed this task.
sbassett removed a project: Patch-For-Review.
sbassett added a project: Vuln-XSS.

@sbassett Thanks ;) I'm wondering, since I've never requested CVEs before, what is the standard practice of when to request CVEs and when not to?

@zhuyifei1999 - As a security-minded person, I tend to recommend requesting CVEs for pretty much all vulnerabilities, especially for FLOSS code. I'm not sure if Mitre would ever reject a request by deeming the application not noteworthy enough or something like that - I'm guessing Quarry probably isn't run outside of wmflabs? Regardless, the form should only take a few minutes to fill out, so if you have the cycles, I'd recommend doing that. And if a CVE ID is issued, we can update this tasks's title to include it.

I'm guessing Quarry probably isn't run outside of wmflabs?

I'm pretty sure that's the case. Never seen or heard (even the intention of creating) another Quarry install outside of https://quarry.wmflabs.org/ and some test installs (in vagrant and in wmflabs).

I don't think too that it's used by someone else, and code was not designated to such usage. Thus I don't think that there is a need to request cve.