{"action":"created","issue":{"url":"https://api.github.com/repos/digital-analytics-program/gov-wide-code/issues/61","repository_url":"https://api.github.com/repos/digital-analytics-program/gov-wide-code","labels_url":"https://api.github.com/repos/digital-analytics-program/gov-wide-code/issues/61/labels{/name}","comments_url":"https://api.github.com/repos/digital-analytics-program/gov-wide-code/issues/61/comments","events_url":"https://api.github.com/repos/digital-analytics-program/gov-wide-code/issues/61/events","html_url":"https://github.com/digital-analytics-program/gov-wide-code/issues/61","id":255801567,"number":61,"title":"Custom DAP code gives google-analytics.com unfettered control of USG websites","user":{"login":"fulldecent","id":382183,"avatar_url":"https://avatars0.githubusercontent.com/u/382183?v=4","gravatar_id":"","url":"https://api.github.com/users/fulldecent","html_url":"https://github.com/fulldecent","followers_url":"https://api.github.com/users/fulldecent/followers","following_url":"https://api.github.com/users/fulldecent/following{/other_user}","gists_url":"https://api.github.com/users/fulldecent/gists{/gist_id}","starred_url":"https://api.github.com/users/fulldecent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fulldecent/subscriptions","organizations_url":"https://api.github.com/users/fulldecent/orgs","repos_url":"https://api.github.com/users/fulldecent/repos","events_url":"https://api.github.com/users/fulldecent/events{/privacy}","received_events_url":"https://api.github.com/users/fulldecent/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2017-09-07T03:08:45Z","updated_at":"2017-09-14T04:22:49Z","closed_at":null,"author_association":"NONE","body":"I have reviewed the current implementation that participating websites are using, I believe the latest version is posted at https://github.com/digital-analytics-program/gov-wide-code/blob/master/Universal-Federated-Analytics.js\r\n\r\nThe largest vulnerability you have is in these lines: https://github.com/digital-analytics-program/gov-wide-code/blob/master/Universal-Federated-Analytics.js#L532-L536\r\n\r\nThis is unmodified from Google's original ISOGRAM code. However, this fails to include a a.crossorigin = 'anonymous' line which is best practice. Additionally, any security audit you have performed is invalid because a. \\integrity is not specified. Therefore google-analytics.com has the unfettered ability to inject arbitrary code or modify the contents of any US government web page.\r\n\r\nThis is a common practice on the web today, but it is not best practice. Because you are recommending a policy for ALL US government websites your standards should be higher.\r\n\r\nI have reported this issue to dap@support.digitalgov.gov, but I have opened primary discussion of this issue here on GitHub where the most relevant audience may find it.\r\n\r\n# Work plan\r\n\r\n- [ ] Add `a.crossorigin = 'anonymous'` to the recommended DAP code\r\n- [ ] Better document the risks that the DAP code has w/r/t google-analytics.com and google.com\r\n- [ ] Adopt SRI for Google Analytics, by adopting one of the following\r\n  * Renegotiate with Google, have them host a versioned copy of the file which can be reviewed and hashed, link to that file\r\n  * Copy or \"closely reimplement\" the Google Analytics script and host on common GSA servers, link to that file\r\n  * Copy or \"closely reimplement\" the Google Analytics script and host it on every DAP program participant"},"comment":{"url":"https://api.github.com/repos/digital-analytics-program/gov-wide-code/issues/comments/329367150","html_url":"https://github.com/digital-analytics-program/gov-wide-code/issues/61#issuecomment-329367150","issue_url":"https://api.github.com/repos/digital-analytics-program/gov-wide-code/issues/61","id":329367150,"user":{"login":"konklone","id":4592,"avatar_url":"https://avatars0.githubusercontent.com/u/4592?v=4","gravatar_id":"","url":"https://api.github.com/users/konklone","html_url":"https://github.com/konklone","followers_url":"https://api.github.com/users/konklone/followers","following_url":"https://api.github.com/users/konklone/following{/other_user}","gists_url":"https://api.github.com/users/konklone/gists{/gist_id}","starred_url":"https://api.github.com/users/konklone/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/konklone/subscriptions","organizations_url":"https://api.github.com/users/konklone/orgs","repos_url":"https://api.github.com/users/konklone/repos","events_url":"https://api.github.com/users/konklone/events{/privacy}","received_events_url":"https://api.github.com/users/konklone/received_events","type":"User","site_admin":false},"created_at":"2017-09-14T04:22:49Z","updated_at":"2017-09-14T04:22:49Z","author_association":"CONTRIBUTOR","body":"> True, Google has failed to make any assurances regarding this code (i.e. that it wont change). True, Google is unlikely to make assurances regarding this code unless they are required to. GSA, as a very large Google client, is uniquely positioned to negotiate such a clause.\r\n\r\nThis is unlikely to be practical for Google, and is the opposite of the direction they (and we) would be likely to go. While the DAP could make use of snapshotted URLs by updating its link to GA in each snapshot of the DAP code, this sort of use of GA is extremely rare. Overwhelmingly, GA is used by administrators dropping in the embed code and never touching it again. \r\n\r\nThis is a **good thing** for the security of the GA ecosystem, because privacy and security fixes get distributed immediately to the entire population. DAP, though one layer removed, has the exact same problem -- when the only option for agencies was self-hosting, it was impossible for DAP to distribute security- and privacy-relevant fixes, and rot across the ecosystem overall reduced user security.\r\n\r\nThis is one of the reasons why dap.digitalgov.gov was created as central hosting, and it has the same dynamic you outline for GA. Agencies would potentially be more secure from compromise of **our** servers by either self-hosting, or by the DAP committing to snapshots and providing SRI hashes. However, this would paralyze the ecosystem and defeat the benefits of central hosting.\r\n\r\nI do understand the security issue you are pointing out, but there are larger, ecosystemic security issues to weigh, and SRI is in fundamental tension with the principle of automatic updates across a deployed ecosystem -- a fundamental tenet of maintaining secure clients. \r\n\r\nSRI is far more practical when there's a small/single number of groups of people maintaining the surface area of SRI hashes and overall dependency updates. In a distributed ecosystem, it's unlikely to make sense -- either for DAP, or for Google.\r\n\r\n> The page https://login.gov/ includes a resource from Google that is identified only by URL. Therefore, Google has full permission and authority to modify this page as it sees fit. \r\n\r\nYes, this is understood and accepted.\r\n\r\n> Issue 18F/identity-idp#1257 is discussed but I don't think they implemented it because https://secure.login.gov/ still includes analytics.\r\n\r\nThe pull request, which says to use DAP when the user is fully logged out, was implemented. DAP is only present on the login page, where the user is fully logged out.\r\n\r\nThe rest of the app, even when logged in, continues to use _their own_ Google Analytics account (not connected to DAP). So yes, the team currently accepts the risk of Google Analytics inside the authenticated environment.\r\n\r\n@tdlowden I recommend this issue be closed, as I don't believe there's anything that DAP can feasibly do about the issues raised here, for the reasons explained above. (If the DAP team wants to do `crossorigin=anonymous`, that would probably function best as a separate issue at this point.)\r\n\r\nOn a personal note, @fulldecent, while I share your concerns about overreliance on, and underawareness of the dangers of, Google Analytics across the internet, I think the issue has be to be handled at another layer. DAP would be well-served to reduce its own reliance on Google Analytics and to explore other alternatives, but if GA is going to be used, then the risk here just has to be accepted. If you've got a passion for removing unnecessary third party dependencies that aren't as critical to business success as Google Analytics, I suggest taking a look at https://github.com/18F/domain-scan/pull/107 and finding other third party services which could easily be eliminated from .gov services. There are many!"}}
{"actor":{"display_login":"konklone"}}