Re: Security Question - how do you deal with sensitive information hardcoded in SQL statements

  • From: Pavel <ocp.pauler@xxxxxxxxx>
  • To: michaelw436@xxxxxxxxx, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 4 May 2011 11:28:36 +0400

Good article, thanks for sharing this information.


2011/5/3 Michael Wehrle <michaelw436@xxxxxxxxx>

> Jared, I had this issue (possibly similar) a few years back on a 10.2.0
> database, and Oracle actually provided a patch for it. See my writeup about
> it here
> and if you have anymore questions, I will be glad to TRY to remember them,
> as it was a few years ago.
> On Tue, May 3, 2011 at 11:39 AM, Jared Still <jkstill@xxxxxxxxx> wrote:
>> What I have seen so far in this thread is this:
>> "There isn't a good technical solution to this problem using
>>   without using add on products"
>> Not terribly surprising I guess.
>> Even with add on products I am not sure of the value in
>> this situation.
>> Do data masking and/or encryption hide the values
>> that may be hardcoded into a WHERE clause?
>> I don't know the answer to that, but I don't expect
>> that values appearing in the WHERE clause would
>> be affected.
>> ASO and probably data masking as well are aimed at
>> hiding the values seen in a table, not the values hardcoded
>> into a SQL statement.
>> Jared Still
>> Certifiable Oracle DBA and Part Time Perl Evangelist
>> Oracle Blog:
>> Home Page:
>> On Mon, May 2, 2011 at 10:49 AM, Jared Still <jkstill@xxxxxxxxx> wrote:
>>> First, the assumption is that you are working with a 3rd party
>>> application, and there
>>> is nothing you can do to modify the SQL statements used by the app.
>>> Nor are you able at this time to apply an extra cost option, such as ASO.
>>> How do you deal with sensitive information that may be hardcoded into SQL
>>> statements?
>>> This kind of SQL presents all kinds of problems.
>>> * statspack/AWR reports showing Top SQL
>>> * queries for cached SQL
>>> * execution plans.
>>> * trace files
>>> * probably many more I am not thinking of at the moment.
>>> The problem arises when any sensitive information (SSN, CC#, etc) appears
>>> as a
>>> hardcoded value in a SQL statement, and the SQL in question is a subject
>>> of
>>> current performance discussions, or troubleshooting of database and SQL
>>> issues.
>>> The SQL statements get sent to Oracle support as part of AWR or Statspack
>>> reports,
>>> execution plan analysis, trace files etc.
>>> They can also inadvertently appear in emails, meetings and even
>>> presentations.
>>> How do you deal with this?
>>> This issue has the potential for a fairly serious security breach.
>>> TIA,
>>> Jared Still
>>> Certifiable Oracle DBA and Part Time Perl Evangelist
>>> Oracle Blog:
>>> Home Page:

Other related posts: