search

jupyter / nbconvert

Jupyter Notebook Conversion
https://nbconvert.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
1.73k stars 566 forks source link

HTML export and XSS #238

Open pferreir opened 8 years ago

pferreir commented 8 years ago

I'm not sure this is the right repo to post this issue to, but here it goes: embedding arbitrary Jupyter notebooks in web sites currently means a trade-off between security and functionality. Many notebooks require inline JavaScript or access to CDNs that include too wide of a choice for whitelisting to be even an option. Services like GitHub have chosen to strip notebooks of unsafe JavaScript and CSS and link to nbviewer when necessary. In our case (Indico) we are setting a restrictive CSP and whitelisting the MathJax libraries. I believe it will become increasingly more difficult to provide people with a pleasant notebook browsing experience as new, more interactive JS-based libraries are developed.

My idea for a possible long term solution would be to work on a declarative model that doesn't require inline JavaScript/CSS, together with a clear specification of notebook dependencies which host applications can provide locally (and whitelist/blacklist modules as necessary). For instance, my notebook might declare it needs BokehJS or MathJax. It would be up to the server to provide those if present (and when required). From what I understand, Jupyter notebook extensions already use require.js, so, it wouldn't be hard to set up a local base URL. On the other hand, there are lots of notebooks sourcing JS from external CDNs. That would be blocked.

As for the declarative model, I wonder if data- attributes could be used to specify that a particular cell should be targeted by a particular JS library. That would remove the dependency on inline JS and degrade gracefully if the JS code for the plugin cannot be loaded.

Those are just ideas, based on my perception of the way Jupyter works. I really like the interactive experience that is provided and it would be great if we could have that everywhere. A shorter term solution could be providing a "strict mode" that would sanitize all potentially unsafe HTML/JS/CSS on export.

takluyver commented 8 years ago

We have had a similar idea before for nbextensions, so that, for instance, a notebook could have metadata specifying that it used a table of contents extension, which would be automatically loaded if the user had it installed. I don't think that would have extended to static renderings, though, which this would.