Überlegungen zur Sicherheit von JScript
Das Schreiben von sicherem Code stellt in jeder Sprache 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 sind mit Ausnahme der eval-Methode durch die neue Funktionalität von .NET Framework bedingt.
eval-Methode
Eine Funktion von JScript, die sehr leicht falsch verwendet wird, ist die eval-Methode, die die dynamische Ausführung von JScript-Quellcode ermöglicht. Da in einer JScript-Anwendung, für die die eval-Methode verwendet wird, jeder von einem Programm an diese Methode übergebene Code ausgeführt werden kann, 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.
Sicherheitsattribute
Mit den Sicherheitsattributen von .NET Framework können Sie die Standardsicherheitseinstellungen in JScript explizit ü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 VSA-Host (Visual Studio for Applications), kann sich daher das Verhalten der Anwendung ändern.
Dies hat zur Folge, dass jeder JScript-Code in einer Anwendung (bzw. in einer Instanz einer AppDomain-Klasse) auf keiner höheren Vertrauensebene ausgeführt werden sollte als der restliche Code in der Anwendung. Andernfalls kann das Modul für die JScript-Klasse vom anderen Code geändert werden. Dadurch wiederum können 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 bei der Assemblyentwicklung in JScript, dass diese möglicherweise in Multithreadkontexten verwendet wird. Sie sollten mit den 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.
Tipp
Für in JScript geschriebene ASP.NET-Anwendungen ist kein Synchronisierungscode erforderlich, da ASP.NET die Synchronisierung aller selbst erstellten Threads verwaltet. In JScript geschriebene Websteuerelemente 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, z. B. 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 auf 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. Mit der Option /fast- werden Sprachfunktionen 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 systeminternen Objekten hinzugefügt werden, z. B. dem String-Objekt.
Der Kompatibilitätsmodus soll Entwickler beim Erstellen eigenständiger ausführbarer Dateien in ä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