{"id":156,"date":"2020-08-05T03:53:35","date_gmt":"2020-08-05T10:53:35","guid":{"rendered":"https:\/\/blog.mozilla.org\/attack-and-defense\/?p=156"},"modified":"2020-08-05T03:53:35","modified_gmt":"2020-08-05T10:53:35","slug":"understanding-web-security-checks-in-firefox-part-2","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/attack-and-defense\/2020\/08\/05\/understanding-web-security-checks-in-firefox-part-2\/","title":{"rendered":"Understanding Web Security Checks in Firefox (Part 2)"},"content":{"rendered":"

 <\/p>\n

This is the second and final part of a blog post series that explains how Firefox implements Web Security fundamentals, like the Same-Origin Policy<\/a> and Content-Security-Policy<\/a>. While the first post<\/a> explained Firefox security terminology and theoretical foundations, this second post covers how to log internal security information to the console in a human readable format. Ultimately, we hope to inspire new security research in the area of web security checks and to empower participants in our bug bounty program to do better, deeper work.<\/p>\n

Generally, we encourage everyone to do their security testing in Firefox Nightly<\/a>. That being said, the logging mechanisms described in this post, work in all versions of Firefox \u2013 from self-build<\/a>, to versions of Nightly<\/a>, Beta<\/a>, Developer Edition<\/a>, Release<\/a> and ESR<\/a> you may have installed locally already.<\/p>\n

Logging Security Internals to the console<\/h2>\n

All Firefox versions ship with a logging framework<\/a> that allows one to inspect Gecko’s<\/a> (Firefox\u2019 rendering engine) internals. In general, logging Firefox internals is as easy as defining an environment variable called MOZ_LOG<\/code>. When testing on mobile, the document Configuring GeckoView<\/a> describes and guides you through defining environment variables in GeckoView\u2019s runtime environment. For printing web security checks we simply have to enable the logger named \"CSMLog\"<\/a><\/code>. You can also set MOZ_LOG_FILE<\/a><\/code> if you want to write into a log file.<\/p>\n

Defining MOZ_LOG=\"CSMLog:5\"<\/code> as an environment variable will print all security checks to the console, where the digit 5 indicates the highest log-level (Verbose<\/a>) which naturally prints a lot of debugging information but in turn allows debugging program flow.<\/p>\n

Understanding Security Load Information<\/h2>\n

Here is a log example when defining CSMLog:5<\/code> and opening https:\/\/example.com<\/a> in a new tab. For the sake of simplicity we removed line prefixes like [Parent 361301: Main Thread]<\/code> which provide additional information around process type (parent\/child), process id (pid) and the thread in which the logging occurred. These prefixes can also be omitted<\/a> by appending \",raw\"<\/code> to the MOZ_LOG<\/code> value.<\/p>\n\n\n\n
\n
V\/CSMLog doContentSecurityCheck:\r\nV\/CSMLog \u00a0 - channelURI<\/b>: https:\/\/example.com\/\r\nV\/CSMLog \u00a0 - httpMethod<\/b>: GET\r\nD\/CSMLog \u00a0 - loadingPrincipal<\/b>: nullptr\r\nD\/CSMLog \u00a0 - triggeringPrincipal<\/b>: SystemPrincipal\r\nD\/CSMLog \u00a0 - principalToInherit<\/b>: NullPrincipal\r\nV\/CSMLog \u00a0 - redirectChain<\/b>:\r\nV\/CSMLog \u00a0 - internalContentPolicyType<\/b>: TYPE_DOCUMENT\r\nV\/CSMLog \u00a0 - externalContentPolicyType<\/b>: TYPE_DOCUMENT\r\nV\/CSMLog \u00a0 - upgradeInsecureRequests<\/b>: false\r\nV\/CSMLog \u00a0 - initialSecurityChecksDone<\/b>: false\r\nV\/CSMLog \u00a0 - allowDeprecatedSystemRequests<\/b>: false\r\nD\/CSMLog \u00a0 - CSP<\/b>:\r\nV\/CSMLog \u00a0 - securityFlags<\/b>:\r\nV\/CSMLog \u00a0\u00a0\u00a0 - SEC_ALLOW_CROSS_ORIGIN_SEC_CONTEXT_IS_NULL<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 1: Firefox Security Log (CSMLog:5<\/code>) when opening https:\/\/example.com<\/a> in a new tab.<\/p>\n
As of Firefox 80, every logged Web Security Check appears in the format from Listing 1. At the beginning of each line you see CSMLog<\/code> which is the name of our logger and D\/V are short for Debug\/Verbose, which indicate the log level (4 is Debug, 5 is Verbose). The output format after this prefix is valid YAML and should be easy to parse automatically. These blocks of attributes are surrounded by #DebugDoContentSecurityCheck Begin <\/b>and End<\/b> for each and every outgoing request, which corresponds to the function name doContentSecurityCheck<\/a> in the SecurityManager. This function contains all available information of the current security context, before a request is sent over the wire. Naturally, this does not include the security checks that can only happen after the response is received (e.g., X-Frame-Options<\/a>, X-Content-Type-Options<\/a>, etc.).<\/p>\n
Most of the information below is readily available through the nsILoadinfo<\/a> object that corresponds to the request:<\/p>\n
channelURI<\/b><\/code>
\nThe URI about to be loaded and evaluated within this security check.<\/p>\n
httpMethod<\/b><\/code> (optional)
\nIndicates the HTTP request methods<\/a> like e.g., GET, HEAD or POST and hence is only available for HTTP requests.<\/p>\n
loadingPrincipal<\/b><\/code>
\nIn general, the loadingPrincipa<\/a>l reflects the security context (the Principal<\/a>) where the result of this resource load will be used. In case of an image load for example, this would be the security context (ContentPrincipal) of the loading document. Since this is a top-level load, the loadingPrincipal is null because the result of the load is a new document.<\/p>\n
triggeringPrincipal<\/b><\/code>
\nThe security context (reflected through a Principal<\/a>) which triggered this load. For almost all subresource loads, the triggeringPrincipal<\/a> and the loadingPrincipal<\/a> are identical. Since the user entered https:\/\/example.com<\/a> in the URL-Bar, it is a user-triggered action which in Firefox is equivalent to a load triggered by the System and hence is using a SystemPrincipal as the triggeringPrincipal. For the sake of completeness, imagine a cross-origin CSS file which loads a background image. Then the triggeringPrincipal for that image load would be the security context (ContentPrincipal) of the CSS, but the loadingPrincipal would be the security context (ContentPrincipal) of the document where the image load will be used.<\/p>\n
principalToInherit<\/b><\/code>
\nThe principalToInherit<\/a> is only relevant to loads of type document (top-level loads) and type subdocument (e.g., iframe loads) and indicates the principal that will be inherited, e.g., when loading a data URI.<\/p>\n
redirectChain<\/b><\/code>
\n<\/b>In case a load encounters a redirect (e.g. a 302 server side redirect<\/a>) then the RedirectChain contains all Principals (serialized into origin URI strings) of all the redirects this load went through.<\/p>\n
internalContentPolicyType\/externalContentPolicyType<\/b><\/code>
\n<\/b>Indicates the (internal and external) content policy type of the load. In that particular case, the load was of TYPE_DOCUMENT<\/a>. The reason there is an internal and an external type is because Firefox needs to enforce different security mappings. For example, the separation of different script types allows precise mapping to e.g. CSP directives.<\/p>\n
upgradeInsecureRequests<\/b><\/code>
\n<\/b>Indicates whether the request needs to be upgraded from HTTP to HTTPS before it hits the network due to the CSP directive upgrade-insecure-requests<\/a>.<\/p>\n
initialSecurityChecksDone<\/b><\/code>
\n<\/b>Whenever the ContentSecurityManager performs security checks the first time for a channel, then this bit gets flipped indicating that initial security checks on that channel have been completed. In turn, this flag causes certain security checks, like e.g. CORS<\/a>, to be bypassed after a redirect.<\/p>\n
allowDeprecatedSystemRequests<\/b><\/code>
\nIn one of our hardening efforts<\/a>, we started to disallow web requests in system privileged contexts, when the triggeringPrincipal is of type SystemPrincipal (see CheckAllowLoadInSystemPrivilegedContext()<\/a><\/code>). However, there are certain system requests where we allow that temporarily, e.g., for OCSP requests<\/a>.<\/p>\n
CSP<\/b><\/code>
\nThe Content Security Policy<\/a> that needs to be enforced for this request. If there is no CSP to enforce, then the value for this field remains empty.<\/p>\n
securityFlags<\/b><\/code>
\nThe securityFlags<\/a> indicate what kind of security checks need to be performed for that channel. For example, whether to enforce the same-origin-policy or whether this load requires CORS<\/a>.<\/p>\n
Analyzing and Finding Security Bugs with Logging<\/h2>\n
Now that we know all the entries in a web security log, let\u2019s dive a little deeper and investigate a historical bug and how it could have been found using the discussed logging capabilities. We will be looking at CVE-2019-17000<\/a>, a limited CSP bypass from October 2019 that we fixed in Firefox 70. A Proof of Concept could look a bit like this:<\/p>\n\n\n\n
\n
<meta<\/span> http-equiv<\/span>=<\/span>\"Content-Security-Policy\"<\/span>\r\n      content<\/span>=<\/span>\"default-src 'self'; object-src data:; img-src 'none';\"<\/span>\/><\/span>\r\n<body><\/span>\r\n  The following object element is allowed.<\/span>\r\n  <object<\/span> data<\/span>=<\/span>'data:text\/html,<\/span><<\/span>p>Object element has an image:<\/span><<\/span>br><\/span>\r\n  <<\/span>img src=\"https:\/\/freddyb.neocities.org\/danger.jpg<\/u><\/span>\"<\/span>\r\n       alt=\"This image should not load\"\/><\/span><<\/span>br><\/span>\r\n   This text is underneath the image.'<\/span>><\/span>\r\n  <\/object><\/span>\r\n<\/body><\/span><\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 2: Document defining a CSP blocking all images and loading an <object> tag with a data: URI.<\/p>\n
The document in Listing 2 comes with a Content-Security-Policy that allows loading object elements which point to a data URL (object-src data:), but denies all image loads (img-src ‘none’). A browser needs to perform various security checks to completely load this document: First, we\u2019re loading the top level document in a new tab, which is allowed. Then, we adjust the document\u2019s CSP given the <meta><\/code> element and load the <object><\/code> element according to the CSP (allowed in object-src). Given it\u2019s data URL, the <object<\/code>> element is cross-origin (i.e., loaded using a NullPrincipal<\/a>). Therefore, the inner <img><\/code> element needs to be loaded using a different, unique origin. However, the image load should still be forbidden based on the img-src ‘none’ directive of the parent <\/i>document!<\/p>\n
Let\u2019s take a closer look at just the image request when logging in an unaffected version of Firefox:<\/p>\n\n\n\n
\n
doContentSecurityCheck:\r\n - channelURI<\/b>: https:\/\/freddyb.neocities.org\/danger.jpg\r\n - httpMethod<\/b>: GET\r\n - loadingPrincipal<\/b>: NullPrincipal\r\n - triggeringPrincipal<\/b>: NullPrincipal\r\n - principalToInherit<\/b>: nullptr\r\n - redirectChain<\/b>:\r\n - internalContentPolicyType<\/b>: TYPE_INTERNAL_IMAGE\r\n - externalContentPolicyType<\/b>: TYPE_IMAGE\r\n - upgradeInsecureRequests<\/b>: true\r\n - initialSecurityChecksDone<\/b>: false\r\n - allowDeprecatedSystemRequests<\/b>: false\r\n - CSP<\/b>:\r\n    - default-src 'self'; object-src data:; img-src 'none'\r\n - securityFlags<\/b>:\r\n   - SEC_ALLOW_CROSS_ORIGIN_INHERITS_SEC_CONTEXT\r\n   - SEC_ALLOW_CHROME<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 3: The request is loaded into a new Security Context (using a NullPrincipal), but the CSP is inherited.<\/p>\n
But here is what it looked like in the vulnerable Firefox version 69:<\/p>\n\n\n\n
\"Screenshot<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 4: Screenshot of the page opened in a vulnerable version of Firefox 69. Photo by Mikael Seegen<\/a>.<\/p>\n
So, what happened here – why did the image load?<\/p>\n
We can investigate the erroneous behavior using our logging. Here\u2019s a listing for the very same image request from Firefox 69:<\/p>\n\n\n\n
\n
doContentSecurityCheck:\r\n - channelURI<\/b>: https:\/\/freddyb.neocities.org\/danger.jpg\r\n - httpMethod<\/b>: GET\r\n - loadingPrincipal<\/b>: NullPrincipal\r\n - triggeringPrincipal<\/b>: NullPrincipal\r\n - principalToInherit<\/b>: nullptr\r\n - redirectChain<\/b>:\r\n - internalContentPolicyType<\/b>: TYPE_INTERNAL_IMAGE\r\n - externalContentPolicyType<\/b>: TYPE_IMAGE\r\n - upgradeInsecureRequests<\/b>: true\r\n - initialSecurityChecksDone<\/b>: false\r\n - CSP<\/b>:\r\n - securityFlags<\/b>:\r\n   - SEC_ALLOW_CROSS_ORIGIN_INHERITS_SEC_CONTEXT\r\n   - SEC_ALLOW_CHROME<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 5: The very same request as in Listing 3, but logged using Firefox 69.<\/p>\n
Can you spot the difference?<\/p>\n
In the vulnerable case (Listing 5), the security check was not aware of an effective CSP. Even though the <object><\/code>\u2019s content does not inherit the origin of the page (it\u2019s loaded with a data: URL after all) – it should inherit the CSP of the document.<\/p>\n
An attacker could use a CSP bypass like this and target users on web pages that are susceptible to XSS or content injections. However, this bug was identified in a previous version of Firefox and has been fixed for all of our users since.<\/p>\n
To summarize, using the provided logging mechanism allows us to effectively detect security problems by visual inspection. One could take it even further and generate graph structures for nested page loads. Using these graphs to observe where the security context (e.g., the CSP) changes can be a very powerful tool for runtime security analysis.<\/p>\n
Going Forward<\/h2>\n
We have explained how to enable logging mechanisms within Firefox which allows for visual inspection of every web security check performed. We would like to point out that finding security flaws might be eligible for a bug bounty<\/a>. Finally, we hope the provided instructions foster security research and in turn allow researchers, bug bounty hunters and generally everyone interested in web security to contribute to Mozilla and the Security of the Open Web.<\/p>\n","protected":false},"excerpt":{"rendered":"
  This is the second and final part of a blog post series that explains how Firefox implements Web Security fundamentals, like the Same-Origin Policy and Content-Security-Policy. While the first … Read more<\/a><\/p>\n","protected":false},"author":405,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[449525],"tags":[],"coauthors":[280726,280776],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts\/156"}],"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\/405"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/comments?post=156"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts\/156\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/media?parent=156"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/categories?post=156"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/tags?post=156"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/coauthors?post=156"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}