View the Exhibit and examine the procedure to create a trigger name based on the table name supplied to the procedure.
Which three statements are appropriate for protecting the code in the procedure from SQL injection?
(Choose three.)
A.
Explicitly validate the identifier length limit.
B.
Add AUTHID DEFINER to the definition of the procedure.
C.
Use PRAGMA RESTRICT_REFERENCES in the procedure.
D.
Filter out control characters in user-supplied identifier names.
E.
Use the object ID of the table from the data dictionary to build the trigger name.
A,D,E
answer a) d) e), all of them are ways to prevent malious sql injection. I.E
an attacker peform below attack steps:
(1) create an malicious function with AUTHID CURRENT_USER
create or replace function malicious_function() AUTHID CURRENT_USER
AS
BEGIN
EXECUTE IMMEDIATE ‘GRANT DBA TO SCOTT”;
END;
(2) insert the malicious_function into p_table_name
EXECUTE add_trigger(‘scott’, ‘tablexxx’ || malicious_funtion());
Let’s see what happened? SCOTT has the SYS grant now,
a) check the identifier length d) remove cotrol character like “(” “)” e) e)retrive object_id from user_objects against table_name would incur the failure of trigger compiling if the user inject some malicious code like “|| malicious_function” into the actual parameter p_table_name
Some other malicious sql injections (1) concatenate for-ever correct condition clause like “|| 1=1” in the query where clause to retrive out-of-scope data, one solution is apply FGAC(fine grained access control) policy to project the in-scoper data to one user (2) concatenate “union select confidential_data from the_table” to retrieve the confidental data, FGAC is also one good solution. Whereas, FGAC will slow down the performance, especially the policy is the dynamic policy,
AD seems correct, B is incorrect. E not sure..
???