Veo código de desarrolladores que usan conversión de fecha implícita. Me gustaría una respuesta definitiva a por qué no deberían hacer esto.
SELECT * from dba_objects WHERE Created >= '06-MAR-2012';
Veo código de desarrolladores que usan conversión de fecha implícita. Me gustaría una respuesta definitiva a por qué no deberían hacer esto.
SELECT * from dba_objects WHERE Created >= '06-MAR-2012';
Respuestas:
Porque '2012/12/1'
en los Estados Unidos es 11 meses después de la misma fecha de cadena en Europa.
Permitir conversiones implícitas significa que está a merced de la configuración de ubicación.
Si puede nombrar un negocio donde 11 meses es un margen de error aceptable, me impresionará.
Hay problemas que ocurrirán si una sesión con un formato de fecha diferente ejecuta el código.
Fracaso de la declaración
DROP TABLE t1;
CREATE TABLE t1 AS (SELECT sysdate mydate FROM dual WHERE 1=2);
ALTER SESSION SET NLS_DATE_FORMAT = 'MON-DD-RR';
INSERT INTO t1 VALUES ('01-02-12');
*
ERROR at line 1:
ORA-01843: not a valid month
Datos incorrectos
DROP TABLE t1;
CREATE TABLE t1 AS (SELECT sysdate mydate FROM dual WHERE 1=2);
--User 1
ALTER SESSION SET NLS_DATE_FORMAT = 'MM-DD-RR';
INSERT INTO t1 VALUES ('01-02-11');
--User 2
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MM-RR';
INSERT INTO t1 VALUES ('01-02-11');
--User 3
ALTER SESSION SET NLS_DATE_FORMAT = 'RR-MM-DD';
INSERT INTO t1 VALUES ('01-02-11');
SELECT to_char(mydate,'MM/DD/YYYY') FROM t1;
En esta situación, porque cada una de las declaraciones de alteración / inserción podría ser realizada por diferentes usuarios. Todos estarían ejecutando las mismas declaraciones, pero las fechas resultantes serían completamente diferentes. Las instrucciones de inserción pueden estar enterradas en un paquete que solo se llama indirectamente. Debido a que no se devolvió ningún error, el problema podría no encontrarse hasta mucho más tarde.
Inyección SQL
CLEAR SCREEN;
DROP TABLE Secrets;
CREATE TABLE Secrets (RevealDate Date, Secret Varchar2(200));
INSERT INTO Secrets VALUES (trunc(sysdate), '*** Common Knowledge. ***');
INSERT INTO Secrets VALUES (trunc(sysdate+1), '*** Don''t Let Anyone know this. ***');
CREATE OR REPLACE PROCEDURE ShowRevealedSecrets IS
vStatement varchar2(200);
vOutput Varchar2(1000);
vDate date:=sysdate;
begin
vStatement:='SELECT secret FROM Secrets WHERE RevealDate = ''' || vDate || '''';
execute immediate vStatement INTO vOutput;
DBMS_Output.Put_Line(vOutput);
END;
/
--Normal Use.
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY';
EXEC ShowRevealedSecrets();
--Explointing SQL Injection
ALTER SESSION SET NLS_DATE_FORMAT = '"'' OR RevealDate > sysdate--"';
EXEC ShowRevealedSecrets();
En esta situación, un individuo malintencionado podría alterar el formato de la fecha de las sesiones de tal manera que les dé acceso a datos a los que normalmente no tendrían acceso.