The November, 2009 issue of MSDN Magazine contained a column by Bryan Sullivan
called "XML Denial of Service Attacks and Defenses." Under the category,
"Security Briefs", the article detailed a specific denial of service attack (DoS)
vector called "XML Bombing," in which well-formed, valid and malicious XML doc
is introduced into a target system with the goal of disabling it. 

Among the threats Sullivan discussed is associated with XML Document Type
Definitions (DTD). DTDs may be declared within an XML document both via
an external reference (most common), AND via internal, inline definition.

W3 Schools discusses DTD's here: http://www.w3schools.com/Xml/xml_dtd.asp

One type of XML bomb is a document containing very deeply nested entities
within a DTD. The net effect is that the XML parser will consume gigabytes
of memory trying to parse the DTD.

Another type of bomb uses a large number of attributes -- Sullivan estimates
100,000 or more -- associated with a single element. This type of attack
would produce a similar condition to the DTD-based attacked described above,
but only in .NET Framework versions prior to 2.0.

A final attack type Sullivan offered was associated with external entities
inside DTDs. The attacker would introduce a document which points to a URL
which will return nothing OR to a URL of some other resource on a company's
intranet, thereby conducting DoS on two sites at once. 

In this web application, as you know, I use XML for content management
instead of an RDBMS. With XmlTextReader objects instantiated to do the
heavy lifting for me, I wanted a way I could change the settings of every
instance to help secure each against this threat.

Sullivan advised modifying two attributes of the XmlTextReader instance.
The first was to make use of the ProhibitDtd property (framework versions
3.5 and earlier). By default, the value of that property is set to FALSE,
which enables the reader object to interpret inline DTD information. 

	Public Shared Sub ProhibitXmlDtd(ByVal objReader As XmlTextReader)
	        objReader.ProhibitDtd = True
	End Sub

(I implemented this solution, then rinsed every XmlTextReader object through
it.)

A second action Sullivan described was to set the XmlResolver property of
your reader's associated XmlReaderSettings object to null. That will prevent
your reader from resolving external entities. (Sullivan offers a more involved
approach to security if you require the ability to resolve external entities.)

I'd recommend spending a few moments reading Sullivan's article. I'm glad I did.
http://msdn.microsoft.com/en-us/magazine/ee335713.aspx

Best,

halfgk

copyright 2009 halfgk.com