You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2015/07/04 22:13:04 UTC

[jira] [Commented] (DERBY-6820) Improve error handling in XmlVTI

    [ https://issues.apache.org/jira/browse/DERBY-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14614041#comment-14614041 ] 

ASF subversion and git services commented on DERBY-6820:
--------------------------------------------------------

Commit 1689194 from [~bryanpendleton] in branch 'code/trunk'
[ https://svn.apache.org/r1689194 ]

DERBY-6810: Add regression tests for XXE vulnerability

This change adds tests which provoke XML External Entity vulnerabilities
in the XmlVTI class. One test demonstrates a file access vulnerability;
the other test attempts the "billion laughs" attack. These are the XmlVTI
versions of similar tests added in revision 1685313.

These new tests exercise error-handling code paths in XmlVTI and hence
are related to (and serve as tests of) the changes made by DERBY-6820.

> Improve error handling in XmlVTI
> --------------------------------
>
>                 Key: DERBY-6820
>                 URL: https://issues.apache.org/jira/browse/DERBY-6820
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.11.1.1
>            Reporter: Bryan Pendleton
>            Assignee: Bryan Pendleton
>             Fix For: 10.12.0.0
>
>         Attachments: errorHandling.diff
>
>
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)