Symbolic Execution for JavaScript

Abstract

We present a framework for trustworthy symbolic execution of JavaScripts programs, whose aim is to assist developers in the testing of their code: the developer writes symbolic tests for which the framework provides concrete counter-models. We create the framework following a new, general methodology for designing compositional program analyses for dynamic languages. We prove that the underlying symbolic execution is sound and does not generate false positives. We establish additional trust by using the theory to precisely guide the implementation and by thorough testing. We apply our framework to whole-program symbolic testing of real-world JavaScript libraries and compositional debugging of separation logic specifications of JavaScript programs.

JaVerT 2.0: compositional symbolic execution for JavaScript

“…In addition, we perform whole-program symbolic testing of the real-world Buckets.js [Santos 2016] data structure library, which has over 65K downloads on npm [npm, Inc. 2018]. We reproduce our previously reported bugs [Fragoso Santos et al 2018a], but also discover a new one, in times that are almost two orders of magnitude faster, suggesting scalability of our whole-program symbolic testing to much larger codebases. As in [Fragoso Santos et al 2018a,b], we perform the entire evaluation on a machine with an Intel Core i7-4980HQ CPU 2.80 GHz, DDR3 RAM 16GB, and a 256GB solid-state hard-drive running OSX.…”

“…The JSIL semantics, however, just like JavaScript semantics, does not observe the frame property: one can introduce bugs into a JSIL/JavaScript program by extending the state in which the program was run. Our solution is to design an instrumented state instantiation, and corresponding instrumented semantics [Fragoso Santos et al 2018a], that exhibits the frame property by explicitly keeping track of object properties that we know are not present. By having the instrumented semantics as a proper interim stage between the concrete semantics and the symbolic semantics, we obtain more modular reasoning and substantially simpler proofs than previous approaches based on weak locality [Gardner et al 2012[Gardner et al , 2008.…”

“…Just as for symbolic tests, the pre-condition of a bug spec can be concretised, revealing a concrete execution triggering the corresponding JS native error. On the other hand, success specs can be turned into actual symbolic tests [Fragoso Santos et al 2018a], meaning that, for example, after fixing the bug, we could collect all the success specs to produce a comprehensive symbolic test suite for our expression evaluator.…”

“…We introduce the interface of the Semantics Module (ğ3.2) and the general JSIL semantics (ğ3.3). Following our previous approaches [Fragoso Santos et al 2018a,b], we instantiate the Semantics Module to obtain the concrete and symbolic JSIL semantics (ğ3.4śğ3.5). We highlight our novel treatment of errors, essential for meaningful error reporting for whole-program symbolic testing, as well as for the inference of resource of the bi-abductive semantics, shown in ğ3.3.1 and ğ3.5.2.…”

“…The bi-abductive symbolic execution discussed above generates a success spec. The value of success specs lies in the fact that they can be converted into concrete/symbolic tests [Fragoso Santos et al 2018a], effectively providing the user with a comprehensive concrete/symbolic test suite for the analysed program and bringing immediate value to the software development process.…”