[IPython-dev] Some Thoughts on Notebook Security
Mon Dec 10 22:18:23 CST 2012
Sent from my iPhone
On Dec 10, 2012, at 11:12 PM, Brian Granger <email@example.com> wrote:
> I appreciate your thinking about this. It is really important. But I
> think it *may* simple to fix:
> There are two issues we have:
> * In markdown cells users can put arbitrary HTML and JS.
> To fix this, we need to enable the HTML sanitizer that comes with the
> JS Markdown rendered that we are using. This is what StackOverflow
> uses to sanitize their markdown and should completely remove any
> security risks coming from within markdown cells.
> into eval. This only happens when code is run, not when the notebook
> is loaded, so it is less critical, but still needs to be fixed.
> objects altogether.
> Will these two things not completely fix the security problems we
> currently have?
> Now the question is how to enable all of the nice things you can do
> and JSON handlers:
> the person who runs the notebook server once and for all notebooks on
> that server. Similar to how python packages are installed = you do
> this before you start python. To get data from python to the
> to handle them.
> Unless I am misunderstanding the nature of the security risks, I think
> this is what we should do.
> On Mon, Dec 10, 2012 at 5:48 PM, Carl Smith <firstname.lastname@example.org> wrote:
>> The IPython Notebook's vulnerability to cross-site scripting and
>> cross-site request forgery, XSS and XSRF, is a serious problem that
>> provides baddies with a range of attack vectors, each with almost
>> unlimited potential for harm to the user. Attempting to find a single
>> solution to so many problems is overwhelming and almost bound to fail.
>> Therefore, we will likely benefit from breaking the problem down,
>> insofar as we're able.
>> The most obvious place to start is to distinguish between static views
>> of a notebook and a notebook that has a running kernel, which I'll
>> call static notebooks and kernelled notebooks for lack of a
>> A static notebook is just a webpage, so it should ideally behave like
>> static notebooks have this ability is not a concern in itself.
>> Serving all static notebooks from a separate domain should prevent XSS
>> and XSRF attacks because of the Same Origin Policy.
>> Static notebooks, served from a different domain, could be rendered
>> inside iframes, enabling us to embed them inside other webpages and
>> applications. These notebooks would still be superficially served by
>> our own servers, so the UX wouldn't be effected.
>> Using randomised URLs, or some other scheme that does not validate
>> requests by stored credentials, may allow us to serve notebooks from
>> the separate domain while keeping access to the notebooks private.
>> This may be useful when users wish to share a static notebook
>> removing it altogether. This seems like a bad idea as many static
>> notebooks, particularly in the long run, will need to be able to use
>> never-ending spiral.
>> I think we need to build on browser security, and therefore trust it,
>> rather than build a heap of nasty hacks, which may be circumvented
>> Just taking it back to basics for a moment: If Malory signs up for a
>> dating site, she might decide to put some dodgy JS inside some script
>> tags, and submit that as part of her profile. If the site doesn't
>> sanitise that HTML, we all know how it plays out; any poor chap that
>> thinks she's a hotty gets pwned. Sanitising her input is textbook.
>> Static notebooks are a totally different scenario. User's will want to
>> include JS and have it work when publishing a static notebook. This is
>> a feature of the Notebook. Furthermore, there's a number of ways to
>> get JS into a static notebook, some more subtle than others, while a
>> dating site is only dealing with text from an input field.
>> I don't have much to say about kernelled notebooks right now, but on
>> statics, I'd like to ask: If we serve a static notebook from a domain
>> which has zero features beyond hosting static notebooks, would those
>> notebooks be able to do anything to a user that a regular webpage
>> couldn't? I'm not a security guy, so I really don't know, but it seems
>> that we'd be totally free to let users publish whatever they liked,
>> with no more restrictions than browsers impose already.
>> I just don't want to see hours of work ploughed into crippling a super
>> powerful feature, if we could just an use extra domain with a simple
>> API instead.
>> IPython-dev mailing list
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> email@example.com and firstname.lastname@example.org
> IPython-dev mailing list
More information about the IPython-dev