Finding and Preventing Bugs in Javascript Bindings Fraser Brown⋆ Shravan Narayan† Riad S

Total Page:16

File Type:pdf, Size:1020Kb

Finding and Preventing Bugs in Javascript Bindings Fraser Brown⋆ Shravan Narayan† Riad S Finding and Preventing Bugs in JavaScript Bindings Fraser Brown? Shravan Narayany Riad S. Wahby? Dawson Engler? Ranjit Jhalay Deian Stefany ?Stanford University yUC San Diego Abstract—JavaScript, like many high-level languages, relies on run- secure foundational operations [41, 69, 107]. This paper focuses time systems written in low-level C and C++. For example, the on detecting and exploiting flaws in two pervasive JavaScript Node.js runtime system gives JavaScript code access to the under- runtime systems—Node.js and Chrome—since binding bugs in lying filesystem, networking, and I/O by implementing utility func- tions in C++. Since C++’s type system, memory model, and execution these systems endanger hundreds of millions of people (e.g., all model differ significantly from JavaScript’s, JavaScript code must users of the Chrome browser). call these runtime functions via intermediate binding layer code that JavaScript’s variables are dynamically typed. Therefore, translates type, state, and failure between the two languages. Unfor- when JavaScript code calls a binding layer function, that C++ tunately, binding code is both hard to avoid and hard to get right. This paper describes several types of exploitable errors that bind- binding function should first determine the underlying type of ing code creates, and develops both a suite of easily-to-build static each incoming parameter. Then, the function should translate checkers to detect such errors and a backwards-compatible, low- each parameter’s current value to its equivalent statically-typed overhead API to prevent them. We show that binding flaws are a representation in C++. The binding code should also determine serious security problem by using our checkers to craft 81 proof-of- if values are legal (e.g., whether an index is within the bounds concept exploits for security flaws in the binding layers of the Node.js and Chrome, runtime systems that support hundreds of millions of of an array); if not, the binding should propagate an error back users. As one practical measure of binding bug severity, we were to the JavaScript layer. Finally, before the function completes, awarded $6,000 in bounties for just two Chrome bug reports. it should store any result in the memory and type representation that JavaScript expects. 1 Introduction In practice, writing binding code is complicated: it can fail at Many web services and other attacker-facing code bases are many points, and bindings should detect failure and correctly written in high-level scripting languages like JavaScript, Python, communicate any errors back to JavaScript. Too often, binding and Ruby. By construction, these languages prevent developers code simply crashes, leading to denial-of-service or covert- from introducing entire classes of bugs that plague low-level channel attacks (§2). If a binding function does not crash, it languages—e.g., buffer overflows, use-after-frees, and memory might still skip domain checking (e.g., checking that an array leaks. On the other hand, high-level languages introduce new index is in bounds)—or even ignore type checking, therefore classes of severe, exploitable flaws that are often less obvious allowing attackers to use nonsensical values as legal ones. (e.g., than low-level code bugs. by invoking a number as a function). One especially insidious High-level languages push significant functionality to their source of errors is the fact that binding code may invoke new runtime systems, which are written in low-level, unsafe lan- JavaScript routines during type and domain checking. For ex- guages (mainly C and C++). Runtime systems provide function- ample, in translating to a C++ uint32_t, bindings may use the ality not possible in the base scripting language (e.g., network Uint32Value method, which could invoke a JavaScript “upcall” and file system access) or expose fast versions of routines that (i.e., a call back into the JavaScript layer). JavaScript gives users would otherwise be too slow (e.g., sorting routines). Since the extreme flexibility in redefining fundamental language methods, high-level, dynamically-typed scripting language and low-level which makes it hard to know all methods that an upcall can language have different approaches to typing, memory man- transitively invoke, and makes it easy for attackers to circum- agement, and failure handling, the scripting code cannot call vent security and correctness checks. For example: bindings runtime routines directly. Instead, it invokes intermediary bind- may check that a start index is within the bounds of an array ing code that translates between value types, changes value before calling Uint32Value to get the value of an end index. representations, and propagates failure between the languages. The Uint32Value call, however, may be hijacked by a mali- Binding code has the dangerous distinction of being both cious client to change the value of the start index, invalidating hard to avoid and hard to get right. This paper demonstrates the all previous bounds checking. severity of the problem by demonstrating 81 proof-of-concept These bugs are neither hypothetical nor easily avoidable. exploits for bugs in multiple widely-used runtimes for the Our checkers find numerous exploitable security holes in both JavaScript language. We picked JavaScript because of its ubiq- Node.js and Chrome, heavily-used and actively developed code uity: it is both the most popular language on GitHub and the bases. Furthermore, security holes in binding code may be sig- language with the largest growth factor [12, 111]. And though nificantly more dangerous than holes in script code. First, these it was originally confined to web pages, JavaScript now appears bugs render attacks more generic: given an exploitable binding in desktop applications, server-side applications, browser ex- bug, attackers need only trigger a path to that bug, rather than tensions, and IoT infrastructure. Organizations like PayPal and craft an entire application-specific attack. Second, binding flaws Walmart use JavaScript to process critical financial information, do not appear in scripts themselves: a script implementor can and as a result implicitly rely on runtimes and binding code for write correct, flawless code and still introduce security errors Violation type Possible consequence Application code JavaScript Crash-safety DOS attacks, including poison-pill attacks [46]; breaking language-level security abstractions, including [42, 43, 95, 110], by introducing a new covert channel. Binding code Type-safety Above + type confusion attacks which, for example, can be used to carry out remote code execution attacks. V8 C++ Memory-safety Above + memory disclosure and memory corruption Blink runtime system attacks which, for example, can be used to leak TLS keys [29] or turn off the same-origin policy [83]. Figure 1—The Blink runtime system uses the V8 JavaScript engine to execute JavaScript application code. Blink also uses V8’s APIs to Table 1—The three types of binding bugs that we describe extend the base JavaScript environment with new functionality and APIs, such as the DOM. This code—which bridges the JavaScript if their code calls flawed runtime routines. As a result, writing application code and Blink’s C++ runtime—is binding code. secure scripts requires not only understanding the language (already a high bar for many), but also knowing all of the bugs or otherwise impersonate other [website] origins” [85]. Table 1 in all of the versions of all of the runtime systems on which the summarizes the security consequences of these classes of bugs. code might run. In §4 we will discuss the precise security implications of safety To address this threat, this paper makes two contributions: violations with respect to the systems that we analyze. 1. A series of effective checkers that find bugs in widely-used We start with an overview of how binding code works in JavaScript runtime systems: Node.js, Chrome’s rendering runtime systems and how untrusted JavaScript application code engine Blink, the Chrome extension system, and PDFium. can call into the trusted C++ runtime system to exploit binding We show how bugs lead to exploitable errors by manually bugs. We find that these bugs often arise because JavaScript en- writing 81 exploits, including multiple out-of-bounds mem- gines like V8 make it easy for developers to violate JavaScript’s ory accesses in Node.js and use-after-frees in Chrome’s crash-, type-, and memory-safety; even V8’s “hello world” code PDFium (two of which resulted in $6,000 in bug bounties). examples depend on hard-crashing functions [106]. We con- clude with a detailed overview of V8-based binding functions. 2. A backwards-compatible binding-code library that wraps Runtime system binding bugs. Runtime systems use the V8 JavaScript engine’s API, preventing bugs without JavaScript engines to execute application code written in imposing significant overhead. Our library does not break JavaScript. For example, the Chrome rendering engine, Blink, any of Node.js’s over 1,000 tests or the test suites of 74 relies on the V8 engine to interpret and run JavaScript code external Node.js-dependent modules. By design, the migra- embedded in web pages as <script> elements. The JavaScript tion path is simple enough that we are able to automatically application code embedded in the <script> elements can use rewrite a portion of Node.js’s bindings to use our safe API. APIs like the Document Object Model (DOM), a representation While we focus on (V8-based) JavaScript runtime systems, of a web page, to modify the page and content layout. Binding JavaScript is not special: other scripting languages have es- code makes these modifications possible: Blink developers use sentially identical architectures and face essentially identical the V8 engine API to extend the JavaScript application code’s challenges; it would be remarkable if these languages did not environment with such new functionality.
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]
  • On the Incoherencies in Web Browser Access Control Policies
    On the Incoherencies in Web Browser Access Control Policies Kapil Singh∗, Alexander Moshchuk†, Helen J. Wang† and Wenke Lee∗ ∗Georgia Institute of Technology, Atlanta, GA Email: {ksingh, wenke}@cc.gatech.edu †Microsoft Research, Redmond, WA Email: {alexmos, helenw}@microsoft.com Abstract—Web browsers’ access control policies have evolved Inconsistent principal labeling. Today’s browsers do piecemeal in an ad-hoc fashion with the introduction of new not have the same principal definition for all browser re- browser features. This has resulted in numerous incoherencies. sources (which include the Document Object Model (DOM), In this paper, we analyze three major access control flaws in today’s browsers: (1) principal labeling is different for different network, cookies, other persistent state, and display). For resources, raising problems when resources interplay, (2) run- example, for the DOM (memory) resource, a principal is time changes to principal identities are handled inconsistently, labeled by the origin defined in the same origin policy and (3) browsers mismanage resources belonging to the user (SOP) in the form of <protocol, domain, port> [4]; but principal. We show that such mishandling of principals leads for the cookie resource, a principal is labeled by <domain, to many access control incoherencies, presenting hurdles for > web developers to construct secure web applications. path . Different principal definitions for two resources are A unique contribution of this paper is to identify the com- benign as long as the two resources do not interplay with patibility cost of removing these unsafe browser features. To do each other. However, when they do, incoherencies arise. For this, we have built WebAnalyzer, a crawler-based framework example, when cookies became accessible through DOM’s for measuring real-world usage of browser features, and used “document” object, DOM’s access control policy, namely the it to study the top 100,000 popular web sites ranked by Alexa.
    [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]
  • Bounds Checking on GPU
    Noname manuscript No. (will be inserted by the editor) Bounds Checking on GPU Troels Henriksen Received: date / Accepted: date Abstract We present a simple compilation strategy for safety-checking array indexing in high-level languages on GPUs. Our technique does not depend on hardware support for abnormal termination, and is designed to be efficient in the non-failing case. We rely on certain properties of array languages, namely the absence of arbitrary cross-thread communication, to ensure well-defined execution in the presence of failures. We have implemented our technique in the compiler for the functional array language Futhark, and an empirical eval- uation on 19 benchmarks shows that the geometric mean overhead of checking array indexes is respectively 4% and 6% on two different GPUs. Keywords GPU · functional programming · compilers 1 Introduction Programming languages can be divided roughly into two categories: unsafe languages, where programming errors can lead to unpredictable results at run- time; and safe languages, where all risky operations are guarded by run-time checks. Consider array indexing, where an invalid index will lead an unsafe lan- guage to read from an invalid memory address. At best, the operating system will stop the program, but at worst, the program will silently produce invalid results. A safe language will perform bounds checking to verify that the array index is within the bounds of the array, and if not, signal that something is amiss. Some languages perform an abnormal termination of the program and print an error message pointing to the offending program statement. Other languages throw an exception, allowing the problem to be handled by the pro- gram itself.
    [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]
  • Using Replicated Execution for a More Secure and Reliable Web Browser
    Using Replicated Execution for a More Secure and Reliable Web Browser Hui Xue Nathan Dautenhahn Samuel T. King University of Illinois at Urbana Champaign huixue2, dautenh1, kingst @uiuc.edu { } Abstract Unfortunately, hackers actively exploit these vulnerabil- ities as indicated in reports from the University of Wash- Modern web browsers are complex. They provide a ington [46], Microsoft [61], and Google [49, 48]. high-performance and rich computational environment Both industry and academia have improved the se- for web-based applications, but they are prone to nu- curity and reliability of web browsers. Current com- merous types of security vulnerabilities that attackers modity browsers make large strides towards improving actively exploit. However, because major browser plat- the security and reliability of plugins by using sandbox- forms differ in their implementations they rarely exhibit ing techniques to isolate plugins from the rest of the the same vulnerabilities. browser [62, 33]. However, these browsers still scatter In this paper we present Cocktail, a system that uses security logic throughout millions of lines of code, leav- three different off-the-shelf web browsers in parallel to ing these systems susceptible to browser-based attacks. provide replicated execution for withstanding browser- Current research efforts, like Tahoma [32], the OP web based attacks and improving browser reliability. Cock- browser [36], the Gazelle web browser [59], and the Illi- tail mirrors inputs to each replica and votes on browser nois Browser Operating System [58] all propose build- states and outputs to detect potential attacks, while con- ing new web browsers to improve security. Although tinuing to run.
    [Show full text]
  • HTTP Cookie - Wikipedia, the Free Encyclopedia 14/05/2014
    HTTP cookie - Wikipedia, the free encyclopedia 14/05/2014 Create account Log in Article Talk Read Edit View history Search HTTP cookie From Wikipedia, the free encyclopedia Navigation A cookie, also known as an HTTP cookie, web cookie, or browser HTTP Main page cookie, is a small piece of data sent from a website and stored in a Persistence · Compression · HTTPS · Contents user's web browser while the user is browsing that website. Every time Request methods Featured content the user loads the website, the browser sends the cookie back to the OPTIONS · GET · HEAD · POST · PUT · Current events server to notify the website of the user's previous activity.[1] Cookies DELETE · TRACE · CONNECT · PATCH · Random article Donate to Wikipedia were designed to be a reliable mechanism for websites to remember Header fields Wikimedia Shop stateful information (such as items in a shopping cart) or to record the Cookie · ETag · Location · HTTP referer · DNT user's browsing activity (including clicking particular buttons, logging in, · X-Forwarded-For · Interaction or recording which pages were visited by the user as far back as months Status codes or years ago). 301 Moved Permanently · 302 Found · Help 303 See Other · 403 Forbidden · About Wikipedia Although cookies cannot carry viruses, and cannot install malware on 404 Not Found · [2] Community portal the host computer, tracking cookies and especially third-party v · t · e · Recent changes tracking cookies are commonly used as ways to compile long-term Contact page records of individuals' browsing histories—a potential privacy concern that prompted European[3] and U.S.
    [Show full text]
  • Lime Rock Gazette
    L 1M E R 0 C K GAZETTE. DEVOTED TO COMMERCE, AGRICULTURE, ART, SCIENCE, MORALITY AND GENERAL INTELLIGENCE. PUBLISHED WEEKLY, BY RICHARDSON & PORTER. Tpiihs, $1,50 in Advance, $1.75 in six monllis $2.00 afleiv-Adverliseinenls inserted al Hie ciisloniarv prices VOL J- LAST—TIIOIIASTOV, TlllltSO AV 1IOILVIA«L O< TOK I it 15. 1840 AO. »». i.j_ - xi u f c i . b.w rjw vjwcyxayztt i TIlC Relllllied Pastor. *,o,n v*cw> nn,l 0,1 *Gc morning of the 'themselves together for family worship.— from nine o’clock in the morning to three 'Aint I a man now. Miss Tabitha, I ’d only, however, who knew the former level- twenty-second of the same month he look- Ho was told that twenty missionaries might I in the nOcrnoon; and from live to nine in like to know ,’ said Jotliam , rising with ness o f the spot. Ct will be recollected By many ol otn renders, that (,d ,|p0„ ,bc s|,((1.es of England—on the find employment there. the eveninu. There were twelve hundred spirit and putting his hat on his head, ‘ I f The Lieutenant, who had c ritic a lly the Kcv. Mr. Vomroy, Tastor ot the livst ( j following day ho landed. He wished to; Mr. l’omroy enumerated the places of | persons composing the convention, about I aint a man now. and a whole hog o f a watched the manoeuvring of the men, grognltonnl Church ol Bangor, lelt his people see ns much of the land of our fathers as interest ho visited in the Holy Land.— nine hundred of whom were clergymen, one too, I think it darned strange.’ congratulated the Orderly on the perfec- sonic sixteen months Since, for an European possible— a land that should lie dear to ! Sidon, Sarepta, Tyre.
    [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]
  • The Multi-Principal OS Construction of the Gazelle Web Browser
    The Multi-Principal OS Construction of the Gazelle Web Browser Helen J. Wang, Chris Grier, Alex Moshchuk, Sam King, Piali Choudhury, Herman Venter Browser as an application platform • Single stop for many computing needs – banking, shopping, office tasks, social networks, entertainment • Static document browsing rich programs – obtained from mutually distrusting origins – same-origin policy: a browser is a multi-principal platform where web sites are principals • Browser = prime target of today’s attackers Your valuables are online! • Existing browser security mentality: – valuables on local machine – protect local machine from the web Browser OS • This work’s mentality: – valuables online – must also protect web site principals from one another Browser OS Browser design requires OS thinking • Cross-principal protection is an essential function of an operating system • Fundamental flaw with existing browser designs: – OS logic is intermingled with application-specific content processing – consequences: HTML • unreliable cross-principal protection JS engine parsing • many vulnerabilities DOM same-origin rendering protection Persistent network state access browser Gazelle • An OS exclusively manages: HTML JS engine – protection across principals parsing DOM – resource allocation same-origin – resource access control rendering protection Persistent network state access • Our approach for designing Gazelle: Browser kernel – take all OS functionality out of content processing logic – put it into a small, simple browser kernel Gazelle • Build
    [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]