System.Xml Espace de noms

Classes

Interfaces

Énumérations

Délégués

Remarques

Normes prises en charge

L’espace System.Xml de noms prend en charge ces normes :

• XML 1.0, y compris la prise en charge de DTD

• Espaces de noms XML, à la fois au niveau du flux et du DOM

• Schémas XML

• Expressions XPath

• Transformations XSLT

• DOM Niveau 1 Core

• DOM Niveau 2 Core

Consultez la section Différences par rapport aux spécifications W3C pour deux cas dans lesquels les classes XML diffèrent des recommandations du W3C.

Espaces de noms associés

.NET fournit également d’autres espaces de noms pour les opérations liées à XML. Pour obtenir une liste, des descriptions et des liens, consultez espaces de nomsSystem.Xml.

Traitement asynchrone du code XML

Les System.Xml.XmlReader classes et System.Xml.XmlWriter incluent un certain nombre de méthodes asynchrones basées sur le modèle de programmation asynchrone. Ces méthodes peuvent être identifiées par la chaîne « Async » à la fin de leur nom. Avec ces méthodes, vous pouvez écrire du code asynchrone similaire à votre code synchrone, et vous pouvez facilement migrer votre code synchrone existant vers du code asynchrone.

• Utilisez les méthodes asynchrones dans les applications où la latence de flux réseau est importante. Évitez d’utiliser les API asynchrones pour les opérations de lecture/écriture de flux de mémoire ou de flux de fichiers locaux. Le flux d’entrée, XmlTextReader, et XmlTextWriter doit également prendre en charge les opérations asynchrones. Sinon, les threads seront toujours bloqués par les opérations d’E/S.

• Nous vous déconseillons de mélanger les appels de fonction synchrones et asynchrones, car vous risquez d’oublier d’utiliser le await mot clé ou d’utiliser une API synchrone où une api asynchrone est nécessaire.

• Ne définissez pas l’indicateur XmlReaderSettings.Async ou XmlWriterSettings.Async sur true si vous n’avez pas l’intention d’utiliser une méthode asynchrone.

• Si vous oubliez de spécifier le await mot clé lorsque vous appelez une méthode asynchrone, les résultats ne sont pas déterministes : vous pouvez recevoir le résultat attendu ou une exception.

• Lorsqu’un XmlReader objet lit un nœud de texte volumineux, il peut mettre en cache uniquement une valeur de texte partielle et retourner le nœud de texte. La récupération de la XmlReader.Value propriété peut donc être bloquée par une opération d’E/S. Utilisez la XmlReader.GetValueAsync méthode pour obtenir la valeur de texte en mode asynchrone, ou utilisez la XmlReader.ReadValueChunkAsync méthode pour lire un bloc de texte volumineux en blocs.

• Lorsque vous utilisez un XmlWriter objet, appelez la XmlWriter.FlushAsync méthode avant d’appeler XmlWriter.Close pour éviter de bloquer une opération d’E/S.

Différences par rapport aux spécifications du W3C

Dans deux cas qui impliquent des contraintes sur les composants de schéma de groupe de modèles, l’espace System.Xml de noms diffère des recommandations du W3C.

Cohérence dans les déclarations d’éléments :

Dans certains cas, lorsque des groupes de substitution sont utilisés, l’implémentation System.Xml ne satisfait pas la spécification « Contrainte de composant de schéma : déclarations d’éléments cohérentes », qui est décrite dans la section Contraintes sur les composants de schéma de groupe de modèles de la spécification W3C.

Par exemple, le schéma suivant inclut des éléments qui ont le même nom, mais des types différents dans le même modèle de contenu, et des groupes de substitution sont utilisés. Cela doit provoquer une erreur, mais System.Xml compile et valide le schéma sans erreurs.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

   <xs:element name="e1" type="t1"/>
   <xs:complexType name="t1"/>

   <xs:element name="e2" type="t2" substitutionGroup="e1"/>
      <xs:complexType name="t2">
         <xs:complexContent>
            <xs:extension base="t1">
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1"/>
         <xs:element name="e2" type="xs:int"/>
      </xs:sequence>
   </xs:complexType>
</xs:schema>

Dans ce schéma, le type t3 contient une séquence d'éléments. En raison de la substitution, la référence à l'élément e1 de la séquence peut générer soit un élément e1 de type t1, soit un élément e2 de type t2. Ce dernier cas entraînerait une séquence de deux e2 éléments, où l’un est de type t2 et l’autre de type xs:int.

Attribution de particules unique :

Dans les conditions suivantes, l’implémentation System.Xml ne satisfait pas à la « contrainte de composant de schéma : attribution unique de particules », qui est décrite dans la section Contraintes sur les composants de schéma de groupe de modèles de la spécification W3C.

• L'un des éléments du groupe fait référence un autre élément.

• L'élément référencé est un élément head d'un groupe de substitution.

• Le groupe de substitution contient un élément qui porte le même nom que l’un des éléments du groupe.

• La cardinalité de l’élément qui référence l’élément principal du groupe de substitution et l’élément portant le même nom qu’un élément de groupe de substitution n’est pas fixe (minOccurs < maxOccurs).

• La définition de l’élément qui fait référence au groupe de substitution précède la définition de l’élément portant le même nom qu’un élément de groupe de substitution.

Par exemple, dans le schéma ci-dessous le modèle de contenu est ambigu et doit provoquer une erreur de compilation, mais System.Xml compile le schéma sans erreurs.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

  <xs:element name="e1" type="xs:int"/>
  <xs:element name="e2" type="xs:int" substitutionGroup="e1"/>

  <xs:complexType name="t3">
    <xs:sequence>
      <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
      <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="e3" type="t3"/>
</xs:schema>

Si vous essayez de valider le code XML suivant par rapport au schéma ci-dessus, la validation échoue avec le message suivant : « L’élément 'e3' a un élément enfant non valide 'e2'. » et une XmlSchemaValidationException exception est levée.

<e3>
  <e2>1</e2>
  <e2>2</e2>
</e3>

Pour contourner ce problème, vous pouvez permuter les déclarations d’éléments dans le document XSD. Exemple :

<xs:sequence>
  <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
  <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
</xs:sequence>

devient cela :

<xs:sequence>
  <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
  <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
</xs:sequence>

Voici un autre exemple du même problème :

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
   <xs:element name="e1" type="xs:string"/>
   <xs:element name="e2" type="xs:string" substitutionGroup="e1"/>

   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
         <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
      </xs:sequence>
   </xs:complexType>
   <xs:element name="e3" type="t3"/>
</xs:schema>

Si vous essayez de valider le code XML suivant par rapport au schéma ci-dessus, la validation échoue avec l’exception suivante : « Exception non gérée : System.Xml. Schema.XmlSchemaValidationException : l’élément 'e2' el n’est pas valide - La valeur 'abc' n’est pas valide en fonction de son type 'http://www.w3.org/2001/XMLSchema:int' de données . La chaîne 'abc' n’est pas une valeur Int32 valide. »

<e3><e2>abc</e2></e3>

Considérations relatives à la sécurité

Les types et les membres de l’espace System.Xml de noms s’appuient sur le système de sécurité .NET. Les sections suivantes traitent des problèmes de sécurité spécifiques aux technologies XML.

Notez également que lorsque vous utilisez les System.Xml types et les membres, si le code XML contient des données susceptibles d’avoir des implications sur la confidentialité, vous devez implémenter votre application d’une manière qui respecte la confidentialité de vos utilisateurs finaux.

Accès externe

Plusieurs technologies XML permettent de récupérer d'autres documents pendant le traitement. Par exemple, une définition de type de document (DTD) peut résider dans le document en cours d'analyse. La DTD peut également résider dans un document externe référencé par le document en cours d'analyse. Le langage XSD (XML Schema Definition) et les technologies XSLT permettent également d'inclure des informations provenant d'autres fichiers. Ces ressources externes peuvent présenter des problèmes de sécurité. Par exemple, vous devez vous assurer que votre application récupère des fichiers uniquement à partir de sites de confiance et que le fichier qu’elle récupère ne contient pas de données malveillantes.

La XmlUrlResolver classe est utilisée pour charger des documents XML et pour résoudre des ressources externes telles que des entités, des DTD ou des schémas, et pour importer ou inclure des directives.

Vous pouvez remplacer cette classe et spécifier l’objet XmlResolver à utiliser. La classe XmlSecureResolver doit être utilisée si vous devez ouvrir une ressource non contrôlée ou non fiable. L'objet XmlSecureResolver enveloppe l'objet XmlResolver et permet de limiter les ressources auxquelles l'objet XmlResolver sous-jacent a accès.

Déni de service

Les scénarios suivants sont considérés comme moins vulnérables aux attaques de refus de service car les classes System.Xml fournissent un moyen de protection contre ces attaques.

• Analyse de données de texte XML

• Analyse des données XML binaires si les données XML binaires ont été générées par Microsoft SQL Server.

• Écriture de documents XML et de fragments provenant de sources de données dans le système de fichiers, des flux, un objet TextWriter ou StringBuilder

• Chargement de documents dans l'objet DOM (Document Object Model) si un objet XmlReader est utilisé et si XmlReaderSettings.DtdProcessing est défini sur DtdProcessing.Prohibit

• Exploration de l'objet DOM

Les scénarios suivants ne sont pas recommandés en cas de crainte concernant les attaques de refus de service ou d'utilisation d'un environnement non fiable.

• Traitement DTD

• Traitement de schéma - Il comprend l’ajout d’un schéma non fiable à la collection de schémas, la compilation d’un schéma non fiable et la validation à l’aide d’un schéma non fiable.

• Traitement XSLT

• Analyse de n'importe quel flux arbitraire de données XML binaires fournies par l'utilisateur

• Opérations DOM telles que l’interrogation, la modification, le déplacement de sous-arborescences entre des documents et l’enregistrement d’objets DOM

Si vous êtes préoccupé par des problèmes de déni de service ou si vous traitez avec des sources non approuvées, n’activez pas le traitement DTD. Cette option est désactivée par défaut sur XmlReader les objets créés par la XmlReader.Create méthode.

Si le traitement DTD est activé, vous pouvez utiliser la XmlSecureResolver classe pour restreindre les ressources auxquelles le XmlReader peut accéder. Vous pouvez également concevoir votre application afin que le traitement XML soit limité en mémoire et en temps. Par exemple, vous pouvez configurer des limites de délai d’expiration dans votre application ASP.NET.

Considérations relatives au traitement

Les documents XML pouvant faire référence à d'autres fichiers, il est difficile de déterminer la puissance de traitement nécessaire pour analyser un document XML. Les documents XML peuvent, par exemple, inclure une DTD. Si la DTD comporte des entités imbriquées ou des modèles de contenu complexes, l'analyse du document peut durer longtemps.

Lorsque vous utilisez XmlReader, vous pouvez restreindre la taille du document qu'il sera possible d'analyser en définissant la propriété XmlReaderSettings.MaxCharactersInDocument. Définissez la propriété XmlReaderSettings.MaxCharactersFromEntities pour limiter le nombre maximal de caractères résultant des entités développées. Consultez les rubriques de référence appropriées pour obtenir des exemples de définition de ces propriétés.

Les technologies XSD et XSLT disposent de fonctionnalités supplémentaires qui peuvent affecter les performances de traitement. Par exemple, il est possible de construire un schéma XML nécessitant un traitement relativement long lorsqu'il est évalué en fonction d'un document relativement petit. Il est également possible d'intégrer des blocs de script dans une feuille de style XSLT. Les deux cas représentent une menace de sécurité potentielle pour votre application.

Lorsque vous créez une application qui utilise la XslCompiledTransform classe , vous devez être conscient des éléments suivants et de leurs implications :

• Le script XSLT est désactivé par défaut. Le script XSLT ne doit être activé que si la prise en charge des scripts est nécessaire et si vous travaillez dans un environnement totalement fiable.

• La fonction document() XSLT est désactivée par défaut. Si vous activez la fonction document(), limitez les ressources accessibles en transmettant un objet XmlSecureResolver à la méthode XslCompiledTransform.Transform.

• Les objets d'extension sont activés par défaut. Si un objet XsltArgumentList contenant des objets d’extension est transmis à la méthode XslCompiledTransform.Transform, les objets d’extension sont utilisés.

• Les feuilles de style XSLT peuvent inclure des références à d'autres fichiers et à des blocs de script intégrés. Un utilisateur malveillant peut exploiter cette fonction en fournissant des données ou feuilles de style qui, une fois exécutées, peuvent entraîner l'exécution du traitement jusqu'à l'épuisement des ressources de l'ordinateur.

• Les applications XSLT qui s’exécutent dans un environnement de confiance mixte peuvent entraîner une usurpation de feuille de style. Un utilisateur malveillant peut, par exemple, charger un objet avec une feuille de style nuisible et le transmettre à un autre utilisateur qui appelle ensuite la méthode XslCompiledTransform.Transform et exécute la transformation.

Vous pouvez réduire ces problèmes de sécurité en désactivant le script ou la fonction document() sauf si la feuille de style provient d'une source fiable et en refusant les objets XslCompiledTransform, les feuilles de style XSLT ou les données de base XML provenant d'une source non fiable.

Gestion des exceptions

Les exceptions levées par les composants de niveau inférieur peuvent divulguer des informations de chemin que vous ne souhaitez pas exposer à l’application. Vos applications doivent intercepter les exceptions et les traiter de manière appropriée.

Voir aussi

• System.Xml.Xsl
• System.Xml.Schema
• System.Xml.Linq
• Documents et données XML