Javascript in Javascript (Js.Js): Sandboxing Third-Party Scripts

Total Page:16

File Type:pdf, Size:1020Kb

Javascript in Javascript (Js.Js): Sandboxing Third-Party Scripts JavaScript in JavaScript (js.js): Sandboxing third-party scripts Jeff Terrace, Stephen R. Beard, and Naga Praveen Kumar Katta Princeton University Abstract script to execute only what is expected of it. The third- party, however, has full access to the application. It could Running on billions of today’s computing devices, redirect the page, modify the DOM, or insert malware. JavaScript has become a ubiquitous platform for deploy- ing web applications. Unfortunately, an application de- An application owner could download the third-party veloper who wishes to include a third-party script must script and serve it from his or her own servers. This enter into an implicit trust relationship with the third- at least ensures that the script being run by the applica- party—granting it unmediated access to its entire appli- tion hasn’t been modified without the application owner cation content. knowing. However, this is not always possible with dynamically-generated scripts (e.g., advertisements), and In this paper, we present js.js, a JavaScript interpreter it still doesn’t ensure that the third-party script is not ma- (which runs in JavaScript) that allows an application to licious. Third-party services often compress their code execute a third-party script inside a completely isolated, (e.g., using the closure compiler), producing a large soup sandboxed environment. An application can, at runtime, of JavaScript that can make it very difficult for a human create and interact with the objects, properties, and meth- or static analyzer to verify its behavior. Alternatively, ods available from within the sandboxed environment, the application could include the third-party scripts in an giving it complete control over the third-party script. js.js iframe, but iframes still have privileges (e.g., alerts, redi- supports the full range of the JavaScript language, is rection, etc.) that the application might want to disallow. compatible with major browsers, and is resilient to at- It also requires cumbersome inter-iframe messaging for tacks from malicious scripts. communication. We conduct a performance evaluation quantifying the overhead of using js.js and present an example of using Static analyzers can be used to rewrite third-party js.js to execute Twitter’s Tweet Button API. JavaScript [16, 9, 2, 17] before it gets executed. This is often used on small, user-submitted widgets to guaran- tee their safety, but doesn’t provide flexible, fine-grained 1 Introduction control over the third-party script’s privileges, and there- fore, are not applicable to large, third-party libraries. The web has undoubtedly become one of the most Other approaches extend the browser itself to provide dominant application deployment platforms. Thanks to security mechanisms for third-party scripts [12]. While its wide support from today’s consumer devices—from a nice approach, adopting a new standard in all major desktops and laptops to tablets and smartphones—the browsers is difficult and breaks backwards-compatibility. web’s scripting language, JavaScript, is available on bil- In this paper, we present js.js, a JavaScript interpreter lions of devices. that runs on top of JavaScript. It allows site operators One problem facing a web application developer is to mediate access to a page’s internals by executing a the implicit trust of including third-party scripts. A third-party script inside a secure sandbox. We created a third-party script is a JavaScript file included from a prototype js.js implementation by compiling the Spider- party other than the application owner. Examples of Monkey [3] JavaScript engine to LLVM [11] and then commonly used third-party scripts are Google Analytics, translating it to JavaScript using Emscripten [20]. The Facebook’s Like button, Twitter’s Tweet buttons, and ad- implementation is used to demonstrate the js.js API se- vertising platforms. When including one of these third- curity features and benchmark performance on the Sun- party scripts, the application is trusting the third-party Spider benchmark suite [4]. 1 Browser Page var src="nativeAdd(17, 2.4);"; var jsObjs=JSJS.Init(); js.js Library function nativeAdd(d1, d2){ Mediator return d1+ d2; Sandboxed Script } var dblType=JSJS.Types.double; Virtual DOM var wrappedNativeFunc=JSJS.wrapFunction({ func: nativeAdd, window args:[dblType, dblType], document DOM returns: dblType}); JSJS.DefineFunction(jsObjs.cx, jsObjs.glob, "nativeAdd", wrappedNativeFunc, 2, 0); var rval=JSJS.EvaluateScript(jsObjs.cx, Figure 1: js.js architecture for example application jsObjs.glob, src); 2 Design //Convert result to native value vard= rval&&JSJS.ValueToNumber(jsObjs.cx , rval); The design goals for js.js are as follows: • Fine-grained control: Rather than course-grained control, e.g., disallowing all DOM access, an appli- Figure 2: Example of binding a native function to the cation should have fine-grained control over what global object space of a sandboxed script. actions a third-party script can perform. • Full JavaScript Support: The full JavaScript lan- guage should be supported, including with and eval, tor intercepts all access, such that it can allow or reject which are impossible to support with static analysis. requests. • Browser Compatibility: All major browsers should be supported without plugins or modifica- The js.js API aims to be easy to use and flexible. The tions. example in Figure 2 demonstrates using the API to bind • Resilient to attacks: Resilient to possible attacks to the sandboxed environment, a global function called nativeAdd such as page redirection, spin loops, and memory that accepts two numbers as arguments and re- exhaustion. turns the sum. Init initializes a sandboxed environment with standard JavaScript classes and an empty global ob- With these goals in mind, the js.js API has been de- ject. wrapFunction is a helper function that allows an signed to be very generic, similar in structure to the Spi- application to specify expected types of a function call. derMonkey API. Rather than being specific to a web en- If the wrong types are passed to the function, an error is vironment, the js.js API can be used to bind any kind of triggered in the sandbox space, which will result in an global object inside the sandbox space. Initially, a sand- error handler being called in native space, allowing ap- boxed script has no access to any global variables ex- plications to detect sandboxed errors. DefineFunction cept for JavaScript built-in types (e.g., Array, Date, and binds the wrapped function to a name in the global ob- String), but the application can add additional names. In ject space of the sandbox, EvaluateScript executes the web environment, these include global names like the script, and ValueToNumber converts the result of window and document. The js.js API allows an applica- evaluating the expression to a native number. tion, for example, to add a global name called alert that, when called inside the sandbox, calls a native JavaScript In addition to primitive types like bool, int, and dou- function. This way, the application using js.js has com- ble, the js.js API also includes helper functions for bind- plete control over the sandboxed script since the only ing more complex types like objects, arrays, and func- access the sandbox has to the outside is through these tions to the sandboxed space. With the js.js API, an ap- user defined methods. Thus these methods must give the plication can expose whatever functionality of the DOM script access only to the elements that the user allows. it wants to a sandboxed script. It can also be used to run Figure 1 shows an example application architecture user-submitted scripts in a secure way, even providing a using js.js. The Mediator is a JavaScript application that custom application-specific API to its users. Currently, uses the js.js library to execute a third-party script in a creating this virtualized DOM is fairly complex. As fu- sandbox. The Virtual DOM is comprised of the usual ture work, we wish to extend the js.js API to make it eas- web-specific global variables that a script expects, but ier to use by allowing the user to easily setup white/black instead of referring directly to the browser, the media- lists of browser elements, sites, etc. 2 Fine-Grained Full JS Page Spin Loop / Memory Suspend / DOM Control Support Redirection Terminate Exhaustion Resume Direct Include %!%%%% iframe %!%%%% Web Worker %!!!%% Static !%!%%% Static + Runtime !%!%%% js.js !!!!!! Figure 3: Table of related work and the attack vectors which they can protect against or support (!) and those that they cannot (%). “Static” refers to purely static techniques such as ADsafe and Gatekeeper, while “Static + Runtime” refers to techniques such as Caja and WebSandbox. The power of eval and with make them difficult to ex- late the LLVM bytecode to JavaScript. ecute securely. For example, malicious code can use eval Emscripten works by translating each LLVM instruc- to disable or circumvent any protections that have been tion into a line of JavaScript. Typed Arrays (a browser added through JavaScript code. Thus, most other tech- standard) allows Emscripten to emulate the native stack niques either completely prohibit using them or provide and heap, such that loads and stores can be translated to some limited version. However, the powerful sandbox- simple array accesses. When possible, Emscripten trans- ing of scripts that js.js employs means that even eval and lates operations to native JavaScript operations. For ex- with can be executed securely as they can still only ac- ample, an add operation is translated into a JavaScript cess the protected Virtual DOM. add operation. An LLVM function call is translated into Since js.js contains a full JavaScript interpreter (a a JavaScript function call. It also has its own version of a compiled version of SpiderMonkey in our prototype im- libc implementation.
Recommended publications
  • Differential Fuzzing the Webassembly
    Master’s Programme in Security and Cloud Computing Differential Fuzzing the WebAssembly Master’s Thesis Gilang Mentari Hamidy MASTER’S THESIS Aalto University - EURECOM MASTER’STHESIS 2020 Differential Fuzzing the WebAssembly Fuzzing Différentiel le WebAssembly Gilang Mentari Hamidy This thesis is a public document and does not contain any confidential information. Cette thèse est un document public et ne contient aucun information confidentielle. Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Technology. Antibes, 27 July 2020 Supervisor: Prof. Davide Balzarotti, EURECOM Co-Supervisor: Prof. Jan-Erik Ekberg, Aalto University Copyright © 2020 Gilang Mentari Hamidy Aalto University - School of Science EURECOM Master’s Programme in Security and Cloud Computing Abstract Author Gilang Mentari Hamidy Title Differential Fuzzing the WebAssembly School School of Science Degree programme Master of Science Major Security and Cloud Computing (SECCLO) Code SCI3084 Supervisor Prof. Davide Balzarotti, EURECOM Prof. Jan-Erik Ekberg, Aalto University Level Master’s thesis Date 27 July 2020 Pages 133 Language English Abstract WebAssembly, colloquially known as Wasm, is a specification for an intermediate representation that is suitable for the web environment, particularly in the client-side. It provides a machine abstraction and hardware-agnostic instruction sets, where a high-level programming language can target the compilation to the Wasm instead of specific hardware architecture. The JavaScript engine implements the Wasm specification and recompiles the Wasm instruction to the target machine instruction where the program is executed. Technically, Wasm is similar to a popular virtual machine bytecode, such as Java Virtual Machine (JVM) or Microsoft Intermediate Language (MSIL).
    [Show full text]
  • Interaction Between Web Browsers and Script Engines
    IT 12 058 Examensarbete 45 hp November 2012 Interaction between web browsers and script engines Xiaoyu Zhuang Institutionen för informationsteknologi Department of Information Technology Abstract Interaction between web browser and the script engine Xiaoyu Zhuang Teknisk- naturvetenskaplig fakultet UTH-enheten Web browser plays an important part of internet experience and JavaScript is the most popular programming language as a client side script to build an active and Besöksadress: advance end user experience. The script engine which executes JavaScript needs to Ångströmlaboratoriet Lägerhyddsvägen 1 interact with web browser to get access to its DOM elements and other host objects. Hus 4, Plan 0 Browser from host side needs to initialize the script engine and dispatch script source code to the engine side. Postadress: This thesis studies the interaction between the script engine and its host browser. Box 536 751 21 Uppsala The shell where the engine address to make calls towards outside is called hosting layer. This report mainly discussed what operations could appear in this layer and Telefon: designed testing cases to validate if the browser is robust and reliable regarding 018 – 471 30 03 hosting operations. Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student Handledare: Elena Boris Ämnesgranskare: Justin Pearson Examinator: Lisa Kaati IT 12 058 Tryckt av: Reprocentralen ITC Contents 1. Introduction................................................................................................................................
    [Show full text]
  • Machine Learning in the Browser
    Machine Learning in the Browser The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:38811507 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA Machine Learning in the Browser a thesis presented by Tomas Reimers to The Department of Computer Science in partial fulfillment of the requirements for the degree of Bachelor of Arts in the subject of Computer Science Harvard University Cambridge, Massachusetts March 2017 Contents 1 Introduction 3 1.1 Background . .3 1.2 Motivation . .4 1.2.1 Privacy . .4 1.2.2 Unavailable Server . .4 1.2.3 Simple, Self-Contained Demos . .5 1.3 Challenges . .5 1.3.1 Performance . .5 1.3.2 Poor Generality . .7 1.3.3 Manual Implementation in JavaScript . .7 2 The TensorFlow Architecture 7 2.1 TensorFlow's API . .7 2.2 TensorFlow's Implementation . .9 2.3 Portability . .9 3 Compiling TensorFlow into JavaScript 10 3.1 Motivation to Compile . 10 3.2 Background on Emscripten . 10 3.2.1 Build Process . 12 3.2.2 Dependencies . 12 3.2.3 Bitness Assumptions . 13 3.2.4 Concurrency Model . 13 3.3 Experiences . 14 4 Results 15 4.1 Benchmarks . 15 4.2 Library Size . 16 4.3 WebAssembly . 17 5 Developer Experience 17 5.1 Universal Graph Runner .
    [Show full text]
  • Javascript API Deprecation in the Wild: a First Assessment
    JavaScript API Deprecation in the Wild: A First Assessment Romulo Nascimento, Aline Brito, Andre Hora, Eduardo Figueiredo Department of Computer Science Federal University of Minas Gerais, Brazil romulonascimento, alinebrito, andrehora,figueiredo @dcc.ufmg.br { } Abstract—Building an application using third-party libraries of our knowledge, there are no detailed studies regarding API is a common practice in software development. As any other deprecation in the JavaScript ecosystem. software system, code libraries and their APIs evolve over JavaScript has become extremely popular over the last years. time. In order to help version migration and ensure backward According to the Stack Overflow 2019 Developer Survey1, compatibility, a recommended practice during development is to deprecate API. Although studies have been conducted to JavaScript is the most popular programming language in this investigate deprecation in some programming languages, such as platform for the seventh consecutive year. GitHub also reports Java and C#, there are no detailed studies on API deprecation that JavaScript is the most popular language in terms of unique in the JavaScript ecosystem. This paper provides an initial contributors to both public and private repositories2. The npm assessment of API deprecation in JavaScript by analyzing 50 platform, the largest JavaScript package manager, states on popular software projects. Initial results suggest that the use of 3 deprecation mechanisms in JavaScript packages is low. However, their latest survey that 99% of JavaScript developers rely on wefindfive different ways that developers use to deprecate API npm to ease the management of their project dependencies. in the studied projects. Among these solutions, deprecation utility This survey also points out the massive growth in npm usage (i.e., any sort of function specially written to aid deprecation) and that started about 5 years ago.
    [Show full text]
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [Show full text]
  • Ecmascript (Or ES)
    Lesson: Web Programming(1) Omid Jafarinezhad Sharif University of Technology Objective Covers languages, tools, and techniques for developing interactive and dynamic web pages. Topics include page styling, design, and layout; client and server side scripting; web security; and interacting with data sources such as databases Web development can range from developing the simplest static single page of plain text to the most complex web apps (such as electronic businesses, and social network services) ● HTTP, JavaScript, CSS, HTML5, ReactJs, Flow, Progressive Web App ● Golang, NodeJs, MongoDB, PostgreSQL, Redis ● Docker, Git, YUIDoc, Jest, Materials WebPack, Gulp, Browserify, Locust ● (Optional/Research) Kubernetes, InfluxDB, RabbitMQ, gRPC, Ansible Grading Big Picture Internal or external Content Delivery Email/SMS/... services; may be Network (CDN) Service developed in different language Win HTTP, gRPC HTTP Linux WebSocket front-end back-end Data storage Mac JavaScript, Html, NodeJs, mongoDB, CSS, Ajax, GoLang, cache postgreSQL, WebRTC, ReactJs, C#, Java, InfluxDB, ... Mobile AngularJs,... Dart, ... Redis, AMQP, ... Memcached, ... logs queue Logstash, RabitMQ, Fluentd, ... ZeroMQ, ... back-end 1 Load front-end back-end 2 balancing kubernetes cluster, HAProxy, Docker Swarm, ... back-end 3 Git repository Test, Continuous deployment, Code coverage, Merge, Review Build automation, Deployment automation Development Staging Production Bug User feedback, Crash report,... Continuous ... Continuous Integration basically just means that the developer's
    [Show full text]
  • Comparing Javascript Engines
    Comparing Javascript Engines Xiang Pan, Shaker Islam, Connor Schnaith Background: Drive-by Downloads 1. Visiting a malicious website 2. Executing malicious javascript 3. Spraying the heap 4. Exploiting a certain vulnerability 5. Downloading malware 6. Executing malware Background: Drive-by Downloads 1. Visiting a malicious website 2. Executing malicious javascript 3. Spraying the heap 4. Exploiting a certain vulnerability 5. Downloading malware 6. Executing malware Background: Drive-by Downloads Background: Drive-by Downloads Setup: Making the prototype null while in the prototype creates a pointer to something random in the heap. Background: Drive-by Downloads Environment: gc( ) is a function call specific to Firefox, so the attacker would want to spray the heap with an exploit specific to firefox. Background: Drive-by Downloads Obfuscation: If the browser executing the javascript it firefox,the code will proceed to the return statement. Any other browser will exit with an error due to an unrecognized call to gc( ). Background: Drive-by Downloads Download: The return will be to a random location in the heap and due to heap-spraying it will cause shell code to be executed. Background: Goal of Our Project ● The goal is to decode obfuscated scripts by triggering javascript events ● The problem is when triggering events, some errors, resulting from disparity of different engines or some other reasons, may occur and terminate the progress ● We need to find ways to eliminate the errors and Ex 1therefore generate more de-obfuscated scripts <script> function f(){ //some codes gc(); var x=unescape(‘%u4149%u1982%u90 […]’)); eval(x); } </script> Ex 2 <script type="text/javascript" src="/includes/jquery/jquery.js"></script> Project Overview - Part One ● Modify WebKit engine so that it can generate error informations.
    [Show full text]
  • Time-Travel Debugging for Javascript/Node.Js
    Time-Travel Debugging for JavaScript/Node.js Earl T. Barr Mark Marron Ed Maurer University College London, UK Microsoft Research, USA Microsoft, USA [email protected] [email protected] [email protected] Dan Moseley Gaurav Seth Microsoft, USA Microsoft, USA [email protected] [email protected] ABSTRACT Time-traveling in the execution history of a program during de- bugging enables a developer to precisely track and understand the sequence of statements and program values leading to an error. To provide this functionality to real world developers, we embarked on a two year journey to create a production quality time-traveling de- bugger in Microsoft’s open-source ChakraCore JavaScript engine and the popular Node.js application framework. CCS Concepts •Software and its engineering ! Software testing and debug- Figure 1: Visual Studio Code with extra time-travel functional- ging; ity (Step-Back button in top action bar) at a breakpoint. Keywords • Options for both using time-travel during local debugging Time-Travel Debugging, JavaScript, Node.js and for recording a trace in production for postmortem de- bugging or other analysis (Section 2.1). 1. INTRODUCTION • Reverse-Step Local and Dynamic operations (Section 2.2) Modern integrated development environments (IDEs) provide a that allow the developer to step-back in time to the previously range of tools for setting breakpoints, examining program state, and executed statement in the current function or to step-back in manually logging execution. These features enable developers to time to the previously executed statement in any frame in- quickly track down localized bugs, provided all of the relevant val- cluding exception throws or callee returns.
    [Show full text]
  • Investigating Reason As a Substitute for Javascript
    DEGREE PROJECT IN COMPUTER ENGINEERING, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2020 Investigating Reason as a substitute for JavaScript AXEL PETTERSSON KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Investigation of Reason as a substitute for JavaScript AXEL PETTERSSON Degree Programme in Information and Communication Technology Date: June 4, 2020 Supervisor: Thomas Sjöland Examiner: Johan Montelius School of Electrical Engineering and Computer Science Host company: Slagkryssaren AB Swedish title: Undersökning av Reason som ett substitut till JavaScript Investigation of Reason as a substitute for JavaScript / Undersökning av Reason som ett substitut till JavaScript c 2020 Axel Pettersson Abstract | i Abstract JavaScript has in recent years become one of the most utilized programming languages for developing different kinds of applications. However, even though it has received a lot of praise for its simplicity, versatility and highly active community, it lacks some functionalities and features that a lot of programmers highly value, like static and strict typing, compile-time debugging, and to not be required to make use of third-party libraries to integrate crucial functionality. However, several new languages built on top of JavaScript have been developed to address and resolve these issues developers find with JavaScript without losing the benefits that come with it. One of these super- set languages is Reason, the new syntax and toolchain powered by the OCaml compiler. This thesis aims to address whether there are scenarios where Reason could act as a reasonable substitute of JavaScript by investigating how the languages compare in regards to different criteria. The criteria examined are writability, data structures and typing, reliability and testing, community support, market demand, portability, and performance.
    [Show full text]
  • Node.Js I – Getting Started Chesapeake Node.Js User Group (CNUG)
    Node.js I – Getting Started Chesapeake Node.js User Group (CNUG) https://www.meetup.com/Chesapeake-Region-nodeJS-Developers-Group Agenda ➢ Installing Node.js ✓ Background ✓ Node.js Run-time Architecture ✓ Node.js & npm software installation ✓ JavaScript Code Editors ✓ Installation verification ✓ Node.js Command Line Interface (CLI) ✓ Read-Evaluate-Print-Loop (REPL) Interactive Console ✓ Debugging Mode ✓ JSHint ✓ Documentation Node.js – Background ➢ What is Node.js? ❑ Node.js is a server side (Back-end) JavaScript runtime ❑ Node.js runs “V8” ✓ Google’s high performance JavaScript engine ✓ Same engine used for JavaScript in the Chrome browser ✓ Written in C++ ✓ https://developers.google.com/v8/ ❑ Node.js implements ECMAScript ✓ Specified by the ECMA-262 specification ✓ Node.js support for ECMA-262 standard by version: • https://node.green/ Node.js – Node.js Run-time Architectural Concepts ➢ Node.js is designed for Single Threading ❑ Main Event listeners are single threaded ✓ Events immediately handed off to the thread pool ✓ This makes Node.js perfect for Containers ❑ JS programs are single threaded ✓ Use asynchronous (Non-blocking) calls ❑ Background worker threads for I/O ❑ Underlying Linux kernel is multi-threaded ➢ Event Loop leverages Linux multi-threading ❑ Events queued ❑ Queues processed in Round Robin fashion Node.js – Event Processing Loop Node.js – Downloading Software ➢ Download software from Node.js site: ❑ https://nodejs.org/en/download/ ❑ Supported Platforms ✓ Windows (Installer or Binary) ✓ Mac (Installer or Binary) ✓ Linux
    [Show full text]
  • Secure Coding Open Source Libraries for Java Programmers
    Secure Coding Open Source Libraries for Java Programmers Jim Manico @manicode OWASP Volunteer - Global OWASP Board Member Independent Secure Coding Instructor - Developer 17+ years - Secure coding educator - Co-author of "Iron Clad Java Building Secure Web ApplicaGons" from Oracle Press McGraw Hill Kama'aina Resident of Kauai, Hawaii - Aloha! Authen;caon Password Storage Defense Overview • Offline A?acks – Avoid Hashing or Encrypon – Use proper key derivaDon funcDons and stretching configuraons – Use random and unique per-user salts • Less effec;ve against targeted aacks, but use them anyhow – Strict Password Policy – Mul;-Factor Authen;caon reference: Openwall and http://www.openwall.com/presentations Password Storage !Store password based on need "Use a salt (de-duplicaon) "BCRYPT/SCRYPT/PBKDF2 (slow, performance hit, easy) "HMAC (requires good key storage, tough) Allow very complex and long passwords 1) Do not limit the type of characters or length of user password • Limiting passwords to protect against injection is doomed to failure • Use proper encoder and other defenses described instead • Set large password length limits • Django DOS vulnerability Salt passwords uniquely for each user 2) Use a cryptographically strong credential-specific salt protect( salt + password ); • Use a 32char or 64char salt (actual size dependent on protection function); • Do not depend on hiding, splitting, or otherwise obscuring the salt Leverage One-Way Keyed Func;ons 3) Impose difficult verification on [only] the attacker (strong/fast) HMAC-SHA-256( key,
    [Show full text]
  • The Virtual Faraday Cage
    University of Calgary PRISM: University of Calgary's Digital Repository Graduate Studies The Vault: Electronic Theses and Dissertations 2013-08-09 The Virtual Faraday Cage King, James King, J. (2013). The Virtual Faraday Cage (Unpublished master's thesis). University of Calgary, Calgary, AB. doi:10.11575/PRISM/28416 http://hdl.handle.net/11023/867 master thesis University of Calgary graduate students retain copyright ownership and moral rights for their thesis. You may use this material in any way that is permitted by the Copyright Act or through licensing that has been assigned to the document. For uses that are not allowable under copyright legislation or licensing, you are required to seek permission. Downloaded from PRISM: https://prism.ucalgary.ca UNIVERSITY OF CALGARY The Virtual Faraday Cage by James King A THESIS SUBMITTED TO THE FACULTY OF GRADUATE STUDIES IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF A MASTERS OF SCIENCE DEPARTMENT OF COMPUTER SCIENCE CALGARY, ALBERTA AUGUST, 2013 c James King 2013 Abstract This thesis' primary contribution is that of a new architecture for web application plat- forms and their extensions, entitled \The Virtual Faraday Cage". This new architecture addresses some of the privacy and security related problems associated with third-party extensions running within web application platforms. A proof-of-concept showing how the Virtual Faraday Cage could be implemented is described. This new architecture aims to help solve some of the key security and privacy con- cerns for end-users in web applications by creating a mechanism by which a third-party could create an extension that works with end-user data, but which could never leak such information back to the third-party.
    [Show full text]