Electron and XSS: How Small Bugs Escalate to Big Problems

Eric Damtoft
Jan 25, 2019 · 4 min read
Image for post
Image for post
Photo by Markus Spiske on Unsplash

Earlier this month, a colleague noticed some formatting issues going on in Azure Data Studio (formerly SQL Operations Studio). For background, Azure Data Studio is basically SQL Server Management Studio’s little sibling that’s meant to be a cross-platform application for running SQL queries and performing basic management tasks. It’s built with Electron and based on the same guts as the popular Visual Studio Code editor.

Normally, a formatting bug in a desktop app isn’t something to bat an eye over, but what was happening was that HTML in the database was somehow leaking outside of what should have been a text field and being rendered onto the page as formatted HTML.

Image for post
Image for post
HTML should be in its column as text, but ended up actually getting rendered to the page

Since an Electron app like Azure Data Studio is basically a web browser masquerading as a desktop app, this quickly raised concern about Cross Site Scripting (XSS). XSS happens when you can inject arbitrary HTML or JavaScript onto a page, either from server-generated content or from setting a raw string as innerHTML without proper escaping. Injected JavaScript on a login page or checkout page can easily steal sensitive information or take over an account. In general, although this can compromise a site, it will not by itself compromise the computer viewing the page or the server displaying it.

A quick inspection with the built-in chrome developer tools quickly revealed that the HTML was ending up on the page by having the raw value of a column set to the title attribute of an element in the data table. XSS can happen when an unescaped value is written as raw HTML like in the example below:

element.innerHTML = `<span title="${value}">...</span>`;

By setting the value to "><h1>Hello World</h1><span title=" , this would cause the HTML output to the page to look like this:

<span title=""><h1>Hello World</h1><span title="">...</span>

With HTML on the page, a few well known hacks allowed us execute whatever JavaScript we wanted. This meant that an attacker could insert a crafted value into the database that would execute as soon as a developer or database admin viewed the value in Azure Data Studio. After some quick testing, we had a 1-liner keystroke logger that would log all keystrokes to the console, including password entry in the SQL connection tab. The logger would persist as long as the app was open after the user viewed the dangerous content.

This seemed concerning enough that we gave a heads up to the Microsoft Security Response Center. Around the same time, a github issue about the formatting issues was also created and Microsoft employees noted the potential for XSS.

However, this raised the question of how much damage you could do with an XSS bug in an Electron app like Azure Data Studio or Visual Studio Code. I had never done more than spin up a quick test project with Electron, so after some digging, I learned that you could set an Electron window to run as an isolated browser window or with tight integration with the node.js back-end. Tight integration with node is convenient but it also means that any XSS bug can escalate into a code execution bug. As it turns out, this tight integration is used in Azure Data Studio.

Image for post
Image for post
With node integration, what started out as an HTML formatting bug turned into shell access.

By executing JavaScript which called into Electron’s node.js API, we were able to gain shell access. In the above example, we exploited this to open the windows calculator app to demonstrate.

The bug was reported quickly by multiple parties and addressed by the Azure Data Studio team within days which speaks to their responsiveness. It was already fixed by the time our report made its way through the Microsoft Security Response Center. The patch is included in version 1.3.9 and is available now.

That being said, this leaves broader questions open about the risks of script injection in Electron-based apps. XSS is listed on the OWASP top 10 list of web application vulnerabilities, but is often overlooked as less impactful than other vulnerabilities because scripts are still sandboxed in the browser. By using web technologies, Electron promises cross-platform compatibility and quick software development cycles for desktop, but as a trade-off, a single missed call to escape or sanitize HTML can quickly escalate to a much more serious threat.

Thanks to sohjsolwin

Eric Damtoft

Written by

Software Architect at DealerOn

DealerOn Dev

Syndicated from https://dev.to/dealeron | On the DealerOn Dev Team, we strive to be the industry leader in code quality, innovation, and culture. The author’s views expressed in this publication are endorsed by DealerOn. The author’s views elsewhere may not be.

Eric Damtoft

Written by

Software Architect at DealerOn

DealerOn Dev

Syndicated from https://dev.to/dealeron | On the DealerOn Dev Team, we strive to be the industry leader in code quality, innovation, and culture. The author’s views expressed in this publication are endorsed by DealerOn. The author’s views elsewhere may not be.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store