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
Executing arbitrary expressions like enabled by the expression parser of
4
+
mathjs involves a risk in general. When you're using mathjs to let users
5
+
execute arbitrary expressions, it's good to take a moment to think about
6
+
possible security and stability implications.
7
+
8
+
## Security risks
9
+
10
+
A user could try to inject malicious JavaScript code via the expression
11
+
parser. The expression parser of mathjs offers a sandboxed environment
12
+
to execute expressions which should make this impossible. It's possible
13
+
though that there is an unknown security hole, so it's important to be
14
+
careful, especially when allowing server side execution of arbitrary
15
+
expressions.
16
+
17
+
The expression parser of mathjs parses the input in a controlled
18
+
way into an expression tree, then compiles it into fast performing
19
+
JavaScript using JavaScript's `eval` before actually evaluating the
20
+
expression. The parser actively prevents access to JavaScripts internal
21
+
`eval` and `new Function` which are the main cause of security attacks.
22
+
23
+
When running a node.js server, it's good to be aware of the different
24
+
types of security risks. The risk whe running inside a browser may be
25
+
limited though it's good to be aware of [Cross side scripting (XSS)](https://www.wikiwand.com/en/Cross-site_scripting) vulnerabilities. A nice overview of
26
+
security risks of a node.js servers is listed in an article [Node.js security checklist](https://blog.risingstack.com/node-js-security-checklist/) by Gergely Nemeth.
27
+
Lastly, one could look into running server side code in a sandboxed
28
+
[node.js VM](https://nodejs.org/api/vm.html).
29
+
30
+
## Stability risks
31
+
32
+
A user could accidentally or on purpose execute a
33
+
heavy expression like creating a huge matrix. That can let the
34
+
JavaScript engine run out of memory or freeze it when the CPU goes
35
+
to 100% for a long time.
36
+
37
+
To protect against this sort of issue, one can run the expression parser
38
+
in a separate Web Worker or child_process, so it can't affect the
39
+
main process. The workers can be killed when it runs for too
40
+
long or consumes too much memory. A useful library in this regard
41
+
is [workerpool](https://github.com/josdejong/workerpool), which makes
42
+
it easy to manage a pool of workers in both browser and node.js.
0 commit comments