• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

eval in Javascript

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    eval in Javascript

    One for the webby types:

    I have this inside some (client side) Javascript on a web page that hosts a flash movie as a way for the movie to call generic Javascript commands:

    Code:
    function JSFunction(jsf)
    {
    eval(jsf);
    }
    Does anybody know of any circumstance where eval might not be allowed? And does anybody know if the evaluated code can be relied on to be called from the same thread - i.e. has finised by the time eval exits?

    This is one of those third hand "sometimes it doesn't work" type problems so I'm just looking for anything dubious.

    Ta.
    Will work inside IR35. Or for food.

    #2
    That approach allows the Flash content to execute arbitrary code. IMHO, it makes more sense from a security perspective to ensure that Flash only seeks to execute JS code provided specifically to support its requirements. That can be done without using eval.

    Using eval may be perfectly safe and secure for your application, but it's a powerful vector for script injection, cross-site scripting, and cross-site request forgery.

    It also imposes a performance cost: a whole new instance of the JS engine has to be instantiated to parse the passed string (which is what I assume the type of the jsf parameter is) and then execute it.

    [Aside: Before anybody jumps in about my mention of the type of the parameter: JS does have types, and also has clearly defined rules for automatic type conversion. This can create the illusion of the language lacking types to those who are careless, but it is an illusion. The only people who think JS is an untyped language are those who don't know the language or haven't read the ECMA-262 spec.]

    When this is done purely from within JS code itself it's far from ideal, but as JS runs on one thread it shouldn't be a problem. When done from within a plugin like Flash, the waters become muddier: the specifications governing browser behaviour aren't clear on how these interactions should be handled (in fact, they don't really exist), and it's definitely an area where one might expect to encounter bugs relating to the separate execution contexts of the JS code and the plugin code. Normally these things work well together, but the case of a plugin invoking a JS function which uses eval to create a new JS execution context, separate from the execution context of which the plugin is aware, is to my mind very much an edge case where unpredictable platform-dependent behaviour might well be encountered.

    Put it this way: if I was writing the browser code and plugin code that handles the interaction of the plugin, the JS engine, and the new instance of the JS engine created by using eval, I would tend to assume that, despite my best efforts, I would almost certainly end up with some weird synchronisation bug in there. It's a tricky thing to do.

    Comment


      #3
      Thanks Nick - knew I could count on a 4am reply from you.

      I think this was done as a shortcut, but in this application there's only 3 functions that need to be called so is a bit stupid. However, from what I've found on the web it does seem the whole Flash - Javascript interface is a bit flakey anyway so this part probably isn't the issue.
      Will work inside IR35. Or for food.

      Comment

      Working...
      X