Überlegungen zur Sicherheit von JScript
Aktualisiert: November 2007
Das Schreiben sicheren Codes stellt in jeder Programmiersprache eine Herausforderung dar. Jscript enthält einige wenige Bereiche, in denen Entwickler die Programmiersprache unwissentlich auf unsichere Weise verwenden könnten, da sie durch die Programmiersprache nicht angehalten werden, die effizienteste Vorgehensweise zu nutzen. Obwohl bei der Entwicklung von Jscript besonderes Augenmerk auf die Sicherheit gelegt wurde, ist das Hauptziel die schnelle Entwicklung sinnvoller und effektiver Anwendungen. In einigen Fällen widersprechen sich diese beiden Ziele.
Sie können Sicherheitsprobleme vermeiden, wenn Sie in einigen, nachstehend aufgeführten Schlüsselbereichen die möglichen Probleme kennen. Diese Sicherheitsüberlegungen stehen mit Ausnahme der eval-Methode mit der neuen Funktionalität in Zusammenhang, die mit .NET Framework eingeführt wird.
eval-Methode
Ein Feature von Jscript, das sehr leicht falsch verwendet wird, ist die eval-Methode, die die dynamische Ausführung von Jscript-Quellcode ermöglicht. Da eine Jscript-Anwendung, die die eval-Methode verwendet, jeden Code ausführen kann, den ein Programm an die Methode übergibt, stellt jeder Aufruf der eval-Methode ein Sicherheitsrisiko dar. Solange die Anwendung nicht die Flexibilität erfordert, beliebigen Code auszuführen, sollten Sie den Code, den die Anwendung an die eval-Methode übergibt, explizit erstellen.
Um die Sicherheit von Anwendungen zu erhöhen, die die volle Flexibilität der eval-Methode benötigen, wird der an eval übergebene Code standardmäßig in einem beschränkten Kontext ausgeführt. Der beschränkte Sicherheitskontext trägt dazu bei, jeglichen Zugriff auf Systemressourcen, z. B. das Dateisystem, das Netzwerk oder die Benutzeroberfläche, zu verhindern. Wenn der Code versucht, auf diese Ressourcen zuzugreifen, wird eine Sicherheitsausnahme ausgelöst. Der Code, der von der eval-Methode ausgeführt wird, kann jedoch weiterhin lokale und globale Variablen ändern. Weitere Informationen finden Sie unter eval-Methode.
Code, der in früheren Versionen von Jscript erstellt wurde, erfordert u. U., dass die eval-Methode den Code im selben Sicherheitskontext ausführt wie der aufrufende Code. Um dieses Verhalten möglich zu machen, können Sie die Zeichenfolge unsafe als optionalen zweiten Parameter an die eval-Methode übergeben. Sie sollten nur Codezeichenfolgen ausführen, die aus zuverlässigen Quellen stammen, da die Codezeichenfolge im unsicheren Modus mit den gleichen Berechtigungen ausgeführt wird wie der aufrufende Code.
Sicherheitsattribute
Die Sicherheitsattribute von .NET Framework können dazu verwendet werden, die Standardsicherheitseinstellungen in Jscript explizit zu überschreiben. Die Sicherheitsstandards sollten aber nur dann geändert werden, wenn Sie sich über die Konsequenzen genau bewusst sind. Insbesondere sollten Sie nicht das benutzerdefinierte AllowPartiallyTrustedCallers-Attribut (APTCA) verwenden, da nicht vertrauenswürdige Aufrufer Jscript-Code in der Regel nicht sicher aufrufen können. Wenn Sie eine vertrauenswürdige Assembly mit APTCA erstellen, die anschließend von einer Anwendung geladen wird, kann ein teilweise vertrauenswürdiger Aufrufer auf voll vertrauenswürdige Assemblys in der Anwendung zugreifen. Weitere Informationen finden Sie unter Richtlinien für das Schreiben von sicherem Code.
Teilweise vertrauenswürdiger Code und JScript-Hostcode
Das Hostmodul für Jscript lässt es zu, dass jeder aufgerufene Code Teile des Moduls ändert, z. B. globale Variablen, lokale Variablen und Prototypenketten beliebiger Objekte. Darüber hinaus kann jede Funktion die expando-Eigenschaften oder –Methoden aller übergebenen expando-Objekte ändern. Wenn eine Jscript-Anwendung teilweise vertrauenswürdigen Code aufruft oder in einer Anwendung mit anderem Code ausgeführt wird (z. B. in einem Visual Studio für Applikationen-[VSA-]Host), könnte das Verhalten der Anwendung daher geändert werden.
Dies hat zur Folge, dass jeder Jscript-Code in einer Anwendung (bzw. in einer Instanz einer AppDomain-Klasse) nicht auf einer höheren Vertrauensebene ausgeführt werden sollte als der restliche Code in der Anwendung. Andernfalls könnte der andere Code das Modul für die Jscript-Klasse ändern. Dadurch könnten Daten geändert und der übrige Code in der Anwendung beeinflusst werden. Weitere Informationen finden Sie unter _AppDomain.
Assemblyzugriff
Jscript kann sowohl mit starken Namen als auch mit einfachen Textnamen auf Assemblys verweisen. Ein Verweis mit einem starken Namen enthält die Versionsinformationen der Assembly sowie eine kryptografische Signatur, die die Integrität und Identität der Assembly bestätigt. Obwohl es einfacher ist, beim Verweis auf eine Assembly einen einfachen Namen zu verwenden, trägt ein starker Name zum Schutz von Code bei, falls eine andere Assembly im System denselben einfachen Namen, aber eine andere Funktionalität aufweist. Weitere Informationen finden Sie unter Gewusst wie: Verweisen auf eine Assembly mit starkem Namen.
Threading
Die Jscript-Laufzeit ist nicht threadsicher. Daher kann Jscript-Multithreadcode zu einem unvorhersehbaren Verhalten führen. Berücksichtigen Sie beim Entwickeln einer Assembly in Jscript, dass sie u. U. in einem Multithreadkontext verwendet werden kann. Sie sollten mithilfe der Klassen im System.Threading-Namespace, z. B. der Mutex-Klasse, sicherstellen, dass der Jscript-Code in der Assembly mit der richtigen Synchronisierung ausgeführt wird.
Da der Code für eine einwandfreie Synchronisierung in jeder Programmiersprache schwer zu erstellen ist, sollten Sie nur dann allgemein verwendbare Assemblys in Jscript erstellen, wenn Sie gute Kenntnisse in der Implementierung des erforderlichen Synchronisierungscodes besitzen. Weitere Informationen finden Sie unter System.Threading.
.gif "Hinweis") Hinweis: |
|---|
Für ASP.NET-Anwendungen, die in Jscript geschrieben wurden, ist kein Synchronisierungscode erforderlich, da ASP.NET die Synchronisierung aller selbst erstellten Threads verwaltet. Websteuerelemente, die in Jscript geschrieben wurden, müssen jedoch Synchronisierungscode enthalten, da sie sich wie Assemblys verhalten. |
Laufzeitfehler
Da Jscript eine Programmiersprache mit flexibler Typbindung ist, verhält sie sich bei möglichen Typenkonflikten toleranter als andere Sprachen wie Visual Basic und Visual C#. Da Typenkonflikte Laufzeitfehler in Anwendungen verursachen können, ist es wichtig, mögliche Typenkonflikte bereits bei der Codeentwicklung zu erkennen. Sie können das /warnaserror-Flag mit dem Befehlszeilencompiler oder das warninglevel-Attribut der @ Page-Direktive in ASP.NET-Seiten verwenden. Weitere Informationen finden Sie unter /warnaserror und @ Page.
Kompatibilitätsmodus
Assemblys, die im Kompatibilitätsmodus (mit der Option /fast-) kompiliert wurden, sind weniger verschlüsselt als solche, die im schnellen Modus (Standardmodus) kompiliert wurden. Durch die Option /fast- werden Sprachfeatures aktiviert, die standardmäßig nicht zur Verfügung stehen, aber aus Gründen der Kompatibilität mit Skripts erforderlich sind, die für Jscript, Version 5.6 und früher, geschrieben wurden. Beispielsweise können im Kompatibilitätsmodus expando-Eigenschaften dynamisch zu systeminternen Objekten, z. B. dem String-Objekt, hinzugefügt werden.
Der Kompatibilitätsmodus soll Entwickler beim Erstellen von eigenständigen ausführbaren Dateien aus älterem Jscript-Code unterstützen. Verwenden Sie beim Entwickeln von neuen ausführbaren Dateien den Standardmodus. Dies erhöht nicht nur den Schutz der Anwendungen, sondern trägt auch zur besseren Leistung und Interaktion mit anderen Assemblys bei. Weitere Informationen hierzu finden Sie unter "/fast".
Siehe auch
Konzepte
Aktualisieren von Anwendungen, die in früheren Versionen von JScript erstellt wurden