Bohunky0's Web Sucurity
This site updated on 11/14/2005
WINDOWS SCRIPTING HOST: TOO MUCH POWER?
The recent spate of script viruses proved conclusively that a little power is a dangerous
thing and that convenience features in operating systems can easily backfire when
exploited. Neil Rubenking's article in our Solutions section isn't about dodging e-mail
worms, but about the innards of
the Windows Scripting Host. It's a straightforward description of how to use it, and how
to harness the additional power of WSH 2.0. The article includes links to downloadable
sample scripts.
One of the points that Rubenking makes is that WSH allows execution of JavaScript and
VBScript, and the scripts are no harder to write than DOS batch files. While intended for
"good" purposes, the scripting language is very powerful, and has full access to
the registry and the file system, and can easily be used to write destructive scripts. WSH
2.0 is stronger still, with StdIn() and
StdOut() and other calls that allow you to create commandline programs that can start and
control other applications. At the other end of the spectrum, Microsoft's new Windows
Script Encoder allows you to encode your scripts in HTML or ASP pages so that users cannot
decipher your
scripts.
Windows automation is a wonderful thing, but I'm getting the feeling that it's a loaded
gun. the MSDN scripting site (http://msdn.microsoft.com/scripting)
is full of good examples of how to harness the power for seamless, interactive Web pages,
but contains nary a word about defending
against rogue scripts. If you would rather have fewer features and more protection, here's
a link to the Symantec Knowledge Base article
(http://service1.symantec.com/support/nav.nsf/docid/2000050
512031906) that tells you how to turn off scripting support. You can also turn off active
scripting in Outlook, but that's not going to stop you from clicking on a script and
launching it. Here's a link to the Microsoft article on removing active scripting.
(http://support.microsoft.com/support/kb/articles/q215/7/74
.asp) Note that I haven't tested these solutions myself; I'm passing along the links for
your information. For that matter, I don't use Internet Explorer. Given the wide variety
of sites that I visit in my reviewing and researching, I consider the risk of ActiveX
controls to be greater than
I want to bear, and certificates are essentially meaningless.
Ultimately, we'll need a more secure model than we currently have. But in the meantime,
you should familiarize yourself with Windows scripting so that you can make a realistic
assessment of the ways it can help--and hurt--you.
http://cgi.zdnet.com/slink?35191:3802671