Veja que eu não inventei esse negócio, é um assunto bem antigo, e já muito discutido : já virou até piada, em http://bobby-tables.com/ o cara mostra um cartoon bem antiguinho, mas ainda válido, tanto como piada técnica quanto nas considerações técnicas feitas ...
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, Jefferson Silva <jeff_programador@...> escreveu > > Caramba , q aula... esse cara é bom msm... rsrs > > > > ________________________________ > De: José Laurindo <jlchiappa@...> > 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] >
