This discussion is archived
5 Replies Latest reply: Nov 19, 2012 1:20 PM by Patrick Wolf RSS

Security Issue with APEX LDAP Authoization

j.sieben Newbie
Currently Being Moderated
Hi,
we're using LDAP-Authorization in our applications. Now the DBA pointed out that all the passwords are logged into the log files if you monitor the apex_public_user session with dbms_monitor.session_trace_enable (You need to set binds to true to get the passed parameters).

Although one might argue that a user how is allowed to run dbms_monitor should be a trusted DBA, the requirement is to hide the passwords from the log files. To my understanding, this is impossible to do, or am I mislead here?

If this is true, is the only option to securely use LDAP is to have the browser authenticate the user directly, bypassing any APEX logic?

Best regards,

Jürgen
  • 1. Re: Security Issue with APEX LDAP Authoization
    Patrick Wolf Employee ACE
    Currently Being Moderated
    Hi Jürgen,

    how does your custom LDAP Authorization look like? Are you calling the APEX_LDAP package? If you want to avoid bind variables in this context to prevent logging them in the trace file, you can use the V function instead. For example:
    if apex_ldap.is_member (
           p_username => :P101_USERNAME,
           p_pass     => V('P101_PASSWORD'),
           ... ) then
    Regards
    Patrick
    -----------
    My Blog: http://www.inside-oracle-apex.com
    APEX Plug-Ins: http://apex.oracle.com/plugins
    Twitter: http://www.twitter.com/patrickwolf

    Edited by: Patrick Wolf on Nov 19, 2012 2:26 PM
  • 2. Re: Security Issue with APEX LDAP Authoization
    j.sieben Newbie
    Currently Being Moderated
    Hi Patrick,

    yes, we're using apex_ldap. As usual, your answer is straight to the point and helpful. More often than not, the obvious things are the ones one don't see ...

    Best regards,

    J. Sieben
  • 3. Re: Security Issue with APEX LDAP Authoization
    j.sieben Newbie
    Currently Being Moderated
    Hi Patrick,

    we tested the approach you mentioned and came across another issue where you might be able to advice us on how to avoid this:
    It seems as if wwv_flow.accept shows the parameters in the trace as well:

    <pre>
    PARSING IN CURSOR #46988237165640 len=199 dep=0 uid=855 oct=47 lid=855 tim=1353335524250374 hv=128338310 ad='9cfc0568' sqlid='283apm83uckc6'
    begin
    wwv_flow.accept(p_flow_step_id=>:1 ,
    p_t02=>:2 ,
    p_t01=>:3 ,
    p_request=>:4 ,
    p_page_submission_id=>:5 ,
    p_md5_checksum=>:6 ,
    p_flow_id=>:7 ,
    p_arg_names=>:8 ,
    p_instance=>:9 );
    commit;
    end;
    END OF STMT
    PARSE #46988237165640:c=0,e=63,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=1353335524250373
    BINDS #46988237165640:
    Bind#0
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d2f7000 bln=32767 avl=03 flg=05
    value="101"
    Bind#1
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d7e7000 bln=32767 avl=06 flg=05
    value="abba.1" ================================= Password in clear text
    Bind#2
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d486fa8 bln=32767 avl=07 flg=05
    value="int5256" ================================= Username in clear text
    Bind#3
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d6b7020 bln=32767 avl=05 flg=05
    value="LOGIN"
    Bind#4
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d437000 bln=32767 avl=16 flg=05
    value="3620882293309888"
    Bind#5
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d3d7000 bln=32767 avl=00 flg=05
    Bind#6
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d4e7080 bln=32767 avl=06 flg=05
    value="134160"
    Bind#7
    oacdty=01 mxl=32767(32767) mxlc=00 mal=02 scl=00 pre=00
    oacflg=43 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d7cf020 bln=32767 avl=00 flg=05
    Bind#8
    oacdty=01 mxl=32767(32766) mxlc=00 mal=00 scl=00 pre=00
    oacflg=03 fl2=1000010 frm=01 csi=873 siz=32767 off=0
    kxsbbbfp=2abc4d2c7000 bln=32767 avl=16 flg=05
    value="3624269070972227"
    *** ACTION NAME:(begin) 2012-11-19 15:32:04.252
    </pre>

    On the page we didn't mention P101_USERNAME or :P101_PASSWORD as bind variables, but only using the v('...')-Syntax.
    Plus, we advised APEX to store these values encrypted in session state. So what else are we doing wrong here?

    Best regards,

    Jürgen
  • 4. Re: Security Issue with APEX LDAP Authoization
    j.sieben Newbie
    Currently Being Moderated
    The problem was partially solved, but wwv_flow.accept seems to be passing around the parameters in clear text as well, therefore the problem still remains.
  • 5. Re: Security Issue with APEX LDAP Authoization
    Patrick Wolf Employee ACE
    Currently Being Moderated
    Hi Jürgen,

    I think the reason is that in a previously used db session the tracing is still enabled. That's why the call from the APEX Listener/mod_plsql to the database is also traced the next time APEX Listener/mod_plsql takes the db session from the connection pool.

    I think the only way to workaround this is to always disable tracing in the "Pre-Procedure" of the APEX Listener/mod_plsql. See "Pre-Post Processing" at http://www.oracle.com/technetwork/developer-tools/apex-listener/overview/index.html

    Regards
    Patrick
    -----------
    My Blog: http://www.inside-oracle-apex.com
    APEX Plug-Ins: http://apex.oracle.com/plugins
    Twitter: http://www.twitter.com/patrickwolf

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points