It is not true to say that you need ALTER SESSION privilege granted to actually issue ALTER SESSION commands. Yes, that sounds counter-intuitive but it is true that you can issue SOME alter session commands if you can connect to a database regardless of what privs you have.
In this case setting NLS_DATE_FORMAT can be done by ANYONE regardless of whether they have ALTER SESSION granted.
some observations:
1. in most web apps you wont have access to the database, just the webserver...the database should be firewalled off.
2. it is RARE for PL/SQL developers to use resort to using dynamic SQL (execute immediate/DBMS_SQL) to run SQL, so this flaw, whilst interesting, is HIGHLY unlikely to be a problem...its certainly no where near as dangerous as developers not validating inputs where a application tier (java/php etc) does sql commands (esp if its not using bind variables) against a database [which by definition are dynamic sql calls].
Not to mention that using execute immediate without the USING clause and bind variables is again really rare by any half competent pl/sql developer.
3. the code also relies on another major error in the coding..type conversion. the date is implicitly converted to a string due to concatenation(||) i.e oracle rewrote that internally as to_char(v_date) and, as there was no supplied format it uses NLS_DATE_FORMAT.
i.e. in the example in the paper:
stmt:='select object_name from all_objects where created = ''' ||
v_date || '''';
dbms_output.put_line(stmt);
execute immediate stmt;
would undoutably be written PROPERLY as (in the dynamic case)
execute immediate 'select object_name from all_objects where created =:b1' using v_date;
which is not susceptible to injection (NLS_DATE_FORMAT cant even come into play here).
Slashdot Mirror
In this case setting NLS_DATE_FORMAT can be done by ANYONE regardless of whether they have ALTER SESSION granted.
some observations:
1. in most web apps you wont have access to the database, just the webserver...the database should be firewalled off.
2. it is RARE for PL/SQL developers to use resort to using dynamic SQL (execute immediate/DBMS_SQL) to run SQL, so this flaw, whilst interesting, is HIGHLY unlikely to be a problem...its certainly no where near as dangerous as developers not validating inputs where a application tier (java/php etc) does sql commands (esp if its not using bind variables) against a database [which by definition are dynamic sql calls].
Not to mention that using execute immediate without the USING clause and bind variables is again really rare by any half competent pl/sql developer.
3. the code also relies on another major error in the coding..type conversion. the date is implicitly converted to a string due to concatenation(||) i.e oracle rewrote that internally as to_char(v_date) and, as there was no supplied format it uses NLS_DATE_FORMAT.
i.e. in the example in the paper: stmt:='select object_name from all_objects where created = ''' || v_date || ''''; dbms_output.put_line(stmt); execute immediate stmt;
would undoutably be written PROPERLY as (in the dynamic case) execute immediate 'select object_name from all_objects where created = :b1' using v_date;
which is not susceptible to injection (NLS_DATE_FORMAT cant even come into play here).