There are various methods of how the plsql coders write their code to avoid sql injection attacks, and here we will see some methods and tips of how we can really protect the code..
Native dynamic SQL code what i feel is actually little easy to read and write than the code that uses the DBMS_SQL package, and runs much faster specially when it can be optimized by the compiler. But thats not the point of our discussion, the point is that SQL injection is a pretty famous attack and we can avoid this with strict adherence to some basic coding practices....
Assuming that you know the concepts of dynamic sql and then bind arguments, and what oracle says you must use dynamic SQL and not only this using bind arguments protects us against SQL injection attacks. Using bind arguments also enables cursor sharing, and thus improves application performance.
If an interface is not available to an attacker, it is clearly not available to be abused. Thus the first, and arguably most important, line of defense is to reduce the exposed interfaces to only those absolutely required.
Be alert of the following rights :=
Use Definer's Right: When you want to provide users unrestricted access to a table or tables via a subprogram, create the subprogram with definer's right.
Use Invoker's Right: When the purpose of the subprogram is to perform a parameterized, but powerful, operation by using the privileges of the user that invokes it, create the subprogram with invoker's right. Using invoker's rights helps to limit the privileges, and thereby, minimize the security exposure. However, it is not sufficient as the sole measure for eliminating SQL injection vulnerabilities.
Invoker's rights helps to minimize the security exposure
For the following procedure if you give execute privilege to HR user lets say, HR user would only be able to change the password of any user including the user SYS only if he has the ALTER USER system privilege.
create or replace procedure change_password (p_username varchar2 default null,p_new_password varchar2 default null)
is
v_sql_stmt varchar2(500);
begin
v_sql_stmt := 'ALTER USER '||p_username||' IDENTIFIED BY '||p_new_password;
execute immediate v_sql_stmt;
end change_password;
/
How bind arguments should be used ? Basically complete protected code from sql injection attack can be achieved only through elimination of input string concatenation in dynamic SQL, so 1 should avoid input string concatenation and use bind arguments be it automatically through static SQL or explicitly through dynamic SQL statements. A basic code of how bind arguments are used is below :=
create or replace procedure sum_it_up
( a number, b number, c number)
is
begin
dbms_output.put_line(a+b+c);
end;
/
DECLARE
x NUMBER := 2;
y NUMBER := 5;
plsql_block VARCHAR2(100);
BEGIN
plsql_block := 'BEGIN sum_it_up(:g, :g, :h); END;';
EXECUTE IMMEDIATE plsql_block USING x, y;
END;
/
How to reduce the actual attack, below we will see how the code is not immune in the first go and then how the code is immune in the following 2 cases ( PROCEDURE GET_CODE), below is the table of citizens where humas have their social security number which is the most private number and shall be hidden or protected :=
SQL> create table citizens (fname varchar2(20),lname varchar2(20), s_security_num number);
Table created.
SQL> insert into citizens values ('karan','dodwal',10034007);
1 row created.
SQL> insert into citizens values ('ram','singh',10059991);
1 row created.
SQL> commit;
Commit complete.
--FIRST ORDER ATTACK
Now look how it is vulnuerable in the following code
create or replace procedure get_code (p_fname varchar2 default null)
is
type c is ref cursor;
cv c;
vcode citizens.s_security_num%type;
v_stmt varchar2(300);
begin
v_stmt := 'select s_security_num from citizens where fname='''||p_fname||'''';
dbms_output.put_line('sql query : '||v_stmt);
open cv for v_stmt;
loop
fetch cv into vcode;
exit when cv%notfound;
dbms_output.put_line('code is '||vcode);
end loop;
close cv;
exception when others then
dbms_output.put_line(sqlerrm);
dbms_output.put_line('sql query '||v_stmt);
end;
/
Social security number of only ram is printed in the following output
SQL> exec get_code('ram');
sql query : select s_security_num from citizens where fname='ram'
code is 10059991
PL/SQL procedure successfully completed.
But look below how the Social security number of KARAN is also printed without even knowing RAM or KARAN, just by dummy ''X''
SQL> exec get_code('x'' union select s_security_num from citizens where ''x''=''x');
sql query : select s_security_num from t1 where fname='x' union select
s_security_num from t1 where 'x'='x'
code is 10034007
code is 10059991
ISNT IT REALLY BAD...
--PROTECTION
--Now see how it isnt vulnuerable in the following code because here we are avoiding the use of dynamic SQL with concatenated input values
create or replace procedure get_code (p_fname varchar2)
is
begin
for i in (select s_security_num from citizens where fname=p_fname)
loop
dbms_output.put_line(i.s_security_num);
end loop;
end;
/
Social security number of only ram is printed in the following output
SQL> exec get_code('ram');
10059991
PL/SQL procedure successfully completed.
But look below how neither of Social security numbers are printed and attacker is defeated clearly
SQL> exec get_code('x'' union select s_security_num from citizens where ''x''=''x');
PL/SQL procedure successfully completed.
In my subsequent posts i will share with you other protection mechanisms, but for the time being i wish you all happy thanks giving and also do note the following practices to observe when you secure the Oracle database:
1) Encrypt sensitive data so that it cannot be viewed.
2) Evaluate all PUBLIC privileges and revoke them where possible.
3) Do not widely grant EXECUTE ANY PROCEDURE.
4) Avoid granting privileges WITH ADMIN option.
5) Ensure that application users are granted minimum privileges by default. Make privileges configurable if necessary.
6) Do not allow wide access to any standard Oracle packages that can operate on the operating system. These packages include:
UTL_HTTP, UTL_SMTP, UTL_TCP, DBMS_PIPE, UTL_MAIL, and UTL_FTP
7) Certain Oracle packages such as UTL_FILE and DBMS_LOB are governed by the privilege model of the Oracle DIRECTORY object. Protect Oracle DIRECTORY objects.
8) Lock the database default accounts and expire the default passwords.
9) Remove example scripts and programs from the Oracle directory.
10) Run the database listener as a nonprivileged user.
11) Ensure that password management is active.
12) Enforce password management. Apply basic password management rules, such as password length, history, and complexity, to all user passwords. Mandate that all the users change their passwords regularly.
13) Lock and expire the default user accounts and change the default user password.
Native dynamic SQL code what i feel is actually little easy to read and write than the code that uses the DBMS_SQL package, and runs much faster specially when it can be optimized by the compiler. But thats not the point of our discussion, the point is that SQL injection is a pretty famous attack and we can avoid this with strict adherence to some basic coding practices....
Assuming that you know the concepts of dynamic sql and then bind arguments, and what oracle says you must use dynamic SQL and not only this using bind arguments protects us against SQL injection attacks. Using bind arguments also enables cursor sharing, and thus improves application performance.
If an interface is not available to an attacker, it is clearly not available to be abused. Thus the first, and arguably most important, line of defense is to reduce the exposed interfaces to only those absolutely required.
Be alert of the following rights :=
Use Definer's Right: When you want to provide users unrestricted access to a table or tables via a subprogram, create the subprogram with definer's right.
Use Invoker's Right: When the purpose of the subprogram is to perform a parameterized, but powerful, operation by using the privileges of the user that invokes it, create the subprogram with invoker's right. Using invoker's rights helps to limit the privileges, and thereby, minimize the security exposure. However, it is not sufficient as the sole measure for eliminating SQL injection vulnerabilities.
Invoker's rights helps to minimize the security exposure
For the following procedure if you give execute privilege to HR user lets say, HR user would only be able to change the password of any user including the user SYS only if he has the ALTER USER system privilege.
create or replace procedure change_password (p_username varchar2 default null,p_new_password varchar2 default null)
is
v_sql_stmt varchar2(500);
begin
v_sql_stmt := 'ALTER USER '||p_username||' IDENTIFIED BY '||p_new_password;
execute immediate v_sql_stmt;
end change_password;
/
How bind arguments should be used ? Basically complete protected code from sql injection attack can be achieved only through elimination of input string concatenation in dynamic SQL, so 1 should avoid input string concatenation and use bind arguments be it automatically through static SQL or explicitly through dynamic SQL statements. A basic code of how bind arguments are used is below :=
create or replace procedure sum_it_up
( a number, b number, c number)
is
begin
dbms_output.put_line(a+b+c);
end;
/
DECLARE
x NUMBER := 2;
y NUMBER := 5;
plsql_block VARCHAR2(100);
BEGIN
plsql_block := 'BEGIN sum_it_up(:g, :g, :h); END;';
EXECUTE IMMEDIATE plsql_block USING x, y;
END;
/
How to reduce the actual attack, below we will see how the code is not immune in the first go and then how the code is immune in the following 2 cases ( PROCEDURE GET_CODE), below is the table of citizens where humas have their social security number which is the most private number and shall be hidden or protected :=
SQL> create table citizens (fname varchar2(20),lname varchar2(20), s_security_num number);
Table created.
SQL> insert into citizens values ('karan','dodwal',10034007);
1 row created.
SQL> insert into citizens values ('ram','singh',10059991);
1 row created.
SQL> commit;
Commit complete.
--FIRST ORDER ATTACK
Now look how it is vulnuerable in the following code
create or replace procedure get_code (p_fname varchar2 default null)
is
type c is ref cursor;
cv c;
vcode citizens.s_security_num%type;
v_stmt varchar2(300);
begin
v_stmt := 'select s_security_num from citizens where fname='''||p_fname||'''';
dbms_output.put_line('sql query : '||v_stmt);
open cv for v_stmt;
loop
fetch cv into vcode;
exit when cv%notfound;
dbms_output.put_line('code is '||vcode);
end loop;
close cv;
exception when others then
dbms_output.put_line(sqlerrm);
dbms_output.put_line('sql query '||v_stmt);
end;
/
Social security number of only ram is printed in the following output
SQL> exec get_code('ram');
sql query : select s_security_num from citizens where fname='ram'
code is 10059991
PL/SQL procedure successfully completed.
But look below how the Social security number of KARAN is also printed without even knowing RAM or KARAN, just by dummy ''X''
SQL> exec get_code('x'' union select s_security_num from citizens where ''x''=''x');
sql query : select s_security_num from t1 where fname='x' union select
s_security_num from t1 where 'x'='x'
code is 10034007
code is 10059991
ISNT IT REALLY BAD...
--PROTECTION
--Now see how it isnt vulnuerable in the following code because here we are avoiding the use of dynamic SQL with concatenated input values
create or replace procedure get_code (p_fname varchar2)
is
begin
for i in (select s_security_num from citizens where fname=p_fname)
loop
dbms_output.put_line(i.s_security_num);
end loop;
end;
/
Social security number of only ram is printed in the following output
SQL> exec get_code('ram');
10059991
PL/SQL procedure successfully completed.
But look below how neither of Social security numbers are printed and attacker is defeated clearly
SQL> exec get_code('x'' union select s_security_num from citizens where ''x''=''x');
PL/SQL procedure successfully completed.
In my subsequent posts i will share with you other protection mechanisms, but for the time being i wish you all happy thanks giving and also do note the following practices to observe when you secure the Oracle database:
1) Encrypt sensitive data so that it cannot be viewed.
2) Evaluate all PUBLIC privileges and revoke them where possible.
3) Do not widely grant EXECUTE ANY PROCEDURE.
4) Avoid granting privileges WITH ADMIN option.
5) Ensure that application users are granted minimum privileges by default. Make privileges configurable if necessary.
6) Do not allow wide access to any standard Oracle packages that can operate on the operating system. These packages include:
UTL_HTTP, UTL_SMTP, UTL_TCP, DBMS_PIPE, UTL_MAIL, and UTL_FTP
7) Certain Oracle packages such as UTL_FILE and DBMS_LOB are governed by the privilege model of the Oracle DIRECTORY object. Protect Oracle DIRECTORY objects.
8) Lock the database default accounts and expire the default passwords.
9) Remove example scripts and programs from the Oracle directory.
10) Run the database listener as a nonprivileged user.
11) Ensure that password management is active.
12) Enforce password management. Apply basic password management rules, such as password length, history, and complexity, to all user passwords. Mandate that all the users change their passwords regularly.
13) Lock and expire the default user accounts and change the default user password.
