I could find the answers in FAQ.

Special XML attacks

XML messages have a few intrinsic weakness, that Web Service creators should know about. None of these problems are unique to SOAP; anyone processing incoming XML needs to know and resist these.

  1. Large XML Documents
    Have a client post an XML doc of extreme length/depth <foo><foo><foo>...</foo></foo></foo> This does bad things to DOM parsers and memory consumption on the server: a DoS attack. The issue here is that the costs of handling a large XML document are much greater than the cost of generating one.
  2. Entity Expansion Attacks.
    If an XML doc header declares some recursive entity declarations, and the file refers to them, then bad things happen. Axis became immune to this between versions 1.0 and 1.1.
  3. Entities referring to the filesystem.
    Here you declare an entity referring to a local file, then expand it. Result: you may be able to probe for files, perhaps even get a copy of it in the error response. As Axis does not support entities any more, it resists this. If your code has any way of resolving URLs from incoming messages, you may recreate this problem.

The other thing to know about XML is that string matching is not enough to be sure that the content is safe, because of the many ways to reformat the same XML.

 

Thanks

 

-Venky


From: Venkatesh Jayaraman (jvenky)
Sent: Thursday, November 09, 2006 9:57 AM
To: [email protected]
Subject: RE: Do we have XML Injection thread on AXIS 1.X Soap Servers?

 

Does AXIS take care of this internally?

Thanks for the answers in advance.

 

-Venky

 


From: Venkatesh Jayaraman (jvenky)
Sent: Thursday, November 09, 2006 9:51 AM
To: '[email protected]'
Subject: Do we have XML Injection thread on AXIS 1.X Soap Servers?

 

Security Issue Posed by Nested Entity Definitions

While XML does not allow recursive entity definitions, it does permit nested entity definitions, which produces the potential for Denial of Service attacks on a server which accepts XML data from external sources. For example, a SOAP document like the following that has very deeply nested entity definitions can consume 100% of CPU time and large amounts of memory in entity expansions:

<?xml version="1.0" encoding ="UTF-8"?>



 
 <!DOCTYPE foobar[



 
 <!ENTITY x100 "foobar">



 
 <!ENTITY  x99 "&x100;&x100;">



 
 <!ENTITY  x98 "&x99;&x99;">



 
 ...



 
 <!ENTITY   x2 "&x3;&x3;">



 
 <!ENTITY   x1 "&x2;&x2;">



 
 ]>



 
<SOAP-ENV:Envelope xmlns:SOAP-ENV=...>



 
<SOAP-ENV:Body>



 
<ns1:aaa xmlns:ns1="urn:aaa" SOAP-ENV:encodingStyle="...">



 
<foobar xsi:type="xsd:string">&x1;</foobar>



 
</ns1:aaa>



 
</SOAP-ENV:Body>



 
</SOAP-ENV:Envelope> 

A system that doesn't take in external XML data need not be concerned with the issue, but one that does can utilize one of the following safeguards to prevent the problem:

New system property to limit entity expansion

The entityExpansionLimit system property lets existing applications constrain the total number of entity expansions without recompiling the code. The parser throws a fatal error once it has reached the entity expansion limit. (By default, the limit is set to 64000.)

To set the entity expansion limit using the system property, use an option like the following on the java command line:
-DentityExpansionLimit=100000

 

New parser property to disallow DTDs

The application can also set the http://apache.org/xml/features/disallow-doctype-decl parser property to true. A fatal error is then thrown if the incoming XML document contains a DOCTYPE declaration. (The default value for this property is false.) This property is typically useful for SOAP based applications where a SOAP message must not contain a Document Type Declaration.

New feature for Secure Processing

JAXP 1.3 includes a new secure processing feature in which an application can configure the SAXParserFactory or DocumentBuilderFactory to get an XML processor that behaves in a secured fashion.  Setting this feature to true sets the entity expansion limit to 64000.  Note that the default limit can be increased using the entityExpansionLimit system property.

 

 

 

 

http://java.sun.com/j2se/1.5.0/docs/guide/xml/jaxp/JAXP-Compatibility_150.html

 

 

Thanks

 

-Venky (Venkatesh Jayaraman)

 

 

Reply via email to