Why Scripting Can Be Dangerous
"Why can scripting be dangerous?" isn't a question many administrators have to ask. Something like 70% of all new viruses, according to some authorities, are script based; certainly some of the most devastating viruses, including Nimda, Melissa, and others, propagate at least partially through scripts sent via e-mail. Even internally produced scripts can be dangerous, as scripts can delete users, create files, and perform any number-in fact, an almost unlimited number-of tasks. There's little question about the damage scripts can do, making it vitally important that your environment be secured to allow only those authorized, tested scripts that you or your fellow administrators authorize.
Perhaps the most dangerous aspect of administrative scripting is the easy accessibility scripts have to the system. Users can launch scripts without even realizing that they're doing so; a large number of file extensions are registered to the Windows Script Host, and double-clicking any file with one of those extensions launches the script. In Windows XP, the default script extensions are
JS for JScript files JSCRIPT for Jscript files JSE for Jscript encoded files VBE for VBScript encoded files VBS for VBScript files WSC for Windows Script Components WSF for Windows Script Files
Note that older computers may also register VB for VBScript files, SCR for script files, and other extensions; Windows XP cleaned up the filename extension list a bit. Don't forget, of course, static HTML files-with HTML or HTM filename extensions-which can contain embedded client-side script.
NOTE
Other types of scripts exist, such as the Visual Basic for Applications (VBA) embedded into Microsoft Office documents. However, I'm going to focus this discussion on scripts associated or executed by the Windows Script Host.
The goal of any security program should be to allow beneficial, authorized scripts to run, while preventing unauthorized scripts from running.
|