Flexible access control for javascript

Richards, Gregor; Hammer, Christian; Nardelli, Francesco Zappa; Jagannathan, Suresh; Vítek, Jan

doi:10.1145/2509136.2509542

Cited by 10 publications

(6 citation statements)

References 32 publications

(35 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Other research on TypeScript includes formalization and variations of its type system [4,17,18,22], and several alternative techniques for JavaScript type inference exist [16,11,6], however, none of that work addresses the challenges that arise when integrating JavaScript libraries into typed application code.…”

Section: Related Workmentioning

confidence: 99%

Inference and Evolution of TypeScript Declaration Files

Kristensen

Møller

2017

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

Abstract. TypeScript is a typed extension of JavaScript that has become widely used. More than 2 000 JavaScript libraries now have publicly available TypeScript declaration files, which allows the libraries to be used when programming TypeScript applications. Such declaration files are written manually, however, and they are often lagging behind the continuous development of the libraries, thereby hindering their usability. The existing tool tscheck is capable of detecting mismatches between the libraries and their declaration files, but it is less suitable when creating and evolving declaration files. In this work we present the tools tsinfer and tsevolve that are designed to assist the construction of new TypeScript declaration files and support the co-evolution of the declaration files as the underlying JavaScript libraries evolve. Our experimental results involving major libraries demonstrate that tsinfer and tsevolve are superior to tscheck regarding these tasks and that the tools are sufficiently fast and precise for practical use.

show abstract

Section: Related Workmentioning

confidence: 99%

Inference and Evolution of TypeScript Declaration Files

Kristensen

Møller

2017

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

show abstract

“…Confidentiality violations like information stealing are possible wherever third-party code is loaded directly into another web page [2]. Loading third-party code into separate iframes protects the main frame by the same-origin policy, but hinders interaction that mashup pages crucially rely on and does not guarantee absence of attacks [3]. Information flow control (IFC) is an elegant solution for such problems.…”

Section: Introductionmentioning

confidence: 99%

“…It ensures security even in the presence of untrusted and buggy code. IFC for JS differs from traditional IFC as JS is extremely dynamic [3,1], which makes sound static analysis difficult.…”

Section: Introductionmentioning

confidence: 99%

Information Flow Control in WebKit’s JavaScript Bytecode

Bichhawat

Rajani

Garg

et al. 2014

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

Abstract. Websites today routinely combine JavaScript from multiple sources, both trusted and untrusted. Hence, JavaScript security is of paramount importance. A specific interesting problem is information flow control (IFC) for JavaScript. In this paper, we develop, formalize and implement a dynamic IFC mechanism for the JavaScript engine of a production Web browser (specifically, Safari's WebKit engine). Our IFC mechanism works at the level of JavaScript bytecode and hence leverages years of industrial effort on optimizing both the source to bytecode compiler and the bytecode interpreter. We track both explicit and implicit flows and observe only moderate overhead. Working with bytecode results in new challenges including the extensive use of unstructured control flow in bytecode (which complicates lowering of program context taints), unstructured exceptions (which complicate the matter further) and the need to make IFC analysis permissive. We explain how we address these challenges, formally model the JavaScript bytecode semantics and our instrumentation, prove the standard property of terminationinsensitive non-interference, and present experimental results on an optimized prototype.

show abstract

“…Since most of the common JavaScript vulnerabilities cannot be prevented or resolved with browser-level security (which can be omitted, wrongly configured, or bypassed [11,29,38]), a variety of static [15,22,23,33] and dynamic [5,7,13,25,32,35,36,37,39,41] analyses have been proposed to make applications more secure. On the one hand, a static analysis reason about the program's source code, allowing developers to detect and resolve security issues in the early stages before deploying or executing the application.…”

Section: Introductionmentioning

confidence: 99%

Deriving Static Security Testing from Runtime Security Protection for Web Applications

2021

View full text Add to dashboard Cite

Context: Static Application Security Testing (SAST) and Runtime Application Security Protection (RASP) are important and complementary techniques used for detecting and enforcing application-level security policies in web applications.Inquiry: The current state of the art, however, does not allow a safe and efficient combination of SAST and RASP based on a shared set of security policies, forcing developers to reimplement and maintain the same policies and their enforcement code in both tools.Approach: In this work, we present a novel technique for deriving SAST from an existing RASP mechanism by using a two-phase abstract interpretation approach in the SAST component that avoids duplicating the effort of specifying security policies and implementing their semantics. The RASP mechanism enforces security policies by instrumenting a base program to trap security-relevant operations and execute the required policy enforcement code. The static analysis of security policies is then obtained from the RASP mechanism by first statically analyzing the base program without any traps. The results of this first phase are used in a second phase to detect trapped operations and abstractly execute the associated and unaltered RASP policy enforcement code.Knowledge: Splitting the analysis into two phases enables running each phase with a specific analysis configuration, rendering the static analysis approach tractable while maintaining sufficient precision.Grounding: We validate the applicability of our two-phase analysis approach by using it to both dynamically enforce and statically detect a range of security policies found in related work. Our experiments suggest that our two-phase analysis can enable faster and more precise policy violation detection compared to analyzing the full instrumented application under a single analysis configuration.Importance: Deriving a SAST component from a RASP mechanism enables equivalent semantics for the security policies across the static and dynamic contexts in which policies are verified during the software development lifecycle. Moreover, our two-phase abstract interpretation approach does not require RASP developers to reimplement the enforcement code for static analysis.

show abstract

Flexible access control for javascript

Cited by 10 publications

References 32 publications

Inference and Evolution of TypeScript Declaration Files

Inference and Evolution of TypeScript Declaration Files

Information Flow Control in WebKit’s JavaScript Bytecode

Deriving Static Security Testing from Runtime Security Protection for Web Applications

Contact Info

Product

Resources

About