6 ms·

We’re concerned about this as well at GitHub. We don’t link directly to the Google Analytics script, which could be updated at anytime. Instead we host our own

We’re concerned about this as well at GitHub. We don’t link directly to the Google Analytics script, which could be updated at anytime. Instead we host our own script version that’s locked down with CSP and SRI. We still allow XHRs to the Google Analytics origin to report the data but the script code itself can’t be changed without an internal security review.

dom0 9y ago
It's reassuring that you (GitHub) seem to have not only thought about the problem, but implemented processes to reduce exposure.
- tptacek 9y ago
  Github has one of the best application security teams in the industry. (I have no relationship with Github other than that I am a customer and have watched them steadily hire some of the best people I know in the industry).
  - ptoomey3 9y ago
    Thank for the kind words. As Neil noted below, we would like to lock things down even further by proxing all data that is sent to Google Analytics. And, as a bonus, it would remove the last destination host for content exfil attacks that we know of. Our strict CSP policy has been a nice win, but the strictness has made it that much more clear that allowing nearly any third party sites, even for innocuous things such as images/xhr, isn't ideal. And, we are always on the lookout for more bypasses: https://bounty.github.com/targets/csp.html https://bounty.github.com/targets/csp.html.
    - sitepodmatt 9y ago
      Oh nice, tell me more about proxying to GA, do you just change some hostname config in the ga universal js snippet to point to your forwarding proxy? how does GA know end user IP as it will be your proxy forwarders normally?
      - ptoomey3 9y ago
        You basically report the data to your own servers and then relay whatever subset you like to google using their “measurement protocol”: https://developers.google.com/analytics/devguides/collection/protocol/v1/ https://developers.google.com/analytics/devguides/collection...
        sitepodmatt 9y ago
        Interesting, what do you use on the client-side to pick up browser information (resolution etc..)?
- ndm 9y ago
  And this can be ratcheted down further by leveraging something like the measurement protocol. It would eliminate the 3rd party calls/code in the browser while giving GitHub the ability to anonymize the source (e.g. IP address, user agent, etc.). Twitter does this with some of their 3rd party integrations.
drdaeman 9y ago
> we host our own script version that’s locked down with CSP Excuse me, is there any article about this, or maybe some pointer where one could get a GA script that doesn't need `script-src data:` (or eval or similar insanity) in the CSP? I've tried to add CSP for a page that has GA (no other external deps) and it seemed to deliver some scripts from base64-encoded data URI. I haven't researched what exactly it does, but suppose it was the unpacker inserting code that way, instead of using eval. Could be wrong, though, but the only external JS reference was analytics.js, and when testing in Firefox 57 CSP had complained about script with a data URI.

dom0 9y ago

It's reassuring that you (GitHub) seem to have not only thought about the problem, but implemented processes to reduce exposure.

tptacek 9y ago
Github has one of the best application security teams in the industry. (I have no relationship with Github other than that I am a customer and have watched them steadily hire some of the best people I know in the industry).
- ptoomey3 9y ago
  Thank for the kind words. As Neil noted below, we would like to lock things down even further by proxing all data that is sent to Google Analytics. And, as a bonus, it would remove the last destination host for content exfil attacks that we know of. Our strict CSP policy has been a nice win, but the strictness has made it that much more clear that allowing nearly any third party sites, even for innocuous things such as images/xhr, isn't ideal. And, we are always on the lookout for more bypasses: https://bounty.github.com/targets/csp.html https://bounty.github.com/targets/csp.html.
  - sitepodmatt 9y ago
    Oh nice, tell me more about proxying to GA, do you just change some hostname config in the ga universal js snippet to point to your forwarding proxy? how does GA know end user IP as it will be your proxy forwarders normally?
    - ptoomey3 9y ago
      You basically report the data to your own servers and then relay whatever subset you like to google using their “measurement protocol”: https://developers.google.com/analytics/devguides/collection/protocol/v1/ https://developers.google.com/analytics/devguides/collection...
      - sitepodmatt 9y ago
        Interesting, what do you use on the client-side to pick up browser information (resolution etc..)?
ndm 9y ago
And this can be ratcheted down further by leveraging something like the measurement protocol. It would eliminate the 3rd party calls/code in the browser while giving GitHub the ability to anonymize the source (e.g. IP address, user agent, etc.). Twitter does this with some of their 3rd party integrations.

drdaeman 9y ago

> we host our own script version that’s locked down with CSP Excuse me, is there any article about this, or maybe some pointer where one could get a GA script that doesn't need `script-src data:` (or eval or similar insanity) in the CSP? I've tried to add CSP for a page that has GA (no other external deps) and it seemed to deliver some scripts from base64-encoded data URI. I haven't researched what exactly it does, but suppose it was the unpacker inserting code that way, instead of using eval. Could be wrong, though, but the only external JS reference was analytics.js, and when testing in Firefox 57 CSP had complained about script with a data URI.