Windows Scripting Host

Der Windows Scripting Host (WSH) ist eine ziemlich umfangreiche Programmbibliothek, die Möglichkeiten für Skriptsprachen, aber auch für Hochsprachen bereitstellt. Er ist unter anderem in den Internet Explorer seit Version 5 (?) integriert, wo er die Steuerung übernimmt. In neueren Betriebssystemen Microsoft Windows ist er standardmäßig aktiviert.

Der Scripting Host wurde aus der Notwendigkeit erstellt Administratoren die Möglichkeit zu geben Vorgänge, die sonst nur über die Grafische Benutzeroberläche ausführbar sind, zu automatisieren.

Zu DOS und Windows 3.11 oder zu Windows NT Zeiten mussten Administratoren auf die, fast schon nostalgisch anmutenden, Batch-Skripte zurückgreifen.

Betriebssysteme wie Unix, Linux oder Sun Solaris (ein Unix Derivat) boten solche Möglichkeiten zum Scripten von Vorgängen schon seit ihren Anfängen.

Auch wurden unter den gennaten Betriebssystemen verschiedene Script-Sprachen (Programmiersprachen) zur Verfügung gestellt.

Dieses Mittel der Administration fehlte in Windows lange Zeit gänzlich.

Der WSH unterstützt von Haus aus zur Zeit JavaScript und VBScript. Programmierer können somit zumindest zwischen zwei Sprachen entscheiden, die beide den kompletten Funktionsumfang des WSH abdecken. Es sind auch Implementierungen von Drittanbietern erstellt wurden, die sich aber zur Zeit noch nicht so nahtlos integrieren lassen. Auch erfordern diese, dass man zusätzliche Software installiert.

Der Windows Scripting Host bietet mehrere Objekte, wie unter anderem das FileSystemObject, eine einfache Schnittstelle zur Kommunikation mit dem Dateisystem, aber auch das Shell-Object, das einem das Ausführen von Dateien, aber auch das Lesen und Bearbeiten der Registry erlaubt.

Jedoch ist der Einsatz des Windows Scripting Hostes umstritten. Zum einen hinkt er im Geschwindigkeitsvergleich zu den synchronen API-Funktionen hinterher, welche natürlich weniger kompfortabel zu deklarieren sind. Zum anderen ist der WSH (Windows Skripting Host) auf vielen Systemen, vor allem auf kommerziell genutzten, auf Grund vieler Sicherheitsrisiken deaktiviert: Gerade der Microsoft Internet Explorer weißt ohne entsprechende Sicherheitsupdates einige Hackern hochwillkommene Sicherheitslücken, zum Beispiel durch Exploits. Daher empfiehlt es sich als Entwickler auf diese Funktionen zu verzichten.

Eins der prominetesten Beispiele in diesem Zusammenhang ist der ILoveYou Virus (genauer ein Wurm)

Es muss jedoch fairer Weise erwähnt werden, dass der Scripting Host an sich keine Sicherheistlücke darstellt. Der Scripting Host führt ausführbare Script-Dateien aus. Diese enden mit *.wsh, *.vbs, *.js (*.htm enthalten ebenfalls Scripting Source werden aber von einer anderen Engine ausgeführt. Meist mshta.exe)

Somit sind Scripting Dateien nicht gefährlicher als .exe-Dateien oder .com, .bat, .cmd oder gar .pif, .lnk Dateien.

Bei allen diesen Dateitypen handelt es sich um potentiell gefähliche Anweisungen, die ausgeführt werden. Dennoch würde nie jemand auf die Idee kommen .exe Dateien zu deaktivieren.

Mit Hilfe von WMI, den Windows Management Instrumentations, ist es seit Windows 2000 auch möglich nahezu die komplette Systemadministration in einem Windows-Netzwerk Scriptgesteuert und Remote zu erledigen. Das bedeutet, dass Administratoren, mit entsprechenden Scripts ausgestattet, alle Monitoring bzw. Überwachungsaufgaben, Maintanance bzw. Wartungsaufgaben oder sonstige administrative Veränderungen von ihrem Arbeitsplatz aus ferngesteuert erledigen können. Dies bedarf natürlich einer dedizierten Rechtevergabe.

Weblinks

• arstechnica.de
• Download-Seite von Microsoft Windows Script 5.6 mit Visual Basic Script Edition (VBScript) Version 5.6, JScript Version 5.6, Windows Script Components, Windows Script Host 5.6 und Windows Script Runtime Version 5.6.
• Gründe, warum Sie auf den Einsatz vom Windows Scripting Host verzichten sollten