Enable permissive CORS on static file serving #1397
Conversation
|
Generally speaking, I wouldn't recommend using hydra to serve static content. Instead upload the data somewhere else before serving it. Otherwise, CORS is not really something I know a lot about, so I'll defer reviewing safety of this to someone else. |
| @@ -237,6 +237,7 @@ sub serveFile { | |||
| # Have the hosted data considered its own origin to avoid being a giant | |||
| # XSS hole. | |||
| $c->response->header('Content-Security-Policy' => 'sandbox allow-scripts'); | |||
| $c->response->header('Access-Control-Allow-Origin', '*'); | |||
There was a problem hiding this comment.
@hsjobeki Can this be abused in any way?
This is only for cross-domain requests, but our problem is that hydra.nixos.org is the same domain as the build. The only way I can see how can be made secure is by having builds on a different subdomain (maybe for even each build even) |
|
The page https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox
add that, when the CSP sandbox is used (and unless allow-same-origin is used), "the resource is treated as being from a special origin that always fails the same-origin[https://developer.mozilla.org/en-US/docs/Glossary/Same-origin_policy] [https://developer.mozilla.org/en-US/docs/Glossary/Same-origin_policy]policy[https://developer.mozilla.org/en-US/docs/Glossary/Same-origin_policy] (potentially preventing access to data [https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_data_storage_access]storage[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_data_storage_access]/cookies[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_data_storage_access] and some JavaScript APIs)."
21 août 2024 10:31:45 Jörg Thalheim ***@***.***>:
…
PS: MDN confirm that this won’t send Cookies or other Authentification information (in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials): "Credentials are cookies, TLS client certificates, or authentication headers containing a username and password. By default, these credentials are not sent in cross-origin requests, and doing so can make a site vulnerable to CSRF attacks.
This is only for cross-domain requests, but our problem is that hydra.nixos.org is the same domain as the build. The only way I can see how can be made secure is by having builds on a different subdomain (maybe for even each build even)
—
Reply to this email directly, view it on GitHub[#1397 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AFMKJZAZP7STK2LA7OH3SZTZSRF5HAVCNFSM6AAAAABLLDAZISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRGQ3DQOJXHE].
You are receiving this because you authored the thread.
|
|
Since I hope you don't run Hydra without a reverse proxy like nginx, why not set the header there? |
|
So i think we're kind of misunderstanding each other. Problem: https://hydra.nixos.org/build/263397466/download/1/manual/ has broken fonts and icons somehow because of cors. Another problem: Same origin policy (as of right now) allows any build page to access any other build resource. I.e. To solve this the build-id could become part of the origin? (If accessing cross resources is a security issue).
The proposed solution for the first problem:
Solves the issue, but also opens up even more cross site scripting. Although no-credentials would be sen, as mentioned. |
|
So, from my understanding, a page with this PR won't be able to access *https[https://hydra.nixos.org/priviate]**://[https://hydra.nixos.org/priviate]**hydra.nixos.org[https://hydra.nixos.org/priviate]**/[https://hydra.nixos.org/priviate]**priviate[https://hydra.nixos.org/priviate]*, as it does not serve a build result (and so does not have the permissive CORS header). Any page would have access to other built content thought (as long as they do not require authentification), which should be okay for publicly-exposed static file.
Althought the https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy seems to describe a way that would allow to instead specify allowed URL. But it'll be for another day for me to try to improve this PR using it.
Finally, I could have indeed used nginx for that (Can't do much without using it given the amount of subdomain I use). I just didn't thought of it, and also it's a software bug that may be worth upstreaming (and getting scrutinized)
21 août 2024 17:22:18 Johannes Kirschbauer ***@***.***>:
…
So i think we're kind of misunderstanding each other.
Problem: https://hydra.nixos.org/build/263397466/download/1/manual/ has broken fonts and icons somehow because of cors.
Another problem:
Same origin policy (as of right now) allows any build page to access any other build resource.
I.e. *https://hydra.nixos.org/build/263397466/download/1/manual/* could access *https://hydra.nixos.org/priviate* because of the same origin.
To solve this the build-id could become part of the url? If accessing cross resources is a security issue.
*https://263397466.hydra.nixos.org*
The proposed solution for the first problem:
*'Access-Control-Allow-Origin', '*')*
Solves the issue, but also opens up even more cross site scripting. Although no-credentials would be sen, as mentioned.
I didn't figure out why the fonts files couldn't be loaded strangely. Maybe you can find a narrower setting than "*" ?
—
Reply to this email directly, view it on GitHub[#1397 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AFMKJZANIHQW2GQ5ININ44DZSSV6XAVCNFSM6AAAAABLLDAZISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBSGM2TQNBUGQ].
You are receiving this because you authored the thread.
|
I think this was specifically about hydra.nixos.org. |
I had this issue while experimenting with CI for MR preview of static site with Hydra. The same issue also impact the Nix and Hydra manual, where font icons are not displayed (at least with recent Firefox and Chromium).
(https://hydra.nixos.org/build/263397466/download/1/manual/)
I’m not really sure why CORS is needed for some request and not other ones. I suspect this is due to the Content-Security-Policy=sandbox header, as the same program I have work well on another deployment that don’t send that header.
This should stay secure, as only static files are served, but will allow other sites to embed built content served by Hydra.
PS: MDN confirm that this won’t send Cookies or other Authentification information (in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials): "Credentials are cookies, TLS client certificates, or authentication headers containing a username and password. By default, these credentials are not sent in cross-origin requests, and doing so can make a site vulnerable to CSRF attacks."