|No such thing as a small change|
The Windows Script host allows you to use multiple languages in one script file, run scripts from the command line, write windows components and make your HTML pages a bit more dynamic through ASP. In addition to the language-specific functions, WSH provides a number of objects, methods and properties that are always accessible regardless of which language you are using at the time.
Other software companies can write ActiveX scripting engine versions of their languages to be used within WSH. ActiveState has written PerlScript (a WSH version of Perl) which has been bundled with ActivePerl for some time. PerlScript offers almost the whole set of perl functionality. The only things that I've noticed missing or different is I/O - you can't ``print'' in PerlScript, you have to use the WSH methods for output ($Response->Write or $WScript->Echo). So, apart from ``print''ing PerlScript looks just like normal Perl. You can use Perl modules or if you want to make your code even less portable you can use some of the built-in WSH methods.
So far, the security implications aren't too great.
ASP runs on the remote server and is executed before the output is sent to your browser.
Command line WSH scripts and components run under your UID so as long as you know what you're executing and you don't run other people's scripts without checking them first, you should be ok.
However, one thing I haven't mentioned is that part of the WSH integration with Windows, is that it is built in to Internet Explorer too. If you are running IE 3 or higher (which you probably are if you have WSH installed) then you can run client-side scripts embedded in an HTML page. Now, there are reasons why this would be nice, but it makes me shiver to think about the consequences of running a language as powerful as Perl that is hidden in <script> tags.
Imagine the following pseudo-script hidden in an web page: (it could be MUCH worse than this)
Thankfully in IE4 or above you can restrict clientside languages from running based on the Zone (local, Internet, trusted, etc). In IE3 it is either enabled or disabled for all zones. In fact, I don't think that the concept of zones existed in IE3.
By default, ActiveState sets the PerlScript security setting to ``Local'' zones only. This means that if you open up an html file on your hard disk then it will allow Perlscript to run, but if you navigate IE to an external website, PerlScript will be silently ignored.
That's ok surely? NO! It's not ok. Imagine being sent an email with an attachment - it's a .html. It got through your virus scanners because they can't scan for malicious perl code and it looks just like a regular html page. It's stored locally on your hard disk before you open it in Outlook Express. You open it and BANG!
Error: Keyboard not attached. Press F1 to continue.