Why it's so hard to secure JavaScript

@Kragen

 

 

IDS' are looking for anomalies in the stream. The stream is often text, and in some cases it's executable content - such as when an e-mail is carrying an attachment, or an attachment in a SOAP message, or a download via HTTP. In those cases they are most certainly looking for known signatures indicating problems inside executable content.

 

 

Is it *really* the object code? No. I skipped a step in there, my deepest apologies. It doesn't change the basic fact that they're signature based and can't really do anything about interpreted code.

 

 

FBJS is in a way different category than generalized JavaScript. ADsafe is a library that runs as part of the page, IOW it's on the browser. I assume Caja is similar. These are not *external* they are still libraries, on the client, running in the confines of the browser.

 

 

The general point is that no external - as in *external to the browser* - solution exists that parses/verifies/contains JavaScript in the manner that solutions exist for XML, HTML, and other text-based languages.

 

 

But I am glad to see pointers to *some* option for JavaScript, though FBJS is too specific to FB, and the documentation on ADsafe isn't enough to convince me. That's a failure of the documentation, however, not a condemnation of the library.