Web Browser

An application program that provides a way to look at and interact with data that's available on the WWW

  • Web browsers are different from most other programs because they're meant to take in resources from remote and untrusted areas of the Web and render or run them on your local machine

OS vs Web browsers

  • Operating systems have system calls to interact with trusted code, the web browsers use the Document Object Model (DOM) to allow subjects to interact with different web content

  • Operating systems manage storage on the disk (disk-based storage), and allow or disallow access based on certain policies, the web browser has local storage in cookies, and allows or disallows access to cookies based on certain policies

  • Operating systems have isolation based on processes while web browsers have isolation based on frames

  • Operating systems' principals (An entity that can be authenticated by a computer system or network) are users and you mediate actions based on that while web browsers' principles are where your content comes from (origins) and you mediate actions based on that

Google (Chromium)

An application program that provides a way to look at and interact with data that's available on the WWW

  • Google uses Chromium, which is the source code for what became the Chrome browser and was created by Google

Chromium: Security Architecture

Chromium sandboxes the render engines and plugins so that when one has issues, these issues don't bleed over to the rendering of other sites on different tabs

 Chromium Security Architecture

Chromium: Threat Model and Leverage of OS Isolation

The sandboxing done in Chromium leverages four OS mechanisms, on Windows:

  • A token with restricted rights
  • The Windows job object
  • The Windows desktop object
  • Integrity levels

 Chromium Sandboxing

Chromium: Components of Browser Security Policy

  • While sandboxing and access control are the mechanisms that keep the browser secure, they're only as strong as the security policy they protect

  • A browser also needs to check how a frame can interact with a principle like storage through cookies

  • Sometimes, the frame should be able to read or write cookies from the given site and sometimes it should not
      * In order to do this, we have the ReadCookie and WriteCookie checks
      * Imagine you have a frame F and a site S
        * We say that ReadCookie (F, S) is true if the Frame F is allowed to read cookies from Site S
        * We say that WriteCookie (F, S) is true if we're allowed to write cookies for Site S from Frame F

  • Frame-frame relationships
      * Isolation can be done on the frame level, as well as on a process level in an OS
      * Just like how processes sometimes want to interact with each other on an OS, we sometimes have frames that want to interact with each other on the browser, which can do in a few different ways:

CanScript

  • Imagine you have two frames: Frame A and Frame B
      * We can say CanScript (Frame A and Frame B) is true if the policy allows Frame A to execute a script that manipulates arbitrary DOM elements of Frame B

  • We need to be very careful with the CanScript relationship, since running arbitrary scripts on other frames can lead to the compromise of accounts, unwanted actions, and other undesirable outcomes

CanNavigate
  • Imagine you have two frames: Frame A and Frame B
      * We say CanNavigate (Frame A and Frame B) is true if Frame A is allowed to change the origin of content for Frame B
  • One element of a frame is its origin
      * Some security mechanisms rely on the origin in order to make access control decisions, meaning that being able to change the origin of another frame is something we would want to do only in the rarest of circumstances

Chromium: Good Design Decisions

  • Chromium follows the principle of least privilege, both to sandboxed code and to the code that controls the sandbox (Sandboxes and the code inside them were given minimal privileges to do what they needed to do)
      * Part of the reason for this is because of the assumption that the code that's running in the sandbox is malicious code (besides some early code to set up the sandbox, code that starts executing from the moment the untrusted code arrives should be considered to be malicious)
      * Following this assumption, it's only logical that the principle of least privilege should be used in order to avoid further compromise \n

  • In addition to the privilege of least privilege, the development team of Chromium decided not to reinvent the wheel and instead let the OS apply its security to the objects it controls

  • In addition, it created some application-level objects that have a custom security model, but they didn't extend the OS kernel with a different security model

  • In addition, Chromium attempts to be nimble
      * The sandbox is designed to impose near-zero performance impact but accepts performance penalties for exceptional cases when a sensitive resource needs to be handled in a controlled manner (This is aided by proper use of the OS security mechanisms)

  • Chromium doesn't attempt to achieve security by needlessly emulating
      * Emulations and virtual machines don't inherently provide security by themselves (Instead, Chromium provides sandboxing that doesn't rely on code emulation, translation or patching to provide the security desired)