XML schema and DTD validation passes if XML is not well-formed, but still is mostly parseable

[rcbarnett-zz]

MODSEC-5: A missing and/or bad end tag may cause the XML to not be well formed, but it may still pass validation. It seems that libxml2 is being lax here and inserting the correct end tag into the tree?

* Can this lead to an evasion?
* Can (should) we tell libxml2 to be more strict? 

In the following, the XML parsing yields:

{noformat}
XML: Parsing complete (well_formed 0).
XML parser error: XML: Failed parsing document.
...
XML: Successfully validated payload against DTD: /path/to/SoapEnvelope.dtd
{noformat}

XML (missing 'e' in ):
{noformat}

12123 {noformat}

DTD:
{noformat}

{noformat}

Rules:
{noformat}
SecRule REQUEST_HEADERS:Content-Type "^text/xml$"
"phase:1,t:none,t:lowercase,nolog,pass,ctl:requestBodyProcessor=XML"
SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skipAfter:12345
SecRule XML "@validateDTD /path/to/SoapEnvelope.dtd"
"phase:2,deny,id:12345"
{noformat}

[rcbarnett-zz]

Original reporter: brectanus

[rcbarnett-zz]

brectanus: Fixed a typo in the description.

[rcbarnett-zz]

brectanus: Patch to fail XML validation after previous parser error.

[rcbarnett-zz]

brectanus: Changeset: 1187

[rcbarnett-zz]

ivanr: Why not check msr->xml->well_formed and use a meaningful message such as "XML: DTD validation failed because content is not well formed."?

[rcbarnett-zz]

brectanus: Any previous errors are already logged:

[4] XML: Parsing complete (well_formed 0).
[2] XML parser error: XML: Failed parsing document.

This also prevents a possibly well-formed XML that may have had other generic errors.

However, it is a good idea to check that as well and yield a bit more meaningful error. I added that as well.

Changeset 1203