{"id":143,"date":"2020-06-10T00:40:25","date_gmt":"2020-06-10T07:40:25","guid":{"rendered":"https:\/\/blog.mozilla.org\/attack-and-defense\/?p=143"},"modified":"2020-06-16T07:24:05","modified_gmt":"2020-06-16T14:24:05","slug":"understanding-web-security-checks-in-firefox-part-1","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/attack-and-defense\/2020\/06\/10\/understanding-web-security-checks-in-firefox-part-1\/","title":{"rendered":"Understanding Web Security Checks in Firefox (Part 1)"},"content":{"rendered":"
<\/div>\n

This is the first part of a blog post series that will allow you to understand how Firefox implements Web Security fundamentals, like the <\/span>Same-Origin Policy<\/span><\/a>. This first post of the series covers the architectural design, terminology, and introduces core interfaces that our implementation of the Same-Origin Policy relies on: <\/span>nsIPrincipal<\/span><\/a> and <\/span>nsILoadinfo<\/span><\/a>.<\/span><\/p>\n

 <\/p>\n

Background on Web Security Checks<\/span><\/h2>\n

Whenever Firefox on Desktop or Android fetches a resource from the web, Firefox performs a variety of web security checks to ensure web pages can not harm end users by performing malicious actions. For example, when loading a sub-resource from a web page, Firefox ensures that its URL is not targeting the local file system with a file:\/\/ scheme. Before diving deeper into Firefox Security internals we have to introduce the term <\/span>Security Principal<\/span><\/i>, which is key for understanding how Firefox enforces web security checks.<\/span><\/p>\n

 <\/p>\n

The Security Contexts in Firefox<\/span><\/h2>\n

All web related security checks within Firefox are evaluated based on the security concept of a Principal. Briefly, a Principal reflects a security context. E.g., when visiting https:\/\/example.com a <\/span>Content-Principal<\/span><\/i> of https:\/\/example.com reflects the security context of that page. More precisely, Firefox captures the security context using one of the following four types of Principals:<\/span><\/p>\n

    \n
  1. Content-Principal<\/strong>
    \n<\/span>The <\/span>    HTML specification<\/span><\/a> associates an origin with a Document or a Worker. That origin information is encapsulated within a Content-Principal and reflects the security context for all web-hosted resources. E.g. when loading the web page https:\/\/example.com, then Firefox creates a Content-Principal encapsulating origin information of https:\/\/example.com which then reflects the security context of that web page.<\/span><\/span><\/li>\n
  2. Null-Principal<\/strong>
    \nIn special cases, websites are never same-origin with anything else. Two such cases are iframes with a sandbox attribute and documents loaded with a data: URI. The HTML specification calls the origin of those pages an <\/span>    opaque origin<\/span><\/a>. Our implementation uses a\u00a0 <\/span>Null-Principal<\/span><\/i> for reflecting the security context of an opaque origin. In contrast to a Content-Principal which internally maps to the origin of the resource, a Null-Principal uses a custom scheme and host, e.g. moz-nullprincipal:{0bceda9f-…}, where the host is represented as a UUID. So, when loading an iframe with a sandbox attribute Firefox internally generates a Null-Principal to reflect that security context. Please note that a Null-Principal is not equal to any other Principal and also not equal to any other Null-Principal. E.g., a data: URI iframe is not same-origin with another data: URI iframe because both security contexts are mapped through different Null-Principals.<\/span><\/span><\/li>\n
  3. System-Principal<\/strong>
    \nThe System-Principal<\/i> is used for the browser\u2019s user interface, commonly referred to as \u201cbrowser chrome\u201d. An example of a page with these extra privileges is \u201cabout:support\u201d. The System-Principal is shared across all privileged resources, and implemented as a Singleton. Since browser chrome code does not rely on a URI, the System-Principal internally also does not map to an origin. The System-Principal passes all security checks.<\/span><\/span><\/li>\n
  4. Expanded-Principal<\/strong>
    \nA browser extension is more privileged than normal web pages, but must also be able to assume the security context of a website. Hence, an Expanded-Principal<\/i> is best understood as a list of principals<\/i> to match the security needs for     Content Scripts<\/a> in Firefox Extensions. When creating an Expanded-Principal Firefox takes multiple existing Principals, storing them in an allowlist. The security checks on the Expanded-Principal are then implemented as a loop through this allowlist of principals.<\/span><\/li>\n<\/ol>\n


    \nThe Loading Life-Cycle in Firefox<\/span><\/h2>\n

    Whenever a page performs a request, Firefox internally creates an <\/span>nsIChannel<\/span><\/a> object (which acts as the transport algorithm, such as HTTP(S), WebSocket etc.). Amongst other things an <\/span>nsIChannel<\/span><\/a> consists of an <\/span>nsIURI<\/span><\/a>, which is the URI to be loaded, and an <\/span>nsILoadInfo<\/span><\/a> object. The latter holds all security relevant attributes including security flags indicating what security checks need to be performed and the aforementioned Principal. It is worth emphasizing that the loadinfo – including the Principal – gets frozen at creation time and remains attached to the <\/span>nsIChannel<\/span><\/a> instance even if the load encounters any kind of redirect, e.g. a 302. The last step before Firefox starts loading bits over the network is performing all relevant security checks within the function <\/span>asyncOpen()<\/span><\/a> of any <\/span>nsIChannel<\/span><\/a> implementation.<\/span><\/p>\n

     <\/p>\n

    Enforcing Web Security Checks in Firefox<\/span><\/h2>\n

    Firefox enforces all <\/span>web security checks by default<\/span><\/a> by consulting a centralized <\/span>ContentSecurityManager<\/span><\/a>. As mentioned, every <\/span>asyncOpen()<\/span><\/a> implementation internally calls <\/span>doContentSecurityCheck()<\/span><\/a> which then performs all relevant web security checks e.g., <\/span>Same-Origin Policy<\/span><\/a>, <\/span>Content Security Policy<\/span><\/a>, <\/span>Mixed Content Blocking<\/span><\/a>.<\/span><\/p>\n

    To perform all relevant security checks Firefox has to take <\/span>multiple<\/span><\/i> principals into consideration, most notably the <\/span>loadingPrincipal<\/span><\/a> and the <\/span>triggeringPrincipal<\/span><\/a>.\u00a0 The <\/span>loadingPrincipal<\/span> is the principal of the document where the result of the load will be used. The <\/span>triggeringPrincipal<\/span> is the security context that actually triggered the URL to load. In most cases the loadingPrincipal and the triggeringPrincipal are identical. One example where loadingPrincipal and triggeringPrincipal differ is a cross-origin CSS file requesting an image. In that case the loadingPrincipal is a Content-Principal of the page where the image will be loaded into, and the triggeringPrincipal is a cross-origin Content-Principal of the CSS file.<\/span><\/p>\n

    Taking the loadingPrincipal and the triggeringPrincipal into account, Firefox performs security checks in an <\/span>asymmetric <\/span><\/i>fashion. More precisely, a Principal may have access to another Principal but not necessarily vice versa. This is also why security checks are not implemented as equality checks. Instead, Firefox relies on the concept of \u2018subsumes\u2019. In more detail, Firefox uses <\/span>aPrincipal->Subsumes(aOtherPrincipal)<\/span>, to see if<\/span> aPrincipal <\/span>has access to <\/span>aOtherPrincipal<\/span>.<\/span><\/p>\n

    The aforementioned System-Principal subsumes all other principals, but a Null-Principal basically fails all security checks and is only same-origin with itself. A Content-Principal is same- origin to another Content-Principal if <\/span>scheme, host and port<\/span><\/a> are the same for both. If so, Firefox allows the load.<\/span><\/p>\n

     <\/p>\n

    An illustrative example of a Web Security Check<\/span><\/h2>\n

    Let\u2019s assume you visit the web page https:\/\/example.com and that page then loads library.js from https:\/\/foo.com. For the JavaScript load to occur Firefox will internally create an nsIChannel with the URL of https:\/\/foo.com\/library.js.<\/span><\/p>\n

    \"\"<\/p>\n

    As illustrated, the loadinfo for that load would include the following information: A triggeringPrincipal of https:\/\/example.com, because the page https:\/\/example.com actually triggered the load to occur. The loadingPrincipal would also be set to https:\/\/example.com because the result of the JS load will be used in the security context of https:\/\/example.com. The ContentPolicy type will be set to TYPE_SCRIPT which e.g., allows mapping of content type to Content Security Policy directives (in this particular case to the script-src directive). Finally, the security flags would be set to ALLOW_CROSS_ORIGIN because JavaScript files are allowed to be loaded cross origin.<\/span><\/p>\n

    While in that particular case Firefox would allow the cross origin load, it would still ensure that the web page is not trying to access the local file system of the end user.<\/span><\/p>\n

     <\/p>\n

    Going Forward<\/span><\/h2>\n

    In this blog post, we explained how Firefox enforces Web Security checks, like the Same-Origin Policy. In the next post we\u2019ll explain how to enable available logging mechanisms which allow for visual inspection of every web security check performed. We hope that this introduction will aid security research as well as bug bounty hunting and sparks your curiosity to go further, even contribute to Mozilla and the Open Web.<\/span><\/p>\n

     <\/p>\n","protected":false},"excerpt":{"rendered":"

    This is the first part of a blog post series that will allow you to understand how Firefox implements Web Security fundamentals, like the Same-Origin Policy. This first post of … Read more<\/a><\/p>\n","protected":false},"author":960,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[449525],"tags":[],"coauthors":[280776,280726],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts\/143"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/users\/960"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/comments?post=143"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts\/143\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/media?parent=143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/categories?post=143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/tags?post=143"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/coauthors?post=143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}