JSDOM and Security

[greim]

If I use node/jsdom to load random HTML pages from the web and parse
them unquestioningly into DOM trees, what are the security
implications? Can a maliciously-crafted page do bad things on my
system? Or is it all tightly sandboxed?

[Elijah Insua]

On Thu, Dec 16, 2010 at 6:46 PM, greim <gregr...@gmail.com> wrote:

If I use node/jsdom to load random HTML pages from the web and parse
them unquestioningly into DOM trees, what are the security
implications?

Strictly speaking, parsing html is safe.  The real problem is when you start executing scripts from an untrusted source.

 

Can a maliciously-crafted page do bad things on my system?

Yes, someone could potentially add a <script>process.exit()</script> and shutdown your node process.

 

Or is it all tightly sandboxed?

Not currently, although the javascript execution sandbox needs some love and I would love to see more flexibility in this area.

For the moment, I'd suggest turning off script execution which can be done like so: https://github.com/tmpvar/jsdom/blob/master/test/jsdom/index.js#L108-113

-- Elijah

 

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[greim]

Thanks for the reply. Wow.

Given that browsers are tightly sandboxed environments, client-side JS
devs (such as myself) may not immediately grok the implications of
loading pages in a non-sandboxed environment. This was informative.
Maybe this is something that could be stressed in the documentation,
lest the message become lost in the "hey we can do server-side dom
now!" noise?

Thanks,
Greg

On Dec 17, 10:30 am, Elijah Insua <tmp...@gmail.com> wrote:

> On Thu, Dec 16, 2010 at 6:46 PM, greim <gregrei...@gmail.com> wrote:
> > If I use node/jsdom to load random HTML pages from the web and parse
> > them unquestioningly into DOM trees, what are the security
> > implications?
>
> Strictly speaking, parsing html is safe.  The real problem is when you start
> executing scripts from an untrusted source.
>
> > Can a maliciously-crafted page do bad things on my system?
>
> Yes, someone could potentially add a <script>process.exit()</script> and
> shutdown your node process.
>
> > Or is it all tightly sandboxed?
>
> Not currently, although the javascript execution sandbox needs some love and
> I would love to see more flexibility in this area.
>
> For the moment, I'd suggest turning off script execution which can be done
> like so:https://github.com/tmpvar/jsdom/blob/master/test/jsdom/index.js#L108-113
>
> -- Elijah
>
>
>
>
>
>
>
>
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

[Ryan Gahl]

Personally I don't see a huge difference in terms of best practices. Thinking of the server as just another client (which is true for this usage profile), you don't willy nilly load scripts from other domains and execute them in a browser (and by explicitly doing so you have declared that you trust that code to run), so don't do it on the server either. Sandboxing to me is a separate discussion.

---
Warm Regards,
Ryan Gahl

To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Dean Landolt]

On Fri, Dec 17, 2010 at 6:25 PM, Ryan Gahl <ryan...@gmail.com> wrote:

Personally I don't see a huge difference in terms of best practices. Thinking of the server as just another client (which is true for this usage profile), you don't willy nilly load scripts from other domains and execute them in a browser (and by explicitly doing so you have declared that you trust that code to run), so don't do it on the server either. Sandboxing to me is a separate discussion.

As a user of your web browser client you sure do load scripts willy nilly. And if your server is just another client scraping pages with jsdom is sandboxing still a separate discussion?

[Ryan Gahl]

Good point. It still seems like the answer is in the range of "if you don't explicitly trust the site don't visit it", but you're right; sandboxing gives you another layer of protection.

--

[Elijah Insua]

This is why I mentioned the fact that the script execution aspect of jsdom needs some love.  For templating and runat="server" type stuff, it is not as important to sandbox the script execution, but loading scripts from the wild web definitely deserves a secure container.

Basically, we need granular control over script execution between "same origin policy" to "no access to require/process/etc" all the way to "I dont care, allow it all".  With this in mind, selecting a sane default becomes much more important.

The old security vs usability doesn't really apply here as jsdom is a development tool that we all own. As of right now, it follows an "execute everything or nothing model", but I'm be happy to hear how you all think this should change.

-- Elijah

[greim]

I've also observed that if you use jquery to detach a node containing
a script and then re-add it to the document, jquery happily re-
executes the script for you (whereas using native DOM methods this
won't happen.) This takes many programmers by surprise, as it did me
at one point. My point being that you'd want a way to sandbox all
script execution, not just ones initiated by jsdom itself.

Sorry, not trying to pick on jsdom, just trying to improve my own
understanding and possibly bring some issues to attention. I'm
actually really excited about this library.

Greg

On Dec 17, 6:05 pm, Elijah Insua <tmp...@gmail.com> wrote:
> This is why I mentioned the fact that the script execution aspect of jsdom
> needs some love.  For templating and runat="server" type stuff, it is not as
> important to sandbox the script execution, but loading scripts from the wild
> web definitely deserves a secure container.
>
> Basically, we need granular control over script execution between "same
> origin policy" to "no access to require/process/etc" all the way to "I dont
> care, allow it all".  With this in mind, selecting a sane default becomes
> much more important.
>
> The old security vs usability doesn't really apply here as jsdom is a
> development tool that we all own. As of right now, it follows an "execute
> everything or nothing model", but I'm be happy to hear how you all think
> this should change.
>
> -- Elijah
>
>
>
>
>
>
>
> On Fri, Dec 17, 2010 at 7:33 PM, Ryan Gahl <ryan.g...@gmail.com> wrote:
> > Good point. It still seems like the answer is in the range of "if you don't
> > explicitly trust the site don't visit it", but you're right; sandboxing
> > gives you another layer of protection.
>

> > On Fri, Dec 17, 2010 at 5:58 PM, Dean Landolt <d...@deanlandolt.com>wrote:

>
> >> On Fri, Dec 17, 2010 at 6:25 PM, Ryan Gahl <ryan.g...@gmail.com> wrote:
>
> >>> Personally I don't see a huge difference in terms of best practices.
> >>> Thinking of the server as just another client (which is true for this usage
> >>> profile), you don't willy nilly load scripts from other domains and execute
> >>> them in a browser (and by explicitly doing so you have declared that you
> >>> trust that code to run), so don't do it on the server either. Sandboxing to
> >>> me is a separate discussion.
>

> >> As a user of your web browser *client* you sure do load scripts willy
> >> nilly. And if your server is just another *client* scraping pages with

> >> jsdom is sandboxing still a separate discussion?
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "nodejs" group.
> >> To post to this group, send email to nod...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/nodejs?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .