[Python-talk] [js] Javascript Uber Alles? Is script without the sandbox a good idea?

Ben Scott dragonhawk at gmail.com
Tue Jul 3 22:05:30 EDT 2007


On 7/3/07, Lloyd Kvam <lkvam at venix.com> wrote:
> HTML is simply a bunch of text tags.

  One could say the same about JavaScript.  <--- rhetorical

  We like to think of JavaScript "taking actions", and HTML generally
just "displaying stuff", and that's their original purpose, to be
sure.  But both are decidedly non-trivial -- a complete HTML/CSS/HTTP
stack is a rather complicated beast.  In a perfect world, sure,
"passive" HTML would be safer.  But if this world was perfect, we
wouldn't be having this discussion...

> Javascript offers programmed access into local files (cookies),
> connections to servers, generated text, and more.  Bugs in the sandbox,
> programming errors, and general complexity open avenues for attack.

  Heh.  Just to illustrate my point: Every single one of those has a
non-JavaScript equivalent.  Cookies?  Existed before LiveScript was
created.  Connections to servers?  HTTP (duh).  Generated text?
Server-side scripting (e.g., phishing pages)  (What differences does
it make *where* the malicious text got generated?).  Sandbox bugs?
Exploitable browser bugs.  General complexity?  See above.

  JavaScript does do some things you didn't mention:

  JavaScript increases the attack surface.  Having a JavaScript
interpreter means more code (vs not having one), and more code means
more opportunities for exposure.  (Of course, this is a continuum,
like most things in security.  netcat+less likely makes for a very
secure, if rather feature-poor, web browser.)

  JavaScript allows a greater range of by-design capabilities than
just HTTP+HTML+CSS.  I kept trying to put that in less general terms,
but every time I got specific, I could think of a case where a non-JS
web system was (ab)used in the past to similar ends.

  Cross-site cookie stealing?  Early HTTP cookie implementations
allowed everyone to access everyone else's cookies.

  "Just viewing a web page" causing connections to other servers to be
initiated?  IMG, IFRAME, OBJECT, etc.  Tracking via images ("web
bugs").

  JavaScript injection in public forms?  HTML and SQL injection in same.

  Things happening in response to "clicks on a web page"?  HTML forms
and image submit buttons.

  I'm not trying to argue that one should just give up.  I'm not even
saying NoScript is worthless.  My points are (1) FWIW, a lot of these
problems are not unique to JavaScript and (2) these issues were
addressed, over time, when they didn't involve JavaScript; I believe
they can also be addressed when they do involve client-side-scripting.

> There is always the possibility of an exploitable browser bug, but I
> think the risk with open source browsers is reasonably low.

  I think your trust in Open Source as a panacea is gravely misplaced.

  I know of at least one exposure in Mozilla which went unfixed for
years -- it made Slashdot.  (It had do with URI scheme handlers, IIRC.
 It's been awhile.)

  The list of security advisories for Firefox is decidedly non-empty:

http://www.mozilla.org/projects/security/known-vulnerabilities.html

  In general, in practice, I haven't found Open Source to be
intrinsically more secure than closed source software.  There's the
opportunity for peer code review, true, but it seems we still get
plenty of bugs found by black hats, and either way, it means I'm
installing patches.  I agree with the theories that give FOSS as
potentially more secure, but their realization is canceled by other
factors (mostly human).

  I'm a fan of FOSS, don't get me wrong, I'm just saying in practice,
we don't seem to realize the supposed security benefits of FOSS.

>> And you put email into the picture, and geez...
>
> And you keep automatic image loading off so that you don't notify the
> spammers that you opened the email, Right??

  I wasn't even thinking of that.  I was thinking of the fact that an
MUA (which also includes HTML and CSS, these days) is as complicated
as any HTTP/HTML UA, if not more so.  It seems that exploiting bugs in
MTAs and MUAs has gone out of vogue lately (I don't know why), but
that used to be a very popular avenue of attack.  And unlike the web,
email doesn't need you to surf on to a compromised page -- they can
just send you the exploit direct, since we so conveniently publish MX
records.

  There's also the fact that the weakest link in security -- for web
or email -- is usually the operator.  Present-day spyware, adware, and
email worms are still mostly of the "get the luser to run my code on
their computer" variety.  I imagine anyone on this list is smart
enough to not do that in general, but mistakes can still happen...

> When necessary, I'll allow sites to use javascript or flash, but it's
> my decision.

  As I said, I found that I ended up enabling JavaScript on way too
many sites.  If I end up doing that, is it really "my decision"?  <---
rhetorical

  Less rhetorical: The sites that I enabled it on were also the sites
that were most likely to be used for JavaScript attacks: Big name
sites with lots of user-posted content, like Slashdot, Wikipedia,
Yahoo, Google, etc.  And porn sites, of course.

>>   Whether the final ultimate solution is a better JavaScript sandbox,
>> or something else entirely (maybe sandboxed Python -- ha!  on-topic!),
>> I think this kind of thing is inevitable.
>
> Oddly enough, I can often skip right through register-to-view-screens
> and on to the "protected" content ...

  Um.  Okay.  Good for you.  So what?  :)  That comment seems a bit of
a non-sequitur.

On 7/3/07, Lloyd Kvam <lkvam at venix.com> wrote:
>>  I tried NoScript myself, for a while.
>
> The security works.

  I'm not so sure.  I believe NoScript works in the sense that it
successfully (dis)ables JavaScript on a domain-by-domain basis.
Whether that yields a real-world improvement in defense against
JavaScript attacks, I'm not sure.  See above.

-- Ben


More information about the Python-talk mailing list