See discussions, stats, and author profiles for this publication at: [Link]

net/publication/380709647

(In)Security of File Uploads in [Link]

Conference Paper · May 2024

DOI: 10.1145/3589334.3645342

CITATIONS READS
4 473

6 authors, including:

Harun Oz Abbas Acar

Meta Florida International University
11 PUBLICATIONS 343 CITATIONS 47 PUBLICATIONS 2,616 CITATIONS

SEE PROFILE SEE PROFILE

Ahmet Arış Güliz Seray Tuncay

Florida International University University of Illinois Urbana-Champaign
42 PUBLICATIONS 1,397 CITATIONS 21 PUBLICATIONS 331 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Harun Oz on 19 May 2024.

The user has requested enhancement of the downloaded file.

 (In)Security of File Uploads in [Link]
Harun Oz Abbas Acar Ahmet Aris
Florida International University Florida International University Florida International University
Miami, Florida, USA Miami, Florida, USA Miami, Florida, USA
hoz001@[Link] aacar001@[Link] aaris@[Link]

Güliz Seray Tuncay Amin Kharraz Selcuk Uluagac

Google Florida International University Florida International University
Mountain View, California, USA Miami, Florida, USA Miami, Florida, USA
gulizseray@[Link] ak@cs.@[Link] suluagac@[Link]

ABSTRACT 1 INTRODUCTION
File upload is a critical feature incorporated by a myriad of web File upload is a critical feature incorporated by a myriad of web
applications to enable users to share and manage their files conve- applications to share and manage their files conveniently. It has
niently. It has been used in many useful services such as file-sharing been used in many useful services such as file-sharing and social
and social media. While file upload is an essential component of media. While file upload is an essential part of web applications, it
web applications, the lack of rigorous checks on the file name, type, also extends the attack surface in these applications by creating an
and content of the uploaded files can result in security issues, often opportunity for adversaries to upload malicious payloads to web
referred to as Unrestricted File Upload (UFU). In this study, we ana- applications. In particular, the lack of rigorous checks on the file
lyze the (in)security of popular file upload libraries and real-world name, type, and content of the uploaded files can result in security
applications in the [Link] ecosystem. To automate our analysis, we issues, often referred to as the Unrestricted File Upload (UFU). A
propose NodeSec– a tool designed to analyze file upload insecuri- successfully uploaded malicious payload can cause potential code
ties in [Link] applications and libraries. NodeSec generates unique execution on both the client side and the server side of the web
payloads and thoroughly evaluates the application’s file upload se- application.
curity against 13 distinct UFU-type attacks. Utilizing NodeSec, we The popularity of [Link] has grown significantly over the years
analyze the most popular file upload libraries and real-world ap- with over one billion downloads 1 . It is especially preferred by
plications in the [Link] ecosystem. Our results reveal that some major companies to develop scalable high-traffic web applications.
real-world web applications are vulnerable to UFU attacks and dis- [Link] developers frequently depend on third-party libraries to
close serious security bugs in file upload libraries. As of this writing, important features such as file upload, authentication, and logging
we received 19 CVEs and two US-CERT cases for the security is- that require security attention. Given the sheer number of existing
sues that we reported. Our findings provide strong evidence that security issues and implementation mistakes discovered in the third-
the dynamic features of [Link] applications introduce security party libraries [1, 4, 15, 28, 36], we argue that there is a dire need
shortcomings and that web developers should be cautious when to further investigate the security of the file upload libraries in
implementing file upload features in their applications. [Link].
While previous works proposed tools for identifying UFU vul-
CCS CONCEPTS nerabilities in other ecosystems [7, 8, 10], there is a dire need for
• Security and privacy → Web application security. a tool that is tailored for testing [Link] applications. As existing
tools face challenges when applied to [Link] applications due to
their unique features such as syntax, file handling, and distinct exe-
KEYWORDS
cution environments. Consequently, adapting these existing tools
Web Application Security, [Link], Unrestricted File Upload to test [Link] applications requires significant domain expertise
ACM Reference Format: and in-depth knowledge of the existing tools’ source code. More-
Harun Oz, Abbas Acar, Ahmet Aris, Güliz Seray Tuncay, Amin Kharraz, over, the techniques employed by other tools primarily focus on
and Selcuk Uluagac. 2024. (In)Security of File Uploads in [Link]. In Pro- identifying the incompleteness of the file upload checks in web
ceedings of the ACM Web Conference 2024 (WWW ’24), May 13–17, 2024, applications rather than examining potential implementation mis-
Singapore, Singapore. ACM, New York, NY, USA, 12 pages. [Link] takes in security-related functions. Considering almost 93.2% of the
10.1145/3589334.3645342 code in [Link] applications comes from third-party libraries [9],
a tool tailored for [Link] applications must also be capable of
Permission to make digital or hard copies of part or all of this work for personal or detecting implementation issues in the file upload libraries.
classroom use is granted without fee provided that copies are not made or distributed Motivated by the urgent need, in this work, we propose NodeSec to
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for third-party components of this work must be honored. analyze [Link] applications and file upload libraries against UFU
For all other uses, contact the owner/author(s). attacks. Our tool includes 13 distinct UFU-type attacks, derived
WWW ’24, May 13–17, 2024, Singapore, Singapore from a thorough review of previously published UFU-related CVEs,
© 2024 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-0171-9/24/05.
[Link] 1 [Link]

1573
WWW ’24, May 13–17, 2024, Singapore, Singapore Harun Oz et al.

OWASP resources, and GitHub issues. Furthermore, we conducted Responsible Disclosure. We responsibly reported the security
an exhaustive literature review by examining UFU vulnerabilities issues we found in all of the server-side file upload libraries and
across various ecosystems and adapted these attacks to the [Link] real-world web applications, resulting in 19 CVEs at the time of this
environment, if applicable. Finally, we examined common security writing. We also notified the US-CERT about the issues and they
mistakes made by developers and previous bugs to identify possible acknowledged our findings. We detail our vulnerability disclosure
implementation errors specific to [Link] developers. process in Section 9 in the Appendix.
Based on our investigation, we identified three generic objec-
tives that a secure file upload implementation must meet to prevent 2 UNRESTRICTED FILE UPLOAD
UFU attacks. We leverage NodeSec to analyze the six most popular In this section, we discuss the general file upload process and unre-
server-side file upload libraries. Our findings revealed that none of stricted file upload in [Link] applications.
these libraries fulfilled all three objectives, as they contained imple-
mentation mistakes in their validation functions and lacked critical
2.1 File Upload in [Link]
security measures, potentially exposing them to attack vectors that
allow the uploading of malicious payloads that would affect millions A typical scenario of the file upload process with HTTP(S) protocol
of live web applications using these libraries to implement their is shown in Figure 1. First, the user picks a file and initiates the
file upload feature. Moreover, we examined 11 popular real-world upload process to a web application. Following that, the user’s client
web applications written in [Link] using NodeSec. Our analysis machine sends an HTTP(S) request that contains a multipart/form-
revealed that these applications are not resilient against UFU due data form of the uploaded file to the web application server. As
to several reasons: 1) they overrely on file upload libraries for se- shown in Figure 1, the web application can perform various checks
curity 2) they make errors when configuring security options in to validate the uploaded file both on the client and the server. For
the libraries, and 3) they fail to address all edge cases in their cus- instance, it can validate the file type by checking its MIME (i.e.,
tom implementation. Our analysis also revealed that some of these Content) type on the server side. If the file type is not valid or
real-world web applications use additional packages or custom is undesired, the web application may reject the uploaded file to
implementations to prevent UFU attacks. Moreover, our findings prevent any unintended file on the web application server.
demonstrate that web application developers should not blindly File Upload Library Usage in [Link] Applications. Third-
trust a file upload library despite its popularity in the ecosystem party libraries have become an integral component of the [Link]
and instead should implement their own metadata and content ecosystem. In a typical [Link] application, over 90% of the code
checks or use additional packages that implement these security originates from third-party libraries [9]. To properly handle the
checks for uploaded files. file upload process, [Link] developers often utilize server-side file
Contributions. Our contributions are as follows: upload libraries available in the Node Package Manager (npm). For
example, the file upload library formidable is downloaded over
• Comprehensive Analysis of UFU in [Link]: For the
8.6 million times weekly and it is used by 1.5 million open-source
first time in the literature, we investigate the security pos-
applications. These libraries serve as middleware for [Link] web
ture of the [Link] file upload ecosystem. We outline three
applications, providing file upload capabilities and implementing
objectives for securely handling the file upload process in
the necessary security checks and validations to prevent any attacks
[Link] applications and present prevention methods and
that could be exploited via uploading a file.
mechanisms, that can be used by web application developers
While using third-party libraries is convenient for developers to
to prevent file upload attacks and satisfy objectives.
develop [Link] applications, it comes with security risks [5, 36].
• [Link] UFU Analysis Tool: We implement and open
Recent incidents [19] and studies have shown that developers tend
source 2 NodeSec– a tool designed to analyze file upload
to assume that popular third-party libraries are safe to use, which
insecurities in [Link] applications and file upload libraries.
can result in the introduction of vulnerabilities into applications.
This tool will serve as a valuable resource for the community
When a vulnerability exists in a middleware or library or it is inse-
to test their web applications and libraries against file upload
cure, it can transmit to a web application and potentially impact a
insecurities before deployment.
vast number of Internet users. Conversely, If the library (i.e., mid-
• Evaluation of Web Applications & Libraries: Utilizing
dleware) handled the security checks, the web application would
NodeSec, we investigate the security of the [Link] file up-
be automatically secured, in contrast to the situation where the
load ecosystem. Our analysis discloses that some real-world
checks were not done by the library. Furthermore, addressing vul-
web applications are insecure against our attacks and we
nerabilities in third-party packages can be time-consuming, and
disclose serious security bugs in the popular file upload li-
developers may not prioritize fixes [36]. Consequently, this practice
braries. As of this writing, we received 19 CVEs and two
poses a significant security threat to the entire web ecosystem.
US-CERT cases for the security issues that we reported.
• Root Causes & Recommendations: Based on our knowl-
edge gained from these experiments and experience from
2.2 Unrestricted File Upload in [Link]
responsibly disclosing these security issues to developers Unrestricted File Upload is a type of security weakness that enables
we enumerate root causes leading to the insecurity of the an attacker to upload malicious files to a web application server.
[Link] file upload ecosystem and our recommendations. Even if the target server does not immediately execute the uploaded
file, the web application can still be considered vulnerable or inse-
2 [Link] cure with respect to UFU. This is because the presence of malicious

1574
(In)Security of File Uploads in [Link] WWW ’24, May 13–17, 2024, Singapore, Singapore

1 const checkFileIsValid = (fileData, types, extensions)=>{

2 const type = [Link];
3 if ([Link](type) && [Link](
[Link])) {
Uploads the file HTTP(s) POST
User
via user interface
Client-side
Multipart/form-data 4 return true; }
File Upload Library/Middleware
5 return false; };

Content Filtering,
Listing 1: A sample code snippet from the GhostCMS
Sanitize, Validate implementing content-filtering checks that can lead to UFU
vulnerabilities.
Figure 1: A typical scenario of file upload procedure in web
applications.

3.1 Attack Identification

Our research includes the following objectives: 1) identifying tech-
niques that adversaries can employ to exploit UFU 2) investigating
files in the web application server poses a natural security risk as the common mistakes made by developers on file upload libraries 3)
malicious content in the file can later be executed in various ways, evaluating the effectiveness of [Link] libraries in preventing UFU
such as exploiting other vulnerabilities in the third-party packages, vulnerabilities. We initiated our analysis by exploring the CVEs
direct object references, or even tricking users/admins into execut- related to UFU. To achieve this, we developed a Python script that
ing it. Once the file is executed, depending on the content of the utilizes the NIST National Vulnerability Database (NVD) API, al-
file, this vulnerability can lead to server-side attacks such as RCE lowing us to extract all the CVEs from the NVD dataset. Utilizing
or client-side attacks such as XSS [22]. this script, we retrieved all CVEs ranging from the year 2002 to
Listing 1 shows a code snippet from the GhostCMS [Link] appli- February 2023. This provided us with a comprehensive dataset that
cation that implements security checks for uploaded files through includes over two decades of vulnerability data, consisting of a
the checkFileIsValid function. Line 3 checks if the file’s MIME total of 221,549 CVEs. Given the scope of this work, we checked the
type and extension are included in the provided arrays. However, descriptions and Common Weakness Enumeration (CWE) codes
relying solely on MIME type and file extension for validation in- of the CVEs. In particular, we checked for terms such as ’file up-
troduces security risks, as both can be easily bypassed by an at- load’, ’unrestricted upload’, ’arbitrary file upload’, and also the
tacker [12]. Consequently, the web application remains susceptible CWE-434 ’Unrestricted Upload of Files with Dangerous Types’. Our
to file upload vulnerabilities, potentially leading to arbitrary code final dataset includes 1846 CVEs that are all related to the UFU
execution on either the client or server side. For example, an at- vulnerabilities. We also checked for any false positives or dupli-
tacker could upload a malicious client-side script (e.g., HTML) that cates and removed them from the dataset. To make our dataset
executes in the victim’s browser context when the file’s URL is more comprehensive to identify our attacks we analyzed OWASP,
accessed. The primary goal of the attacker is to exploit the UFU sources and GitHub issues of the file upload libraries to investi-
security weaknesses within the target [Link] application to exe- gate recent techniques employed by adversaries to exploit UFU
cute malicious code on the client-side or server-side that can lead in [Link] applications. Furthermore, we examined the common
to various types of attacks. security mistakes made by the developers [34] and previous GitHub
The consequences of UFU attacks may differ depending on the issues of libraries to identify implementation errors. Lastly, we con-
specific features and functionalities of the programming language ducted an exhaustive literature review on prior research examining
of the server. For instance, languages like PHP can directly execute UFU vulnerabilities across various ecosystems [7, 8, 10], adapting
code embedded in uploaded files if they are placed in an executable these attacks to the [Link] environment, if applicable. From our
path and have the executable file extension (e.g., .php) [11]. In con- analysis, we selected 13 different attacks, grouped into three cate-
trast, as [Link] applications do not directly map URLs to file paths gories: (1) File Name-based Attacks (File Extension Injection, Null
by default, it does not automatically execute code from uploaded Byte Injection, Script-Named File Name, Path Traversal, Overwrite),
files in response to HTTP requests [13]. Although this reduces the (2) File Type-based Attacks (Spoofing-based, Polyglot File Attacks,
likelihood of direct arbitrary code execution on the server, it does Executable File Attack), and (3) File Content-based Attacks (PDF
not completely eliminate the possibility of UFU vulnerabilities, as File Attacks, SVG Upload Attack).
the presence of a malicious file in the web application server in-
troduces an inherent security weakness to the web application. As 3.2 Attack Descriptions
evading security checks in a web application to upload a malicious
In this section, we provide detailed descriptions of the attacks and
payload is itself unintended and exposes the application’s insecurity
their respective categories considered in this work. We elaborate
and attackers can still exploit UFU vulnerabilities in various ways
on the impact of each attack, discuss its possible consequences, and
as explained in Section 11 in Appendix.
explain their differences.
File Name-based Attacks In this attack category, an adversary
3 METHODOLOGY modifies the file name to alter the intended logic of the web applica-
In this section, we outline our methodology for analyzing UFU on tion or injects malicious characters into the file name to abuse the
file upload libraries and [Link] applications. file upload inputs of the web application. The malicious characters

1575
WWW ’24, May 13–17, 2024, Singapore, Singapore Harun Oz et al.

can be in the form of multiple file extensions, without file exten- to hide malicious payloads and bypass the file type validation logic
sion, null bytes, scripts, or non-alphanumeric characters. Further of the web application [14]. Unlike spoofing-based attacks, where
details about different file naming-based attacks that are employed an adversary only changes the magic bytes and/or MIME type of
by NodeSec are enumerated below. the file, polyglot files are constructed by merging the syntax and
• [A1] File Extension Injection: In this attack, an adversary modifies semantics of multiple file formats. As a result, a web application
the extension of the file name to exploit improper file name ex- might be resilient against spoofing-based attacks but still be vul-
tension controls in the web application. For example, an attacker nerable to polyglot file attacks. Polyglot files can be used to inject
can inject multiple file extensions to bypass the file validation malicious scripts and bypass the content security policy of the file
logic based on file extensions. upload mechanism of a web application, leading to various types
• [A2] Null Byte Injection: In this attack, the attacker inserts a null- of attacks such as XSS and RCE.
byte into a file name to alter the intended logic of the application. • [A8] JS+JPEG Polyglot: This type of polyglot file is valid in both
An attacker can inject different portions of the file name to per- JPEG and JS file formats. If the content-filtering mechanism of the
form this type of attack. For example, similar to the File Extension web application accepts it as a JPEG file, it will be uploaded to the
Injection attack (A1), an attacker injects a null byte between a for- server. Once the file is uploaded to the web application server, the
bidden extension and an allowed extension to alter the intended attacker can execute the malicious payload by remotely accessing
logic of the targeted [Link] application. the file or during the parsing it can cause to server to down.
• [A3] Script-named file name: In this attack, the attacker inserts • [A9] HTML+PDF Polyglot: A PDF+HTML polyglot file is valid in
a script into a file name, such as an XSS payload, which may both PDF and HTML file formats. It can be used by adversaries to
trigger the execution of the payload in the victim’s browser if bypass the content security checks of web applications and insert
the name of the uploaded file is not sanitized properly. a malicious payload within the HTML file. Similar to the JS+JPEG
• [A4] Path Traversal: In this attack, the adversary inserts malicious Polyglot file, the attacker can execute the malicious payload by
characters into the file name to achieve path traversal attacks, po- remotely accessing the file from the browser [3].
tentially allowing them to access directories outside the restricted
directory in the Node server. [A10] Executable File Upload Attack. In this attack, an attacker
• [A5] Overwrite Attack: In this attack, an adversary aims to over- uploads an executable file (e.g., EML, HTML) that is possible to be
write a file on a target web application server, particularly server executed on the client or server side of a web application. In this
configuration files, to maliciously change the server settings. attack, an attacker uploads an HTML payload file to a target web
With this attack, an attacker can externally control critical con- application. The uploaded payload file can redirect a victim to a
figuration files that play a crucial role in the operation of the malicious website or execute a JavaScript payload embedded on a
target web application, payload file [23–25, 29].
File Content-based Attacks In these attacks, an adversary em-
File Type-based Attacks In these attacks, an adversary modifies
beds malicious content into a seemingly benign file, such as a PDF
the file type of the malicious payload. In the next subsections, we
or SVG. Although these types of attacks can be achieved by insert-
explain the details of how it can be realized to create a malicious
ing malicious content into different file types. We focus on PDF and
payload.
SVG files due to their popularity in the web ecosystem in general
Spoofing-based Attacks. In these attacks, the adversary bypasses
and their potential malicious impacts.
the file type validation logic of the web application by spoofing the
PDF File Attacks. PDF is one of the most popular file formats used
file content-type (MIME-type) and magic header bytes of a file [16].
in web applications. Web applications, such as PDF editors, may
These attacks can lead to the execution of malicious code on the
render the PDF file on the server side to display the document to
server or client-side, unauthorized access, and data leaks.
the user. Additionally, web applications used by law firms (e.g.,
• [A6] MIME Type Spoofing: A file’s content-type represents the DocuSign) may require users to upload necessary information in
file’s MIME type, which describes the file and its structure. File PDF format and store it on the server side. The structure of PDF files
upload libraries may use MIME types to validate file types. How- can be abused by adversaries by embedding a JavaScript payload
ever, an attacker can easily bypass this attempt by modifying or compressing the content to exhaust the resources of the target
or spoofing the content type of the file. If the target server re- server.
lies only on the MIME type check to validate the file content,
MIME type spoofing can enable the attacker to bypass the checks • [A11] JavaScript Embedded PDF: In this attack, adversaries inject
and upload a malicious payload file, potentially leading to code malicious JavaScript code inside a PDF document. For instance, an
execution on the server-side. attacker can inject a JavaScript payload into a PDF document and
• [A7] Magic Byte Spoofing: Another technique used to validate upload it to a web application to perform a stored XSS attack [32].
file types is checking the magic header byte [2]. An attacker can • [A12] PDF Bomb Attack: This attack involves adversaries abusing
create a malicious file, such as a script, and change the magic the encoding options of a PDF file to compress the streams. Once
byte to other file types, such as a PNG file, to bypass the file type the malicious PDF file is uploaded to a web application server, it
validation checks performed by the web application. This attack decompresses the content, causing resource exhaustion on the
can lead to the execution of malicious code on the server. target server [17].
Polyglot File Attacks. Polyglot files are files that are valid in mul- [A13] SVG File Upload Attack. SVG file attacks exploit the features
tiple different file formats, allowing adversaries to create these files of SVG files, which support inline JavaScript code. In this attack, the

1576
(In)Security of File Uploads in [Link] WWW ’24, May 13–17, 2024, Singapore, Singapore

adversary injects a JS payload into an SVG file to achieve different

types of attacks, such as XSS. Malicious Payload Generator
Extension Injector Validator

3.3 Secure File Upload Validation Objectives Null-byte Injector Payload Database
Our goal in this section is to enumerate a set of objectives that Script Injector Uploader
should be implemented by web applications utilizing file upload
Non-alphanumeric Injector
features. We enumerate these objectives by searching the following
resources: secure file upload implementation principles described Spoofer Node
by OWASP [22], prevention techniques and tools against the at- Server
Polyglot File Generator
tacks enumerated in Section 3.2, secure file upload implementation
practices in other ecosystems. Malicious PDF Generator
Authorizator CONF File
Our search resulted in two types of techniques: 1) Techniques
to validate the uploaded files, and 2) Techniques to minimize the Seed Files Attack Payloads

risks of malicious file uploads. The former includes efforts to iden-

tify malicious intent from the file and methods to prevent them, Figure 2: The architecture of NodeSec and experiment setup
while the latter includes other practices such as storing the up- to test the security of file upload vulnerabilities in [Link]
loaded files on a different server, authentication, and authorization applications.
mechanisms, and file size and upload request limiting mechanisms
against DoS attacks. In this paper, we only study the attacks that
can be performed by modifying the uploaded files, we consider the web applications should continually monitor and update their file
techniques in the latter as out of scope. In conclusion, a file upload validation processes to stay ahead of new attack vectors. File size
mechanism in the web application should satisfy the following file limiting/validation can also be added to the list to prevent a DoS
upload validation objectives to prevent UFU attacks: attack on the server, but file size-based attacks are out of the scope
• Objective-1: File Name Validation: An adversary can abuse the of this paper. Finally, we note that there is at least one open source
file name of the uploaded file to trigger a UFU vulnerability [Link] package for each objective, and if a web application sat-
in the web application, as given in Section 3.2. To validate the isfies these objectives, it would prevent all of the thirteen attacks
file name, a web application can assign a randomly generated explained in Section 3.2.
safe string such as UUID to the file name. Additionally, a web
application can also sanitize the file name of an uploaded file 3.4 NodeSec
by removing malicious characters before it is uploaded to the To systematically analyze file upload security weaknesses in [Link]
server. The developers either implement their own sanitization applications and libraries, we developed NodeSec, which automat-
functions or integrate third-party packages to sanitize the file ically generates attack payload files for our attacks (A1-A13) and
name. uploads the malicious payloads to the target web application in
• Objective-2: File Type Validation: A web application can check the an automated fashion. The architecture of NodeSec is depicted in
MIME type of the uploaded file from the file upload request and Figure 2 and consists of five main modules. The first module, 1
reject the uploaded files with unexpected MIME types. While Malicious Payload Generator, creates payload files to trigger the
this method prevents crude file upload attacks, the MIME type of attacks. It comprises multiple attack generator components that
file provided by the client cannot be trusted and it can be easily transform seed files into attack payloads. The second module, 2
spoofed by the attacker. Validating the file type directly from Payload Database, serves as a comprehensive repository for attack
the content of the uploaded file is robust against such spoofing payloads. 3 For authorization purposes, the Authorization module
techniques. Depending on the expected file type of the web ap- automates the collection of essential data, such as login creden-
plication, the techniques for the validating file type can differ. A tials, cookie tokens, and request headers. The 4 Uploader module
developer can make use of open-source packages by detecting then automates the process of uploading attack payload files to the
the file type by its metadata or file stream. server side of the target application. Lastly, the 5 Validator module
• Objective-3: File Content Sanitization: An adversary can insert conducts the validation process after each payload is successfully
malicious content (i.e., script) into a seemingly benign file to uploaded. Due to space limitations, we give the full implementation
trigger UFU vulnerability on the server or client side. To prevent details of NodeSec in Appendix Section 10.
this, a web application should sanitize the malicious content
in the file. The sanitization technique can differ based on the 4 ANALYZING LIBRARIES & APPLICATIONS
file type [21]. A developer can utilize open-source packages to In this section, we analyze the security of file upload libraries and
sanitize the file or set security headers to prevent arbitrary code real-world web applications written in [Link] using NodeSec. To
execution. create our experimental setup, we first downloaded packages from
Overall, implementing these techniques mitigates against UFU npm containing file upload libraries and real-world web applica-
attacks and ensure that only safe and authorized files are allowed tions, then created sample web applications on our local server.
to be uploaded to the system. However, it is important to note Next, we executed NodeSec to evaluate the security of these real-
that there is no silver bullet solution for secure file upload, and world web applications and file upload libraries.

1577
WWW ’24, May 13–17, 2024, Singapore, Singapore Harun Oz et al.

For server-side file upload libraries, we adhered to the guide- Table 1: The analysis of popular file upload libraries.
lines provided in their official documentation and employed the Weekly File Name File Type File Content
widely-used [Link] framework on the server side incorporating
Library Version
Downloads Validation Validation Sanitization
libraries as middleware. To assess the libraries’ security against express-fileupload 1.2.1 276,281
UFU, we enforced all available security settings and conducted multer 1.4.4 4,200,142
checks for potential UFU attacks and possible implementation mis- formidable 2.0.1 8,736.018
takes. We further discuss the functionality of these settings and connect-multiparty 2.2.0 81,248
their effectiveness against UFU. Following a similar approach, we skipper 0.9.1 25,672
installed real-world web applications according to the instructions graphql-upload 13.0.0 358,743
provided in their official documentation. Subsequently, we assessed : Fully implemented, : Partially/Improperly implemented
the security of these sample real-world web applications without : Not implemented,
modifying their source code.
of these popular file upload libraries as it is would be insecure to
4.1 (In)Securities in File Upload Libraries all file content-based attacks.
We selected the popular server-side file upload libraries based on
the following criteria: (1) It should be implemented in [Link]. (2) 4.2 (In)securities in Real world Applications
It should have more than 1K stars on GitHub or received over 80K In this section, we present our analysis of real-world [Link] web
weekly downloads from npm. Based on this criteria, we selected the applications. We utilize NodeSec to perform experiments. We de-
most popular six server-side file upload libraries, which, on average, picted our experiment results on in Table 2. We use the output of
have 2 million weekly downloads from the npm. We analyzed these the NodeSec to fill our table. As explained in Section 2, [Link]
libraries with NodeSec to see whether they satisfy the file upload servers do not execute files in response to an upload request. So,
validation objectives presented in Section 3.3. We examined both the in our analysis, we did not consider the execution of the file in
availability and effectiveness of the security checks. We summarize the server response regarding file execution. As our scope is only
the results in Table 1. analyzing [Link] applications, we consider whether the uploaded
Poorly Handling File Name. To fulfill the file upload validation file poses a security threat to [Link] applications. ✓ indicates that
objective, a library must handle the file name safely. A library can the real-world web application is secure against the attack. In other
achieve this either by sanitizing or randomizing the name of the words, the real-world web application has a prevention mechanism
uploaded file. While libraries such as multer, formidable, connect- against the attack. On the other hand, ✗ indicates that the real-
multiparty, and skipper adopt file name randomization techniques, world web application is insecure against the attack. Particularly,
express-fileupload and graphql-upload employ file name saniti- the real-world web application has no security mechanism against
zation methods to mitigate file name-based attacks. Our analysis the attack.
revealed that some popular file upload libraries such as express- Our investigation throughout this study revealed that mitigat-
fileupload and formidable were improperly implementing their ing one attack does not necessarily guarantee protection against
functions related to the uploaded file name. In express-fileupload, other attacks within the same category. For instance, during the
implementation mistakes in its options cause both the upload of responsible disclosure process, in one case, after we report the
hidden files to a web application server and incorrect trimming insecurity on real-world web application against Executable File
of file extensions. In formidable, due to a regex implementation Upload Attack. The maintainer fixed the issue by implementing a
issue, the function fails to correctly parse extensions with multiple MIME-type checking which caused the application to be insecure
dots and does not sanitize characters between the dots, leaving the to other types of file type attacks. This implies that each attack in
malicious payload exposed on the application server. our attack dataset requires a unique consideration, and maybe a
Insufficient File Type Validation. As we defined in our second specific prevention technique depending on the implementation.
objective, a secure file upload implementation must validate the Considering these, we decided that grouping the insecurities based
expected file type correctly to prevent UFU attacks. Our analysis re- on their root causes could potentially underestimate risks and fail
vealed that all of the file upload libraries are performing MIME type to capture variations in the actual exploitation of attacks. Instead,
validation for file type validation. While this technique can prevent we adopted an approach that treats each successful attack as an
the executable file upload attack, it can be evaded by performing individual insecurity. In addition to analyzing real-world web ap-
spoofing attacks [26]. Hence, web applications using one of these plications with NodeSec, we manually examined their source code
popular file upload libraries without any additional prevention to highlight the reasons of these insecurities and good practices
method would be insecure to all file type-based attacks. currently implemented in these applications. Below, we discuss our
No Malicious Content Sanitization. An adversary can insert findings for each real-world web application.
malicious content into a seemingly benign file to trigger the UFU • GhostCMS currently receives over 10k weekly downloads and
vulnerability in the web application. To prevent that, web applica- is used by more than 50k live websites. It uses multer file upload
tions can either sanitize the malicious content in the file or detect library to handle the file upload process and it does not use any
and prevent the upload of the malicious file. Nevertheless, our anal- additional package to prevent UFU. Thus, similar to multer, it is also
ysis revealed that none of the file upload libraries in our dataset insecure to four file type-based and content-based attacks. Interest-
provides a mechanism to detect or sanitize any malicious content- ingly, although Multer randomizes the file name by default, instead
embedded file. Hence, we found that any web application using one of using Multer’s randomization function, GhostCMS implements

1578
(In)Security of File Uploads in [Link] WWW ’24, May 13–17, 2024, Singapore, Singapore

Table 2: Evaluation of NodeSec against 11 real-world applications.

File Name-based File Type-based File Content-based
Web Application Version Library Attacks Attacks Attacks
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13
Strapi 4.1.7 formidable ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓
GhostCMS 4.42.0 multer ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗
payloadCMS 0.15.1 express-fileupload ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗
ButterCMS 1.2.9 formidable ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗
Keystone 4.2.1 graphql-upload ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓
Apostrophe 3.17.0 connect-multiparty ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Wikijs 2.5.2 multer ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Sanity 2.29.3 Custom ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
FireCMS 1.0.0 Custom ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗
Tiddlywiki 5.2.2 Custom ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗
totaljs 4.0.0 Custom ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✗ ✗ ✓ ✗
✓: Secure, ✗: Insecure
A1: File Extension Injection; A2: Null Byte Injection; A3: Script-named file name; A4: Path Traversal via inserting Non-Alpha; A5: Overwrite
Attack; A6: MIME Type Spoofing; A7: Modified Magic Header Bytes; A8: JS+JPEG Polyglot A9: HTML+PDF Polyglot; A10: Executable File
Upload Attack; A11: JavaScript Embedded PDF; A12: PDF Bomb Attack; A13: SVG File Upload Attack.

its own custom sanitization function, which causes it to be insecure to all types of file type-based and two types of content-based at-
against A1 attack. tacks. Different from formidable, it uses a security package named
koa-helmet module to prevent the code execution in the browser
✗ Not using already existing function in the library: which makes resilient against SVG Upload attack.
Our analysis reveals that despite the availability of a security
function in the file upload library, an ineffective implementation ✗ Blind-trust to the file upload library:
of a custom validation function can introduce security flaws. Our analysis disclose that some application developers may place
undue trust in the security features provided by upload libraries,
• Tiddlywiki is another popular open-source interactive wiki-like which can lead to overlooked insecurities.
website builder. Although Tiddlywiki implements a file name fil-
tering function to prevent four types of file name-based attacks, it • Apostrophe is a popular website builder with currently 4.3k weekly
relies on the MIME type for validating the type of the file which downloads and having received over 4K stars on GitHub. It uses
resulting in Tiddlywiki being insecure against all types of file type- the file upload library connect-multiparty as a file upload library.
based and content-based attacks. We found Apostrophe is resilient to all attacks we tested against.
• PayloadCMS makes use of the express-fileupload library to pro- The reason is that, similar to wikijs, Apostrophe uses additional
cess files uploaded to the server. Our examination of its source code security packages such as Imagemagick to validate file type. Thus,
revealed that the security options available in express-fileupload it is resilient to all types file type-based attacks. Also, it makes use
has not been utilized at all. Moreover, PayloadCMS has a custom of sanitize-html package to sanitize malicious HTML payload
getSafeFileName function, which causes it to be insecure to A1 inside files. Therefore, it is resilient against the SVG upload attack.
attack. However, it is also insecure to SVG upload attack and Ex- • Wikijs is a Wikipedia-like informative website builder with over
ecutable File Upload since it does not utilize any file validation 2.8k weekly downloads and over 22k stars on GitHub. It uses the
method. multer library to handle the file upload process. We found that it is
resilient against all types of UFU attacks. We analyzed its source
✗ Missing edge cases in the custom implementation: code and found that developers of wikijs utilize different types
Our analysis highlights that a custom security implementation of open-source security packages to prevent all types of attacks.
must address all edge cases. Consequently, they may defend Particularly, wiki’s uses sanitize-filename package for handling
against certain attacks within an attack category, yet remain uploaded file names, file-type package package to determine the
susceptible to others from the same group. file type of the uploaded files. Finally, to prevent the code execution
via SVG Upload attack, it utilizes xss package.
• Strapi is the second most popular headless CMS in the top 1M • Sanity is a popular open-source CMS that receives more than 72k
sites. It utilizes the formidable library to process files uploaded to weekly downloads. It uses custom functions to handle the uploaded
the server. Our investigation shows that Strapi uses the formida- files before they are transmitted to its backend. To prevent file name-
ble library without utilizing any additional security mechanism based attacks, it assigns a random file name to any uploaded file,
to prevent all the attacks we consider in this work, except for the which makes sanity resilient to all types of file name-based attacks.
SVG upload attack. Thus, same as formidable, Strapi is insecure Moreover, it validates file type from the metadata of the uploaded

1579
WWW ’24, May 13–17, 2024, Singapore, Singapore Harun Oz et al.

file by utilizing the exif-js package and it is resilient against all we detail in Section 4, these bugs not only present theoretical risks
types of spoofing-based, polyglot file, and PDF file attacks. Similarly but also attack vectors that can be exploited by malicious actors to
to Apostrophe, it uses an additional security package, sanitize-html launch various types of UFU attacks on web applications utilizing
to prevent the SVG file upload attack. these libraries. Our analysis on the source code of these libraries
revealed that they have not been tested against all the attack scenar-
✓ Utilizing custom functions and packages to prevent UFU: ios that can be utilized by an attacker. For example, the sanitization
Our analysis showed that demonstrates that a combination of function in the formidable library did not consider payloads that
custom implementations and open-source packages can effec- can be inserted between the extensions of the uploaded files. Con-
tively prevent all attacks, while also providing the flexibility to sequently, our recommendation is the developers must consider all
defend against specific attacks as needed. the edge cases while implementing these functions in their libraries.

In addition to these seven real-world applications, we also an-

alyzed ButterCMS, FireCMS, [Link], and Keystone. Their results
are presented in Table 2. Due to the page limit, we present their
6 RELATED WORK
detailed explanation in Section 12 in Appendix. [Link] Security. In [31], the authors proposed a static analysis-
based prevention tool against injection attacks in the [Link] ecosys-
5 ROOT CAUSES & RECOMMENDATIONS tem. In [30] investigated the security of [Link] applications against
ReDoS attacks. Differently, Nielsen et al. [18] proposed a modular
In this section, based on the knowledge gained from our responsible
call graph-based approach for security scanning in [Link] applica-
disclosure process and our experiments we enumerate primary
tions. In [35], the authors focused on the communication process
factors contributing to the challenges faced by file upload library
between client- and server-side code in [Link] programs and iden-
and [Link] application developers.
tified vulnerabilities that can lead to different types of server-side
Security Documentation is Imperative. Our analysis identified
attacks.
a lack of well-designed and comprehensive security documentation
File Upload Security. Uddin et al. [33], investigated the file up-
for current file upload libraries. This deficiency is a significant chal-
load security in a cloud service model. Huang et al. proposed
lenge for security-unaware developers, as they may be unaware
UChecker [7], a static analysis-based tool that automatically de-
on these issues. While developers are encouraged to incorporate
tects UFU vulnerabilities in PHP-based server-side web applications.
such ready-to-use third-party software packages into their systems,
Likewise, Huang et al. introduced UFuzzer [8], a locality analysis-
due to missing security documentation, they are unfortunately left
based UFU vulnerability detection system for PHP applications.
with minimal guidance on how to implement security against UFU
In [10], the authors proposed a penetration testing tool for identify-
attacks. Our analysis of real-world web applications concluded
ing file upload bugs in PHP-based web applications. We enumerate
that the absence of security documentation on file upload libraries
the challenges in using existing tools for [Link] and compare the
places application developers in an uncertain position, where they
attack coverage of NodeSec with existing tools in Section 13 in
inadvertently introduce security misconfigurations to their appli-
Appendix.
cations or fail to implement necessary file validation/sanitization
mechanisms which makes their applications insecure against UFU
attacks. Consequently, library developers should explicitly enumer- 7 CONCLUSION
ate the use cases of the file upload library and clearly state both In this paper, we analyzed the security posture of the file upload
the absent and present security mechanisms against UFU attacks ecosystem in [Link]. We introduce NodeSec a tool designed to
in their security documentation. analyze [Link] applications and libraries in the context of UFU-
Lack of Consensus of Responsibility. Our analysis elucidates related security issues and we analyze popular file upload libraries
that the process to report and patch critical libraries is not entirely and real-world web applications using NodeSec. Our analysis re-
clear to the involved parties as our disclosure process exhibits an vealed security issues in eleven popular [Link] web applications
absence of a well-defined consensus concerning the allocation of and bugs in file upload libraries and received 19 CVEs. With this
accountability for implementing content and metadata validation study, we aim to raise awareness about the importance of security
within the file upload ecosystem. While some library developers measures in file upload libraries and web applications, contributing
took the reported issues very seriously and initiated the patching to the development of better practices and tools to protect users
process, others conveniently deferred the responsibility to web ap- from UFU attacks.
plication developers. This confusion on where the responsibility
lies greatly endangers the overall security of the file upload ecosys-
tem. Consequently, we posit that the responsibility to implement 8 ACKNOWLEDGEMENT
defense against UFU should be clearly defined and we suggest that We thank the anonymous reviewers for their helpful feedback and
the implementation of security checks at the file upload library level time. This work was partially supported by the US National Sci-
would be scalable and substantially contribute to mitigating the ence Foundation (Awards: 2039606, 2219920, 2113880), US National
risks associated with this critical issue in the file upload ecosystem. Security Agency (Award: H982302110324). Florida International
Lack of Comprehensive Security Test Cases. Our analysis dis- University Graduate School, Cyber Florida, Google ASPIRE Pro-
closed that popular file upload libraries (e.g., express-fileupload, gram, and Microsoft. The views expressed are those of the authors
formidable) contain bugs within their security-related functions. As only, not of the funding agencies.

1580
(In)Security of File Uploads in [Link] WWW ’24, May 13–17, 2024, Singapore, Singapore

REFERENCES [27] Ax Sharma. 2022. NodeJS module downloaded 7M times lets hackers inject
[1] Abbas Acar, Güliz Seray Tuncay, Esteban Luques, Harun Oz, Ahmet Aris, and code. [Link]
Selcuk Uluagac. 2024. 50 Shades of Support: A Device-Centric Analysis of Android downloaded-7m-times-lets-hackers-inject-code/.
Security Updates. In Network and Distributed System Security Symposium. [28] Konstantinos Solomos, Panagiotis Ilia, Soroush Karami, Nick Nikiforakis, and
[2] Mehdi Chehel Amirani, Mohsen Toorani, and A. Beheshti. 2008. A new ap- Jason Polakis. 2022. The Dangers of Human Touch: Fingerprinting Browser
proach to content-based file type detection. In IEEE Symposium on Computers Extensions through User Actions. In 31st USENIX Security Symposium.
and Communications. [29] Mahdi Soltani, Behzad Ousat, Mahdi Jafari Siavoshani, and Amir Hossein Jahangir.
[3] Anton Barua, Hossain Shahriar, and Mohammad Zulkernine. 2011. Server-Side 2023. An Adaptable Deep Learning-based Intrusion Detection System to Zero-day
Detection of Content Sniffing Attacks. In International Symposium on Software Attacks. Journal of Information Security and Applications 76 (2023), 103516.
Reliability Engineering. [30] Cristian Staicu and Michael Pradel. 2018. Freezing the Web: A Study of ReDoS
[4] Shrenik Bhansali, Ahmet Aris, Abbas Acar, Harun Oz, and Selcuk Uluagac. 2022. Vulnerabilities in JavaScript-based Web Servers. In USENIX Security Symposium.
A First Look at Code Obfuscation for WebAssembly. In In the Proceedings of the [31] Cristian Staicu, Michael Pradel, and Benjamin Livshits. 2018. SYNODE: Under-
15th ACM Conference on Security and Privacy in Wireless and Mobile Networks. standing and Automatically Preventing Injection Attacks on [Link]. In Network
[5] D. Cayir, A. Acar, R. Lazzeretti, M. Angelini, M. Conti, and S. Uluagac. 2024. and Distributed System Security Symposium.
Augmenting Security and Privacy in the Virtual Realm: An Analysis of Extended [32] Phil Stokes. 2019. Malicious PDFs. [Link]
Reality Devices. IEEE Security & Privacy (2024). pdfs-revealing-techniques-behind-attacks/.
[6] James Davis, Arun Thekumparampil, and Dongyoon Lee. 2017. [Link]: Fuzzing [33] Nasir Uddin and Mohammad Jabr. 2016. File Upload Security and Validation in
the Server-Side Event-Driven Architecture. In Proceedings of the Twelfth European Context of Software as a Service Cloud Model. In 6th International Conference on
Conference on Computer Systems. Association for Computing Machinery. IT Convergence and Security (ICITCS).
[7] Jin Huang, Yu Li, Junjie Zhang, and Rui Dai. 2019. UChecker: Automatically De- [34] Daniel Votipka, Kelsey R. Fulton, James Parker, Matthew Hou, Michelle L.
tecting PHP-Based Unrestricted File Upload Vulnerabilities. In 2019 49th Annual Mazurek, and Michael Hicks. 2020. Understanding security mistakes devel-
IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). opers make: Qualitative analysis from Build It, Break It, Fix It. In 29th USENIX
[8] Jin Huang, Junjie Zhang, Jialun Liu, Chuang Li, and Rui Dai. 2021. UFuzzer: Security Symposium.
Lightweight Detection of PHP-Based Unrestricted File Upload Vulnerabilities Via [35] Feng Xiao, Jianwei Huang, Yichang Xiong, Guangliang Yang, Hong Hu, Guofei
Static-Fuzzing Co-Analysis. In Proceedings of the 24th International Symposium Gu, and Wenke Lee. 2021. Abusing Hidden Properties to Attack the [Link]
on Research in Attacks, Intrusions and Defenses. Ecosystem. In USENIX Security Symposium.
[9] Igibek Koishybayev and Alexandros Kapravelos. 2020. Mininode: Reducing [36] Markus Zimmermann, Cristian Staicu, Cam Tenny, and Michael Pradel. 2019.
the Attack Surface of [Link] Applications. In 23rd International Symposium on Small World with High Risks: A Study of Security Threats in the npm Ecosystem.
Research in Attacks, Intrusions and Defenses. In 28th USENIX Security Symposium.
[10] Taek-Jin Lee, Seongil Wi, Suyoung Lee, and Sooel Son. 2020. FUSE: Finding File
Upload Bugs via Penetration Testing. In Network and Distributed System Security
Symposium.
[11] R. Lerdorf, K. Tatroe, B. Kaehms, R. McGredy, N. Torkington, and P.M. Ferguson.
APPENDIX
2002. Programming PHP. O’Reilly Media. 9 VULNERABILITY DISCLOSURE AND
[12] Xiaowei Li and Yuan Xue. 2014. A Survey on Server-Side Approaches to Securing
Web Applications. ACM Comput. Surv. (2014). RESPONSES
[13] Magnus Madsen, Frank Tip, and Ondřej Lhoták. 2015. Static analysis of event-
driven [Link] JavaScript applications. In Proceedings of the 2015 ACM SIGPLAN We responsibly disclosed our findings to the respective developers
International Conference on Object-Oriented Programming, Systems, Languages, and maintainers of the libraries and CMSs. As of writing this paper,
and Applications.
[14] Jonas Magazinius, Billy K. Rios, and Andrei Sabelfeld. 2013. Polyglots: crossing
we received 8 CVEs (CVE-2022-26963, CVE-2022-27140, CVE-2022-
origins by crossing formats. ACM conference on Computer & communications 27261, CVE-2022-27141, CVE-2022-29622, CVE-2022-27262, CVE-
security (2013). 2022-29623, CVE-2022-29353) for libraries and 11 CVEs (CVE-2022-
[15] Yassine Mekdad, Giuseppe Bernieri, Mauro Conti, and Abdeslam El Fergougui.
2021. The rise of ICS malware: A comparative analysis. In European Symposium 27263, CVE-2022-27951, CVE-2022-27266, CVE-2022-27952, CVE-
on Research in Computer Security. Springer. 2022-27139, CVE-2022-28397, CVE-2022-27260, CVE-2022-29351,
[16] MITRE. 2022. CWE-1287: Improper Validation of Specified Type of Input. https: CVE-2022-29354, CVE-2022-30013, CVE-2022-45775) for CMSs. For
//[Link]/data/definitions/[Link].
[17] Jens Müller, Dominik Noss, Christian Mainka, Vladislav Mladenov, and Jörg disclosure, we sent an initial notification email to each developer.
Schwenk. 2021. Processing Dangerous Paths–On Security and Privacy of the We sent a second email to the ones that responded to our notification
Portable Document Format. In Network and Distributed System Security Sympo-
sium.
email. In the second email, we included the following: (i) general
[18] Benjamin Barslev Nielsen, Martin Toldam Torp, and Anders Møller. 2021. Modular description, (ii) implementation issues, (iii) steps for reproducing
Call Graph Construction for Security Scanning of [Link] Applications. In ACM the vulnerabilities, (iv) the proof-of-concept attack videos, and (v)
International Symposium on Software Testing and Analysis.
[19] Andres Ojamaa and Karl Düüna. 2012. Assessing the security of [Link] platform. potential countermeasures for each vulnerability. The summary of
In International Conference for Internet Technology and Secured Transactions. library and CMS developers’ responses is given in the Table 3.
[20] Behzad Ousat, Mohammad Ali Tofighi, and Amin Kharraz. 2023. An End-to-End Library Developers’ Responses and Reactions. We received an
Analysis of Covid-Themed Scams in the Wild. In Proceedings of the 2023 ACM
Asia Conference on Computer and Communications Security. 509–523. initial response from five libraries within three days after the initial
[21] OWASP. 2022. File Content Validation OWASP . [Link] notification email. We did not receive a response from the connect-
.org/cheatsheets/File_Upload_Cheat_Sheet.html#file-content-validation.
[22] OWASP. 2023. Unrestricted File Upload. [Link]
multiparty library. Meanwhile, express-fileupload and formidable
lnerabilities/Unrestricted_File_Upload. libraries acknowledged the issues and implementation mistakes
[23] Harun Oz, Ahmet Aris, Abbas Acar, Güliz Seray Tuncay, Leonardo Babun, and related to their file name handling on uploaded files. They fixed
Selcuk Uluagac. 2023. { RøB } : Ransomware over Modern Web Browsers. In 32nd
USENIX Security Symposium (USENIX Security 23). 7073–7090. the problems and released patched versions. Moreover, although
[24] Harun Oz, Ahmet Aris, Albert Levi, and A. Selcuk Uluagac. 2022. A Survey on the multer library acknowledged the issue, they refused to patch
Ransomware: Evolution, Taxonomy, and Defense Solutions. ACM Comput. Surv. the library, claiming that their library simply accepts all files re-
(jan 2022). [Link]
[25] Harun Oz, Faraz Naseem, Ahmet Aris, Abbas Acar, Guliz Seray Tuncay, and gardless of their content and deferred the responsibility to web
A Selcuk Uluagac. 2022. Poster: Feasibility of Malware Visualization Techniques application developers to apply the necessary security checks. Fur-
against Adversarial Machine Learning Attacks. In 43rd IEEE Symposium on Secu-
rity and Privacy (S&P).
thermore, the graphql-upload library considered the reported issue
[26] Upasana Sarmah, D.K. Bhattacharyya, and J.K. Kalita. 2018. A survey of detection to be outside the scope of the offered service since the library op-
methods for XSS attacks. Journal of Network and Computer Applications (2018). erates as middleware. We recommended that they clarify this in
their security documentation, stating that they do not perform any

1581
WWW ’24, May 13–17, 2024, Singapore, Singapore Harun Oz et al.

Table 3: Library/CMS developer responses and patching sta- • Malicious Extension Injector. This component takes a seed file as
tus of the reported vulnerabilities. input, such as [Link], and injects multiple extensions through
either random prepending or appending with benign extensions
Name Type Version Response Ack
CVE Patching (e.g., [Link], [Link]), removing the file extension entirely
Issued Status
(e.g., test), disguising the file extension by randomly altering the
express-fileupload Library 1.2.1 02/02/2022 Yes Yes Yes
case of its characters (e.g., [Link], testJS), and appending unusual
multer Library 1.4.4 03/12/2022 No Yes No
extensions (e.g., seed.html5, test.js6). It also generates filenames
formidable Library 2.0.1 04/02/2022 Yes Yes Yes
with triple-appended extensions (e.g., [Link]), ran-
connect-multiparty Library 2.0.0 No No Yes No
domly mixed case extensions (e.g., [Link], [Link]), and
skipper Library 0.9.1 09/09/2022 No Yes No
unusual extensions (e.g., jsx, mjs, xhtml).
graphql-upload Library 13.0.0 04/13/2022 No Yes No
• Null-byte Injector. This module inserts null-byte characters at
GhostCMS CMS 4.42.0 04/07/2022 Yes Yes No
random positions within the file name. To enhance the attack
payloadCMS CMS 0.15.1 04/06/2022 Yes Yes No
Strapi CMS 4.1.7 04/13/2022 Yes Yes Yes
coverage, we base this component on the set of files generated
ButterCMS CMS 1.2.9 04/12/2022 Yes Yes Yes
by the Malicious Extension Injector. Specifically, this component
Keystone CMS 4.2.1 No No Yes No
places different null-bytes in random positions in the file name.
FireCMS CMS 1.0.0 No No No No For example, this module creates file names such as [Link]%[Link],
Tiddlywiki CMS 5.2.2 04/03/2022 Yes Yes No [Link]%.png.
totaljs CMS 4.0.0 04/25/2022 Yes Yes No • Script Injector. This component receives a seed input file and in-
jects script payloads at random positions within the file name.
Similar to the Null-byte Injector component, this module in-
creases the attack coverage of our tool by injecting payload scripts
security checks in their library to avoid misleading web application into random positions of the file name. For instance, using this
developers. module, a JavaScript seed payload file named "[Link]" can be
CMS Developers’ Responses and Reactions. As for the responses transformed into "[Link][payload].js".
from the real-world web applications, six out of the eight vulnerable • Non-alphanumeric Injector. This component takes a seed input file
real-world web applications analyzed, namely GhostCMS, Payload- and injects malicious non-alphanumeric characters into random
CMS, Strapi, ButterCMS, Tiddlywiki, totaljs, replied to our notifi- positions in the file name. For example, given a valid PNG file
cation email in two weeks. So far, ButterCMS and Strapi fixed the named "[Link]" as input, the component can generate file names
vulnerabilities. On the other hand, GhostCMS and PayloadCMS such as "/../..png".
refused to patch the vulnerabilities. They claimed that all users • Spoofer. This component takes an input file and generates a
were considered to be trusted in their "threat model", and that they spoofed version with either altered MIME type or magic bytes.
did not expect them to upload malicious files. Furthermore, totaljs It consists of two separate functionalities: MIME type spoofing
and Tiddlywiki acknowledged our findings and requested more and magic-byte spoofing. For MIME type spoofing, the compo-
information about our findings. After, we sent the aforementioned nent reads a JSON file containing a list of MIME types and their
detailed attack description email. However, we have not received corresponding file extensions. It iterates through the input files
any reply as of the writing of this paper. At the time of this writing, and alters their MIME type from the original value (e.g., "tex-
we unfortunately still have not heard back from the developers of t/javascript") to a different MIME type (e.g., "application/pdf")
fireCMS, and keystone for the vulnerabilities notified. while keeping the file content unchanged. The output files are
US-Cert Involvement. We also notified the US-CERT about the saved with the same file extension but with an updated MIME
issues. They acknowledged our findings and decided to create two type, potentially bypassing file type validation checks based on
cases, one for the libraries and one for impacted CMSs. MIME types. In the case of magic-byte spoofing, the component
reads a JSON file containing a list of magic bytes associated with
10 IMPLEMENTATION DETAILS OF NODESEC different file formats. It iterates through the input files and mod-
To systematically analyze the file upload security weaknesses in ifies the magic byte of each file with another file format. The
[Link] applications and libraries, we developed NodeSec, which output files are saved with a new file extension corresponding to
automatically generates attack payload files for our attacks (A1-A13) the spoofed magic byte, while the file content remains the same.
and uploads the malicious payloads to the target web application • Polyglot File Generator. This component creates polyglot files,
in an automated fashion. The architecture of NodeSec is depicted specifically PDF+HTML and PNG+JS combinations. Polyglot files
in Figure 2 and consists of the following main modules: 1) Mali- are files that are valid in multiple file formats, allowing them to
cious Payload Generator, 2) Payload Database, 3) Authorization 4) bypass certain file validation mechanisms and introduce security
Uploader, and 5) Validator. risks in web applications [14]. To generate PDF+HTML polyglot
Malicious Payload Generator. This module creates payload files files, the script creates a simple PDF file using the ReportLab
to trigger the attacks detailed in Section 3.2. It comprises multiple library and a basic HTML file with a heading. It then combines
attack generator components that transform seed files into attack the PDF and HTML data, separated by a custom delimiter, into a
payloads. After generating the payloads, we verify whether they are single file. For PNG+JS polyglot files, the script reads an existing
executable following the modification and ensure the preservation
of their semantics. Its components include:

1582
(In)Security of File Uploads in [Link] WWW ’24, May 13–17, 2024, Singapore, Singapore

PNG file, calculates its header size, and injects a JavaScript pay- execute the uploaded payload, either on the client or server side [20].
load, preceded by a sequence of null bytes, into the file without We discuss these methods and their potential consequences below.
affecting its validity as a PNG image. Executing on the client side. The file name or content reflected by
• Malicious File Generator. This component generates various types the web page can cause arbitrary code execution on the client side.
of malicious files by embedding payloads within benign PDF, SVG, The attacker can employ various tactics to trigger code execution
and HTML files. The generator creates JavaScript-embedded and on the client side, such as directly uploading an HTML or JS file
compressed PDF files, SVG files with different payloads, and to a web page. Then, a user can trigger the execution of the file
modified HTML and EML files. by accessing or opening it from the public path of the file. This
can lead to various attacks, such as stealing sensitive user data or
Payload Database. This component serves as a comprehensive
redirecting users to malicious websites.
repository for attack payloads, which are then uploaded to the
Executing on the server side. Unlike PHP, [Link] compiles
target web application through the Uploader module. In addition
JavaScript code into machine code before execution, to minimize
to the payloads generated by the Malicious Payload Generator for
the arbitrary code execution [9]. Nevertheless, the attackers can still
our attacks considered in this study, the users can employ their
exploit UFU vulnerabilities to execute code in the server-side. For
own scripts to generate different payload files or directly import
instance, attackers may exploit dangerous [Link] functions, like
pre-created payload files to the database.
eval() and exec(), to enable server-side execution of uploaded
Authorization Module. The Authorization module is a [Link]
files. For example, after the malicious payload file is uploaded to
script that automates the collection of essential data, such as login
the server, the eval() function implemented on the server side
credentials, cookie tokens, and request headers. The script prompts
can execute a JavaScript code embedded in the payload file. While
the user for required details such as login URL, upload target URL,
the security sandboxing of JavaScript decreases the dangers/risks
upload directory, username, and password. After, it navigates and
of these functions by preventing the execution of the code in the
extracts the session cookie and headers, creates a configuration
browser, [Link] does not have a built-in security sandbox [19, 31].
object, and saves it as a JSON file. The configuration file is employed
In some cases, the reliance on third-party libraries and modules
by the Uploader module to automate the upload of payload files.
in [Link] applications can introduce vulnerabilities. For example,
Uploader. The Uploader module automates the process of upload-
after uploading a malicious payload file, an attacker could exploit an
ing attack payload files to the server side of the target web ap-
insecure implementation of the security-related function (e.g., sani-
plication. This module necessitates two critical input files: 1) a
tization function) in a third-party library, executing the embedded
configuration file retrieved from the Authorization module and 2)
JavaScript code in the payload file [27].
a payload file designated for uploading to the target web applica-
tion. It employs the request-promise library to generate upload
requests and accepts configuration and payload files as inputs. The 12 ANALYSIS OF MORE REAL-WORLD WEB
module includes necessary functions that automate the upload APPS
process for different payload files such as preparing form data.
• ButterCMS is another popular CMS with over 20k weekly down-
Validator. The Validator module conducts the validation process af-
loads. It employs the formidable library for processing the uploaded
ter the successful upload of the payload for each attack. For attacks
files. Our analysis, conducted with NodeSec, reveals that it does
involving malicious characters or extensions in the file name (A1-
not use any additional security mechanisms to strengthen its file
A5), this component examines the web application’s sanitization
upload security. As a result, ButterCMS is vulnerable to the same set
process. It determines whether the file name has been adequately
of attacks as the formidable library, which includes file type-based
sanitized by checking the name of the uploaded file. If the file name
attacks and content-based attacks.
retains any malicious characters and/or patterns after a successful
• FireCMS is a CMS used by various websites from different sec-
upload, the Validator module classifies the web application as vul-
tors and received nearly 1k stars on GitHub. It utilizes custom-
nerable. To validate the attacks that could result in code execution
implemented functions to process the uploaded files before sending
on [Link] servers or browsers (A6-A13), the module checks the
them to the server. Thanks to its custom build fileNamebuilder
file contents by searching for malicious content signatures. For
function, FireCMS is resilient to four types of file name-based at-
example, to validate the attack A13, the module scans the SVG file
tacks. Nevertheless, it does not utilize any type of file validation
and checks for a malicious script. After validating the presence of
mechanism to prevent the uploading of malicious files which results
malicious content, it remotely executes the file using the [Link]
in FireCMS being insecure to other types of attacks.
interpreter v16.14.0 by employing [Link] script. The execution
• Totaljs is an open-source CMS, It uses custom file upload functions
is performed by a script that accesses the uploaded payload file’s
to process the uploaded files. We found that it is resilient against
path via the URL obtained from the target web application’s Node
all types of file name-based attacks since it assigns a random name
server.
to an uploaded file via a custom-implemented function. Nonethe-
less, it does not utilize any type of file validation technique before
11 ATTACK EXECUTION & IMPACT uploading a file to its server. Thus, it is insecure against the A10
Evading security checks in a web application to upload a malicious attack type. However, it performs pre-processing and resizing op-
payload is itself unintended and exposes the application’s insecurity. erations on the images before displaying them on the front end. In
However, to successfully exploit the vulnerability, as explained in this process, it raises an exception while pre-processing the image
our threat model in Section, the attacker still needs to find a way to files with a payload. Thus, it is resilient against three types of file

1583
 WWW ’24, May 13–17, 2024, Singapore, Singapore Harun Oz et al.

type-based attacks and one type of content-based attack. However, in Section 4.1, NodeSec uniquely generates file names by insert-
it is not resilient against two types of content-based attacks. ing payloads at random positions, which enabled it to exclusively
• Keystone is a popular CMS with over 1.7k weekly downloads. identify implementation error in the formidable.
It makes use of graphql-upload for uploading files to the server. Different Execution Environments. PHP-based web applications
Our analysis showed that Keystone implements additional security typically run on web servers like Apache or Nginx, whereas [Link]-
mechanisms by assigning a safe file name to an uploaded file before based web applications either have their own integrated web server
sending it to the server by using filenamify package, which makes or use a server like [Link]. Our experiments have shown that
it resilient against all types of file name-based attacks. Moreover, existing tools, such as FUSE and Fuxploider, generate payloads
it uses the image-type module to determine and validate the file based on PHP tags and PHP-specific functions in their payload
types of images, which prevents three types of file type-based at- generation process. These tools are designed to detect UFU vulner-
tacks and SVG upload attacks. Nevertheless, it does not utilize any abilities in PHP web applications, and their payloads are intended
mechanism to detect malicious content within PDF files. Hence, for execution within PHP interpreters on Apache or Nginx servers
Keystone is only insecure against two types of content-based at- or specific server configurations. Although these payloads can suc-
tacks. cessfully identify distinct UFU vulnerabilities in PHP applications,
they are not applicable to [Link] applications. We observed that
FUSE-generated payloads such as ’[Link],’ incorrectly labeled
13 COMPARISON WITH EXISTING TOOLS the application as vulnerable. However, [Link] applications are
The fundamental concept of file uploading remains consistent (i.e., not designed to process PHP code, which results in false positives.
transferring a file from a client to a server) among different server- Furthermore, existing file upload analysis tools primarily focus
side technologies. So, theoretically, all the existing tools can be on the execution of JavaScript files on the client side. In contrast,
adapted for analyzing [Link] applications. Whereas, this requires [Link] environments also allow for the execution of JavaScript
significant domain expertise and in-depth knowledge of the existing files server-side [31].
tools’ source. Below, we enumerate the challenges in using existing
tools for [Link] and compare the attack coverage of NodeSec with B Attack Coverage
existing tools. FUSE is designed to identify UFU vulnerabilities in PHP-based
web applications by performing 13 different mutation techniques
(M1 to M13) on seed files such as HTML, JS, XHTML, and PHP.
A Challenges in Using Existing Tools for NodeSec covers mutations M1, M2, M3, M6, M8, M9, and M13. The
mutation M5 replaces PHP tags in PHP files, is not applicable to
[Link]
[Link] applications that do not use PHP tags. Mutations M4, M7,
During our experiment, we observed the main challenges of using M10, M11, and M12 in FUSE are designed to modify the name of
existing tools for [Link] applications as follows: an uploaded file, all of which are covered by NodeSec. Moreover,
Syntax and Structure. The syntax, structure, and functions of pro- unlike FUSE, NodeSec considers several other attacks related to
gramming languages can differ significantly, leading to challenges file name and file type, such as null-byte injected file name, script-
in detecting and addressing UFU vulnerabilities across different named file name, path traversal, and PDF bomb attack.
languages. These differences in syntax and structure make static UploadScanner allows testing of web application security mecha-
analysis techniques tailored for PHP syntax, such as those em- nisms against both file type-based and file content-based attacks. To
ployed by UChecker [7] and UFuzzer [8], inapplicable for [Link] evaluate web applications against file name-based attacks, Upload-
applications. For instance, the lack of tag-based syntax in [Link] Scanner generates payloads by prepending an extension to a file
might influence the detection process, as tools designed for PHP do name, changing the file’s extension, and injecting scripts, null-bytes,
not parse or analyze JavaScript code to detect UFU vulnerabilities. and path traversal payloads into the file name. NodeSec enhances
Moreover, the execution of listeners within third-party packages in these attacks by integrating randomization logic and inserting null
[Link] applications is event-driven, which can pose challenges for bytes, scripts, and path traversal payloads into random positions of
static analysis-based approaches [6]. the file names. This enables the generation of more sophisticated
Library Usage and Different File Handling. PHP-based web ap- payloads, such as [Link][payload].png. Notably, with this approach,
plications commonly use the _FILES superglobal array and built-in NodeSec uncovered 3 different implementation mistakes in the
functions (e.g., finfo_file), during the file upload process [11]. popular file upload libraries.
These built-in functions are part of the core PHP language. So, Fuxploider is an open-source tool that automates the detection and
they inherently provide a safer setup. Conversely, [Link] web ap- exploitation of file upload vulnerabilities. It focuses on detecting
plications frequently use third-party file upload libraries. Hence, UFU vulnerabilities in PHP and JSP applications by employing the
when analyzing UFU vulnerabilities in [Link] applications, it’s issues in specific functions in these languages function, and server
vital to create attack payloads that specifically address edge cases configurations. In terms of attack coverage, Fuxploider can upload
in these libraries. We evaluated the existing tools on the formida- a file by changing its extension to upper and lower case, using an
ble library and found that the techniques employed by these tools uncommon extension, and altering the MIME-type, all of which are
were unable to detect the existing implementation flaws since their already covered by NodeSec.
attacks mostly focus on the lack of checks during the file upload
mechanisms of the web application. On the other hand, as detailed

1584

View publication stats