
JSCert: Certified JavaScript - lelf
http://jscert.org/
======
inglor
You can't talk about JavaScript formal analysis for security without
mentioning Mark Miller's amazing work here: [http://www-cs-
students.stanford.edu/~ataly/Papers/sp11.pdf](http://www-cs-
students.stanford.edu/~ataly/Papers/sp11.pdf)

Here, not only does he built a secure subset of JavaScript and _prove_ it's
tamper safe using formal logic, Mark also finds exploits with the same method
in high end tamper filters like Yahoo's.

Definitely impressive use of formal logic in language analysis.

~~~
nickpsecurity
Nice paper. Thanks for it.

------
nickpsecurity
Excellent work as usual in practical, formal methods by INRIA. Much of the
formal work in academia amount to just screwing around or redoing the same
stuff. INRIA is awesome because their work is often useful to the rest of us:
robust languages, compilers, parsers, protocols, static analysis tools, WCET
estimation, easier-to-use provers... list goes on.

INRIA and especially Xavier Leroy's people rock! That simple. :)

------
inglor
It's probably a good idea to link to the presentation directly as it explains
the point and methodology more clearly IMO:
[http://jscert.org/popl14/?full#1](http://jscert.org/popl14/?full#1)

------
MichaelCrawford
I applaud every effort to improve Javascript as it all takes eons to download
over my dialup but commonly does not actually work.

A favorite contribution is called something like "You Don't Really Need
jQuery". I will dig it up,in a little bit.

Of most serious concern is how to convince the working JS coder to actually
avail themselves of better javascript? Most dont read HN. I find it is of no
use to point out the errors of their ways.

~~~
CHY872
This isn't for that. This work is to create a formal model of Javascript - a
definition of what a perfect Javascript runtime should do. The next step
(potentially) is then that you can reason about Javascript programs in a
useful manner - you could prove that your security-critical script does the
right thing, for example.

Generally, such work does not lead to many updates to the state of the art -
but is useful in its own way.

~~~
MichaelCrawford

       "I'm not really bad; I'm just drawn that way."
        -- Jessica Rabbit
    

I see your point, but my concern that the coder who implements a security-
critical script doesn't know he should use tools like this one.

Lots of those who use other languages like to gripe about the many faults of
PHP. While I agree that PHP has its problems I've used lots of languages that
were far, far worse. My take is not that PHP is a bad language but that those
who use it are often bad programmers.

Take Bill at [http://www.radioparadise.com/](http://www.radioparadise.com/) He
at first built the sight with phpNuke, but rewrote it from scratch in the best
of just a few days after "some boys from Brazil" overran it. Radio Paradise is
still built on PHP, the difference is that Bill is an excellent engineer.

~~~
CHY872
They shouldn't use tools like this one, though. This is purely a research
project and not industrially usable. In any case, the purpose is to specify
what Javascript is _supposed_ to do, and not what Javascript engines actually
do.

The interpreter was as easily as not an afternoon project; they probably got
one for free.

There's been some interesting discussion about this for the C language -
useful yet undefined behaviours that are relied upon by many pieces of
software, where a formal semantics such as this project may fall flat and lead
to being overly restrictive.

[https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-...](https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-survey-
discussion.html)

~~~
MichaelCrawford
It would be a valuable contribution to publish the difference between what
your tool says JS should do, and what production interpreters really do with
that same JS source.

I expect there is an open source test suite available.

While at Apple in 1995 I came across a common in our system software that said
"MacDraw needs this". Apple had a lending library with every third-party
product that had ever been published, but for QA and bug isolation only.

My job was mostly to isolate crashes that were stimulated by third party code.
About half the time it was their fault; to the extent we possibly could we
isolated it anyway by reverse-engineering their binaries. Apple Developer Tech
Support would work with the developers to help them fix it.

Sometimes its OK to depend on undocumented behavior, sometimes its not.
Embedded systems for example might never receive new firmware so if the
release firmware complies with specification then that undocumented behavior
is completely cool.

