[ 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