Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XSS in Blazegraph workbench #144

Open
lucaswerkmeister opened this issue Jul 16, 2019 · 0 comments · May be fixed by #145
Open

XSS in Blazegraph workbench #144

lucaswerkmeister opened this issue Jul 16, 2019 · 0 comments · May be fixed by #145

Comments

@lucaswerkmeister
Copy link

lucaswerkmeister commented Jul 16, 2019

TL;DR: apply #145

The Blazegraph workbench, the default web UI of Blazegraph, doesn’t HTML-escape results. If you run a query like

SELECT("<script>alert('😱')</script>"AS?x){}

then the embedded JavaScript will run:

oh_noes

This means that an attacker who can to some extent control the content of a Blazegraph database (for example, by editing some upstream data storage that Blazegraph is automatically synchronized with) may be able to gain full control over an administrator’s workbench if they can guess what queries the administrator is likely to run, or manipulate the administrator into running a certain query that will display the attacker’s malicious result.

For example, the attacker could set the label of a Wikidata item to something like <script>fetch('/bigdata/namespace/wdq', { method: 'DELETE' })</script>, then complain about a supposed data corruption issue on this item and hope the administrator will run some query like DESCRIBE wd:[item ID] in the workbench, bypassing whatever proxy usually protects Blazegraph against such requests.

I reported this issue via email in accordance with the security policy months ago, but did not receive any response (as detailed in BLZG-9163). To give other Blazegraph users a chance of protecting themselves against the issue, I am now reporting it publicly, along with the fix we implemented for it at Wikimedia, which may be found in #145.

lucaswerkmeister pushed a commit to lucaswerkmeister/database that referenced this issue Jul 16, 2019
@lucaswerkmeister lucaswerkmeister linked a pull request Jul 16, 2019 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants
@lucaswerkmeister and others