Caramba , q aula... esse cara é bom msm... rsrs
________________________________ De: José Laurindo <jlchia...@yahoo.com.br> Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 1 de Novembro de 2011 14:37 Assunto: [oracle_br] Re: SQL Injection Vamos começar definindo o que é esse coiso : numa explicação bem rasteira (pesquise em http://www.petefinnigan.com/weblog/entries/ e http://asktom.oracle.com para mais detalhes ), SQL Injection ocorre quando vc tem um SQL dinâmico , aonde o usuário pode informar parte do texto do SQL E a aplicação não valida o que o usuário entra, se um usuário mal-intencionado entrar comandos SQL adequadamente formatados nessa string esse comandos são executados... Um exemplo ridiculamente simples, mas pra vc entender : digamos que eu tenha numa tabela chamada EMP uma coluna SAL, que o usuário não deveria poder acessar , tipo : SCOTT@O10GR2:SQL>desc emp Nome Nulo? Tipo ----------------------------------------- -------- ---------------------------- EMPNO NOT NULL NUMBER(4) ENAME VARCHAR2(10) JOB VARCHAR2(9) MGR NUMBER(4) HIREDATE DATE SAL NUMBER(7,2) COMM NUMBER(7,2) DEPTNO NUMBER(2) e o asninho do desenvolvedor queria dar pro usuário final uma consulta que mostra o código (EMPNO) e o nome do empregado (ENAME), mas com a característica de que é o próprio usuário final que informa numa string o nome do empregado a consultar : SCOTT@O10GR2:SQL>select empno, ename from emp where ename = &V_NOME parece ser inocente, né ? E realmente, se o usuário informar o nome só, funciona normalmente : SCOTT@O10GR2:SQL>/ Informe o valor para v_nome: 'MILLER' antigo 1: select empno, ename from emp where ename = &V_NOME novo 1: select empno, ename from emp where ename = 'MILLER' EMPNO ENAME ------------------ ---------- 7934 MILLER => legal... Agora suponha um usuário um pouquinho mais esperto e mal-intencionado, que coloca comandos SQLs dentro da string , ó o que acontece : SCOTT@O10GR2:SQL>/ Informe o valor para v_nome: ename UNION select sal, ename from emp antigo 1: select empno, ename from emp where ename = &V_NOME novo 1: select empno, ename from emp where ename = ename UNION select sal, ename from emp EMPNO ENAME ------------------ ---------- 800 SMITH 950 JAMES 1100 ADAMS 1250 MARTIN 1250 WARD 1300 MILLER 1500 TURNER 1600 ALLEN 2450 CLARK 2850 BLAKE 2975 JONES 3000 FORD 3000 SCOTT 5000 KING 7369 SMITH 7499 ALLEN 7521 WARD 7566 JONES 7654 MARTIN 7698 BLAKE 7782 CLARK 7788 SCOTT 7839 KING 7844 TURNER 7876 ADAMS 7900 JAMES 7902 FORD 7934 MILLER 28 linhas selecionadas. ==> taí, o comando SQL informado foi concatenado ao texto, e como estava sintaticamente correto foi executado - como resultado não-esperado pelo programador, o usuário malicioso obteve o conteúdo da coluna SAL , embora o título da coluna mostre EMPNO ... Veja que foi isso mesmo que aconteceu : SCOTT@O10GR2:SQL>select ename, sal from emp; ENAME SAL ---------- ------------------ SMITH 800 ALLEN 1600 WARD 1250 JONES 2975 MARTIN 1250 BLAKE 2850 CLARK 2450 SCOTT 3000 KING 5000 TURNER 1500 ADAMS 1100 JAMES 950 FORD 3000 MILLER 1300 14 linhas selecionadas. SCOTT@O10GR2:SQL> ===> OK ? Com isso ficou super-simples de te responder as suas perguntas : a. SQL Injection *** NÂO *** é de modo algum exclusividade de aplicações web, já que SQL dinâmico tranquilamente Pode Ser usado em client/server, também... b. como mostrado, NÂO é uma questão do database, é aplicação mal-feita, bug na aplicação, portanto NENHUM "parâmetro" ou ação no database pode impedir c. a camada de rede não tem NADA vezes NADA a ver com o assunto (como mostrado, a aplicação está fazendo a besteira que foi mandada a fazer), não tem como na camada de rede vc detectar usuário aproveitando-se de brecha na aplicação... ==> Já que Redes não tem como atuar, e no banco de dados também não há como identificar se o texto do SQL enviado é o que o programador queria ou não, se teve partes adicionais coladas ou não, fica óbvio que a única camada que pode resolver a questão é a Aplicação, e as boas práticas são : 1. SEMPRE, aonde possível, evitar código SQL dinâmico 2. Aonde for realmente, totalmente, completamente, absolutamente inevitável a porcaria do SQL dinâmico, usar BIND VARIABLES (ie, ao invés de sair colando strings, usar VARIÁVEIS reais no código. 3. No pior dos mundos possíveis, aonde o SQL dinâmico for inevitável, E (por qquer limitação absurda da ferramenta sendo usada) não seja possível usar BIND VARIABLEs, a aplicação TEM que validar os INPUTs do usuário antes de os mandar pro banco E são essas... Sobre BINDING, eis uma re-escrita do meu exemplo ridículo usando BINDs - LÓGICO, usei as sintaxes de criação de variáveis e BINDs do sqlplus, mas TODAS, absolutamente TODAS as principais linguagens de programação, sejam web ou client/server, tem SIM como fazer variáveis e BINDING ... Eis : SCOTT@O10GR2:SQL>variable V_NOME varchar2(40); SCOTT@O10GR2:SQL>exec :V_NOME := 'MILLER'; Procedimento PL/SQL concluído com sucesso. SCOTT@O10GR2:SQL>print V_NOME V_NOME ---------------------------------------------------------- MILLER SCOTT@O10GR2:SQL>select empno, ename from emp where ename = :V_NOME; EMPNO ENAME ------------------ ---------- 7934 MILLER SCOTT@O10GR2:SQL>exec :V_NOME := 'MILLER UNION SELECT SAL, ENAME FROM EMP'; Procedimento PL/SQL concluído com sucesso. SCOTT@O10GR2:SQL>print v_nome V_NOME ---------------------------------------------------------- MILLER UNION SELECT SAL, ENAME FROM EMP SCOTT@O10GR2:SQL>select empno, ename from emp where ename = :V_NOME; não há linhas selecionadas SCOTT@O10GR2:SQL> []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "lfr_66" <luizfernandorocha@...> escreveu > > Senhores, > Sou totalmente leigo a respeito de SQL Injection e gostaria de uma ajuda. > Ataques via SQL Injection somente podem acontecer em bancos de dados que > rodem aplicações web? Há algum parâmetro de banco (ou boas práticas) que > cuide da segurança para esse tipo de situação ou tudo que se pode fazer pra > evitar esse tipo de ataque são tratadas nas camadas de aplicação e rede? > Obrigado! > Luiz Rocha > [As partes desta mensagem que não continham texto foram removidas]
