You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: javascript/msccs-7.md
+30-8Lines changed: 30 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,28 @@
1
1
# MSCCS-7 :: PATH TRAVERSAL IN SALTCORN SERVER
2
2
3
-
**Introduction:** Insufficient neutralization of user-controllable data used to construct pathnames may allow access to files and directories beyond authorized boundaries. An adversary can exploit such a vulnerability by crafting malicious requests targeting sensitive files and directories, leading to unauthorized data exposure or deletion. The underlying weakness in the source code is consistently listed among the CWE™ Top 25 Most Dangerous Software Weaknesses, ranking 5th in 2024. In October 2024, a vulnerability stemming from this weakness was disclosed in the JavaScript-based Saltcorn server. This case study explores the root cause of the vulnerability, its potential impact, and how the code was ultimately fixed.
3
+
### Introduction:
4
4
5
+
Insufficient neutralization of user-controllable data used to construct pathnames may allow access to files and directories beyond authorized boundaries. An adversary can exploit such a vulnerability by crafting malicious requests targeting sensitive files and directories, leading to unauthorized data exposure or deletion. The underlying weakness in the source code is consistently listed among the CWE™ Top 25 Most Dangerous Software Weaknesses, ranking 5th in 2024. In October 2024, a vulnerability stemming from this weakness was disclosed in the JavaScript-based Saltcorn server. This case study explores the root cause of the vulnerability, its potential impact, and how the code was ultimately fixed.
6
+
7
+
### Software:
8
+
9
+
**Name:** Saltcorn
5
10
**Language:** JavaScript
6
-
**Software:** Saltcorn
7
11
**URL:**https://github.com/saltcorn/saltcorn
8
12
9
-
**Weakness:** CWE-22: Improper Limitation of a Pathname to a Restricted Directory
13
+
### Weakness:
14
+
15
+
<ahref="https://cwe.mitre.org/data/definitions/22.html">CWE-22: Improper Limitation of a Pathname to a Restricted Directory</a>
10
16
11
17
The weakness arises when an application utilizes user-controllable data to build a pathname meant to remain within a restricted directory. If the application fails to neutralize navigation commands such as ".." in the input, it may inadvertently allow adversaries to access files in unauthorized areas of the file system.
12
18
13
19
Saltcorn is an open source, no-code database application builder. The Saltcorn package contains a `sync` server route responsible for managing data synchronization between the Saltcorn server and clients, ensuring data consistency and handling offline changes efficiently.
14
20
15
21
The `sync` route contains one endpoint, `/clean_sync_dir`, that handles POST requests, and the handler is tasked with deleting a directory used for syncing once offline data from the client has been uploaded and synchronized accordingly. However, because the code does not adequately neutralize user-controllable inputs for path traversal commands, the resulting pathname may lead to an unauthorized location differing from the intended syncing directory.
16
22
17
-
**Vulnerability:**CVE-2024-47818 – Published 7 October 2024
23
+
### Vulnerability:
24
+
25
+
<ahref="https://www.cve.org/CVERecord?id=CVE-2024-47818">CVE-2024-47818</a> – Published 7 October 2024
18
26
19
27
The weakness in the code originates from the POST request handler for the `/clean_sync_dir` route. The error_catcher() middleware function on line 336 accepts a user-provided request `req` argument and extracts the `dir_name` from the request body on line 337. The code then attempts to construct a pathname `syncDir` on lines 340-345 by joining the potentially tainted `dir_name` to the end of a pre-determined path `rootFolder.location/mobile_app/sync`. The resulting `syncDir` specifies a directory whose contents are to be deleted by calling fs.rm() on line 346.
20
28
@@ -43,7 +51,9 @@ The join() function used on line 340 performs this construction by combining the
An adversary can exploit this weakness by including `../` sequences in `dir_name` to traverse up the server's directory structure, allowing them to specify a path outside the intended confines of `rootFolder.location/mobile_app/sync/`, resulting in the deletion of an unauthorized directory.
49
59
@@ -67,7 +77,9 @@ One way for an adversary to obtain these values is to leverage the password rese
67
77
68
78
Thus, an adversary that controls the POST request is able to exploit this weakness and delete files beyond the intended confines of `rootFolder.location/mobile_app/sync/`, causing data loss or system instability.
69
79
70
-
**Mitigation:** To fix this issue, a new normalise_in_base() function was created to properly join potentially unsafe path segments to a trusted base and then verify that the resultant path still starts with that trusted base.
80
+
### Fix:
81
+
82
+
To fix this issue, a new normalise_in_base() function was created to properly join potentially unsafe path segments to a trusted base and then verify that the resultant path still starts with that trusted base.
71
83
72
84
Looking at the implementation of this new normalise_in_base() function, line 162 joins the array of unsafe paths to the trusted base. As part of this call to join(), the resulting path is normalized. So far, this is similar to the original code. The important change is on line 165, which checks that the resulting path still resides within the trusted base. If it doesn’t, then a null value is returned on line 166.
73
85
@@ -106,9 +118,11 @@ This new normalise_in_base() function was then used within the original error_ca
106
118
107
119
As previously discussed, normalize_in_base() joins the segments, normalizes the resulting path, and verifies that the path is still within the trusted base, thus removing the weakness from the code.
108
120
109
-
**Conclusion:** The changes made to the Saltcorn source code prevent malicious sequences such as “../” from causing the creation of a path outside of the desired trusted base. With the weakness resolved, user-controlled input that reaches the error_cather() method can no longer be crafted to cause the deletion of files outside the restricted base path.
121
+
### Conclusion:
122
+
123
+
The changes made to the Saltcorn source code prevent malicious sequences such as “../” from causing the creation of a path outside of the desired trusted base. With the weakness resolved, user-controlled input that reaches the error_cather() method can no longer be crafted to cause the deletion of files outside the restricted base path.
0 commit comments