Standard JS debugging API

[Daniel C. Wang]

I would much rather have a standard hook that lets me intercept 
javascript before it's executed. You can  expose the javascript syntax 
tree encoded as JASON, or just give people a string representing of the 
code that's  going to be executed. This would let you write a generic 
debugger that worked via dynamic instrumentation, and also have an 
official way to implement the following approach to avoid XSS attacks.

http://www2007.org/paper595.php

* Paper Title:*
Defeating Script Injection Attacks with Browser-Enforced Embedded Policies

* Authors:*

    * Trevor Jim (AT&T Labs Research)
    * Nikhil Swamy (University of Maryland)
    * Michael Hicks (University of Maryland)

* Abstract:*
Web sites that accept and display content such as wiki articles or 
comments typically filter the content to prevent injected script code 
from running in browsers that view the site. The diversity of browser 
rendering algorithms and the desire to allow rich content makes 
filtering quite difficult, however, and attacks such as the Samy and 
Yamanner worms have exploited filtering weaknesses. To solve this 
problem, this paper proposes a simple mechanism called Browser-Enforced 
Embedded Policies (BEEP). The idea is that a web site can embed a policy 
inside its pages that specifies which scripts are allowed to run. The 
browser, which knows exactly when it will run a script, can enforce this 
policy perfectly. We have added BEEP support to several browsers, and 
built tools to simplify adding policies to web applications. We found 
that supporting BEEP in browsers requires only small and localized 
modifications, modifying web applications requires minimal effort, and 
enforcing policies is generally lightweight.


Erik Arvidsson wrote:
> I'm just forwarding this from an internal company mailing list:
>
> Short version:
> JS/ECMA should have a standard interface that JS-VM writers can
> implement, so that third-party tool-vendors can write debuggers that
> will work for any browser (or other JS-VM host) that supports this
> debugging interface.  This would create a market for debugger
> products, and would make web development much more attractive than it
> is today.
>
>
> Long version:
> There are lots of JS debugging tools, like Firebug, Venkman, IE script
> debugger, JS shell, Safari's new Drosera, etc.  I believe each is
> tightly coupled own JS VM.
>
> Java doesn't have a debugger UI, but it has a low-level debugging
> interface, wire protocol, and high-level interface:
> http://java.sun.com/j2se/1.4.2/docs/guide/jpda/architecture.html.
> Each JVM vendor (Sun, IBM, whatever) implements the debugging
> interface, without worrying about the debugging UI.  Tool developers
> (Eclipse, IntelliJ, CodeGuide, etc) write debugging UIs that can debug
> on any such JVM on any machine, locally and remotely.
>
> The API includes stuff like adding and removing breakpoints and
> watchpoints, execution control, an event system, queries, callstacks,
> all the standard stuff.
>
> That seems like a really good model.  But as far as I can tell,
> there's not even a proposed spec for a standard JS debugging
> interface.  Having such a standard spec, and a reference
> implementation, would make web development much more attractive.
> [snip]
>
>