Major Description
While writing XXE vulnerability test suites for XmlVTI, I found that
some of the error handling logic in XmlVTI is a bit rough and could
be made a bit smoother.
At least the following improvements would be useful:
1) Remove the unconditional printStackTrace call in XmlVTI.next()
when it catches a Throwable.
2) Chain the original exception to the SQLException using the
SQLException constructor which takes a "cause" argument.
3) Include an XMLErrorHandler class so that fatal exceptions that
arise within the XML parser don't directly print their own messages
to System.err, to avoid printing
[junit] [Fatal Error] :1:1: The parser has encountered more than "64,000" entity expansions in this document; this is the limit imposed by the application.
4) Close the _xmlResource input stream, if it exists, from the
XMLErrorHandler methods, so that the parser's files are closed
sooner and we are (I think) less likely to encounter
[junit] <assertDirectoryDeleted> attempt 1 left 2 files/dirs behind: 0=extin\xmlOptimizerXXE2.trace 1=extin
[junit] <assertDirectoryDeleted> attempt 2 left 2 files/dirs behind: 0=extin\xmlOptimizerXXE2.trace 1=extin
[junit] <assertDirectoryDeleted> attempt 3 left 2 files/dirs behind: 0=extin\xmlOptimizerXXE2.trace 1=extin
[junit] <assertDirectoryDeleted> attempt 4 left 2 files/dirs behind: 0=extin\xmlOptimizerXXE2.trace 1=extin