OpenJPA
  1. OpenJPA
  2. OPENJPA-1678

SQL Parameter values may contain sensitive information and should not be logged by default.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.3, 1.1.0, 1.2.2, 2.0.0, 2.1.0
    • Fix Version/s: 1.0.4, 1.2.3, 1.3.0, 2.0.1, 2.1.0
    • Component/s: None
    • Labels:
      None

      Description

      The values for parameters used in our SQL statements may contain sensitive information (e.g. social security numbers). By default these values are printed in the exception message and in SQL trace. Having the values printed can be a great help when debugging an application - but presents a risk when used in production.

      To resolve the issue I propose to disable printing the parameter values by default. The parameter values will still be tracked internally - but will not be displayed in exception messages or trace unless the following property is set :
      <property name="openjpa.ConnectionFactoryProperties" value="printParameters=true"/>

        Issue Links

          Activity

          Rick Curtis made changes -
          Link This issue incorporates OPENJPA-1886 [ OPENJPA-1886 ]
          Michael Dick made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 1.3.0 [ 12313326 ]
          Resolution Fixed [ 1 ]
          Michael Dick committed 955383 (2 files)
          Michael Dick made changes -
          Attachment OPENJPA-1678-openjpa.Log.1.2.x.patch.txt [ 12446251 ]
          Michael Dick made changes -
          Attachment OPENJPA-1678-openjpa.CFProps.1.2.x.patch.txt [ 12446250 ]
          Hide
          Michael Dick added a comment -

          Upon further review I'm leaning towards a separate parameter, also on ConnectionFactoryProperties - since this will be in service releases I'd rather not take the risk of affecting behavior or change the meaning of track parameters for any existing applications.

          Show
          Michael Dick added a comment - Upon further review I'm leaning towards a separate parameter, also on ConnectionFactoryProperties - since this will be in service releases I'd rather not take the risk of affecting behavior or change the meaning of track parameters for any existing applications.
          Hide
          Michael Dick added a comment -

          Hi Pinaki,

          I think this is orthogonal to the level of tracing used. While it's often useful in conjunction with other tracing the two should not be tied together. You should be able to see parameters in your exception text (if you so desire) without enabling logging for example.

          I'm not entirely sold on introducing a new log level in service either. For the time being I'm going to treat this as a bug with openjpa.ConnectionFactoryProperties.TrackParameters and fix it that way (the cfProps patch).

          Show
          Michael Dick added a comment - Hi Pinaki, I think this is orthogonal to the level of tracing used. While it's often useful in conjunction with other tracing the two should not be tied together. You should be able to see parameters in your exception text (if you so desire) without enabling logging for example. I'm not entirely sold on introducing a new log level in service either. For the time being I'm going to treat this as a bug with openjpa.ConnectionFactoryProperties.TrackParameters and fix it that way (the cfProps patch).
          Hide
          Pinaki Poddar added a comment -

          I think parameter tracing is useful.
          Here is my suggestion on usage

          <property name="openjpa.Log" value="SQL=DEBUG"/>

          In general DEBUG a new log level finer than TRACE. And DEBUG can be non-localized (what Rick wanted TRACE to be).

          Show
          Pinaki Poddar added a comment - I think parameter tracing is useful. Here is my suggestion on usage <property name="openjpa.Log" value="SQL=DEBUG"/> In general DEBUG a new log level finer than TRACE. And DEBUG can be non-localized (what Rick wanted TRACE to be).
          Michael Dick made changes -
          Field Original Value New Value
          Attachment OPENJPA-1678-openjpa.CFProps.1.2.x.patch.txt [ 12446250 ]
          Attachment OPENJPA-1678-openjpa.Log.1.2.x.patch.txt [ 12446251 ]
          Hide
          Michael Dick added a comment -

          I've tried it two ways. One uses openjpa.Log to control whether parameters are printed, the other uses openjpa.ConnectionFactoryProperties.

          The openjpa.Log approach is just a proof of concept. The changes will have to ripple through to any of our LogFactory classes - I just skipped that and cast to LogFactoryImpl.

          The openjpa.CFProperties approach is a bit leaner and less intrusive (I'm leaning this way at the moment).

          Show
          Michael Dick added a comment - I've tried it two ways. One uses openjpa.Log to control whether parameters are printed, the other uses openjpa.ConnectionFactoryProperties. The openjpa.Log approach is just a proof of concept. The changes will have to ripple through to any of our LogFactory classes - I just skipped that and cast to LogFactoryImpl. The openjpa.CFProperties approach is a bit leaner and less intrusive (I'm leaning this way at the moment).
          Hide
          Michael Dick added a comment -

          I thought about that too. The problem is that it isn't just logging that we're concerned with - we need to alter the toString on LoggingConnectionDecorator.LoggingPreparedStatement (from memory) LoggingConnectionDecorator is already aware of some of this - there's a trackParameters property which does similar things - but it's not quite what we need here..

          What I hadn't considered (until now) is skipping the LoggingConnectionDecorator unless this property is enabled. That might work - not sure offhand what it would do to the rest of SQL or JDBC logging though.

          Show
          Michael Dick added a comment - I thought about that too. The problem is that it isn't just logging that we're concerned with - we need to alter the toString on LoggingConnectionDecorator.LoggingPreparedStatement (from memory) LoggingConnectionDecorator is already aware of some of this - there's a trackParameters property which does similar things - but it's not quite what we need here.. What I hadn't considered (until now) is skipping the LoggingConnectionDecorator unless this property is enabled. That might work - not sure offhand what it would do to the rest of SQL or JDBC logging though.
          Hide
          Albert Lee added a comment -

          I wonder should we use openjpa.Log instead of introduce a new property

          i.e. <property name="openjpa.Log" value="DefaultLevel=TRACE,printParameters=true"/>

          Albert Lee.

          Show
          Albert Lee added a comment - I wonder should we use openjpa.Log instead of introduce a new property i.e. <property name="openjpa.Log" value="DefaultLevel=TRACE,printParameters=true"/> Albert Lee.
          Michael Dick created issue -

            People

            • Assignee:
              Michael Dick
              Reporter:
              Michael Dick
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development