<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Long response to many messages.<div><br></div><div>tl;dr :</div><div>&nbsp;lots of good idea, some misconception, a few good point raised.<br><div><br><div><div>Le 11 déc. 2012 à 02:48, Carl Smith a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">A static notebook is just a webpage, so it should ideally behave like<br>one. Any webpage can execute arbitrary JavaScript, so the fact that<br>static notebooks have this ability is not a concern in itself.</span></blockquote></div><div><br></div><div>I think it is. In nbviewer we would like to allow people to comment,&nbsp;</div><div>which obviously require them to be logged in… so it is not **exactly** static.</div><br><div></div><blockquote type="cite"><div>Static notebooks, served from a different domain, could be rendered<br>inside iframes, enabling us to embed them inside other webpages and<br>applications. These notebooks would still be superficially served by<br>our own servers, so the UX wouldn't be effected.</div></blockquote><div><br></div>keep in mind that iframe are not sandboxed, and you can inject js on parent frame.&nbsp;<div>Unless you use the sandbox attributes, which is part of html5 but not implemented in every</div><div>browser… And not yet infallible, it is more a "we'll help you embed other pages by providing a separate&nbsp;</div><div>js namespace but we don't guaranty yes that the VM is unbreachable"<br><div><br></div><div><br></div><div><blockquote type="cite">I don't have much to say about kernelled notebooks right now, but on<br>statics, I'd like to ask: If we serve a static notebook from a domain<br>which has zero features beyond hosting static notebooks, would those<br>notebooks be able to do anything to a user that a regular webpage<br>couldn't? I'm not a security guy, so I really don't know, but it seems<br>that we'd be totally free to let users publish whatever they liked,<br>with no more restrictions than browsers impose already.</blockquote><br></div><div>We still have some responsibility of what is displayed.</div><div><br></div><div>Responsible disclosure don't want to say much more but but having a statically display&nbsp;</div><div>notebook is often link to having a "sharing/import" button which is dangerous.</div><div>And could lead to self propagating notebook through account that can infect other&nbsp;</div><div>notebooks, or share itself on twitter...</div><div><br></div><div><br></div><div><blockquote type="cite">The main point is that we gain nothing by trying to cripple and<br>sanitise JavaScript in notebooks. I think??</blockquote><div><br></div>I know that Brian does not agree with that, but I am on your side with this point.</div><div>Except that preventing javascript might force people to do things "the right way".</div><div>This will lead to project that will still works across IPython version, whereas displaying JS have great chance to break.</div><div><br></div><div><br></div><div><blockquote type="cite">To fix this, we need to disable the Javascript representation of<br>objects altogether.</blockquote><blockquote type="cite">Unless I am misunderstanding the nature of the security risks, I think<br>this is what we should do.</blockquote></div><div><div><br></div>I disagree with the direct implication, but agree with the fact that disabling javascript repr can be done and will lead to cleaner code.</div><div>Flaws are **not** in repr. Flaws are mostly in assumption made on ipynb as a format and our html frontend. &nbsp; And please stop considering that the "ipython notebook" is&nbsp;</div><div>the only tool that generate ipynb files and use them.</div><div><br></div><div>We really have to choose a more appropriate vocabulary to speak of&nbsp;</div><div>* ipynb as file</div><div>* ipynb as a format</div><div>* A notebook as the repr of a given ipynb files view throughout **our** html frontend.</div><div>* **Our** notebook server.</div><div><br></div><div>We should **not** consider that danger come from html/js repr but from **forged** ipynb file.</div><div><br></div><div>I challenge you to find a PDF generated from a tex file with pdflatex that trigger a breach in adobe reader.&nbsp;</div><div>Anyone ?</div><div><br></div><div>Did anybody have a jpeg that came directly from his/her camera that trigger privileges escalation on windows ?</div><div>No ?</div><div><br></div><div>Corrupted mp3 that crash your computer from audacity ?</div><div><br></div><div>Do you consider that a script that ask for your root password is a virus/malware.. ?</div><div><br></div><div>Example :</div><div><br></div><div>#!/bin/bash&nbsp;</div><div>sudo rm -rf &nbsp;--no-preserve-root /</div><div><br></div><div>No, you just give the ability to do anything, you just make the ability to do bad stuff painful.</div><div>So my take on this one is :</div><div><br></div><div>Allow javascript only if:</div><div><br></div><div>server is **started** with some painfull flag &nbsp;--yes-i-know-what-i-do-i-want-to-enable-js-in-output</div><div>When Js arrives to **frontend** in an output (see i didn't &nbsp;tell where it came from… it could be at load time)</div><div>If the above flag has been set,&nbsp;</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>modal dialog&nbsp;</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>"something want to display js, allows for this session ? " (5 sec count down for before ok button becomes clickable.)</div><div><br></div><div><blockquote type="cite">Regardless of the approach taken, I think that Carl's suggestion of using separate domains for viewing &amp; editing notebooks should be taken to heart. &nbsp;It does help eliminate one vector of attack.</blockquote><br></div><div>Multi domain is a real good idea. I have a clear view in my head on how we could use that in a way close to OAuth to allow javascript by still having "logged-in" users.</div><div>It wouldn't be as seamless a something like github, but close.</div><div><br></div><div><blockquote type="cite">But am I not correct that with the measures I proposed, that attack<br>vector is also rendered null? &nbsp;I don't want to have to tell people -<br>you have to run multiple domains when using the notebook. &nbsp;In many<br>cases, people ar running the notebook without any DNS whatsoever…<br></blockquote><div><br></div><div>The **big** question is:</div><div>Are viewer logged in (in any way) to the given server, and if so do they have the right to do anything else with those credentials ?</div><div>If it is just a public notebook viewer, then it's fine.</div><div><br></div><div>If you want something more "interactive" (sharing/ permissions…etc, and the display any JS ) you won't have much choice.</div><div>Or you will have a painful multi-login.</div><div><br></div><div>In any way this I thing should not diminish the fact that we should tell IPython notebook user to only&nbsp;</div><div>view and even more download ipynb files from people they **trust**.</div><div><br></div><div>One good plugin for IPython notebook might be gpg-notebook-signing and chain of trust.</div><div><br></div></div><div><br></div><div><blockquote type="cite">It appears that IPython.core.display.HTML() allows &lt;script&gt; tags in the&nbsp;<br>html the user submits:<br><br>import IPython<br>IPython.core.display.HTML('&lt;script&gt;alert("hi")&lt;/script&gt;')</blockquote><br></div></div><div>Yes this the issues are that in particular **those** are executed at load time.</div><div><br></div><div>To conclude I would say that Nobody did bring the question of security while collaborating, which is a much more difficult question.</div><div><br></div><div>also I've already written some stuff on js/security in IPep 3, feel free to complete or even make it &nbsp;a separate IPep only focused on security.</div><div><br></div><div><a href="https://github.com/ipython/ipython/wiki/IPEP-3:-Multiuser-support-in-the-notebook">https://github.com/ipython/ipython/wiki/IPEP-3:-Multiuser-support-in-the-notebook</a></div><div><br></div><div><br></div><div>Cheers.</div><div>--&nbsp;</div><div>Matthias</div><div><br></div></div></div></body></html>