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

Use CSP header to treat served files as belonging to a separate origin #3341

Merged
merged 2 commits into from
Mar 9, 2018

Conversation

takluyver
Copy link
Member

We already contain these files using the /view/ handler, which displays them inside an iframe with the same sandboxing. This PR ensures that if a user ends up viewing an untrusted HTML/SVG file at a /files/ URL (instead of /view/), it will still be sandboxed, using the Content-Security Policy: sandbox header.

The browser then treats the page as having a unique origin, so cross-origin protection prevents any Javascript from communicating with the notebook server.

@takluyver takluyver added this to the 5.5 milestone Feb 15, 2018

# In case we're serving HTML/SVG, confine any Javascript to a unique
# origin so it can't interact with the notebook server.
self.set_header('Content-Security-Policy', 'sandbox allow-scripts')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also overrides any currently set Content-Security-Policy -- should we merge with the operator's settings?

Note: I refer to operator to mean whoever administers this deployment, whether a local server user or a jupyterhub administrator.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good point. Do you think it's sufficient to use add_header() to do this, or should we get into checking any existing Content-Security-Policy headers?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can multiple CSP headers be set and do what we want? If not, we might want to override the inherited content_security_policy property instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From MDN:

You can use the Content-Security-Policy header more than once... Adding additional policies can only further restrict the capabilities of the protected resource

I think that means this should work, but maybe the c_s_p property is a neater way to achieve the same thing?

Copy link
Member

@rgbkrk rgbkrk Feb 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I didn't realize we could add multiple headers with the same key. How does set_header work when there are multiple headers with the same key from add_header?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think set_header blows away anything that was set before.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My question comes down to "what's the set of headers after running the following"

self.add_header("X", "y")
self.add_header("X", "z")
self.set_header("X", "x")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AIUI, only X: x would remain.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking using only one header is good. For now I think the value you've set here is a very sane default and further enhancements on merging content security policies can be separate work.

@takluyver
Copy link
Member Author

OK, I've redone this to achieve the same thing by overriding the content_security_policy property, so it shouldn't interfere with other policies we've set.

@rgbkrk
Copy link
Member

rgbkrk commented Mar 8, 2018

I just re-kicked the appveyor build and somehow it went faster than I expected.
¯\_(ツ)_/¯

At any rate, I certainly approve again. 😄

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants