Skip to content
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

duplicated CSP frame-ancestors policy #10042

Closed
wkloucek opened this issue Sep 12, 2024 · 7 comments
Closed

duplicated CSP frame-ancestors policy #10042

wkloucek opened this issue Sep 12, 2024 · 7 comments
Assignees
Labels
Priority:p2-high Escalation, on top of current planning, release blocker Type:Bug

Comments

@wkloucek
Copy link
Contributor

Describe the bug

On the root path of oCIS, we get two content-security-policy headers. One has a static frame-ancestors 'self' config

Steps to reproduce

  1. run oCIS 6.3.0 eg. in Kubernetes using the development-install deployment example
  2. open oCIS, eg https://ocis.kube.owncloud.test/ after opening the network console
  3. Look at the request to https://ocis.kube.owncloud.test/

Expected behavior

Have one header content-security-policy reflecting my oCIS csp configuration.

Actual behavior

image

Further context

The second header seems to be statically set to frame-ancestors 'self' and always there, even if I have a more sophisticated CSP config

@wkloucek
Copy link
Contributor Author

This additional header probably originates here:

// SilentRefresh allows the oidc client lib to silently refresh the token in an iframe
func SilentRefresh(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Security-Policy", "frame-ancestors 'self'")
next.ServeHTTP(w, r)
})
}

@wkloucek
Copy link
Contributor Author

And what it actually does: it takes precedence over the frame-ancestors policy in the first header...

@micbar micbar added the Priority:p2-high Escalation, on top of current planning, release blocker label Sep 23, 2024
@micbar micbar moved this from Qualification to Prio 2 in Infinite Scale Team Board Sep 23, 2024
@micbar
Copy link
Contributor

micbar commented Sep 23, 2024

@kulmann @JammingBen

Escalating it to P2

@jvillafanez
Copy link
Member

As far as I know, the CSP is fully handled by the proxy service (through the csp.yaml file), and no other service should try to set the CSP. The easiest solution is to remove that header from the web service and let the proxy service to handle it; we might need to document that the frame-ancestor 'self' (or a more relaxed) policy is required.

Alternatively, we could implement a way for any service to overwrite the CSP in the proxy service. In this case, the web service would require the proxy service to set, at least, the frame-ancestor 'self' policy. However, the solution seems complex and will require proper design. Note that setting the policy might be critical (service might not work properly if the policy isn't set), and we need to deal with communication errors between the services.

@micbar
Copy link
Contributor

micbar commented Sep 24, 2024

The easiest solution is to remove that header from the web service and let the proxy service to handle it;

Yes. That should do it for now.

@jvillafanez
Copy link
Member

#10146 should fix the double CSP header.

@micbar micbar moved this from Prio 2 to In progress in Infinite Scale Team Board Sep 24, 2024
@jvillafanez
Copy link
Member

PR merged. Closing.

@github-project-automation github-project-automation bot moved this from In progress to Done in Infinite Scale Team Board Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:p2-high Escalation, on top of current planning, release blocker Type:Bug
Projects
Status: Done
Development

No branches or pull requests

3 participants