okTurtles / group-income

A decentralized and private (end-to-end encrypted) financial safety net for you and your friends.
https://groupincome.org
GNU Affero General Public License v3.0
330 stars 43 forks source link

Missing Security Headers #2291

Open corrideat opened 1 month ago

corrideat commented 1 month ago

Problem

The site groupincome.app is missing some important security headers that could mitigate vulnerabilities client-side. This can be verified using https://securityheaders.com.

A note on HTTPS and server trust

Regardless of the values of these headers, they are set by the server, which means that their effectiveness depends on trusting the server and that the response reached the client unmodified.

Trusting the server

I think that it's acceptable to have some minimal degree of trust on the server. It'd be a useful exercise to also have a mechanism to relatively easily audit that all artifacts delivered (scripts especially) haven't been tampered with.

Besides the audit mechanism discussed, another (complimentary) option is to use the service worker to control the flow of information from the server to the app. The service worker can verify all subsequent server responses, effectively turning the trust model to TOFU.

Trusting that the response arrived unmodified

This is a tricker requirement. For the most part, HTTPS provides protection (save for the remote possibility of MitM).

Feasibility of MitM

Although Certificate Transparency [1] is not currently required for valid certificates, Chrome requires [2][3] CT as well as Safari [4] require certificate transparency, making it de facto required. AFAIU, this is not an online check, but issuing such proofs of inclusion will require collusion of parties, making it a difficult attack to carry out, since it's practically difficult and detection is likely to be deleterious for all parties involved.

This attack, however unlikely, is also mitigated in a TOFU model using service workers.

[1] https://www.rfc-editor.org/rfc/rfc6962 [2] https://googlechrome.github.io/CertificateTransparency/ct_policy.html "Since Chrome 94, Chrome clients will also attempt to obtain updated CT Log lists from the Component Updater infrastructure several times per day. On a successful update of the CT Log list, Chrome will update the start of its 70 day CT enforcement window to the freshest log_list_timestamp." [3] https://github.com/GoogleChrome/CertificateTransparency/commit/95694b20950c91b6d72ec1d35fff7a60e7bac242 "Chrome requires all publicly-trusted TLS certificates issued after April 30, 2018 to support CT in order to be recognized as valid. This site provides details on what is required. Any questions should be directed to the ct-policy@chromium.org list." [4] https://support.apple.com/en-us/103214

Solution

taoeffect commented 1 month ago

@corrideat while I could add these to reverse proxy config, that would mean that others who are running Group Income might not get these headers as other servers could be configured differently. What do you think about using Hapi to add these headers?

corrideat commented 1 month ago

I think that's reasonable, and also allows for easier testing (as mentioned, CSP and potentially permissions policy could break things if something is missing)