Ein Kennwort im Klartext irgendwo abzulegen, ist grundsätzlich ein Sicherheitsrisiko – nicht nur für Administrator-Konten. Sofern das Skript nicht unbeaufsichtigt laufen muss, sollten Sie daher während der Skriptausführung nach dem Kennwort fragen (z.B. mit InputBox() oder der Scripting Password-Komponente).

Ungeeignet ist die Kennworteingabe natürlich dann, wenn das Skript entweder unbeaufsichtigt laufen soll oder aber im Kontext eines normalen Benutzers gestartet werden soll, dann aber eine Impersonifizierung als Administrator notwendig wird. Dann ist es natürlich keine Alternative, den Benutzer das Kennwort des Administrators eingeben zu lassen.

Script Encoding

Leider kann man auch bei WSH-Dateien nicht zwischen den Rechten "Ausführung" und "Lesen" unterscheiden. Das Starten einer WSH-Datei erfordert immer Leserechte auf eine Datei und damit ist auch immer die Einsicht in den Quellcode möglich. Eine Möglichkeit – zumindest gegen weniger erfahrene Benutzer – ist dann nur das Script Encoding. Dabei wird der gesamte Quellcode einer Datei unkenntlich gemacht. Leider ist das Verfahren mit im Internet kursierenden Tools reversibel.

ASP

Eine wirklich wirksame Sicherung vor dem Betrachten des Quellcodes bietet der WSH überhaupt nicht. Eine grundsätzliche Alternative sind ASP-Skripte: Sie laufen auf einem Webserver und der Benutzer kann den Quellcode nicht betrachten, sofern er keinen Zugriff auf das Dateisystem des Webservers hat. In der Vergangenheit gab es zwar einige Bugs im IIS, die die Anzeige des Quellcodes ermöglicht haben, doch diese Lücken sollten nach der Sicherheitsinitiative von Microsoft inzwischen gestopft sein.

Weitere Informationen

Liste aller Fragen im FAQ