Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Access Limitation

Re: Access Limitation

From: DA Morgan <damorgan_at_exesolutions.com>
Date: Sun, 23 Feb 2003 10:27:28 -0800
Message-ID: <3E591290.4B4D0F7@exesolutions.com>


Pete Finnigan wrote:

> Hi Daniel
>
> a comment in-line:
>
> In article <3E56AAD1.E6B908E4_at_exesolutions.com>, DA Morgan
> <damorgan_at_exesolutions.com> writes
> >Life Learner wrote:
> >
> >> Hi there,
> >>
> >> I'd like to know how to prevent end users from accessing system directly via
> >> sqlplus, toad etc, while let them do their work only in application level
> >> like forms, proc etc.
> >>
> >> thx.
> >
> >There are a number of methods. Among them:
> >
> >An after logon trigger that checks the connecting software ...
> >
> >SELECT program
> >FROM v_$session;
> >
>
> This cannot be easily tricked by just renaming the sqlplus binary to the
> same name as the binary for the application as the following shows:
>
> oracle:venus> sqlplus sys/change_on_install
>
> SQL*Plus: Release 8.1.7.0.0 - Production on Sat Feb 22 20:47:13 2003
>
> (c) Copyright 2000 Oracle Corporation. All rights reserved.
>
> Connected to:
> Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
> With the Partitioning option
> JServer Release 8.1.7.0.0 - Production
>
> SQL> create user pete identified by pete;
>
> User created.
>
> SQL> grant create session to pete;
>
> Grant succeeded.
>
> SQL> grant select on v_$session to pete;
>
> Grant succeeded.
>
> SQL> connect pete/pete
> Connected.
> SQL> select program from v$session
> 2 where username='PETE';
>
> PROGRAM
> ------------------------------------------------
> sqlplus_at_venus (TNS V1-V3)
>
> SQL> !cp $ORACLE_HOME/bin/sqlplus ./someapp
>
> SQL> exit
> Disconnected from Oracle8i Enterprise Edition Release 8.1.7.0.0 -
> Production
> With the Partitioning option
> JServer Release 8.1.7.0.0 - Production
> oracle:venus> ./someapp pete/pete
>
> SQL*Plus: Release 8.1.7.0.0 - Production on Sat Feb 22 20:47:13 2003
>
> (c) Copyright 2000 Oracle Corporation. All rights reserved.
>
> Connected to:
> Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
> With the Partitioning option
> JServer Release 8.1.7.0.0 - Production
>
> SQL> select program from v$session
> 2 where username='PETE';
>
> PROGRAM
> ------------------------------------------------
> sqlplus_at_venus (TNS V1-V3)
>
> SQL>
>
> I don't have a copy of toad here at present to check if renaming it has
> the same result.
>
> Of course someone a bit more skilled could trick the database as without
> looking into TNS in more detail i suspect that the name of the program
> is sent as part of a TNS packet to the RDBMS, this could be changed, so
> relying on v$session is not 100% foolproof but it would certainly stop
> casual and normal business users.
>
> I just thought i would share that little experiment to see how reliable
> v$session is as a checking mechanism for the source of program
>
> Kind regards
>
> Pete
> --
> Pete Finnigan
>
> Email : pete_at_peterfinnigan.demon.co.uk
> Email : pete_at_petefinnigan.com
>
> Web site: http://www.petefinnigan.com
>
> Independent consultant specialising in Oracle security. Pete Finnigan is the
> author of the recently published book about Oracle security from the SANS
> Institute "Oracle security Step-by-step (A survival guide for Oracle security)"
> - see http://store.sans.org for details.
>
> Some recently published articles include:
>
> http://online.securityfocus.com/infocus/1644 - "SQL injection and Oracle - part
> one"
>
> http://online.securityfocus.com/infocus/1646 - "SQL injection and Oracle - part
> two"

There are ways to trick v_$session, no question about it. But the chances of an end-user realizing that are slim to none. Especially if the first time they try to connect the indication they get that there is a problem comes from a manager that informs them the next time they try they can pick up their final paycheck on the way out the door. That greatly changes the risk-reward ratio.

The most secure way is a required role that is invoked in the application itself.

Daniel Morgan Received on Sun Feb 23 2003 - 12:27:28 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US