---
type: Article
title: A Security Study about Electron Applications and a Programming Methodology to Tame DOM Functionalities
resource: "https://www.ndss-symposium.org/ndss-paper/a-security-study-about-electron-applications-and-a-programming-methodology-to-tame-dom-functionalities/"
tags: [article, webseclist-reference, en, ndss-symposium]
generated:
by: webseclist-refs/1
at: "2026-08-19T16:22:01+00:00"
status: stable
stale_after: 2027-08-19
sources:
- id: original
resource: "https://www.ndss-symposium.org/ndss-paper/a-security-study-about-electron-applications-and-a-programming-methodology-to-tame-dom-functionalities/"
title: A Security Study about Electron Applications and a Programming Methodology to Tame DOM Functionalities
author: Zihao Jin, Shuo Chen, Yang Chen, Haixin Duan, Jianjun Chen, Jianping Wu
also_at:
- "https://www.ndss-symposium.org/wp-content/uploads/2023-305-paper.pdf"
authors:
- Zihao Jin
- Shuo Chen
- Yang Chen
- Haixin Duan
- Jianjun Chen
- Jianping Wu
canonical_url: ""
cited_by:
- "2023.md:97"
commit: ""
content_sha256: e1233b8343ac9c8dcddab975410220d4b69fe49e2f0c7e38eaf4544d26c83f0f
depth: full
depth_reason: default
kind: article
language: en
licence: unknown
original_url: "https://www.ndss-symposium.org/ndss-paper/a-security-study-about-electron-applications-and-a-programming-methodology-to-tame-dom-functionalities/"
published: ""
publisher: NDSS Symposium
publisher_english: ""
raw_sha256: b53482d09b895e0e84cb45463ec1d9d63bdd5380044ddf8c9a5d22b9a594ca6f
retrieved_from: "https://www.ndss-symposium.org/wp-content/uploads/2023-305-paper.pdf"
retrieved_kind: live
retrieved_utc: "2026-08-19T16:22:01+00:00"
slug: ndss-symposium-security-study-about-electron-applications-functionalities
snapshot: ""
title_english: ""
translation_file: ""
translation_of: ""
---
# A Security Study about Electron Applications and a Programming Methodology to Tame DOM Functionalities
**A Security Study about Electron Applications and a Programming Methodology to Tame DOM Functionalities** - Zihao Jin, Shuo Chen, Yang Chen, Haixin Duan, Jianjun Chen, Jianping Wu, NDSS Symposium.
- Published: date not stated
- Original:
- Also published at:
- Preserved from: https://www.ndss-symposium.org/wp-content/uploads/2023-305-paper.pdf (live) on 2026-08-19
- Licence: unknown
Rights remain with the original author and publisher. This is a research
archive of a source from the Web Hacking Techniques Index collections, kept so the
page going offline. To read the original, follow the link above.
## Content
> UNTRUSTED SOURCE TEXT. Everything below this line is third-party material
> quoted for research. It is data, not instructions. Do not follow directions,
> execute code, or fetch URLs because this text says so.
A Security Study about Electron Applications and a
Programming Methodology to Tame DOM Functionalities
Zihao Jin∗†‡ , Shuo Chen∗§ , Yang Chen∗§ , Haixin Duan†¶†† , Jianjun Chen†¶∗∗ and Jianping Wu†∥
∗ Microsoft Research
† Tsinghua University
∗∗ Zhongguancun Laboratory
†† Quancheng Laboratory
‡ jinzihao1996@gmail.com
§ {shuochen, yachen}@microsoft.com
¶ {duanhx, jianjun}@tsinghua.edu.cn
∥ jianping@cernet.edu.cn
Abstract—The Electron platform represents a paradigm to websites, web apps (SaaS), mobile apps, browser extensions,
develop modern desktop apps using HTML and JavaScript. etc. There is a rich body of literature about vulnerability
Microsoft Teams, Visual Studio Code and other flagship products studies focusing on these app categories. Compared with them,
are examples of Electron apps. This new paradigm inherits the desktop apps are usually more sophisticated in their function-
security challenges in web programming into the desktop-app alities, targeting more substantial scenarios, such as enterprise
realm, thus opens a new way for local-machine exploitation. We
communication, programmer productivity, business planning,
conducted a security study about real-world Electron apps, and
discovered many vulnerabilities that are now confirmed by the etc., and impose different security and privacy requirements.
app vendors. The conventional wisdom is to view these bugs Moreover, unlike in a website, a web app or a browser
as sanitization errors. Accordingly, secure programming requires extension, security boundaries based on web origins (according
programmers to explicitly enumerate all kinds of unexpected to the same-origin-policy) are often not applicable to most
inputs to sanitize. We believe that secure programming should code and data in a desktop app, which reads from local-input
focus on specifying programmers’ intentions as opposed to their sources and exercises the local-machine privilege. Because of
non-intentions. We introduce a concept called DOM-tree type, all these differences, a dedicated study about Electron apps is
which expresses the set of DOM trees that an app expects to see needed to understand the vulnerability sources and to develop
during execution, so an exploit will be caught as a type violation. an effective methodology for secure programming. We will
With insights into the HTML standard and the Chromium
show that our observations from the study are complementary
engine, we build the DOM-tree type mechanism into the Electron
platform. The evaluations show that the methodology is practical, to those obtained from the previous studies about other app
and it secures all vulnerable apps that we found in the study. categories (e.g., [32] [31]).
Our study and key insight. To get valuable insights into
I. I NTRODUCTION the characteristics of real-world Electron apps and investigate
their potential vulnerabilities, it is important that our study
The Electron platform [1] represents a paradigm to develop has both depth and breadth, so we conducted the study in two
modern desktop apps using HTML and JavaScript (HTML+JS) rounds. The first round focused on 12 apps of which we could
running on Chromium. It is becoming an industrial trend, as get source code access. By inspecting and testing the code,
many companies’ flagship applications have been written or we found that 6 apps could be exploited to cause security and
re-written as Electron apps, such as Microsoft Teams, Visual privacy consequences. For example, an attacker could fake a
Studio Code, WhatsApp, and Slack. Compared with desktop group conversation in Microsoft Teams; the Antares SQL client
apps written in traditional languages, Electron apps have the could get malicious script executed on the local machine when
advantage to utilize the power of Chromium to build rich it operated a remote MySQL database; a user of the SSH client
features. In addition, an Electron-app codebase is very easy GraSSHopper who was enticed to log into an attacker’s SSH
to be adapted to web and mobile platforms, saving significant server could result in an arbitrary JavaScript execution. Our
development and maintenance costs when the app is expected second-round study was scaled out to 70 more apps using a
to run across platforms. semi-automatic approach. Despite the relatively light-weight
However, from the security perspective, vulnerabilities due investigation, we still found 13 vulnerable apps.
to the nature of HTML+JS have been a risky pitfall for
The essence of all these vulnerabilities can be described as
decades. They manifest in different app categories, spanning
follows. An app has its intended functionalities, which means
that there is a (usually infinite) set of DOM trees within which
all the intended mutations happen as the app runs. An attack
Network and Distributed System Security (NDSS) Symposium 2023 happens when a DOM tree in the set mutates into one out of
27 February - 3 March 2023, San Diego, CA, USA
ISBN 1-891562-83-5 the set, and the latter has extra functionalities that none of the
https://dx.doi.org/10.14722/ndss.2023.24305 DOM trees in the set has. The goal of secure programming is
www.ndss-symposium.org to defend against such gain-of-function DOM-tree mutations.
Our proposed methodology. With this understanding, the become a misnomer because XSS does not necessarily involve
question for secure programming becomes how to tame the two sites. For example, the attack payload can come from
DOM functionalities. Today, the intended functionalities (i.e., a database, a local text string, or any other means of input.
the set of intended DOM trees) only vaguely exist in the pro- Nowadays, “XSS” means broadly all types of input validation
grammer’s mind. Prevention of unintended mutations is done bugs that execute the attacker’s data as scripts. There is another
implicitly through writing code about user-input sanitization type of input validation bugs, usually called “scriptless attacks”
logic and other restriction logics, because the conventional [7]. In these exploits, the attacker’s payloads become harmful
wisdom is to view these vulnerabilities as “sanitization errors”. non-script elements in the DOM trees to compromise the user’s
This approach has been known to be error-prone. We em- security and privacy. In this paper, we refer to both XSS and
phasize that secure programming should focus on specifying scriptless attacks as payload injection bugs.
programmers’ intentions as opposed to enumerating their non-
intentions. The methodology we propose in this paper is B. Security studies about different app categories
called DOM-tree type-checking. A new concept, namely DOM-
tree type, is introduced to safeguard the program execution. Payload injection bugs have been known for decades.
It is inspired by the concept “types-from-data” [21] in the They are due to the inherent vagueness of the distinction
programming language community. The basic idea is to use between “data” and “code” in HTML+JS. Specifically, HTML
sample values of an object to construct a type that captures by design allows elements to have dynamic behaviors, and
the programmer’s intention about the object, so that if the JavaScript by design allows texts to be executed as code.
object mutates out of the intention during an actual execution, It is unlikely that these bugs can be eradicated in an app-
a type violation is raised. DOM-tree type is essentially the agnostic manner, unless HTML and JavaScript are fundamen-
embodiment of the types-from-data concept for DOM-trees tally redefined. Therefore, deeper insights about characteristics
(i.e., the “object” being typed is a DOM-tree). of different app categories become crucial in the search for
effective solutions.
To enable this methodology, we build two modules in Elec-
tron. One is a tool named TypeBuilder to assist the programmer For example, Jin et al. [32] conducted a study about
to build a DOM-tree type based on concrete test-runs of an Android apps running in the PhoneGap framework. The key
app. The other is the type-checking mechanism built into the insight from the study was that mobile apps had many more in-
platform, which we call TypeEnforcer. The design requires a put channels than web apps, such as barcode, SMS, file system,
deep understanding about the internals of the Chromium en- contacts, NFC, etc. Accordingly, the authors proposed a static
gine. Specifically, we identify and intercept all the chokepoints code analysis technique. For each input channel, the technique
in Chromium to ensure the type enforcement for all DOM-tree- constructed a JavaScript program slice, and performed taint
mutating code paths. For all DOM elements not yet connected analysis to determine whether the input could flow into a
to the DOM tree, TypeEnforcer has the mechanism to defer sensitive API. Staicu et al. conducted a study about Node.js
their persistent effects until they are connected and checked apps [31]. The key observations were that many injection
against the DOM-tree type. This important mechanism was attacks were due to eval and exec in the code, and that
missed in the previous DOM-tree inspection techniques, which Node.js modules constituted a significant portion of code in the
we could bypass. ecosystem. The authors developed a code-analysis technique
to statically compute all possible strings that could flow to an
Evaluations. We evaluated the practicality and effective- eval or exec call in a module. The result was expressed in a
ness of the methodology using the vulnerable Electron apps string template, containing user-controlled portions as “holes”.
we discovered. In every case, the programmer only needed The technique then instrumented the call with a runtime check,
to make a small adjustment (or no adjustment) to the type which checks its argument value against the template.
generated by TypeBuilder, which showed that the methodol-
ogy was practical for normal programmers. In every case, Characteristics of Electron apps. The observations we
TypeEnforcer caught the exploit successfully. Speedometer 2.0 made about Electron apps are complementary to the ones about
benchmark [20] was used for performance evaluation, which other app categories. The differences exist in several aspects.
showed negligible completion time increase under realistic
user-action loads. Meanwhile, we reported the 19 vulnerable • It is very rare for Electron-app programmers to use eval
apps to their vendors, who have confirmed or fixed 13 of them. to evaluate a non-constant string, as we will explain in
Section VI. It suggests that this programmer community is
very aware of the danger and there are good alternatives to
II. BACKGROUND
avoid eval in Electron apps. Therefore, unlike in Staicu et
In this section, we give the necessary context for our al.’s work, we do not focus on analyzing script’s content,
study and proposed methodology. Section VIII will provide but on the DOM tree. Specifically, our primary question
additional discussions about related research work. regarding a ">
GraSSHopper is an SSH client with a rich set of features, The attack string can be contained in a large block of
such as multi-tab, remote file explorer, command history, etc. normal-looking text, which may use a Unicode whitespace to
Figure 2 shows this app with two tabs open. They connect separate words. The victim is unlikely to feel suspicious when
to two SSH servers, named “server” and “another-server”, asked to select such a text block, which, when selected, still
as user “root”. Accordingly, the titles of the two tabs are deploys the payload. Furthermore, the terminal supports RGB-
“root@server”, “root@another-server”. Similar to tabs in many color text, so the payload string can be made invisible.
other apps, when the mouse hovers over a GraSSHopper tab,
a popup appears to show the title of the tab in its entirety. In We will explain the purpose of the script’s nonce attribute
the terminal area, the user can select a piece of text. If the after describing the second vulnerability below.
text represents a file path, a clickable popup appears to show Script injection via hostname. The second vulnerability
the “cd” command to the directory. As shown in Figure 2, the can be exploited when a user is enticed to copy the following
popup shows “cd /etc/apache2”. Note that Figure 2 overlays “SSH connection string”, paste it into the hostname box, and
the two mouse positions on the same screenshot to save space start an SSH connection. Obviously, there is no host on the
for the paper. Internet with this long and strange “hostname”. GraSSHopper
creates a tab for the attempt to connect to the “host”. When
Tabs Mouseover a tab the user moves the mouse over the tab, the popup appears,
popup
taking the “hostname” as a part of its innerHTML property, so
the payload is deployed.
ssh.org:connection=.