Re: [caplet] Re: ADsafe, Take 3
- No because ]]> can end a CDATA section introduced by the embedding XHTML page which would then allow the embedding script to play tricks with entities that aren't recognized by your lexer. Consider /* */ .constructor /**/ where 42 === ord('*')
Given that XHTML allows arbitrary entity definitions in DOCTYPE elements, you can't modify your lexer to recognize all entities, so if you want to restrict ADsafe JS to embeddable JS, the only thing you can do is disallow anything that looks like an entity in a pre-lexer pass.
There's a few ways to do this:
- require that the <, >, >=, >>, <<, %, &, and && operators and their self-assignment versions be separated by whitespace from other tokens
- require that characters in [<>&%] in string literals and regular expressions be hex/octal/unicode escaped
mikeOn 04/10/2007, Douglas Crockford <douglas@...> wrote:
--- In email@example.com, "Mike Samuel" <mikesamuel@...> wrote:
> If you do want to allow ADsafe JS to be embedded in a script tag,
> to deal with ]]> as well, since the following could be used to throw
Is it sufficient to disallow <![ ?
- Another situation you may or may not have considered is the following:
This brings up the issue of what exactly is ADsafe guaranteeing its
or write any global variables and is unable to call any global
function (except as mediated by the ADSAFE object). This fails here
because this code is able to call the global "onerror" function.
The simplest solution is to require ADsafe code to be written using
the following idiom:
function it declares but asks the ADSAFE object to call the function.
The ADSAFE object can then call the function inside a try ... catch
block and expose an interface, like ADSAFE.onerror, to embedding
This idiom might be useful for other ADsafe features as well as the