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, au niveau du flux et dom
• Schémas XML
• Expressions XPath
• Transformations XSLT
• Niveau DOM 1 Cœur
• Dom Niveau 2 Core

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

Traitement xml de manière asynchrone

Les System.Xml.XmlReader classes et System.Xml.XmlWriter les classes 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 leurs noms. Avec ces méthodes, vous pouvez écrire du code asynchrone similaire à votre code synchrone, et vous pouvez migrer facilement votre code synchrone existant vers du code asynchrone.

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

• Nous vous déconseillons de combiner des appels de fonction synchrones et asynchrones, car vous pouvez 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 true ou XmlWriterSettings.Async la XmlReaderSettings.Async valeur 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 renvoyer le nœud de texte, de sorte que la récupération de la XmlReader.Value propriété peut ê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 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 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 « 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 entraîner 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 entraîner un élément e1 de type t1 ou 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 est de type xs:int.

Attribution unique de particules :

Dans les conditions suivantes, l’implémentation System.Xml ne répond 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 principal d’un groupe de substitution.
• Le groupe de substitution contient un élément portant le même nom que l’un des éléments du groupe.
• La cardinalité de l’élément qui fait 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 sous le modèle de contenu est ambigu et doit provoquer une erreur de compilation, mais System.Xml compile le schéma sans erreur.

<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 l’élément enfant « e2 » non valide et une XmlSchemaValidationException exception est levée.

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

Pour contourner ce problème, vous pouvez échanger des déclarations d’élément dans le document XSD. Par 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 ceci :

<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 décrivent les 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 qui ont des implications potentielles en matière de confidentialité, vous devez implémenter votre application de manière à respecter la confidentialité de vos utilisateurs finaux.

Accès externe

Plusieurs technologies XML ont la possibilité 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 analysé. Le DTD peut également se trouver dans un document externe référencé par le document analysé. Le langage de définition de schéma XML (XSD) et les technologies XSLT ont également la possibilité d’inclure des informations provenant d’autres fichiers. Ces ressources externes peuvent présenter des problèmes de sécurité. Par exemple, vous souhaiterez vous assurer que votre application récupère des fichiers uniquement à partir de sites approuvés et que le fichier qu’il récupère ne contient pas de données malveillantes.

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

Vous pouvez remplacer cette classe et spécifier l’objet XmlResolver à utiliser. Utilisez la XmlSecureResolver classe si vous devez ouvrir une ressource que vous ne contrôlez pas ou qui n’est pas approuvée. L’encapsule XmlSecureResolver et XmlResolver vous permet de restreindre les ressources auxquelles le sous-jacent XmlResolver a accès.

Déni de service

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

• Analyse des données XML de texte.

• 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 et de fragments XML à partir de sources de données dans le système de fichiers, les flux, un TextWriterou un StringBuilder.

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

• Navigation dans l’objet DOM.

Les scénarios suivants ne sont pas recommandés si vous êtes préoccupé par les attaques par déni de service ou si vous travaillez dans un environnement non approuvé.

• Traitement DTD.

• Traitement du schéma. Cela inclut l’ajout d’un schéma non approuvé à la collection de schémas, la compilation d’un schéma non approuvé et la validation à l’aide d’un schéma non approuvé.

• Traitement XSLT.

• Analyse de tout 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 les documents et l’enregistrement d’objets DOM.

Si vous êtes préoccupé par les problèmes de déni de service ou si vous traitez avec des sources non approuvées, n’activez pas le traitement DTD. Cela est désactivé 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 il 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

Étant donné que les documents XML peuvent inclure des références à d’autres fichiers, il est difficile de déterminer la puissance de traitement nécessaire pour analyser un document XML. Par exemple, les documents XML peuvent inclure un DTD. Si le DTD contient des entités imbriquées ou des modèles de contenu complexes, l’analyse du document peut prendre beaucoup de temps.

Lorsque vous utilisez XmlReader, vous pouvez limiter la taille du document qui peut être analysée en définissant la XmlReaderSettings.MaxCharactersInDocument propriété. Vous pouvez limiter le nombre de caractères résultant du développement d’entités en définissant la XmlReaderSettings.MaxCharactersFromEntities propriété. 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 ont des fonctionnalités supplémentaires qui peuvent affecter les performances de traitement. Par exemple, il est possible de construire un schéma XML qui nécessite un temps important de traitement lorsqu’il est évalué sur un document relativement petit. Il est également possible d’incorporer des blocs de script dans une feuille de style XSLT. Les deux cas représentent une menace de sécurité potentielle pour votre application.

Lors de la création d’une application qui utilise la XslCompiledTransform classe, vous devez connaître les éléments suivants et leurs implications :

• Le script XSLT est désactivé par défaut. Le script XSLT ne doit être activé que si vous avez besoin d’une prise en charge de script et que vous travaillez dans un environnement entièrement approuvé.

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

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

• Les feuilles de style XSLT peuvent inclure des références à d’autres fichiers et blocs de script incorporés. Un utilisateur malveillant peut exploiter ce problème en vous fournissant des données ou des feuilles de style qui, lorsqu’elles sont exécutées, peuvent entraîner le traitement de votre système jusqu’à ce que l’ordinateur s’exécute faiblement sur les ressources.

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

Ces problèmes de sécurité peuvent être atténués en n’activant pas le script ou la document() fonction, sauf si la feuille de style provient d’une source approuvée et en n’acceptant XslCompiledTransform pas d’objets, de feuilles de style XSLT ou de données sources XML provenant d’une source non approuvée.

Traitement des exceptions

Les exceptions levées par des composants de niveau inférieur peuvent divulguer les informations de chemin d’accès 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