Re: Scripting Security

Sorry, I should have explained further. I am talking about actually hosting
the Microsoft Scripting engine using the COM component CLSID_VBScript and
its IActiveScript interface. This allows my application to provide scripting
support to end users.

The question was, when hosting the scripting engine, how can I disable
CreateObject calls (without writing my own code to parse scripts)? As I
said, I believe this Microsoft addressed this security hole at some point by
and added a feature to scripting engine interfaces which disallows calls
like CreateObject (there may have been other security enhancements as well).
I never paid that much attention to the Microsoft Scripting engine back when
I heard this years ago, but now looking at it on msdn and searching google,
I can't find the name or location of this feature anywhere.

So I was asking (perhaps this us the wrong group) what is preferred method
of disallowing CreateObject when hosting scripts?

"mayayana" <mayaXXyana1a@xxxxxxxxxxxxxxxx> wrote in message
news:7w41h.14481$Lv3.14068@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
"creating an application and hosting" ?

Creating a script application? Hosting
script youself in an EXE?

Usually a VBScript
is hosted by either the Windows Script Host (WSH)
or Internet Explorer. If you use script in an
HTML file, in IE, it will be limited by the IE security
settings. But with WSH the "unsafe activeX" rules
don't apply. A COM object is just a COM object.
Anything that can use COM can use it. In other
words, it's system-wide, not supplied by the WSH.
The way to disable operations you consider unsafe
in VBS files is to:

1) Remove those components. (Some
sys. admins remove SCRRUN.DLL, for instance, to
prevent the use of the FileSystemObject.)
There's a limit to how much that will accomplish,
though. On some later Windows versions you
may not be able to remove some components,
and some COM objects that script might be able
to use are also needed for other functions.

2) Disable script altogether by associating the file
types with Notepad and/or removing the WSH
components like WScript and CScript.

3) Write your own script host.
------

CreateObject is built into the system. It's what
transformed VBS from webpage scripting to being
the tool of choice for many system admins and
virus authors. VBScript is not safe and hasn't been
since the mid 90's when CreateObject was added.

I am not too sure if this is the right group to ask, but here goes ...

When creating an application and hosting VBScript using the Microsoft
supplies scripting engine COM objects, what is the preferred way to
prevent
certain functions, specifically allowing/disallowing the script engine to
use CreateObject?

I believe I read something about this being addressed and added to
Windows
Scripting technologies long ago, but can't find this information on
google.
Perhaps some Windows Scripting guru could tell me how this type of
security
can be controlled on a per scripting host basis.

Thanks in advance, Anthony.






.

Quantcast