[ 
https://issues.apache.org/jira/browse/OPENJPA-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Péter Gergő Barna updated OPENJPA-2717:
---------------------------------------
    Description: 
ValidationQuery should be excluded from openjpa.ConnectionProperties and should 
be a separate property.

It is plausible that an application would _not_ allow the the ValidationQuery 
to be configured, rather it would be hardcoded in the application.
On the other hand, the application may allow other db driver specific 
properties to be configured, and these values would then be concatenated into a 
ConnectionProperties string and passed by the application to the 
openjpa.ConnectionProperties, and then subsequently passed by openjpa to the 
driver.

If the application does not sanitize all the configuration values that gets 
their way into the  openjpa.ConnectionProperties string, then it is possible a 
for an attacker to a use driver specific setting to execute arbitrary SQL. 

For example, let's suppose an application has this config option for the db 
connection: trustServerCertificate=true/false. Lets suppose this config 
property is concatenated into the openjpa.ConnectionProperties string by the 
application. The following value could result in executing a delete statement 
each time a connection validation query runs:

trustServerCertificate=true,TestOnBorrow=true,ValidationQuery=delete from 
transactions where id = 'abcd'

We have recently found and fixed such security hole in our application and I 
think it would be nice to have this fix in openjpa so it would prevent naive 
application developers to add such security holes into his/her application.

I am not familiar with openjpa codebase, but I included a rudimentary fix, so 
that it would be clear what I'm thinking about.

  was:
ValidationQuery should be excluded from openjpa.ConnectionProperties and should 
be a separate property.

It is plausible that an application would _not_ allow the the ValidationQuery 
to be configured, rather it would be hardcoded in the application.
On the other hand, the application may allow other db driver specific 
properties to be configured, and these values would then be concatenated into a 
ConnectionProperties string and passed by the application to the 
openjpa.ConnectionProperties, and then subsequently passed by openjpa to the 
driver.

If the application does not sanitize all the configuration values that gets 
their way into the  openjpa.ConnectionProperties string, then it is possible a 
for an attacker to a use driver specific setting to execute arbitrary SQL. 

For example, let's suppose an application has this config option for the db 
connection: trustServerCertificate=true/false. Lets suppose this config 
property is concatenated into the openjpa.ConnectionProperties string by the 
application. The following value could result in executing a delete statement 
each time a connection validation query runs:

trustServerCertificate=true,TestOnBorrow=true,ValidationQuery=delete from 
transactions where id = 'abcd'

We have recently found and fixed such security whole in our application and I 
think it would be nice to have this fix in openjpa so it would prevent naive 
application developers to add such security wholes into his/her application.

I am not familiar with openjpa codebase, but I included a rudimentary fix, so 
that it would be clear what I'm thinking about.


> ValidationQuery should be excluded from ConnectionProperties 
> -------------------------------------------------------------
>
>                 Key: OPENJPA-2717
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2717
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: docs, kernel
>            Reporter: Péter Gergő Barna
>            Priority: Minor
>
> ValidationQuery should be excluded from openjpa.ConnectionProperties and 
> should be a separate property.
> It is plausible that an application would _not_ allow the the ValidationQuery 
> to be configured, rather it would be hardcoded in the application.
> On the other hand, the application may allow other db driver specific 
> properties to be configured, and these values would then be concatenated into 
> a ConnectionProperties string and passed by the application to the 
> openjpa.ConnectionProperties, and then subsequently passed by openjpa to the 
> driver.
> If the application does not sanitize all the configuration values that gets 
> their way into the  openjpa.ConnectionProperties string, then it is possible 
> a for an attacker to a use driver specific setting to execute arbitrary SQL. 
> For example, let's suppose an application has this config option for the db 
> connection: trustServerCertificate=true/false. Lets suppose this config 
> property is concatenated into the openjpa.ConnectionProperties string by the 
> application. The following value could result in executing a delete statement 
> each time a connection validation query runs:
> trustServerCertificate=true,TestOnBorrow=true,ValidationQuery=delete from 
> transactions where id = 'abcd'
> We have recently found and fixed such security hole in our application and I 
> think it would be nice to have this fix in openjpa so it would prevent naive 
> application developers to add such security holes into his/her application.
> I am not familiar with openjpa codebase, but I included a rudimentary fix, so 
> that it would be clear what I'm thinking about.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to