JaVerT 2.0: compositional symbolic execution for JavaScript

We describe JSAI, an abstract interpreter for JavaScript. JSAI uses novel abstract domains to compute a reduced product of type inference, pointer analysis, string analysis, integer and boolean constant propagation, and control-flow analysis. In addition, JSAI allows for analysis control-flow sensitivity (i.e., context-, path-, and heap-sensitivity) to be modularly configured without requiring any changes to the analysis implementation. JSAI is designed to be provably sound with respect to a specific concrete semantics for JavaScript, which has been extensively tested against existing production-quality JavaScript implementations. We provide a comprehensive evaluation of JSAI's performance and precision using an extensive benchmark suite. This benchmark suite includes real-world JavaScript applications, machine-generated JavaScript code via Emscripten, and browser addons. We use JSAI's configurability to evaluate a large number of analysis sensitivities (some well-known, som...

2020

We present JSkel, a formalization of the semantics of JavaScript in Skel, the concrete language used to write skeletal semantics. We describe the improvements to Skel we designed and implemented to significantly simplify the formalization. We show the formalization is both close to the specification and executable.

2011

Abstract JavaScript as a Web scripting language has been widely used following the fast growth of Internet. Due to the flexible and dynamic features offered by the JavaScript language, it has become a challenging problem to statically reason about code written in JavaScript. As a first step towards building a mechanised verification system for JavaScript, we present, in this paper, an axiomatic verification system for a core subset of JavaScript based on a variant of separation logic.

Lecture Notes in Computer Science, 2008

We define a small-step operational semantics for the ECMAScript standard language corresponding to JavaScript, as a basis for analyzing security properties of web applications and mashups. The semantics is based on the language standard and a number of experiments with different implementations and browsers. Some basic properties of the semantics are proved, including a soundness theorem and a characterization of the reachable portion of the heap.

Artifact Digital Object Group, 2020

We introduce Gillian, a platform for developing symbolic analysis tools for programming languages. Here, we focus on the symbolic execution engine at the heart of Gillian, which is parametric on the memory model of the target language. We give a formal description of the symbolic analysis and a modular implementation that closely follows this description. We prove a parametric soundness result, introducing restriction on abstract states, which generalises path conditions used in classical symbolic execution. We instantiate Gillian to obtain trusted symbolic testing tools for JavaScript and C, and use these tools to find bugs in real-world code, thus demonstrating the viability of our parametric approach. CCS Concepts: • Theory of computation → Program analysis; Program semantics; • Software and its engineering → Formal language definitions.

Cornell University - arXiv, 2021

This is an evolving document describing the meta-theory, the implementation, and the instantiations of Gillian, a multi-language symbolic analysis platform. 1 INTRODUCTION Gillian was introduced in [4] as a multi-language platform for whole-program symbolic execution, parametric on the concrete and symbolic memory models of the target language (TL), and underpinned by a core symbolic execution engine with strong mathematical foundations. Gillian analysis is done on GIL, an intermediate goto language parametric on a set of memory actions, which describe the fundamental ways in which TL programs interact with their memories. To instantiate Gillian to a new TL, a tool developer must: (1) identify the set of the TL memory actions and implement the TL memory models using these actions; and (2) provide a trusted compiler from the TL to GIL, which preserves the TL memory models and the semantics. In [4], Gillian was instantiated to JavaScript (JS) and C, and these instantiations, called Gillian-JS and Gillian-C, were used to find bugs in two real-world data-structure libraries. In [1], Gillian was extended with support for compositional memory models and verification based on separation logic. The compositional memory models of Gillian work with partial memories and are formulated in terms of core predicates and associated consumer and producer actions for the TL memory models, which need to be provided by the tool developer. The core predicates describe the fundamental units of TL memories: e.g., a JS object-property pair and a C block cell. The consumers and producers, respectively, frame off and frame on the TL memory resource described by the core predicate. The partial memories also need to track negative resource: that is, the resource known to be absent from the partial memory. Gillian verification is built on top of compositional memory models. In particular, the core predicates induce an assertion language for writing function specifications in separation logic and the consumers and producers allow for the creation of a fully parametric spatial entailment engine, enabling re-use of function specifications in symbolic execution. Gillian also allows tool developers to extend assertions with user-defined predicates so as to identify the TL language interface familiar to code developers, and code developers to provide additional predicates and lemmas to verify the particular data structures in their programs. In [1], Gillian-JS and Gillian-C were extended to support verification, and used to provide verified specifications of the JS and C implementations of the deserialisation module of the AWS Encryption SDK, discovering two bugs in the former and three in the latter. Outline. This document currently contains the following content: (§2) an account of Gillian's whole-program execution, including: (§2.1) the syntax of Gillian's intermediate language, GIL (§2.2) memory models for whole-program execution and their properties, which require the memory actions of the target language (§2.3) allocators, which relieve Gillian users of the need to reason explicitly about allocation (§2.4) state models, which are built on top of memory models, and their properties (§2.5) the single-trace and the collecting GIL semantics, defined in terms of state models

Proceedings of the 40th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages - POPL '13, 2013

Many tools allow programmers to develop applications in highlevel languages and deploy them in web browsers via compilation to JavaScript. While practical and widely used, these compilers are ad hoc: no guarantee is provided on their correctness for whole programs, nor their security for programs executed within arbitrary JavaScript contexts. This paper presents a compiler with such guarantees. We compile an ML-like language with higher-order functions and references to JavaScript, while preserving all source program properties. Relying on type-based invariants and applicative bisimilarity, we show full abstraction: two programs are equivalent in all source contexts if and only if their wrapped translations are equivalent in all JavaScript contexts. We evaluate our compiler on sample programs, including a series of secure libraries.

Proceedings of the Eighth ACM SIGPLAN workshop on Programming languages and analysis for security - PLAS '13, 2013

Dependency analysis is a program analysis that determines potential data flow between program points. While it is not a security analysis per se, it is a viable basis for investigating data integrity, for ensuring confidentiality, and for guaranteeing sanitization. A noninterference property can be stated and proved for the dependency analysis.

2004

Abstract. We reduce JavaScript to a core calculus structured as a small-step operational semantics. We present several peculiarities of the language and show that our calculus models them. We explicate the desugaring process that turns JavaScript programs into ones in the core. We demonstrate faithfulness to JavaScript using real-world test suites. Finally,weillustrateutilitybydefiningasecurityproperty,implementing it as a type system on the core, and extending it to the full language. 1 The Need for Another JavaScript Semantics The growing use of JavaScript has created whole new technical and business models of program construction and deployment. JavaScript is a feature-rich language with many quirks, and these quirks are often exploited by security and privacy attacks. This is especially true in cases where JavaScript has a familiar syntax but an unconventional semantics. Duetoitspopularityandshortcomings,companiesandresearchershavetried to tame JavaScript via program analyses [4...

Proceedings of the 41st Acm Sigplan Sigact Symposium, 2014

JavaScript is the most widely used web language for client-side applications. Whilst the development of JavaScript was initially just led by implementation, there is now increasing momentum behind the ECMA standardisation process. The time is ripe for a formal, mechanised specification of JavaScript, to clarify ambiguities in the ECMA standards, to serve as a trusted reference for high-level language compilation and JavaScript implementations, and to provide a platform for high-assurance proofs of language properties.

This is a preliminary version of a technical report accompanying a conference submission of the same title. It differs from the submission in the following main regards. (1) Expanded section 4, where we provide more details on our JavaScript semantics and background on Lambda JS. (2) Expanded section 5, where we provide more details on our verified runtime JSVerify, more details on the heap invariant used in our theory, and more description of the light translation as well. We also improved on some of the syntactic conventions, which helped facilitate the mechanized proof of JSVerify in F . This makes some of definitions look superficially different, although they remain essentially unchanged. For example, rather than overload stub functions in the Abs heap, we now separate them into their own heap compartment called Stub. This makes the proofs easier, although the main ideas remain unchanged. (3) Expanded section 7, with all the details on our applicative bisimulation machinery—we ...

Proceedings of the 6th ACM SIGPLAN International Workshop on State Of the Art in Program Analysis, 2017

JavaScript is one of the most widely used programming languages. To understand the behaviors of JavaScript programs and to detect possible errors in them, researchers have developed several static analyzers based on the abstract interpretation framework. However, JavaScript provides various language features that are difficult to analyze statically and precisely such as dynamic addition and removal of object properties, first-class property names, and higher-order functions. To alleviate the problem, JavaScript static analyzers often use recency abstraction, which refines address abstraction by distinguishing recent objects from summaries of old objects. We observed that while recency abstraction enables more precise analysis results by allowing strong updates on recent objects, it is not monotone in the sense that it does not preserve the precision relationship between the underlying address abstraction techniques: for an address abstraction A and a more precise abstraction B, recency abstraction on B may not be more precise than recency abstraction on A. Such an unintuitive semantics of recency abstraction makes its composition with various analysis sensitivity techniques also unintuitive. In this paper, we propose a new singleton abstraction technique, which distinguishes singleton objects to allow strong updates on them without changing a given address abstraction. We formally define recency and singleton abstractions, and explain the unintuitive behaviors of recency abstraction. Our preliminary experiments show promising results for singleton abstraction. CCS Concepts • Software and its engineering → General programming languages; • Theory of computation → Program analysis

Springer eBooks, 2008

We discuss how to perform symbolic execution of large programs in a manner that is both compositional (hence more scalable) and demand-driven. Compositional symbolic execution means finding feasible interprocedural program paths by composing symbolic executions of feasible intraprocedural paths. By demand-driven, we mean that as few intraprocedural paths as possible are symbolically executed in order to form an interprocedural path leading to a specific target branch or statement of interest (like an assertion). A key originality of this work is that our demand-driven compositional interprocedural symbolic execution is performed entirely using first-order logic formulas solved with an off-the-shelf SMT (Satisfiability-Modulo-Theories) solver-no procedure in-lining or custom algorithm is required for the interprocedural part. This allows a uniform and elegant way of summarizing procedures at various levels of detail and of composing those using logic formulas. We have implemented a prototype of this novel symbolic execution technique as an extension of Pex, a general automatic testing framework for .NET applications. Preliminary experimental results are encouraging. For instance, our prototype was able to generate tests triggering assertion violations in programs with large numbers of program paths that were beyond the scope of non-compositional test generation.

2011

Abstract As the programming language of the web, JavaScript deserves a principled yet robust framework for static analysis. To achieve both aims simultaneously, we start from an established reduction semantics for JavaScript and systematically derive its intensional abstract interpretation. Our first step is to transform the semantics into an equivalent low-level abstract machine: the JavaScript Abstract Machine (JAM). We then derive the systematic abstraction of the entire low-level machine.

ACM Sigsoft Software Engineering Notes, 2006

Forward symbolic execution is a program analysis technique that allows using symbolic inputs to explore program executions. The traditional applications of this technique have focused on programs that manipulate primitive data types, such as integer or boolean. Recent extensions have shown how to handle reference types at their representation level. The extensions have favorably been backed by advances in constraint solving technology, and together they have made symbolic execution applicable, at least in theory, to a large class of programs. In practice, however, the increased potential for applications has created significant issues with scalability of symbolic execution to programs of non-trivial size-the ensuing path conditions rapidly become unfeasibly complex.