I intend to remove nsILoadInfo::LOAD_CLASSIFY_URI[1] in Firefox 68. If a
channel will be classified by the URL classifier is based on the
information in the channel after landing Bug 1522412
<https://bugzilla.mozilla.org/show_bug.cgi?id=1522412>.


## Introduction

The URL classifier provides services for phishing protection, flash
blocking, and anti-tracking features to identify channels to block.

Channels need to opt in themselves so they can be classified by the URL
classifier.

In the past, we aimed to ensure that all the channels that need to be
classified are properly configured[2] by manually reviewing each of them,
but that is a huge list[3]. There are channels that haven't been reviewed,
and while at the same time, we added new unclassified channels to the code
base. Those unclassified channels may become loopholes that attackers can
exploit[4] to bypass our protection.

# Proposal

We propose to move from a model where URL classification is opt-in to a
model where it is enforced by default unless a channel opts out or is
deemed to be a critical channel based on simple heuristics. By doing so, we
eliminate the URL classifier bypassing loopholes once and for all.

## How it works

The opt-in model was based on the flag nsILoadInfo::LOAD_CLASSIFY_URI. This
flag is now removed and replaced with a heuristic which exempts channels
from classification.

The idea of the heuristic is:

   1.

   Channels created by non-privileged code should be classified.
   2.

   Top-level document’s channels, if loaded by privileged code (system
   principal), should be classified.
   3.

   Any other channel, created by privileged code, is considered safe.


This is how it looks like in the code


nsCOMPtr<nsILoadInfo> loadInfo = aChannel->LoadInfo();

nsContentPolicyType type = loadInfo->GetExternalContentPolicyType();

if (nsContentUtils::IsSystemPrincipal(loadInfo->TriggeringPrincipal()) &&

   nsIContentPolicy::TYPE_DOCUMENT != type) {

   return false;  // Should NOT classify

}

## Risk

A bad/hacked/corrupted safebrowsing database, plus a mistakenly classified
critical channel (this may result from a bug in the exemption rules or
incorrect information being passed into) can cause serious problems. For
example, if the updater channel is classified and blocked by the Safe
Browsing, Firefox can't update itself, and there is no way to recover from
that.

We want to be extremely careful about such scenarios, so to ensure critical
channels are never classified, we have included additional safeguards to
exempt channels from classification prior to applying the exemption rules.

Two safeguards have been added:

1. ServiceRequest, introduced in Bug 1325501
<https://bugzilla.mozilla.org/show_bug.cgi?id=1325501> to ensure channels
that fetch update use conservative TLS setting

2. nsILoadInfo::LOAD_BYPASS_URL_CLASSIFIER, will be added after Bug 1522412
has landed. Critical channels not created via XMLHttpRequest can use this
flag to enforce bypassing classification.

## For module owners

For module owners, if there are any "critical channels" in your component,
we might want to ensure they are not classified by using the method
mentioned above (this is just to add an extra safeguard, without this,
critical channels will still bypass URL classification as long as
everything works as expected).


Here are some criteria to determine if a channel is "critical":

- channels related to an update

- channels may cause security issues if blocked

- channels may prevent the browser to launch if blocked

- channels break basic functionality if blocked

If there is, and it hasn’t been replaced with ServiceRequest, please feel
free to let me know, we can replace it with ServiceRequest or include
nsILoadInfo::LOAD_BYPASS_URL_CLASSIFIER.

Note that right now, any use of the fetch API does not bypass the URL
classifier. If this is a problem, let’s discuss it and find a good way to
support it.

Tracking bugs: bug 1442496
<https://bugzilla.mozilla.org/show_bug.cgi?id=1442496>

## Follow Up

This is not the end for strengthening protection in the URL classifier. We
will continue to work on:

1. Finding channels that should force bypassing the URL classifier check,
as described in ##Risk, to ensure critical channels are never classified. (bug
1442496 <https://bugzilla.mozilla.org/show_bug.cgi?id=1442496>)

2. Adding test cases to cover more loading channel scenarios. It is very
important to make sure all the channels work as expected because as long as
there is a loophole, attackers can use that to bypass our protection. (bug
1532961 <https://bugzilla.mozilla.org/show_bug.cgi?id=1532691>)

3. Fixing bugs that we don't use correct origin for the third-party check.
Even if the rule applies to all the channels correctly, classification may
still be skipped due to a bug in the third-party check. (bug 1437626
<https://bugzilla.mozilla.org/show_bug.cgi?id=1437626>, bug 1456486
<https://bugzilla.mozilla.org/show_bug.cgi?id=1456486>, bug 1408410
<https://bugzilla.mozilla.org/show_bug.cgi?id=1408410>, bug 1231543
<https://bugzilla.mozilla.org/show_bug.cgi?id=1231543>)

## Tracking bugs

https://bugzilla.mozilla.org/show_bug.cgi?id=1522412

## Platform coverage

All

## Estimated or target release

68


Let me know if there is any question or suggestion, Thanks


Dimi


[1]
https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/netwerk/base/nsIChannel.idl#255

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1207775

[3]
https://docs.google.com/spreadsheets/d/1A3pwchORIIcSrIt4u6mQehvbjsPWks51m2A_scYqCKc/edit?usp=sharing
<https://docs.google.com/spreadsheets/d/1A3pwchORIIcSrIt4u6mQehvbjsPWks51m2A_scYqCKc/edit#gid=0>

[4]
https://wholeftopenthecookiejar.eu/data/browsers/firefox/62/tracking_protection


<https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/netwerk/base/nsIChannel.idl#255>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to