db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-3676) Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far
Date Fri, 19 Aug 2011 16:34:27 GMT

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

Rick Hillegas commented on DERBY-3676:
--------------------------------------

I would like to understand the vulnerability better. I don't think that Derby uses (Prepared)Statement.toString()
when it prints diagnostic information to derby.log after you set derby.language.logStatementText=true.
As I understand the attack, the problem is with the (Prepared)Statement once it is in the
application. In a sloppy application, (Prepared)Statements could be visible across threads/sessions,
allowing blackhats to snoop sensitive information.

Is that the attack?

-----------------------

Here are some rambling thoughts about how to protect against this attack:

I am positive about controlling this new toString() behavior with a permission which would
be checked when running under a Java SecurityManager as Dag suggests and as is done with DriverManager.setLogWriter().
See http://download.oracle.com/javase/7/docs/api/java/sql/DriverManager.html#setLogWriter%28java.io.PrintWriter%29
and http://download.oracle.com/javase/7/docs/api/java/sql/SQLPermission.html

For reference: if you are running under a Java SecurityManager, the DriverManager.setLogWriter()
method succeeds only if your security policy grants the "setLog" SQLPermission to your application's
code domain. E.g.:

grant codeBase "file:///Applications/myApp.jar"
{
  permission java.sql.SQLPermission "setLog";
};

We could require something similar in order to protect the (Prepared)Statement.toString()
method from abuse:

grant codeBase "file:///Applications/myApp.jar"
{
  permission java.sql.SQLPermission "com.apache.derby.client.am.Statement", "toString";
  permission java.sql.SQLPermission "com.apache.derby.impl.jdbc.EmbedStatement", "toString";
};

If the permission is granted, then the new toString() behavior would be in effect. Otherwise,
you would get the old toString() behavior.


> Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters
replaced by the values that have been set so far
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3676
>                 URL: https://issues.apache.org/jira/browse/DERBY-3676
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>            Reporter: Rick Hillegas
>            Assignee: Siddharth Srivastava
>         Attachments: humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt,
humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt,
ick.txt, ick.txt, prepared.diff, statementCacheVTI.sql
>
>
> This topic came up in the following email thread on the user list: http://www.nabble.com/PreparedStatement.toString%28%29---nice-formatting-td17250811.html#a17250811
Here's what the thread requests: 
> "In mysql, a toString() on a PreparedStatement will do this, eg "select x
> from foo where x.a = ?" will become "select x from foo where x.a = 1" with
> the appropriate setValue() call."
> At first blush, this seems like it might be a simple project for a newcomer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message