While researching one site, I found that if you enter document.cookie (Firefox) I can see this filed in cookie _gat_gtag_UA_XXXXXXXXX_1=1. There were plain text. As I know gtag is for Google Tag Manager. I was using Google Analytics and Google Tag Manager in my projects too. So, isn't is insecure to show such data as Google Tags or Google Analytics IDs as a plain text?
Add a comment
|
1 Answer
Showing data in plaintext is unavoidable, and the GA ID is not assumed to be secret. So this is not really a security problem, but can be analyzed from a security perspective.
On a website, there are two environments: the server and the browser. In principle, the user/attacker has complete control over the browser, including any JavaScript that a website runs and any data that a website stores. It is fundamentally not possible to process data in the browser without potentially disclosing this data to an attacker.
When using Google Analytics, there is some JavaScript code that sends requests to a Google server in order to record analytics data. Google needs to know to which website this data relates. For that purpose, IDs of the form UA-XXXXXXX-X are used. Since the JavaScript code has to include this identifier in requests, it must be made available as plaintext to the browser, which in turn makes it possible for an attacker to access this identifier.
An attacker can abuse this identifier e.g. to send wrong analytics data to the Google servers, which will distort analytics reports for that website. This is an unavoidable problem in this context. While Google attempts to filter out bots and spam, Google Analytics Referrer Spam is a common problem and requires subsequent data cleaning.
Google Analytics is designed so that you can enable analytics collection just by placing a JavaScript snippet onto the page. This JS-based approach is very convenient because this can be easily done with a static website, by editing a template/theme, or by filtering the HTML before it is served. But this requires disclosure of the GA ID to browsers.
If the analytics system were to have a server-side component, this disclosure would be avoidable. For example, the website server could produce a signed token (like a JWT) that is only valid for a limited time, thus limiting (but not completely preventing) the opportunity for spamming. The disclosure of the GA ID could also be prevented if analytics data is first sent to the website backend, which then forward it to the Google server using a Measurement Protocol. But this merely moves the server that can be spammed from Google to the website.
There is a tradeoff here between different goals: ease of installing Google Analytics on a site, and data quality. When using gtag.js or analytics.js, the website operator has decided this tradeoff more towards ease of installation, and has sacrificed a bit of data quality. Such kinds of tradeoffs are essential in security: absolute security would also mean absolute unusability, so instead different goals must be appropriately balanced.
When designing such systems, it is important to consider what processing is potentially under the control of the attacker, so that we can draw security boundaries appropriately. As explained above, anything the browser does is untrustworthy from the perspective of a server. There cannot be a security boundary within the browser. Instead, the server-side components must treat all requests as untrusted and must have appropriate logic to deal with potentially malicious requests. In this case, it means that the Google Analytics servers will filter out data from requests that don't look authentic. For example, the _gat cookie represents rate limiting information. If an attacker does not respect this rate limit, it would be pretty obvious that the requests are not authentic.
