Hey, I am a security consultant and a penetration tester from Ukraine 🇺🇦. For the current moment I gather money and buy an ammunition and survival goods for my friends who are on the frontier. I want to stop the madness happened in Ukraine 🇺🇦
Pavel Shabarkin is security content
Announcement: The following blog post is dedicated to stop the madness happened in Ukraine 🇺🇦
XSS can be particularly devastating to Electron apps, and can result in RCE and phishing that might not be viable in a browser. Electron has features to mitigate these problems, so applications should turn them on.
Even XSS that would be low-impact in the browser can result in highly effective phishing if the application's URL allowlist is improperly designed. Attacks exploit the Electron model and the application-like presentation of Electron to gain the user's confidence.
It’s fairly common for modern platforms to provide native desktop applications using the Electron JS framework, in taking a look at these one common pattern that is visible is getting RCE within the actual Electron application by loading malicious content in the desktop’s window page. Electron has mechanisms in place that will severely limit the attack possibilities of an XSS, this is discussed in the next section. However, one there is another use of XSS specifically to set up a successful phishing campaigns and harvest user credentials without interfering with the legitimate workflow of application and relying on users trust of native applications.
Companies usually launch their applications on several platforms: web, mobile and desktop applications. All of them share the same API. For the example discussed through out this post lets assume the client-side of the application is based on the Angular framework. By default, Angular prevents many client-side attacks, it protects embedding of any malicious entities. Let's assume our theoretical app allows embedding custom scripts and HTML content from any valid source. This functionality exists to provide users with the ability to create custom functionality based on their web applications or to integrate with 3rd party applications to display dashboards and data. These dashboards can then be shared to other users of the same tenant. Given that this is custom code, its possible for a malicious user to create a 3rd party embedded dashboard that has a simple XSS. If properly integrated into the Electron app this XSS will have limited and low impact. Given that the content is on a separate domain and same-origin policy (SOP) will prevent any type of cross domain access preventing any interesting attacks. This also assumes that Electron controls are configured correctly and access is limited. But even if RCE is not possible we have other interesting attacks we can explore and chain with this XSS.
While this example will explore the XSS within a 3rd party dashboard context within Electron the same attacks will apply to XSS found in any other parts of the platform functionality.
At this point we need to check to ensure that we dont have the ability for native OS level RCE within the Electron app. Poor Electron configuration deployments can lead to real problems, like client-side RCE and should be a big focus of any Electron app security review.
Electron is based on Chromium, but it is not a browser! Certain principles and security mechanisms implemented by modern browsers are not in place. Electron as a platform wants to maintain a balance of developer usability and security.
The desktop application might have access to the user’s device through Node APIs. The following two configurations are responsible for providing mechanisms to prevent the application JavaScript from having direct access to the user’s device and system level commands.
nodeIntegration - is off by default