A while back, I explained how you can use Telerik Fiddler or the Catapult NetLog Viewer to analyze a network logcaptured from Microsoft Edge, Google Chrome, or another Chromium or Electron-based application.
While Fiddler is a native app that runs locally, the Catapult NetLog Viewer is a JavaScript application that runs in your browser. Because NetLogs can contain sensitive data, some users have worried about the privacy of the viewer– what if someday it started leaking sensitive data from logs, either unintentionally or maliciously?
Fortunately, the NetLog Viewer is a self-contained single page application that doesn’t need a network connection to run. You can use it entirely offline, either from a Virtual Machine with no network connection, or from a browser instance configured to override all network requests.
Your first step is to get an copy of the viewer as a file. You can do that by right-clicking this link and choosing “Save Link As”. Save the HTML file somewhere locally, e.g. C:\temp\NetLogView.html on Windows.
If you want to run it from a disconnected VM, simply copy the file into such a VM and you’re good to go.
If, however, you want the convenience of running the viewer from your Internet-connected PC without worrying about leaks, you can run it from a browser instance that won’t make network connections.
After saving the file, open it in a new browser window thusly:
The command line arguments bear some explanation. In reverse order:
The app argument instructs Edge to open the supplied file with a minimal browser UI, as if it were a native app.
The host-rules argument tells the browser instance to direct all network requests to an IP address of 0.0.0.0. On Windows, such requests instantly fail. On Mac/Linux, the null IP points back at your own PC.
The inprivate argument directs the browser to discard all storage after the app exits (since it’s not needed). For Chrome, use --incognito instead.
The user-data-dir instructs the browser to use a temporary browser profile (which prevents the app’s window from being merged into an existing browser process, such that the host-rules argument would’ve been ignored.)
While none of this is strictly necessary (the NetLog Viewer doesn’t leak data), it’s always nice to be able to discard attack surface wherever possible.
I’ve previously gushed about the magic of the File Type Policies component — a mechanism that allows files to be classified by their level of “dangerousness”, such that harmless files (e.g. .txt files) can be downloaded freely, whilst potentially-dangerous files (e.g. .dll files) are subjected to a higher degree of vetting and a more security-conscious user-experience.
File Type Danger Level
Microsoft Edge inherits its file type policies from the upstream Chromium browser; you can view the current contents of the list here, and documentation of its format here. UPDATE: As of 2024, Edge’s JSON has evolved significantly from upstream Chromium, and it treats many types as more dangerous than Chrome does.
Within the list, you’ll see that each type has a danger_level, which is one of three values: DANGEROUS, NOT_DANGEROUS, or ALLOW_ON_USER_GESTURE.
The first two danger levels are simple: NOT_DANGEROUS means Safe to download and open, even if the download was accidental. No additional warnings are necessary.DANGEROUS means Always1 warn the user that this file may harm their computer. Let users continue or discard the file. If [SmartScreen or Safe Browsing] returns a SAFE verdict, still warn the user before saving the file.
The third setting, ALLOW_ON_USER_GESTURE2 is more subtle. Such files are potentially dangerous, but likely harmless if the user is familiar with download site and if the download was intentional. Microsoft Edge will allow such downloads to proceed automatically if two conditions are both met:
User Gesture: There is a user gesture associated with the network request that initiated the download (e.g. the user clicked a link to the download).
Familiar Initiator: There is a recorded prior visit to the referring origin prior to the most recent midnight (i.e. yesterday or earlier). Such a visit implies that the user has at least some history of visiting the site that kicked off the download.
The download will also proceed automatically if the user explicitly initiated a download by using the Save link ascontext menu command or entered directly into the browser’s address bar the download’s URL.
SmartScreen/SafeBrowsing Verdict Overrides
Importantly, if Microsoft Defender SmartScreen (in Edge), or Google Safe Browsing (in Chrome), indicates that the file is known safe, that takes precedent over the ALLOW_ON_USER_GESTURE heuristics.
This override allows the user to avoid spurious/scary warnings, for example, when downloading drivers for their graphics card. Without this override, most users would see a warning because the driver installer .exe is served by their GPU vendor’s website (e.g. ati.com) which is somewhat unlikely to be a domain that passes the Familiar Initiator check. Because SmartScreen reports that the signed ATI drivers are non-malicious, it can return a “Safe” verdict and the download will proceed without warning.
Within Google Chrome, a download lacking a required gesture shows explicit buttons to allow the user to decide whether to proceed with the download or abandon it:
Starting in version 91, Microsoft Edge joined Google Chrome in interrupting downloads that lack the required gesture. However, from Edge 91-94, Microsoft Edge states that the download “was blocked”, although the same options, titled Keep and Delete, are available from the … menu on the download item.
UPDATE: Edge 95+ was updated with an interruption UX more like Chrome’s, in order to better reflect that the user may choose to continue to download the file.
If you visit edge://downloads, you’ll see the same options:
Enterprise Controls
While users are somewhat unlikely to encounter download interruptions for sites they use every day, they might encounter them for legitimate downloads on sites that they use rarely or in sites that hit “Corner Cases” described in a section below.
To help streamline the user-experience for Enterprises, a Group Policy is available.
Enterprises can set a ExemptFileTypeDownloadWarnings policy to specify the filetypes that are allowed to download from specific sites without interruption.
If the SmartScreenForTrustedDownloadsEnabled (or equivalent policy for Chrome) is set to 0 (disabled), and the file download’s URL is Trusted (on Windows, in the Local Machine, Intranet, or Trusted zone) then the download will proceed without interruption (even without a gesture), regardless of danger_level. (Aside: This seems a bit strange, but feels more logical if you pretend that the file type warnings are a part of SmartScreen).
Note: Microsoft Edge’s file type behaviors may (and as of March 2023, does) diverge from the list of types in upstream Chromium, for security and compatibility reasons.
Other Fields in the File Type Policies
You’ll also note that some file types have an auto_open_hint which controls whether the user may configure that type of file to open automatically when the download completes.
File type settings sometimes vary depending on the client OS platform (an .exe is not dangerous on a Mac, while an .applescript is harmless on Windows). The platform attribute of an entry specifies on which OS the danger_level applies.
The max_file_size_to_analyze field controls how big of a file (.zip, .rar, etc) the browser will be willing to unpack to scan it for dangerous content.
Group Policies
DownloadRestrictions is a policy that makes a complicated browser behavior even more complicated. When you set DownloadRestrictions to 1, Edge won’t just interrupt the download, it will block it.
Make matters even more complicated, if you enable DownloadRestrictions and Disable SmartScreen:
…then the file download is blocked silently with no notice — the Download UX does not show, and no warning is emitted to the Developer Tools console.
If you put referrerpolicy="no-referrer"on your download link (or otherwise suppress referrers), the Familiar Initiator check fails.
Prior to v94, if you initiate the download by dynamically creating an <a>element with a download attribute, then click it from JavaScript, the User Gesture check fails.
As of August 2021, Microsoft Outlook Web Access’ email attachment file downloads encounter both of these issues.
Test cases for these conditions can be found here. (Note that you’ll have to have visited webdbg.com yesterday or earlier for the familiarity check to pass).
Surprise: Zones
File download is one of a handful of places where Chromium-based browsers consider Windows security zones.
Beyond the aforementioned impact when the policy SmartScreenForTrustedDownloadsEnabled is set, if you’ve configured a Zone’s setting for Launching applications and unsafe files to Disable using the Windows Internet Control Panel’s Security tab (or the associated Group Policies), Chromium-based browsers will block file downloads from the Zone in question with a terse note: Couldn't download - Blocked.
Update: For version 105, the Chrome team made several significant changes to the file type policies list and behaviors, with the aim of reducing warnings, as seen in this changelist.
-Eric
Appendix: Comparison to other File Type Danger Systems
A Windows Shell API, AssocIsDangerous allows applications to determine whether a given file extension is dangerous according to the system’s registry configuration, which ISVs can extend to describe the danger level of their own file types.
1DANGEROUS level files are still saved without an explicit warning if the user uses the “Save Link As” command on the browser context menu. Entering the URL via the address bar or command line will still show the warning.
2ALLOW_ON_USER_GESTURE_AND_FAMILIAR_INITIATOR would be the accurate name for the setting
Last year, I wrote about how the new Microsoft Edge browser mostly ignores Security Zones (except in very rare circumstances) to configure security and permissions decisions. Instead, in Chromium per-site permissions are controlled by settings and policies expressed using a simple syntax with limited wildcarding support.
Settings Page’s Site Permissions and Group Policy
Internet Explorer offered around 88 URLAction permissions, but the majority (62) of these settings have no equivalent; for instance, there are a dozen that control various features of ActiveX controls, a technology that does not exist in the new Edge.
Unfortunately, there’s no document mapping the old URLActions to the new equivalents (if any) available within the new Edge.
When users open chrome://settings/content/siteDetails?site=https://example.com, they’ll find a long list of configuration switches and lists for various permissions. Users rarely use the Settings Page directly, instead making choices using various widgets and toggles in the Page Info dropdown (which appears when you click the lock) or via various prompts or buttons at the right-edge of the address bar/omnibox.
Enterprises can use Group Policy to provision site lists for individual policies that control the browser’s behavior. To find these policies, simply open the Edge Group Policy documentation and search for ForUrls to find the policies that allow and block behavior based on the loaded site’s URL. I recently wrote a post about Chromium’s URL Filter syntax, which doesn’t always work like one might expect. Most of the relevant settings are listed within the Group Policy for Content Settings.
There are also a number of policies whose names contain Default that control the default behavior for a given setting.
Here’s a list of Site Settings with information about their policies and behavior:
Ads You may be surprised to learn that Chrome and Edge have a built-in ad-blocker. It is only capable of blocking ads on a small list of sites which have been flagged by the vendor for “abusive ad use” (site shows intrusive or misleading ads). This setting allows you to exempt ads on sites that have been so flagged. (Sadly) you cannot use this setting to block ads on sites that are not on the abusive ad list.
Background SyncWeb API that allows ServiceWorker applications to perform sync operations in the background.
Automatic DownloadsThis is a misleading setting name. Basically, it amounts to “This site may initiate a file download without a signal (such as a user gesture) that such a download is expected.” Presently, there’s no Policy to control this; a site should be architected to avoid triggering this permission. (Note: Presently, there are bugs for downloads from cross-origin frames and also Edge’s IEMode).
Insecure contentBy default, the browser will block “active mixed content” (e.g. JavaScript served via HTTP) when embedded on a HTTPS page. The insecurecontentallowedforurls policy allows you to shoot yourself in the foot.
Your Device Use Allow sites to detect when the device has gone idleor the screen has been locked/unlocked.
As you can see, some of these settings are very obscure (WebSerial, WebMIDI) while others will almost never be changed away from their defaults (Images).
Chromium-based browsers like Microsoft Edge make very limited use of Windows Security Zones. Instead, most permissions and features that offer administrators per-site configuration via policy rely on lists of rules in the URL Filter Format.
Filters are expressed in a syntax (Chrome Doc, Edge Doc) that is similar to other types of globbing rules, but different enough to cause confusion. For instance, consider a URLBlocklist rule expressed as follows:
These filters don’t work as expected. The HTTPS rule should notinclude a trailing * in the path component (it won’t match anything), while the data: rule requires a trailing* to function.
The syntax has a few other oddities as well:
You do not use a * to represent a part of a hostname: the * character is only used by itself to mean “ALL hosts”. A rule of *xample.com is invalid and does not match example.com.
The right way to express “Match example.com and its subdomains” is just example.com. If you want to match only the hostname example.com, and none of its subdomains, use .example.com (note the leading dot).
You may specify a path prefix (example.com/foo) but you must not include a wildcard * anywhere in the path
You may specify wildcards in a querystring (example.com?bar=*). You may omit the preceding path component to have that querystring checked on all pages, or include a path to only check the querystring on pages within the path.
A rule of blob:* doesn’t seem to match blob URLs, while a rule of data:* does seem to match all data URLs.
Unfortunately, there’s not a great debugger for figuring out the proper syntax. You can use the chrome://policy page to see whether Chrome finds any glaring error in the policy:
…but short of testing your policy there’s not a great way to verify it does what you hope.
Q: The problem of special-URLs
There are a variety of special URLs (particularlyblob and data) that do not directly express a hostname– instead, the URL exists within a security context that is not included in the URL itself. This can cause problems for Policies if the code implementing the policy does not check the URL of the security context and looks only at the blob/data URL directly. A system administrator might set a policy for downloads from https://example.com/download, but if download page on that site uses a script-generated file download (e.g. a blob), the policy check might overlook the rule for example.com because it checks just the blob: URL.
Q: Can I block everything by adding * to the URLBlocklist?
You can add a simple * rule to the URL Blocklist, but then you must add to the URLAllowlist overriding rules to cover every URL that you need to allow to load in the browser. Beyond the https:// sites you expect, this includes, for example, about:, data:, edge:, and other URLs that you probably haven’t thought about.
Q: Can filters match on a site’s IP?
The Permissions system’s “Site Lists” feature does not support specifying an IP-range for allow and block lists. Wildcards are not supported either.
It does support specification of individual IP literals (e.g. http://127.0.0.1/), but such rules are only respected if the user navigates to the site using said literal IP address. If a non-address hostname is used (http://localhost), the IP Literal rule will not be respected even though the resolved IP of the host matches the filter-listed IP.
Aside: Wildcard support for IP-literals might be nice, so that an admin could specify e.g. http://192.168.*to exempt their private network. Unfortunately, Chromium couldn’t implement a syntax that is quite that simple — if it did, an attacker could just name their evil server https://192.168.evil.com and exploit their enhanced permissions.
Q: Can filters match just dotless hostnames?
Not today, no. You must individually list each desired hostname, e.g. (https://payroll, https://stock, https://who, etc).
Chromium’s URL Filter Format is convenient if your intranet is structured under one private domain (e.g. *.intranet.example.com) but is much less convenient if your Intranet uses dotless hostnames (http://example) or many disjoint private domains.
The ability to match only hostnames not containing dots would be convenient to accommodate the old IE behavior whereby Windows would map dotless hostnames to the Local Intranet Zone by default. (To my surprise, there’s been no significant demand for this capability in the first year of Edge’s existence, so perhaps corporate intranets are no longer using dotless hostnames very much?)
URL Filter Pattern is contrasted with Content Settings Patterns used by the site permissions system. (tl;dr, Content Settings Patterns uses a bracket-wrapped wildcard [*.] as its wildcard sequence)
Last year, I wrote about how the new Microsoft Edge’s adoption of the Chromium stack changed proxy determination away from the Windows Service (WinHTTP Proxy Service) to similar but not identical code in Chromium. This change mostly goes unnoticed, but it can have performance and functionality implications.
In today’s post, I want to explore another side-effect of changing away from the Windows stack– the impact on Proxy Authentication.
Background
When the client is configured to route its traffic through an authenticating proxy server, the proxy responds to any request that does not contain a Proxy-Authorizationrequest header with a HTTP/407 response that demands credentials, specifying the desired authentication scheme using a Proxy-Authenticate header:
The client is expected to resend the request with the requested credentials added in the Proxy-Authorization header.
Browsers tend to support four methods for authentication: the same four used for plain HTTP authentication: Basic, Digest, NTLM, and Negotiate (NTLM+Kerberos). The NTLM and Negotiate schemes are generally much preferred, as they can be configured to authenticate silently without showing a prompt to the user. However, depending on configuration (e.g. not in the right zone, or when the user’s Windows Login Credentials are not the ones the proxy requires), the user might see a proxy-authentication prompt in the browser.
Browser Credential UX
The prompt differs depending on the client; Google Chrome, and until recently Microsoft Edge, show an auth “bubble” anchored to the bottom of the browser address bar UI. In contrast, the latest versions of Edge and Internet Explorer show the battleship gray Windows Hello modal dialog box:
While these experiences are all conceptually similar, they differ in very important ways. First, note that Internet Explorer’s option shows a “Remember my credentials” checkbox while Chrome/Edge do not. Proxy credentials saved by Internet Explorer will be reused without prompting, across browsing sessions and across other applications that use the WinHTTP Proxy Service.
In contrast, in Chrome and older Edge, the proxy credentials prompt is integrated with the browser’s Password Manager. If the user accepts the followup prompt to save the proxy credentials, those credentials will autofill the dialog in future browser sessions. Notably, however, the proxy authentication is not automatic– the user must manually click the Sign in button once per browser session.
Storing a credential in your Edge profile’s password manager only applies to that one browser profile– other profiles and apps do not have access to the credential.
In Edge 88+, this password manager integration was lost in the switch to use the Windows Hello prompt for NTLM/Negotiate. A new policy (WindowsHelloForHTTPAuthEnabled) added to Edge 90 changes Edge’s proxy credentials dialog back to the older dialog.
Other App Credential UX
Support for manually-authenticating proxies outside of browsers has always been terrible, and many Win8 applications didn’t even bother to handle it. Sadly, that shortcoming remains in Windows 10, where you can’t even use the Windows Store when a proxy needs credentials that are not supplied automatically. An generic error page is shown:
However, as mentioned earlier, around IE11 a change was made to push proxy authentication creds entered in Internet Explorer’s proxy authentication prompt into the Windows Credential Manager (CredMan):
As seen in the Control Panel view (Persistence: Enterprise):
Even if you untick the “Remember my credentials” box on the prompt, the entered creds are still remembered for the Windows session (Persistence: Login Session):
As a consequence, users can “unbreak” various Windows scenarios by just using the browser to populate the Credential Manager with the proxy credentials.
We’ve lost that workaround in the new world, because Chromium’s password manager is not integrated with CredMan (for a number of sane1 reasons).
Surface Hub
The Microsoft Surface Hub is a “whiteboard computing” device designed for corporate conference rooms and the like. By default, the Windows logon session on the device uses an account named ComputerName\SurfaceHub, and that account is very unlikely to be supported by an authenticating proxy. To support it, Windows’ Settings applet on Surface Hub has a custom option:
However, this option doesn’t presently do anything for Chromium’s network stack. When Edge gets a Proxy-Authorization: Negotiate challenge from the proxy, it will respond with the credentials for the SurfaceHub account rather than the machine credentials, and the login will likely fail. At present, we don’t have a great workaround for this: it’s probably possible to write a browser extension (catching the onAuthRequired event and responding with non-default credentials) but this won’t pick up the Windows settings.
Other Brokenness
We recently fixed a bug in Edge Canary where the browser would crash on startup if the user was behind a manually-authenticated proxy server. A network request triggered very early in browser startup wasn’t prepared for an auth challenge.
If you have the Microsoft Office Chrome extension installed, it can (for reasons unknown) automatically cancel the manual proxy authentication dialog before the user has a chance to submit credentials.
In conclusion: Two decades in, support for proxy authentication remains a mess. The feature is required by the networks of some corporate titans (and thus support continues to limp along), but many corner cases remain broken. Consider carefully whether proxy authentication needs to be a part of your network strategy.
-Eric
1 There are several reasons, but one obvious one is that Chromium uses a “profiles” system whereby one Windows logon account may have multiple browser profiles, each of which is independent and does not share data with the others. This precludes direct use of system-level features that do not offer such partitioning.
text/plain 