-
Notifications
You must be signed in to change notification settings - Fork 213
csp: allow backend passthrough for /oidc/callback #1478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 4 commits
534aac6
1acbe3d
30b1cf4
96a2910
1a406b4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| proxy_set_header X-Forwarded-Proto $scheme; | ||
| proxy_pass http://service:8383; | ||
| proxy_redirect off; | ||
|
|
||
| # buffer requests, but not responses, so streaming out works. | ||
| proxy_request_buffering on; | ||
| proxy_buffering off; | ||
| proxy_read_timeout 2m; |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -91,9 +91,6 @@ server { | |
|
|
||
| server_tokens off; | ||
|
|
||
| add_header Content-Security-Policy-Report-Only "default-src 'none'; connect-src https://translate.google.com https://translate.googleapis.com; img-src https://translate.google.com; report-uri /csp-report"; | ||
| include /usr/share/odk/nginx/common-headers.conf; | ||
|
|
||
| client_max_body_size 100m; | ||
|
|
||
| gzip on; | ||
|
|
@@ -145,6 +142,7 @@ server { | |
|
|
||
| # More lax CSP for enketo-express: | ||
| # Google Maps API: https://developers.google.com/maps/documentation/javascript/content-security-policy | ||
| proxy_hide_header Content-Security-Policy-Report-Only; | ||
| add_header Content-Security-Policy-Report-Only "default-src 'none'; connect-src 'self' blob: https://maps.googleapis.com/ https://maps.google.com/ https://maps.gstatic.com/mapfiles/ https://fonts.gstatic.com/ https://fonts.googleapis.com/ https://translate.google.com https://translate.googleapis.com; font-src 'self' https://fonts.gstatic.com/; frame-src 'none'; img-src data: blob: jr: 'self' https://maps.google.com/maps/ https://maps.gstatic.com/mapfiles/ https://maps.googleapis.com/maps/ https://tile.openstreetmap.org/ https://translate.google.com; manifest-src 'none'; media-src blob: jr: 'self'; object-src 'none'; script-src 'unsafe-inline' 'self' https://maps.googleapis.com/maps/api/js/ https://maps.google.com/maps/ https://maps.google.com/maps-api-v3/api/js/; style-src 'unsafe-inline' 'self' https://fonts.googleapis.com/css; style-src-attr 'unsafe-inline'; report-uri /csp-report"; | ||
| # | ||
| # Rules set to 'none' here would fallback to default-src if excluded. | ||
|
|
@@ -154,15 +152,17 @@ server { | |
| } | ||
| # End of Enketo Configuration. | ||
|
|
||
| location ~ ^/v\d+/oidc/callback$ { | ||
| include /usr/share/odk/nginx/common-headers.conf; | ||
| include /usr/share/odk/nginx/backend.conf; | ||
| } | ||
|
|
||
| location ~ ^/v\d { | ||
| proxy_set_header X-Forwarded-Proto $scheme; | ||
| proxy_pass http://service:8383; | ||
| proxy_redirect off; | ||
| proxy_hide_header Content-Security-Policy-Report-Only; | ||
| add_header Content-Security-Policy-Report-Only "default-src 'none'; connect-src https://translate.google.com https://translate.googleapis.com; img-src https://translate.google.com; report-uri /csp-report"; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is kind of an aside/tangent, but why do we include these Google Translate URLs for the Backend CSP? Backend almost never returns HTML, so I feel like the Google Translate bit isn't needed. Google Translate isn't going to translate JSON returned from Backend. I know this has been the default value of this header, but I wonder whether it could be further simplified for Backend. Or is the attitude more like, "it never hurts to include Google Translate, so let's just always include it"?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is a mistake - API services should not be loaded in the browser as the main document, so it should be safe to completely lock down their CSPs. On the other hand, the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
|
||
| # buffer requests, but not responses, so streaming out works. | ||
| proxy_request_buffering on; | ||
| proxy_buffering off; | ||
| proxy_read_timeout 2m; | ||
| include /usr/share/odk/nginx/common-headers.conf; | ||
| include /usr/share/odk/nginx/backend.conf; | ||
| } | ||
|
|
||
| location @blank.html { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it definitely safe to remove this
include? Do alllocationblocks that need it already individuallyincludeit?Similarly for the
Content-Security-Policy-Report-Onlyheader, is the reason for removing it here because it's already been added to all the individuallocationblocks that need it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question!
I think so, as do the current tests. But that's not a guarantee!
The most conservative approach might be to lock down all headers here as much as possible. Should we try that? That could definitely catch some cases, but still won't protect from
add_headerdirectives in lower-level blocks from blowing away all headers set here.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually kind of prefer removing these lines if possible. I feel like it's easier to reason about the headers if they're all on one level. But I thought I'd check about it first.
I did a scan of the
locationblocks in this PR, and there seem to be three categories:locationblocks that individuallyincludecommon-headers.conf and add theContent-Security-Policy-Report-Onlyheader (includinglocationblocks thattry_files ... @blank.html;).locationblocks thatreturn 301There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also open to locking down all headers here if you think that's better. 👍 Or at least locking down
Content-Security-Policy-Report-Only. I think my first choice would be to remove these lines if possible, but it's not a strong preference (I'm happy either way).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 looks accurate to me
I think this is a slightly complicated question. I'll reinstate these lines, and merge the PR. We can try to delete or refine these default headers down the line.