System.Xml Security Guidelines

The following sections provide general guidelines that can be used to help secure your System.Xml applications.

Security Issues

The security issues can be broken out into three general categories.

External Access

Several XML technologies have the ability to retrieve other documents during processing. For example, a document type definition (DTD) can reside in the document being parsed. The DTD can also live in an external document that is referenced by the document being parsed. The XML Schema definition language (XSD) and XSLT technologies also have the ability to include information from other files. These external resources can present some security concerns:

• How do you ensure that your application only retrieves files from trusted sites? For example, if an XML document has a file reference to a file from the Internet, do you want your application to retrieve this file?

• If you retrieve a file, how do you ensure that file does not contain malicious data?

Denial of Service

Because XML documents can include references to other files, it is difficult to determine how much processing power is required to parse an XML document. For example, XML documents can include a DTD. If the DTD contains nested entities or complex content models, it could take an excessive amount of time to parse the document.

The following scenarios are considered to be less vulnerable to denial of service attacks because the System.Xml classes provide a means of protection from such attacks. To learn about the types of security issues that can arise when working with System.Xml components and what you can do to mitigate these threats, see System.Xml Security Considerations.

• Parsing text XML data.

• Parsing binary XML data if the binary XML data was generated by Microsoft SQL Server 2005.

• Writing XML documents and fragments from data sources to the file system, streams, a TextWriter, or a StringBuilder.

• Loading documents into the Document Object Model (DOM) object if you are using an XmlReader object and DtdProcessing set to Prohibit.

• Navigating the DOM object.

The following scenarios are not recommended if you are concerned about denial of service attacks, or if you are working in an untrusted environment.

• DTD processing.

• Schema processing. This includes adding an untrusted schema to the schema collection, compiling an untrusted schema, and validating by using an untrusted schema.

• XSLT processing.

• Parsing any arbitrary stream of user supplied binary XML data.

• DOM operations such as querying, editing, moving sub-trees between documents, and saving DOM objects.

When using XmlReader, you can limit the size of the document that can be parsed by setting the MaxCharactersInDocument property. You can limit the number of characters that result from expanding entities by setting the MaxCharactersFromEntities property. See the appropriate reference topics for examples of setting these properties.

Processing

The XSD and XSLT technologies have additional capabilities that can affect processing performance. For example, it is possible to construct an XML schema that requires a substantial amount of time to process when evaluated over a relatively small document. It is also possible to embed script blocks within an XSLT style sheet. Both cases pose a potential security threat to your application.

Mitgations to Security Issues

The following sections detail mitigations to issues raised under the previous Security Issues heading.

External Resources

The XmlUrlResolver class is the default resolver for all classes in the System.Xml namespace. It is used to load XML documents, and to resolve external resources such as entities, DTDs or schemas, and import or include directives.

The APIs allow you to override this by specifying the XmlResolver object to use. Use the XmlSecureResolver class if you need to open a resource that you do not control, or that is untrusted. The XmlSecureResolver wraps an XmlResolver and allows you to restrict the resources that the underlying XmlResolver has access to.

DTD Processing

Do not enable DTD processing if you are concerned about Denial of Service issues or if you are dealing with untrusted sources. DTD processing is disabled by default on XmlReader objects that the Create method creates.

If you have DTD processing enabled, you can use the XmlSecureResolver to restrict the resources that the XmlReader can access. You can also design your application so that the XML processing is memory and time constrained. For example, configure time-out limits in your ASP.NET application.

XSLT Processing

When creating an application that uses the XslCompiledTransform class, you should be aware of the following items and their implications:

• XSLT scripting is disabled by default. XSLT scripting should be enabled only if you require script support and you are working in a fully trusted environment.

• The XSLT document() function is disabled by default. If you enable the document() function, restrict the resources that can be accessed by passing an XmlSecureResolver object to the Transform method.

• Extension objects are enabled by default. If an XsltArgumentList object that contains extension objects is passed to the Transform method, the extension objects are used.

• XSLT style sheets can include references to other files and embedded script blocks. A malicious user can exploit this by supplying you with data or style sheets that, when executed, can cause your system to process until the computer runs low on resources.

• XSLT applications that run in a mixed trust environment can result in style sheet spoofing. For example, a malicious user can load an object with a harmful style sheet and hand it off to another user who subsequently calls the Transform method and executes the transformation.

These security issues can be mitigated by not enabling scripting or the document() function unless the style sheet comes from a trusted source, and by not accepting XslCompiledTransform objects, XSLT style sheets, or XML source data from an untrusted source.

Exception Handling

Exceptions thrown by lower level components can disclose path information that you do not want exposed to the application. Your applications must catch exceptions and process them appropriately.

XmlTextWriter Usage

When you pass the XmlTextWriter to another application, the underlying stream is exposed to that application. If you need to pass the XmlTextWriter to a semi-trusted application, you should use an XmlWriter object created by the Create method instead.

See Also

Tasks

How to: Use the XmlSecureResolver Class

Other Resources

Security and Your System.Xml Applications