4

These days Google Analytics uses a JSONP request to load ga.js into user's web pages via a callback function. According to the Wikipedia, JSONP can "inject any content into a website."

What exactly does this mean? Is there any way to access local storage, variables in RAM (private keys for example)? Are attacks limited to UI attacks (like a fake dialog)?

Wouldn't it be much better to have a more advanced easily readable JavaScript script on the user's web site posting to ga.js in an iframe via postMessage? It seems like you could post anything you want this way while making it clear in a site audit what information is being sent while securing the remote JavaScript.

https://developers.google.com/analytics/devguides/collection/gajs/ https://en.wikipedia.org/wiki/JSONP#Security_concerns

Possible solution (if needed, in the form of a question)

Is Google Analytics HIPAA compliant? How can I find out?

Community
  • 1
jcalfee314
  • 152
  • 8
  • 2
    Many of the security risks associated with JSONP are BY DESIGN. JSONP was originally designed to bypass [cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery) security. – Aron Jul 25 '15 at 08:56
  • Interesting, I see CSRS in new light. Consider this: the website is only static files and using a CORS websocket only. Links into the website or requests to the web server really don't have any power at all. There is no server, just the websocket which is a public API. The target is the local encrypted storage and the info to decrypt it. – jcalfee314 Jul 25 '15 at 16:27

1 Answers1

2

Any time you include script from an external domain you are trusting that domain. e.g. if you site is example.com and you have the following code on your home page

<script src="//example.edu/tracking_script.js"></script>

then example.com is fully trusting example.edu not to do anything malicious inside tracking_script.js. example.edu will have full control of client-side scripting and could do anything a client-side script hosted on example.com could do.

The same goes with Google Analytics - you are adding the script code to your page that creates the external js reference. If Google wanted to, they could adapt their script to do anything client-side to your pages. The same goes for a situation where Google Analytics website is compromised - any attacker will control all domains using Analytics.

Discounting anything malicious, the advantage of this to Google is that they can update the Analytics client-side code without webmasters having to do any updates on their side. So if they update a server-side function, they can update the client-side counterpart appropriately and every site in the world will automatically run the new client-side code for their visitors.

postMessage, while it maintains a security perimeter between your domain and GA's, would not permit any client-side script updates that may be necessary for GA to function after a server-side update. (Note that you do not need an IFrame for secure cross-domain communication, CORS enabled on Google's side would allow your site to send a HTTP POST request to register each page visit.)

When using a Google product, you will be pretty safe including the script referencing - so there is little requirement for this to be done in a different manner. However, having script references to lesser known entities whose security might not be quite upto the standard of Google's may be of cause for concern. In those instances it would be prudent to rely on a more secure client-side technology rather than that of JSONP.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • "The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents." https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy – jcalfee314 Jul 25 '15 at 15:49
  • I still like the postMessage, I want to review any updates. It should be published by Google and available for download. If I were Google, I would want to limit my liability so I couldn't be questioned about the theft of someones coins from on online wallet. Same goes for my company, I don't want the liability of someone eases server being hacked. Google Analytic is not the only opportunity way to benefit by loading JavaScript across sites. We might as well understand how to be safe so it can be used. – jcalfee314 Jul 25 '15 at 15:57