INVESTIGATION/FIX: Security - CSP - why are we using "report only" not "block" in CSP?

[tiblu]

Investigation

Why are we using "report only" for CSP violations, why are we not blocking the requests?

Requires extensive testing of signing and authentication. We MAY have issues with the id-card signing browser extension. Also, MAY have issue in one browser but not in another etc.

Why?

If we really have a nasty violation, let's say a malicious 3rd party script is loaded, we would like to block it, not just report it.

TODO:

• Investigate if we could use "block" for CSP violations.
• IF we can use "block", use it.
• IF we can't, explain why in this issue.

[loorm]

Triage 17: estimated dev time 4 hours.

[tiblu]

Progress

• https://app.citizenos.com/ - Content Security Policy: The page’s settings observed the loading of a resource at inline (“script-src”). A CSP report is being sent.
  • CSP report:

  { 
  "blocked-uri":"self",
  "violated-directive":"script-src",
  "document-uri":"https://app.citizenos.com/en/",
  "referrer":"https://citizenos.com/product/",
  "script-sample":"// Promises \nvar _eid_promises = {}; \n//..."
  }
  

  • Headers:

  { 
  "user-agent":"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0",
  "x-forwarded-for":"****, ****3",
  "cf-ipcountry":"EE",
  "x-request-id":"****"
  }
  

  • Source: Chrome token signing extension - https://github.com/open-eid/chrome-token-signing/blob/master/extension/content.js#L53
  • Browser: Firefox
  • Can we block? NO, Blocking it will disable ID-card vote signing
• https://arvamusfestival.ee/kava
  • CSP report:

  { 
  "blocked-uri":"inline",
  "effective-directive":"style-src-elem",
  "violated-directive":"style-src-elem",
  "document-uri":"https://app.citizenos.com/et/widgets/partners/75a1a714-5a92-4d6c-aca4-3ba0116d27c6/topics/16310/arguments?0=A&1=F&2=o&3=o&4=r&5=u&6=m&widgetId=COarguments",
  "referrer":"https://www.arvamusfestival.ee/",
  "script-sample":""
  }
  {
  "blocked-uri":"inline",
  "violated-directive":"script-src",
  "document-uri":"https://app.citizenos.com/et/widgets/partners/75a1a714-5a92-4d6c-aca4-3ba0116d27c6/topics/16446/arguments?widgetId=COarguments&0=A&1=F&2=o&3=o&4=r&5=u&6=m",
  "referrer":"https://www.arvamusfestival.ee/"
  }
  

  • Headers:

  { 
  "user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36",
  "x-forwarded-for":"IP"
  }
  { 
  "user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0",
  "x-forwarded-for":"IP
  "cf-ipcountry":"EE",
  "x-request-id":"***"
  }
  

  • Source: Unknown. Something tries to apply inline script and styles, but is being blocked.
  • Can we block? YES, I assume it's some kind of a browser extension. Normal use-case should not apply inline styles. BUT, also means some browser extension will suffer.
• FYI: FF has new privacy mode that blocks analytics by default - The resource at “https://www.google-analytics.com/analytics.js” was blocked because content blocking is enabled.

Open questions

• Can you somehow whitelist specific extensions?

Resources:

• CSP info at MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
• CSP and Mozilla Extensions - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy
• CSP and Chrome Extensions - https://developer.chrome.com/extensions/contentSecurityPolicy
  • https://developer.chrome.com/extensions/content_scripts#security
• CSP validation tool - https://csp-evaluator.withgoogle.com/
• CSP reports explained and not explained - https://github.com/nico3333fr/CSP-useful/blob/master/csp-wtf

[tiblu]

Conclusions

TLDR: Cannot use "Block" as ID-card plugin and some other plugins will not work. "Report-only" also has limited usefulness due to very high noise.

Reasons why we cannot use "block"

• Some plugins including Estonian ID-card signing plugin would not work thus Users cannot sign Votes.
  • FIX: Plugin code needs to be updated so that it does not use eval() as it indirectly does right now (https://github.com/open-eid/chrome-token-signing/blob/master/extension/content.js#L53). More about plugins and CSP - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy
  • IF we fix the EID plugin, we can enable "block" BUT other User plugins MAY not work on our site. That applies to both novel and malicious plugins.

Reasons why CSP current implementation is quite useless

CSP was designed for site owners to protect their Users from malicious code that could be run in User context when the site has a XSS vulnerability. Idea is CSP was to define safe list of sources and behaviours, everything outside of it would be blocked and/or reported. Ideally you would like to block and report so that if there is an XSS attach, it would not run in User context and reporting would alert site owners of an attach.

BUT:

• CSP reports are quite useless - they do not contain enough data to decide WHAT is causing the violation. Is it an XSS or is it a browser plugin (addon)? EVEN when you add 'report-sample', usually there is nothing.
  • Example of such reports:

  { 
  "document-uri":"https://app.citizenos.com/en/topics/c58ef8ec-0333-46ce-8eb5-fcd2ce65a142",
  "referrer":"",
  "violated-directive":"script-src-elem",
  "effective-directive":"script-src-elem",
  "original-policy":"default-src 'self'; img-src *; script-src 'self' https://cdn.crowdin.com https://apis.google.com https://www.google-analytics.com; style-src 'self' https://fonts.googleapis.com 'sha256-swnxFqaff0i3bsLtJDRpMd5tZFLBnglxSxSqPSAWdIk='; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://id.citizenos.com https://api.citizenos.com https://sentry.io https://graph.microsoft.com https://www.google-analytics.com; base-uri 'self'; object-src 'none'; frame-src https://p.citizenos.com/ https://accounts.google.com/ https://docs.google.com; report-uri https://api.citizenos.com/api/internal/report;",
  "disposition":"report",
  "blocked-uri":"data",
  "status-code":0,
  "script-sample":""
  }
  

  • That is, something tries to inject a <script> element into DOM with src being data (<script src="data:application/javascript;charset=utf-8;base64,..."></script>). But, there is no hint what is? MAY be a plugin, MAY be an XSS, cannot make a difference.
• The support for CSP depends of the browser. For Citizen OS most browsers are covered, but still. List is here - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#Browser_compatibility

How Citizen OS should move forward?

I suggest:

• Fix the ID-card token signing plugin - https://github.com/open-eid/chrome-token-signing/blob/master/extension/content.js#L53 - issue created Plugin causes CSP (Content Security Policy) violations, cannot use CSP block and ID-card signing functionality at the same time open-eid/chrome-token-signing#158
• Switch CSP to block and see if it has serious User impact (plugins not working...)

[loorm]

@tiblu

• Fix the ID-card token signing plugin - https://github.com/open-eid/chrome-token-signing/blob/master/extension/content.js#L53 - issue created open-eid/chrome-token-signing#158

I agree. Should we create a corresponding issue in our Github, to be able to prioritize, who and when should work on it?

• Switch CSP to block and see if it has serious User impact (plugins not working...)

How would we know, if it has a serious User impact or not?

[tiblu]

I agree. Should we create a corresponding issue in our Github, to be able to prioritize....

Created but forgot to link. Here it is - citizenos/citizenos-fe#422

...who and when should work on it?

It's Open Source, I created an issue to the project - open-eid/chrome-token-signing#158
Community, including us can fix this. I have not written any plugins/extensions so it's hard to estimate properly, but I guess not more than a week.
BUT, once the fix is in place, it needs packaging by the project owner and clients need to update through the ID software updater. So realistically after the fix it takes X amount of months for most of the clients to update, this we can monitor from logs as the chrome token signing extension CSP report has very distinct fingerprint.

How would we know, if it has a serious User impact or not?

That's a tough one, really tough one.
We can see from the reports that there are scripts including plugin scripts being blocked, but we really don't know the user impact - is user annoyed that his/her plugin does not work on our site or not. From the login we cannot even tell what plugin it was, to check out common plugins and their behavior.
TLDR: User feedback is the best, logs provide limited visibility.

[KatiVellak]

Legally reviewed, no additions.