次の方法で共有

Script And IE Security Part Three: Some Object Creation Techniques Are Explicitly Forbidden

  • [アーティクル]

A couple readers have commented that yes, my conjecture that people will continue to use the twentieth-century COM scripting interfaces for some time yet is correct. (And my statement that the documentation on these has been less than 100% complete for the last seven years is also correct!) Thus, I'll probably follow up this series with articles on other low-level details on how the various script engine interfaces work. I appreciate suggestions, so if anyone has ideas for things you'd like to see covered in more depth, let me know. (Of course, you may want details on something I'm clueless about, in which case you'll have to learn to live with disappointment…)

But I digress. There are three object creation scenarios which are automatically errors if either the "safe for untrusted data" or "use security manager" bits are set on the script engine. I call them the DCOM, Moniker and Running Object scenarios:

DCOM

DCOM, as you probably know, is just COM with longer wires. (The details of invoking calls and moving data around become more complex as the wires get longer, but from the call site, the call looks pretty much the same.) The script engines provide syntax for objects to be created cross-machine via DCOM. For example, in JScript Classic you can say

var someobj = new ActiveXObject(someprogid, someserver);

If the scripting security system is turned on (ie, either safe-for-untrusted-data or use-security-manager are set) then any attempt to create an object via DCOM automatically fails. There are no safe, partially-trusted DCOM scenarios.

Object Creation From Monikers

A moniker is a "smart name". That is, a name which has some code associated with it that can do something interesting. A URL, for example, is a moniker which knows how to go out to the web and download the bits associated with the URL. The script engines provide syntax for objects to be created via monikers:

var someobj = GetObject(somemoniker);

If the scripting security system is turned on (ie, either safe-for-untrusted-data or use-security-manager are set) then any attempt to create an object via a moniker automatically fails. There are no safe, partially-trusted scenarios where objects are loaded based on arbitrary monikers.

Object Creation Via the Running Object Table

The script engines provide syntax for accessing already-created objects (usually in other processes, such as the Word object model):

var someobj = GetObject("", someprogid);

If the scripting security system is turned on (ie, either safe-for-untrusted-data or use-security-manager are set) then any attempt to create an object via the running object table automatically fails. There are no safe, partially-trusted scenarios where existing objects are accessed. This could, among other things, break the IE domain security model whereby code from one web site is not allowed to access objects created by code from another web site. It could also enable untrusted scripts to obtain access to powerful object models such as the Office object models.

Object Creation With Persistence but no Security Manager

The script engines provide syntax for creating an object and persisting in state for that object:

var someobj = GetObject(somestatemoniker, someprogid);

If safe-for-untrusted-data is set and use-security-manager is NOT set (that is, the script engine is not running in IE) then any attempt to create an object with persisted state automatically fails. Without access to the IE security manager the script engine has no way of knowing if the script is authorized to access the moniker. The object might be a perfectly safe text box with its state persisted in from a file on the local file system, effectively stealing data from the file system and passing it to a trusted object scripted by an untrusted caller.

The case where there is a security manager is very complicated, so I will devote an entire entry to it later.

Tomorrow: how the script engines create objects in the case where there is no IE security manager available. (I need to explain this first so that I can contrast it with how IE does it.)

Comments

  • Anonymous
    January 14, 2004
    Not to be picky, but...

    var someobj = GetObject("", someprogid);

    ...doesn't work even in a trusted host (like WSH) since the first argument to GetObject()must be omitted, not an empty string, to get a reference to a running object instance.

  • Anonymous
    January 14, 2004
    Not to be picky, but are you sure about that, Mike?

    You're describing the syntax of the VBScript version of GetObject, but the VBScript version of GetObject usually doesn't have the word "var" before it or a semicolon after it. :)

  • Anonymous
    January 14, 2004
    OK, you win, but I still have hope of some day catching you in an error <vbg>!

    Rule #1 - test before posting...
    Rule #2 - don't trust the [JScript] documentation...

    With Word open, the following JScript run under WSH does work though the documentation of JScript's version of GetObject says essentially the same thing as the VBScript version WRT omitting the 1st argument (running instance) vs. an empty string (new instance)...

    var word = GetObject("", "Word.Application");
    WScript.Echo(word.ActiveDocument.Name);
    word.Quit();

  • Anonymous
    January 14, 2004
    Yeah, I found that doc error some time ago. We have not had full-time staff to work on fixing up the scripting documentation for a long, long time, so there are many of these small errors "batched up" waiting for the day when someone has the time to fix them all at once. (I wouldn't hold my breath waiting for that day...)

  • Anonymous
    January 14, 2004
    "...people will continue to use the twentieth-century COM scripting interfaces for some time yet..."

    Going off on a tangent from your actual topic... :)

    Any interest in blogging on WSH/.NET transition and interop issues? Some of it can be rather mundane, but there are some intriguing ways to exploit them as a team.

  • Anonymous
    January 15, 2004
    And the GetObject doc error exists in the JScript.Net docs as well :-)...

  • Anonymous
    June 01, 2004
    The comment has been removed

  • Anonymous
    June 01, 2004
    Sure, they're real COM objects. They might not implement the interfaces that a particular environment requires though.

    I don't know what the requirements are for Outlook addins.

    There are ways to make WSC's implement arbitrary interfaces, but its quite tricky. Maybe I'll blog about that at some point.

  • Anonymous
    June 01, 2004
    Ah. If it is possible to get them to implement arbitrary interfaces then I'd be highly interested in that blog post! I really was trying to avoid writing something and then compiling it when I could just do it in script...

  • Anonymous
    December 22, 2006
    I'd also like to see a blog entry on making WSCs implement arbitrary interfaces, if you can find the time one of these days.

  • Anonymous
    June 03, 2009
    I’ve recently been building an ActiveX Control in .NET 2.0 and thought I would share some of the problems