Secure Central Hosting for the Digital Analytics Program
The U.S. government’s Digital Analytics Program (DAP) collects Web traffic and analytics data from across the federal government. That data flows into a very large central account, and some of that data is automatically made public in real time at analytics.usa.gov.
<script src="/js/federated-analytics.js" id="_fed_an_ua_tag"></script>
While this approach allows agencies more control, it makes it seriously challenging for DAP to ensure that security improvements and other bug fixes are quickly distributed to participating websites.
To address this, DAP has set up a centrally hosted URL at dap.digitalgov.gov containing the most current DAP collection code, which agencies can reference like this:
<script src="https://dap.digitalgov.gov/Universal-Federated-Analytics-Min.js" id="_fed_an_ua_tag"></script>
By adding this tag and following DAP’s guidance (PDF, 273 KB, 7 pages, February 2015) to add parameters identifying your agency, a federal website will begin reporting its Web analytics to DAP and will be guaranteed to always be using the latest, greatest, most secure DAP code.
Securing Visits to Federal Websites
The recent federal government policy on HTTPS requires HTTPS and HSTS for all new federal websites and services. (For agencies: DigitalGov University recently produced educational videos on an Introduction to HTTPS and Implementing HTTPS.)
Breaking the Protocol-Relative URL
Many people on the Web are accustomed to using protocol-relative URLs, which have long been promoted as a best practice. They look like this:
<img src="//domain.com/img/logo.png" alt="" />
This means that the URL will inherit the protocol of the containing page. If the embedding website uses HTTPS, then the image will be fetched over HTTPS, and likewise for HTTP. When HTTPS was considered optional for many sites, this made some sense. However, in 2015, protocol-relative URLs are considered an anti-pattern and are discouraged.
Because dap.digitalgov.gov is a potential high-value target, the Digital Analytics Program did not want to support plain HTTP connections at all—even for a redirect. Though HTTP redirects are helpful, they are still an opportunity for attack. HSTS is designed to help with this, but an even more secure solution is to simply disable HTTP altogether.
This generally isn’t a viable solution for websites, because users type bare domains like “whitehouse.gov” into browser location bars, and browsers generally have to assume plain HTTP as a first try in these situations. But because dap.digitalgov.gov is a brand new subdomain used only as a third party service, DAP can set a higher standard by breaking the protocol-relative URL when used on a plain HTTP site.
The simplest solution is to refuse
http:// connections entirely by closing port 80 and not allowing browsers to connect at all, but this was not a viable option for DAP’s hosting provider. However, returning an error code instead of a redirect for plain HTTP connections would not be in compliance with federal HTTPS policy.
We solved the issue by combining a redirect with an error code. Any HTTP requests to a file on http://dap.digitalgov.gov will redirect the user to https://dap.digitalgov.gov/403, which then returns a 403 error code.
$ curl --head http://dap.digitalgov.gov/Universal-Federated-Analytics-Min.js HTTP/1.1 301 Moved Permanently Location: https://dap.digitalgov.gov/403
This ensures that data can only be collected over HTTPS, and breaks any HTTP or protocol-relative URLs participating agencies might accidentally use when integrating their websites into the Digital Analytics Program.
While DAP’s solution ended up being straightforward, this approach is surprisingly novel—most common third party services today don’t even require HTTPS.
But on today’s Internet, they should, and the Digital Analytics Program is leading by example.
Eric Mill is an 18F team member.