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

Projects
None yet
3 participants
@takluyver
Copy link
Member

takluyver commented Feb 15, 2018

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')

This comment has been minimized.

@rgbkrk

rgbkrk Feb 15, 2018

Member

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.

This comment has been minimized.

@takluyver

takluyver Feb 15, 2018

Author Member

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?

This comment has been minimized.

@minrk

minrk Feb 15, 2018

Member

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.

This comment has been minimized.

@takluyver

takluyver Feb 15, 2018

Author Member

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?

This comment has been minimized.

@rgbkrk

rgbkrk Feb 15, 2018

Member

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?

This comment has been minimized.

@takluyver

takluyver Feb 15, 2018

Author Member

I think set_header blows away anything that was set before.

This comment has been minimized.

@rgbkrk

rgbkrk Feb 15, 2018

Member

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")

This comment has been minimized.

@takluyver

takluyver Feb 15, 2018

Author Member

AIUI, only X: x would remain.

This comment has been minimized.

@rgbkrk

rgbkrk Feb 15, 2018

Member

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.

@rgbkrk

rgbkrk approved these changes Feb 15, 2018

@takluyver

This comment has been minimized.

Copy link
Member Author

takluyver commented Mar 8, 2018

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

This comment has been minimized.

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. 😄

@rgbkrk

rgbkrk approved these changes Mar 8, 2018

@takluyver takluyver merged commit e321c80 into jupyter:master Mar 9, 2018

4 checks passed

codecov/patch 75% of diff hit (target 0%)
Details
codecov/project 78.02% (+0.08%) compared to 25c628c
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@takluyver takluyver deleted the takluyver:csp-sandbox-files branch Mar 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.