Considérations sur la sécurité pour JScript
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'optique 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 relatives à la sécurité, à l'exception de la méthode eval, sont dues à la nouvelle fonctionnalité introduite par 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. Étant donné qu'une application JScript utilisant la méthode eval peut exécuter tout code qu'un programme lui passe, chaque appel à la méthode eval introduit un risque en matière 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.
Attributs de sécurité
Les attributs de sécurité du .NET Framework peuvent être utilisés pour remplacer explicitement les paramètres de sécurité par défaut définis 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) car des appelants non fiables ne peuvent généralement pas appeler de manière sécurisée le code JScript. 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 Instructions 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 objet. En outre, toute fonction peut modifier les propriétés et les méthodes de tout objet expando qui lui est passé. Par conséquent, si une application JScript appelle du code partiellement fiable 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é.
Il s'ensuit que tout code JScript d'une application (ou d'une instance d'une classe AppDomain) doit s'exécuter à un niveau de confiance ne dépassant pas celui du reste du code de l'application. Si tel n'est pas le cas, un code peut manipuler le moteur de la classe JScript, qui risque à son tour de modifier des données et d'affecter d'autres codes de l'application. Pour plus d'informations, consultez _AppDomain.
Accès à l'assembly
JScript peut référencer des assemblys au moyen de noms forts et de noms textuels simples. 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.
Threads
Le runtime JScript n'est pas conçu pour être thread-safe. Par conséquent, 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 un code de synchronisation correct dans tout langage, n'essayez pas de créer des assemblys généraux dans JScript, à moins que vous ne sachiez précisément comment implémenter le code de synchronisation requis. Pour plus d'informations, consultez System.Threading.
Notes
L'écriture de code de synchronisation n'est pas nécessaire 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 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é est 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