Please read it more carefully. "WHEN OTHERS THEN NULL" is *never* acceptable; he's saying to use WHEN OTHERS to close any cursors opened by DBMS_SQL before leaving the program unit.
In fact, WHEN OTHERS THEN NULL will still leave cursors open and exploitable, while neatly concealing the nature of any encountered exception, in addition to concealing the fact that any error occurred at all, to boot.
It is a piece of code that should be flagged as a compilation error by the PL/SQL compiler.
For coding stupidity, "WHEN OTHERS THEN NULL" is closely rivaled by "WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('A serious error has occurred')", which brought a large consumer retail e-commerce website to its knees during Christmas season a few years ago. Talk about a million-dollar piece of code!
rjamya wrote:
1. stop comparing passwords 2. use exception handling " when others then null;" will defeat this exploit. So, this is one place where "when others then null;" is acceptable. There ... no more exploit. Let's get back to bashing 'latch free waits' or 'cache buffers chains'. Raj On 11/27/06, Mladen Gogala <mgogala@xxxxxxxxxxx> wrote:Jared Still wrote: > Not easily exploited, but still possible. > > http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf> <http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf>
-- //www.freelists.org/webpage/oracle-l
