Progressive types

Politz, Joe Gibbs; Vallee, Hannah Quay-de la; Krishnamurthi, Shriram

doi:10.1145/2384592.2384599

Cited by 8 publications

(7 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In earlier work, we proved our type-checking techniques sound [22,26,51]. However, to verify ADsafe, we have to make one additional modification to the previously documented type system: we relax several typing rules to allow more runtime errors [52]. In this section, we illustrate why this modification is necessary and argue that it is safe.…”

Section: Type-checking Javascriptmentioning

confidence: 83%

Typed-based verification of Web sandboxes

Politz

Guha

Krishnamurthi

2014

JCS

Self Cite

View full text Add to dashboard Cite

Web pages routinely incorporate JavaScript code from third-party sources. However, all code in a page runs in the same security context, regardless of provenance. When Web pages incorporate third-party JavaScript without any checks, as many do, they open themselves to attack. A third-party can trivially inject malicious JavaScript into such a page, causing all manner of harm. Several such attacks have occurred in the wild on prominent, commercial Web sites.A Web sandbox mitigates the threat of malicious JavaScript. Several Web sandboxes employ closely related language-based techniques to maintain backward-compatibility with old browsers and to provide fine-grained control. Unfortunately, due to the size and complexity of the Web platform and several subtleties of JavaScript, language-based sandboxing is hard and the Web sandboxes currently deployed on major Web sites do not come with any formal guarantees. Instead, they are routinely affected by bugs that violate their intended sandboxing properties.This article presents a type-based approach to verifying Web sandboxes, using a JavaScript typechecker to encode and verify sandboxing properties. We demonstrate our approach by applying it to the ADsafe Web sandbox. Specifically, we verify several key properties of ADsafe, falsify one intended property, and find and fix several vulnerabilities, ultimately providing a proof of ADsafe's safety.

show abstract

Section: Type-checking Javascriptmentioning

confidence: 83%

Typed-based verification of Web sandboxes

Politz

Guha

Krishnamurthi

2014

JCS

Self Cite

View full text Add to dashboard Cite

show abstract

“…This guarantee is a direct consequence of TeJaS's own type-safety theorem [15], the soundness of Progressive Types [30], and the correctness of our type environment:…”

Section: The Type System Guaranteementioning

confidence: 95%

“…These enhancements are a form of progressive typing [30], in which the programmers using a type system can choose whether to defer some static type checks until runtime, in exchange for a easier-to-satisfy type checker.…”

Section: Language-level Analysesmentioning

confidence: 99%

Verifying Web Browser Extensions’ Compliance with Private-Browsing Mode

Lerner

Elberty

Poole

et al. 2013

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

Abstract. Modern web browsers implement a private browsing mode that is intended to leave behind no traces of a user's browsing activity on their computer. This feature is in direct tension with support for extensions, which can silently void this guarantee. We create a static type system to analyze JavaScript extensions for observation of private browsing mode. Using this type system, extension authors and app stores can convince themselves of an extension's safety for private browsing mode. In addition, some extensions intentionally violate the private browsing guarantee; our type system accommodates this with a small annotation overhead, proportional to the degree of violation. These annotations let code auditors narrow their focus to a small fraction of the extension's codebase. We have retrofitted type annotations to Firefox's a p is and to a sample of actively used Firefox extensions. We used the type system to verify several extensions as safe, find actual bugs in several others (most of which have been confirmed by their authors), and find dubious behavior in the rest. Firefox 20, released April 2, 2013, implements a finer-grained private browsing mode; we sketch both the new challenges in this implementation and how our approach can handle them.

show abstract

“…Such precision may or may not be needed, depending on the analysis, and the choice need not be hard-coded into the type system itself. We have used this flexibility as a form of progressive typing [16], to provide a set of guarantees of varying precision when analyzing jQuery programs [8]. • Assigning a type to the global object becomes markedly easier.…”

Section: Explicit External Environment Definitionsmentioning

confidence: 99%

“…This insight led to recognizing another dimension in type checkers: the ability to parameterize the typed progress guarantee with a set of allowable runtime errors [16]. Operationally, TeJaS implements this idea via typechecker metafunctions that optimistically select from union types the components that do in fact typecheck.…”

Section: Extensible or Modular Type Systemsmentioning

confidence: 99%

TeJaS

Lerner

Politz

Guha

et al. 2013

Proceedings of the 9th Symposium on Dynamic Languages

Self Cite

View full text Add to dashboard Cite

JavaScript programs vary widely in functionality, complexity, and use, and analyses of these programs must accommodate such variations. Type-based analyses are typically the simplest such analyses, but due to the language's subtle idioms and many application-specific needs-such as ensuring general-purpose type correctness, security properties, or proper library usage-we have found that a single type system does not suffice for all purposes. However, these varied uses still share many reusable common elements.In this paper we present TeJaS, a framework for building type systems for JavaScript. TeJaS has been engineered modularly to encourage experimentation. Its initial type environment is reified, to admit easy modeling of the various execution contexts of JavaScript programs, and its type language and typing rules are extensible, to enable variations of the type system to be constructed easily.The paper presents the base TeJaS type system, which performs traditional type-checking for JavaScript. Because JavaScript demands complex types, we explain several design decisions to improve user ergonomics. We then describe TeJaS's modular structure, and illustrate it by reconstructing the essence of a very different type system for JavaScript. Systems built from TeJaS have been applied to several real-world, third-party JavaScript programs.There is a venerable line of research on retrofitting type systems onto previously "untyped" languages, with Morris's seminal dissertation [11] an early example. In practice, these languages are not actually free of types; rather, all type discrimination is performed by primitive operations at runtime. A common practice for retrofitting type systems has been to identify the resulting set of run-time errors and try to eliminate them statically. For instance, Smalltalk type systems [1, 22] focused on eliminating message-not-found errors, and Soft Scheme [25] addressed the wide range of Scheme dynamic errors. Identifying run-time errors and catching them statically can be viewed as the design principle for retrofitted type systems.Unfortunately, this principle is rather difficult to apply to JavaScript (JS), because there are so few actual run-time errors. 1 In this, JS inherits the forgiving mentality of the browser environment where it was born; instead of flagging errors and halting execution, it simply continues running. As a result, operations that in other languages might reasonably be expected to generate errors do not in JS: subtracting one string from another, accessing an array outside its bounds, reading and writing non-existent fields, calling functions with the wrong number of arguments, etc.Obviously, every one of these operations has a welldefined semantics in JS (usually, ironically, involving the value undefined). Therefore, it becomes a purpose-specific judgment call whether or not these should be considered static type errors. If the purpose is to enforce a strict, Javalike programming style, they should probably all be considered errors. If, in contrast, the goal is ...

show abstract

Progressive types

Cited by 8 publications

References 22 publications

Typed-based verification of Web sandboxes

Typed-based verification of Web sandboxes

Verifying Web Browser Extensions’ Compliance with Private-Browsing Mode

TeJaS

Contact Info

Product

Resources

About