JavaScript Native Extensions

[Amnon]

Hi,

I'd like to announce release 1.0.7 of JNEXT (JavaScript Native
Extensions). JNEXT is an open source framework for securely accessing
the full range of native OS resources (files, databases, sockets etc.)
by using JavaScript from within a Web Page. It is light weight, cross
platform, cross browser and designed with simplicity in mind.

More information is available at http://jnext.org

If there are any Mac developers that wish to help port the framework to
OS/X please contact me. Also any developers that wish to extend the
framework with additional plugins are welcome to send an email for more
information.

Thanks,
Amnon

 

[Douglas Crockford]

I'd like to announce release 1.0.7 of JNEXT (JavaScript Native
Extensions). JNEXT is an open source framework for securely accessing
the full range of native OS resources (files, databases, sockets etc.)
by using JavaScript from within a Web Page. It is light weight, cross
platform, cross browser and designed with simplicity in mind.

More information is available at http://jnext.org

JavaScript's design is centered around a global object that is the shared
container for all of the scripts on a page. JavaScript gives every script the
same rights and privileges, regardless of where they came from or how they got
on the page. This is what enables XSS attacks. If an attacker can get script
onto your page, their script can do anything your script can do, including
talking to your server. There is no way your server can tell your script and
their script apart.

The problem is worsened by the web's use of several languages (HTTP, HTML, CSS,
JavaScript, URL, SQL, etc) that can all be embedded in each other, that all have
different quoting, commenting, and escapement conventions. This makes it
surprisingly easy for an attacker to hide scripts in content that appears to be
safe.

In that context, you want to give scripts access to the native resources. This
is extremely risky.

Ultimately, we need to replace JavaScript with a secure language, a language
that resists XSS attacks. The proposed ES4 that is being debated right now is
not that language. It retains the global object, and adds a lot of complicated
stuff. It is a move in the wrong direction.

The capabilities provided thru JNEXT are certainly useful. But until we fix the
browser, it isn't safe to make them available to web pages.

http://javascript.crockford.com/

 

[Peter Michaux]

Ultimately, we need to replace JavaScript with a secure language, a language
that resists XSS attacks. The proposed ES4 that is being debated right now is
not that language. It retains the global object, and adds a lot of complicated
stuff. It is a move in the wrong direction.

In the last few talks of your's that I have watched you have repeated
this point about security and mashups with a good case built up why
change is needed. I've also seen several sources where you make
negative comments directly or implied about ES4. You were part of the
ES3.1 proposal but it doesn't fix the problems either.

I think the negativity deserves some balance. Now that folks have
heard your message and how the situation and committee proposals
(HTML, CSS, ES) it is currently all wrong, how about you and a gang of
Yahoo! programmers write a new browser with a new model for the web
that is backwards compatible (ie can render current pages) and will
take us the next 10 years?

Peter

 

[Amnon]

The problem is worsened by the web's use of several languages (HTTP,
HTML, CSS, JavaScript, URL, SQL, etc) that can all be embedded in each
other, that all have different quoting, commenting, and escapement
conventions. This makes it surprisingly easy for an attacker to hide
scripts in content that appears to be safe.

In that context, you want to give scripts access to the native
resources. This is extremely risky.

You make a valid point about security issues with the current state of
affairs. My angle on this is that the problems cannot be addressed by
starting from scratch, not because it's not right to do it, but simply
because it is not feasible.

JNEXT attempts to address the security issues by means of a white list,
stored in a file on the client side. The only way for a malicious script
to do harm is to be located on a site which has been explicitly added by
the user as a trusted site. While there will always be workarounds by
hackers, I think this is a reasonable solution but of course I'll
welcome any suggestions for improvements.

With JNEXT, it

The capabilities provided thru JNEXT are certainly useful. But until we
fix the browser, it isn't safe to make them available to web pages.

If you learn anything from history, then you understand it is naive to
assume it is possible to make a fool proof (or hacker proof) system. The
best you can do is raise the bar on the amount of creativity and
intelligence that is required to break the system and, as I stated
earlier, I believe this is going to be a evolutionary process and not a
revolutionary one.

-Amnon