1. Academic Perspectives
on Node.js
Jamie (James C.) Davis
@davisjam
@TheDavisJam
Hey howdy hey!

2. This talk is about Node.js-related research
Why events? [E]
Security [S]
Analysis and Correctness [AC]
Benchmarking and Performance [BP]
References are not exhaustive.
There are lots of other papers, especially in the AC section.
[EX] == “useful tools here”

3. Why do researchers study Node.js?
Why events
“Let’s argue about system architectures in different contexts”
Security
“The security of the (Node.js-based) web is important”
Analysis and Correctness
“The event loop paradigm leads to interesting problems”
Benchmarking and Performance
“The performance of the (Node.js-based) web is important”

4. 1. Why events?

5. 1. Why events? Back in the 90s, folks used threadpools for servers
Idea: variations on the server-side event loop [E1, E2, E3, E4]
Save on context switching costs
Easier to reason about (?)
Some push-back [E5]
…or maybe Node.js uses an event loop because
client-side JS uses an event loop?

6. 2. Security

7. 2a. Security (general problems)
Event loop + TP blocking [S1]
Framework-enforced timeouts.
3rd-party npm modules [S2]
Module  process.
Function call  RPC.
Security policies.
- cf. #22112.

8. 2b. Security (specific problems)
ReDoS
SL regexes are “common” (1%) [S3]
Can be mapped to exploits on the web [S4]
Eval
eval and exec in the wild [S5]

9. 3. Analysis and Correctness

10. 3a. Analysis and Correctness (static/misc.)
Define “event call graph” and derive it statically [AC1]
Defining detailed semantics of Node.js [AC2]
Race conditions in Node.js applications [AC3, AC6]
Within-function dataflow analysis (eval and exec) [S5]

11. 3b. Analysis and Correctness (dynamic)
Instrument JS code (function calls, memory accesses, etc.) [AC4]
Detect bad programming practices dynamically [AC5]
Visualize client- and server- side JS interacting [AC6]
Schedule fuzzing: Shuffle event ordering for crashes [AC7]
Instrument full Node app (JS, C++) [AC8]
Detect all sorts of problems dynamically [AC9]
HTTP vs. HTTPS, directory traversal, poor choice of hash algos.
Also, there are many client-side JS analyses.

12. 4. Benchmarking and Performance

13. 4. Benchmarking and Performance
[BP1] Node.js performance is limited by inappropriate assumptions at the micro-processor level.
Event potpourri damages processor’s locality assumptions
[BP2] JITProf: A (perhaps dated) way to ID JIT-unfriendly code
[BP3] Building a Node.js benchmark suite
Software engineering metrics – representative GH projects

14. In closing…

15. What hard problems do you need solved?
In:
Security
Analysis and Correctness
Benchmarking and Performance …
Drop me an !

16. References

17. References: Why events? [EX]
Why threads are a bad idea (for most purposes). Ousterhout. USENIX ATC’96.
Flash: An Efficient and Portable Web Server. Pai, Druschel, and Zwaenepoel. USENIX ATC’99.
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services. Welsh, Culler, and Brewer. SOSP’01.
Why Events Are a Bad Idea (for High-Concurrency Servers). Behren, Condit, and Brewer. HotOS’03.
Comparing the performance of web server architectures. Pariag et al. EuroSys’07.

18. References: Security [SX]
General problems
A Sense of Time for JavaScript and Node.js: First-Class Timeouts as a Cure for Event Handler Poisoning. Davis et al. USENIX Security’18.
BreakApp: Automated, Flexible Application Compartmentalization. Vasilakis et al. NDSS’18.
Specific attacks
The Impact of Regular Expression Denial of Service (ReDoS) in Practice: an Empirical Study at the Ecosystem Scale. Davis et al. ESEC/FSE’18.
Freezing the Web: A Study of ReDoS Vulnerabilities in JavaScript-based Web Servers. Staicu and Pradel. USENIX Security’18.
Synode: Understanding and Automatically Preventing Injection Attacks on Node.js. Staicu et al. NDSS’18.

19. References: Analysis and Correctness [ACX]
Static/Misc
Static analysis of event-driven Node.js JavaScript applications. Madsen et al. OOPSLA’15.
Semantics of Asynchronous JavaScript. Loring et al. DLS’17.
A Comprehensive Study on Real World Concurrency Bugs in Node.js. Wang et al. ASE’17.
Dynamic
Jalangi: a selective record-replay and dynamic analysis framework for JavaScript. Sen et al. ESEC/FSE’13.
DLint: Dynamically Checking Bad Coding Practices in JavaScript. Gong et al. ISSTA’15.
Understanding Asynchronous Interactions in Full-Stack JavaScript. Alimadadi et al. ICSE’16.
Node.fz: Fuzzing the Server-Side Event-Driven Architecture. Davis et al. EuroSys’17.
Efficient Dynamic Analysis for Node.js. Sun et al. Compiler Construction’18.
Dynamic Analysis for JavaScript Code. Gong. PhD Thesis (UC Berkeley).

20. References: Benchmarking and Perf. [BPX]
Microarchitectural Implications of Event-driven Server-side Web Applications. Zhu et al., MICRO’15.
JITProf: Pinpointing JIT-Unfriendly JavaScript Code. Gong et al. ESEC/FSE’15.
Building a Node.js Benchmark: Initial Steps. Maj et al. BenchWork’18.