System.Xml Spazio dei nomi

Classi

Interfacce

Enumerazioni

Delegati

Commenti

Standard supportati

Lo System.Xml spazio dei nomi supporta questi standard:

• XML 1.0, incluso il supporto DTD
• Spazi dei nomi XML, sia a livello di flusso che dom
• XML Schema
• Espressioni XPath
• Trasformazioni XSLT
• DOM Level 1 Core
• DOM Level 2 Core

Vedere la sezione Differenze rispetto alle specifiche W3C per due casi in cui le classi XML differiscono dalle raccomandazioni W3C.

Elaborazione asincrona di XML

Le System.Xml.XmlReader classi e System.Xml.XmlWriter includono diversi metodi asincroni basati sul modello di programmazione asincrona. Questi metodi possono essere identificati dalla stringa "Async" alla fine dei nomi. Con questi metodi, è possibile scrivere codice asincrono simile al codice sincrono ed è possibile eseguire facilmente la migrazione del codice sincrono esistente al codice asincrono.

• Usare i metodi asincroni nelle app in cui è presente una latenza significativa del flusso di rete. Evitare di usare le API asincrone per il flusso di memoria o le operazioni di lettura/scrittura del flusso di file locale. Il flusso di input, XmlTextReadere XmlTextWriter deve supportare anche le operazioni asincrone. In caso contrario, i thread continueranno a essere bloccati dalle operazioni di I/O.

• Non è consigliabile combinare chiamate di funzione sincrone e asincrone, perché è possibile dimenticare di usare la await parola chiave o usare un'API sincrona in cui è necessaria una funzione asincrona.

• Non impostare il XmlReaderSettings.Async flag o XmlWriterSettings.Async su true se non si intende usare un metodo asincrono.

• Se si dimentica di specificare la await parola chiave quando si chiama un metodo asincrono, i risultati sono non deterministici: è possibile ricevere il risultato previsto o un'eccezione.

• Quando un XmlReader oggetto legge un nodo di testo di grandi dimensioni, potrebbe memorizzare nella cache solo un valore di testo parziale e restituire il nodo di testo, pertanto il recupero della XmlReader.Value proprietà potrebbe essere bloccato da un'operazione di I/O. Usare il XmlReader.GetValueAsync metodo per ottenere il valore di testo in modalità asincrona oppure usare il XmlReader.ReadValueChunkAsync metodo per leggere un blocco di testo di grandi dimensioni in blocchi.

• Quando si usa un XmlWriter oggetto, chiamare il XmlWriter.FlushAsync metodo prima di chiamare XmlWriter.Close per evitare di bloccare un'operazione di I/O.

Differenze rispetto alle specifiche W3C

In due casi che coinvolgono vincoli sui componenti dello schema del gruppo di modelli, lo System.Xml spazio dei nomi differisce dalle raccomandazioni W3C.

Coerenza nelle dichiarazioni degli elementi:

In alcuni casi, quando vengono usati i gruppi di sostituzione, l'implementazione System.Xml non soddisfa il "Vincolo componente schema: dichiarazioni di elemento coerenti", descritto nella sezione Vincoli sui componenti dello schema del gruppo di modelli della specifica W3C.

Ad esempio, lo schema seguente include elementi con lo stesso nome ma tipi diversi nello stesso modello di contenuto e vengono usati gruppi di sostituzione. Questo dovrebbe causare un errore, ma System.Xml compila e convalida lo schema senza errori.

<?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>

In questo schema il tipo t3 contiene una sequenza di elementi. A causa della sostituzione, il riferimento all'elemento e1 dalla sequenza può comportare l'elemento di tipo t1 o l'elemento e1e2 di tipo t2. Quest'ultimo caso genera una sequenza di due e2 elementi, dove uno è di tipo t2 e l'altro è di tipo xs:int.

Attribuzione di particelle univoca:

Nelle condizioni seguenti, l'implementazione System.Xml non soddisfa il "Vincolo componente schema: attribuzione di particelle univoche", descritto nella sezione Vincoli sui componenti dello schema del gruppo di modelli della specifica W3C.

• Uno degli elementi del gruppo fa riferimento a un altro elemento.
• L'elemento a cui si fa riferimento è un elemento head di un gruppo di sostituzione.
• Il gruppo di sostituzione contiene un elemento con lo stesso nome di uno degli elementi del gruppo.
• La cardinalità dell'elemento che fa riferimento all'elemento head del gruppo di sostituzione e all'elemento con lo stesso nome di un elemento del gruppo di sostituzione non è fisso (minOccurs maxOccurs < maxOccurs).
• La definizione dell'elemento che fa riferimento al gruppo di sostituzione precede la definizione dell'elemento con lo stesso nome di un elemento del gruppo di sostituzione.

Ad esempio, nello schema seguente il modello di contenuto è ambiguo e dovrebbe causare un errore di compilazione, ma System.Xml compila lo schema senza errori.

<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>

Se si tenta di convalidare il codice XML seguente rispetto allo schema precedente, la convalida avrà esito negativo con il messaggio seguente: "L'elemento 'e3' ha un elemento figlio non valido 'e2'". Verrà generata un'eccezione XmlSchemaValidationException .

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

Per risolvere questo problema, è possibile scambiare le dichiarazioni degli elementi nel documento XSD. Per esempio:

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

diventa questo:

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

Ecco un altro esempio dello stesso problema:

<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>

Se si tenta di convalidare il codice XML seguente rispetto allo schema precedente, la convalida avrà esito negativo con l'eccezione seguente: "Eccezione non gestita: System.Xml.Schema.XmlSchemaValidationException: l'elemento el 'e2' non è valido - Il valore 'abc' non è valido in base al relativo tipo di 'http://www.w3.org/2001/XMLSchema:int' dati- La stringa 'abc' non è un valore Int32 valido".

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

Considerazioni relative alla sicurezza

I tipi e i membri nello System.Xml spazio dei nomi si basano sul sistema di sicurezza .NET. Nelle sezioni seguenti vengono illustrati i problemi di sicurezza specifici delle tecnologie XML.

Si noti anche che quando si usano i System.Xml tipi e i membri, se il codice XML contiene dati con potenziali implicazioni sulla privacy, è necessario implementare l'app in modo da rispettare la privacy degli utenti finali.

Accesso esterno

Diverse tecnologie XML possono recuperare altri documenti durante l'elaborazione. Ad esempio, una definizione del tipo di documento (DTD) può risiedere nel documento analizzato. Il DTD può inoltre trovarsi in un documento esterno a cui fa riferimento il documento analizzato. Le tecnologie XSD (XML Schema Definition Language) e XSLT hanno anche la possibilità di includere informazioni da altri file. Queste risorse esterne possono presentare alcuni problemi di sicurezza. Ad esempio, è necessario assicurarsi che l'app recuperi i file solo da siti attendibili e che il file recuperato non contenga dati dannosi.

La XmlUrlResolver classe viene usata per caricare documenti XML e per risolvere risorse esterne, ad esempio entità, DTD o schemi e importare o includere direttive.

È possibile eseguire l'override di questa classe e specificare l'oggetto XmlResolver da usare. Usare la XmlSecureResolver classe se è necessario aprire una risorsa non controllata o non attendibile. esegue XmlSecureResolver il wrapping di un oggetto XmlResolver e consente di limitare le risorse a cui l'oggetto sottostante XmlResolver ha accesso.

Denial of Service

Gli scenari seguenti sono considerati meno vulnerabili agli attacchi Denial of Service perché le System.Xml classi forniscono un mezzo di protezione da tali attacchi.

• Analisi dei dati XML di testo.

• Analisi dei dati XML binari se i dati XML binari sono stati generati da Microsoft SQL Server.

• Scrittura di documenti e frammenti XML da origini dati nel file system, nei flussi, in un TextWriteroggetto o in StringBuilder.

• Caricamento di documenti nell'oggetto DOM (Document Object Model) se si utilizza un XmlReader oggetto e XmlReaderSettings.DtdProcessing si imposta su DtdProcessing.Prohibit.

• Esplorazione dell'oggetto DOM.

Gli scenari seguenti non sono consigliati se si è preoccupati per gli attacchi Denial of Service o se si lavora in un ambiente non attendibile.

• Elaborazione DTD.

• Elaborazione dello schema. Ciò include l'aggiunta di uno schema non attendibile alla raccolta di schemi, la compilazione di uno schema non attendibile e la convalida tramite uno schema non attendibile.

• Elaborazione XSLT.

• Analisi di qualsiasi flusso arbitrario di dati XML binari forniti dall'utente.

• Operazioni DOM come l'esecuzione di query, la modifica, lo spostamento di sottoalberi tra documenti e il salvataggio di oggetti DOM.

Se si è interessati a problemi denial of service o se si gestiscono origini non attendibili, non abilitare l'elaborazione DTD. Questa opzione è disabilitata per impostazione predefinita sugli XmlReader oggetti creati dal XmlReader.Create metodo .

Se è abilitata l'elaborazione DTD, è possibile usare la XmlSecureResolver classe per limitare le risorse a cui può accedere.XmlReader È anche possibile progettare l'app in modo che l'elaborazione XML sia vincolata da memoria e tempo. Ad esempio, è possibile configurare i limiti di timeout nell'app ASP.NET.

Considerazioni sull'elaborazione

Poiché i documenti XML possono includere riferimenti ad altri file, è difficile determinare la potenza di elaborazione necessaria per analizzare un documento XML. Ad esempio, i documenti XML possono includere un DTD. Se il DTD contiene entità annidate o modelli di contenuto complessi, potrebbe essere necessario un tempo eccessivo per analizzare il documento.

Quando si usa XmlReader, è possibile limitare le dimensioni del documento che è possibile analizzare impostando la XmlReaderSettings.MaxCharactersInDocument proprietà . È possibile limitare il numero di caratteri risultanti dall'espansione delle entità impostando la XmlReaderSettings.MaxCharactersFromEntities proprietà . Vedere gli argomenti di riferimento appropriati per esempi di impostazione di queste proprietà.

Le tecnologie XSD e XSLT hanno funzionalità aggiuntive che possono influire sulle prestazioni di elaborazione. Ad esempio, è possibile costruire un XML Schema che richiede una notevole quantità di tempo per l'elaborazione quando viene valutata su un documento relativamente piccolo. È anche possibile incorporare blocchi di script all'interno di un foglio di stile XSLT. Entrambi i casi rappresentano una potenziale minaccia alla sicurezza per l'app.

Quando si crea un'app che usa la XslCompiledTransform classe , è necessario tenere presenti gli elementi seguenti e le relative implicazioni:

• Lo scripting XSLT è disabilitato per impostazione predefinita. Gli script XSLT devono essere abilitati solo se è necessario il supporto dello script e si lavora in un ambiente completamente attendibile.

• La funzione XSLT document() è disabilitata per impostazione predefinita. Se si abilita la document() funzione, limitare le risorse a cui è possibile accedere passando un XmlSecureResolver oggetto al XslCompiledTransform.Transform metodo .

• Gli oggetti di estensione sono abilitati per impostazione predefinita. Se un XsltArgumentList oggetto che contiene oggetti di estensione viene passato al XslCompiledTransform.Transform metodo , vengono utilizzati gli oggetti di estensione.

• I fogli di stile XSLT possono includere riferimenti ad altri file e blocchi di script incorporati. Un utente malintenzionato può sfruttare questo problema fornendo dati o fogli di stile che, quando eseguiti, possono causare l'elaborazione del sistema fino a quando il computer non viene eseguito con risorse scarse.

• Le app XSLT eseguite in un ambiente trust misto possono comportare lo spoofing dei fogli di stile. Ad esempio, un utente malintenzionato può caricare un oggetto con un foglio di stile dannoso e consegnarlo a un altro utente che successivamente chiama il XslCompiledTransform.Transform metodo ed esegue la trasformazione.

Questi problemi di sicurezza possono essere mitigati non abilitando la creazione di script o la document() funzione a meno che il foglio di stile non provenga da un'origine attendibile e non accetti XslCompiledTransform oggetti, fogli di stile XSLT o dati di origine XML da un'origine non attendibile.

Gestione delle eccezioni

Le eccezioni generate dai componenti di livello inferiore possono divulgare informazioni sul percorso che non si desidera esporre all'app. Le app devono intercettare le eccezioni ed elaborarle in modo appropriato.

Vedi anche

• System.Xml.Xsl
• System.Xml.Schema
• System.Xml.Linq
• Documenti e dati XML