Considérations sur la sécurité pour JScript
Mise à jour : novembre 2007
L'écriture de code sécurisé est un défi dans tout langage. JScript inclut quelques zones où les développeurs pourraient sans le savoir utiliser le langage de manière non sécurisée, car celui-ci n'impose pas les pratiques les plus efficaces aux développeurs. Bien que JScript ait été conçu dans l'objectif de garantir la sécurité, sa fonction première consiste à promouvoir le développement rapide d'applications utiles. Parfois, ces deux objectifs peuvent s'opposer.
Vous pouvez éviter les problèmes de sécurité si vous êtes conscient des problèmes potentiels dans plusieurs domaines clés, répertoriés ci-dessous. Ces considérations de sécurité, à l'exception de la méthode eval, sont dues à la nouvelle fonctionnalité qu'introduit le .NET Framework.
Méthode eval
La fonctionnalité JScript dont il est le plus facile de détourner l'utilisation est la méthode eval, qui permet l'exécution dynamique de code source JScript. Comme une application JScript qui utilise la méthode eval peut exécuter tout code qu'un programme lui passe, chaque appel à la méthode eval génère un risque de sécurité. À moins que votre application nécessite la flexibilité d'exécuter n'importe quel code, envisagez d'écrire explicitement le code que l'application passe à la méthode eval.
Pour augmenter la sécurité des applications qui requièrent la flexibilité complète fournie par la méthode eval, le code passé à eval s'exécute par défaut dans un contexte restreint. Le contexte de sécurité restreint contribue à empêcher tout accès aux ressources système, telles que le système de fichiers, le réseau ou l'interface utilisateur. Une exception de sécurité est générée si le code tente d'accéder à ces ressources. Toutefois, le code exécuté par la méthode eval peut encore modifier des variables locales et globales. Pour plus d'informations, consultez eval, méthode.
Le code écrit dans une version antérieure de JScript peut requérir que la méthode eval s'exécute dans le même contexte de sécurité que le code d'appel. Pour activer ce comportement, vous pouvez passer la chaîne « unsafe » comme second paramètre facultatif à la méthode eval. Vous devez exécuter uniquement les chaînes de code obtenues de sources bien connues car en mode « unsafe » la chaîne de code s'exécute avec les mêmes autorisations que le code d'appel.
Attributs de sécurité
Les attributs de sécurité du .NET Framework peuvent être utilisés pour substituer explicitement les paramètres de sécurité par défaut dans JScript. Toutefois, les valeurs par défaut de sécurité ne doivent pas être modifiées à moins que vous sachiez exactement ce que vous faites. En particulier, vous ne devez pas appliquer l'attribut personnalisé APTCA (AllowPartiallyTrustedCallers Attribute) car des appelants non fiables ne peuvent pas appeler de manière sécurisée le code JScript, en général. Si vous créez un assembly fiable avec APTCA, qui est ensuite chargé par une application, un appelant partiellement de confiance peut accéder à des assemblys totalement de confiance dans l'application. Pour plus d'informations, consultez Indications de codage sécurisé.
Code partiellement de confiance et code JScript hébergé
Le moteur qui héberge JScript permet à tout code appelé de modifier des parties du moteur, telles que des variables globales, des variables locales et des chaînes prototypes de tout projet. En outre, toute fonction peut modifier les propriétés et les méthodes de tout objet expando qui lui est passé. En conséquence, si une application JScript appelle du code partiellement de confiance ou s'exécute dans une application avec un autre code (comme celui d'un hôte VSA [Visual Studio for Applications]), son comportement peut être modifié.
Une conséquence de cela est que tout code JScript dans une application (ou dans une instance d'une classe AppDomain) doit s'exécuter à un niveau de confiance ne dépassant pas celui du reste du code dans l'application. Sinon, l'autre code pourrait manipuler le moteur pour la classe JScript, ce qui pourrait à son tour modifier des données et affecter l'autre code dans l'application. Pour plus d'informations, consultez _AppDomain.
Accès à l'assembly
JScript peut référencer des assemblys utilisant des noms forts ou des noms de type texte simple. Une référence à un nom fort inclut les informations de version de l'assembly ainsi qu'une signature de chiffrement qui confirme l'intégrité et l'identité de l'assembly. Bien qu'il soit plus simple d'utiliser un nom simple pour faire référence à un assembly, un nom fort aide à protéger votre code dans le cas où un autre assembly sur votre système posséderait le même nom simple, mais une fonctionnalité différente. Pour plus d'informations, consultez Comment : référencer un assembly avec nom fort.
Threading
Le runtime JScript n'a pas été conçu pour être à thread sécurisé. En conséquence, le code JScript multithread peut présenter un comportement imprévisible. Si vous développez un assembly dans JScript, n'oubliez pas qu'il peut être utilisé dans un contexte multithread. Vous devez utiliser des classes de l'espace de noms System.Threading, telles que la classe Mutex, pour garantir que le code JScript de l'assembly s'exécute selon une synchronisation correcte.
Étant donné qu'il est difficile d'écrire du code de synchronisation correcte dans n'importe quel langage, n'essayez pas d'écrire des assemblys généraux dans JScript à moins d'avoir des connaissances précises sur la manière d'implémenter le code de synchronisation nécessaire. Pour plus d'informations, consultez System.Threading.
.gif "Remarque") Remarque : |
|---|
Il ne vous est pas nécessaire d'écrire de code de synchronisation pour les applications ASP.NET écrites dans JScript car ASP.NET gère la synchronisation de tous les threads qu'il engendre. Toutefois, les contrôles Web écrits dans JScript doivent contenir un code de synchronisation car ils se comportent comme des assemblys. |
Erreurs d'exécution
JScript étant un langage faiblement typé, il est plus tolérant envers les incompatibilités de types potentielles que d'autres langages, tels que Visual Basic et Visual C#. Comme les incompatibilités de types peuvent causer des erreurs d'exécution dans les applications, il est important de découvrir les incompatibilités de types potentielles lorsque vous développez le code. Vous pouvez utiliser la balise /warnaserror avec le compilateur de ligne de commande ou l'attribut warninglevel de la directive @ Page dans les pages ASP.NET. Pour plus d'informations, consultez /warnaserror et @ Page.
Mode de compatibilité
Les assemblys compilés en mode de compatibilité (avec l'option /fast-) sont moins chiffrés que ceux qui sont compilés en mode rapide (mode par défaut). L'option /fast- permet d'utiliser des fonctionnalités de langage qui ne sont pas disponibles par défaut, mais sont requises pour la compatibilité avec les scripts écrits pour JScript version 5.6 ou version antérieure. Par exemple, les propriétés expando peuvent être ajoutées dynamiquement à des objets intrinsèques, tels que l'objet String, en mode de compatibilité.
Le mode de compatibilité a été conçu pour aider les développeurs à générer des exécutables autonomes à partir de code JScript hérité (legacy). Lorsque vous développez de nouveaux exécutables ou bibliothèques, utilisez le mode par défaut. Cela permet d'obtenir des applications plus sécurisées, mais contribue également à améliorer les performances et l'interaction avec les autres assemblys. Pour plus d'informations, consultez /fast.
Voir aussi
Concepts
Mise à niveau d'applications créées dans des versions précédentes de JScript