Metodologia para aplicação de Testes de Intrusão em Aplicações Web - OWASP

(1)

Projeto do LabSEC

Metodologia para aplicaç ão de Testes de Intrus ão

em Aplicac¸ ˜

oes Web - OWASP

Armindo Guerra

F ´abio Resner

Lucas Vin´ıcius da Rosa

Classificac¸ ˜ao: externo Data: 7 de maio de 2012

(2)

Hist ´

orico

Data Vers ão Descriç ão Autor Revisor Aprovado por

1.0 Versao inicial

Jean

Martina

Jean

Martina

(3)

Sum ´ario

Sum ´ario 3

1 Introduc¸ ˜ao 6

1.1 Objetivos . . . 6

2 Testing for credentials transport (OWASP-AT-001) 7 2.1 Objetivos . . . 7

2.2 Pr ´e-requisitos . . . 7

2.3 Metodologia . . . 7

2.3.1 Configurac¸ ˜ao e uso do WebScarab para realizar o teste . . . 7

2.4 Execuc¸ ˜ao . . . 9

3 Testing for user enumeration (OWASP-AT-002) 10 3.1 Objetivos . . . 10

3.4 Execuc¸ ˜ao . . . 10

4 Testing for Brute Force (OWASP-AT-004) 12 4.1 Objetivos . . . 12

4.4 Execuc¸ ˜ao . . . 12

5 Testing for Bypassing Authentication Schema (OWASP-AT-005) 14 5.1 Objetivos . . . 14

5.4 Execuc¸ ˜ao . . . 14

6 Testing for Vulnerable Remember Password and Pwd Reset (OWASP-AT-006) 16 6.1 Objetivos . . . 16

(4)

Sum ´ario

7 Testing for Logout and Browser Cache Management (OWASP-AT-007) 19

7.1 Objetivos . . . 19

7.4 Execuc¸ ˜ao . . . 19

8 Testing for Reflected Cross Site Scripting (OWASP-DV-001) 21 8.1 Objetivos . . . 21

8.4 Execuc¸ ˜ao . . . 22

9 Testing for Stored Cross Site Scripting (OWASP-DV-002) 26 9.1 Pr ´e-requisitos . . . 26

9.3 Execuc¸ ˜ao . . . 27

10 Testing for DOM-based Cross Site Scripting (OWASP-DV-003) 29 10.1 Pr ´e-requisitos . . . 29

10.3 Execuc¸ ˜ao . . . 29

11 Testing for Cross Site Flashing (OWASP-DV-004) 32 11.1 Objetivos . . . 32

11.4 Execuc¸ ˜ao . . . 32

12 Testing for Session Management Schema (OWASP-SM-001) 34 12.1 Objetivos . . . 34

12.4 Execuc¸ ˜ao . . . 35

13 Testing for Cookies Attributes (OWASP-SM-002) 38 13.1 Objetivos . . . 38

13.4 Execuc¸ ˜ao . . . 39

14 Testing for Exposed Session Variables (OWASP-SM-004) 42 14.1 Objetivos . . . 42

14.4 Execuc¸ ˜ao . . . 43

(5)

Sum ´ario

14.4.2 Proxies e func¸ ˜oes de caching . . . 43

14.4.3 M ´etodo HTTP sendo utilizado . . . 43

14.4.4 Procedimentos de transporte . . . 44

15 Testing for Path Traversal (OWASP-AZ-001) 48 15.1 Objetivos . . . 48

15.4 Execuc¸ ˜ao . . . 48

16 Testing for Bypassing Authorization Schema (OWASP-AZ-002) 50 16.1 Objetivos . . . 50

16.4 Execuc¸ ˜ao . . . 50

17 Testing for Privilege escalation (OWASP-AZ-003) 52 17.1 Objetivos . . . 52

17.2 Objetivos . . . 52

17.5 Execuc¸ ˜ao . . . 52

18 Testing for SQL Injection (OWASP-DV-005) 54 18.1 Objetivos . . . 54

18.4 Execuc¸ ˜ao . . . 55

19 Testing for Buffer Overflow (OWASP-DV-014) 58 19.1 Objetivos . . . 58

(6)

Cap´ıtulo 1. Introduc¸ ˜ao

1 Introduc¸ ˜ao

O projeto OWASP (The Open Web Application Security Project), sendo uma organizaç ão sem fins lucrativos, atende a responsabilidade de tornar as aplicaç ões Web mais seguras. Para isso, oferece, dentre in úmeros projetos, o OWASP Testing Guide, utilizado como refer ência para composiç ão deste documento. O roteiro de testes, assim sendo, compreende um subconjunto de 18 testes do OWASP Testing Guide, classificados nas categorias AT (Authentication Testing), SM (Session Management), AZ (Authorization Testing) e DV (Data Validation). Cada teste possui as-sociado a ele um cap´ıtulo, dividido em Pr é-requisitos – artefatos úteis, nem sempre obrigat órios, para o desenvolvimento do teste –, Metodologia – conceituaç ão e explicaç ão do procedimento de ataque/teste e Execuç ão, que abrange a aplicaç ão pr ática das diretrizes expostas pela seç ão de Metodologia.

1.1 Objetivos

Descrever a teoria, pr ática e ferramental necess ários a realizaç ão de uma s érie de testes definidos pela metodologia OWASP para segurança de aplicaç ões Web. A exemplificaç ão dos testes, quando poss´ıvel, toma por base o sistema e-SAJ, desenvolvido pela empresa Softplan/Poligraph.

(7)

Cap´ıtulo 2. Testing for credentials transport (OWASP-AT-001)

2 Testing for credentials transport

(OWASP-AT-001)

2.1 Objetivos

• Verificar o transporte seguro (cifrado) de credenciais de acesso

– Aplicaç ão de protocolo de transporte seguro (SSL/TLS) – Forma de implementaç ão da transaç ão HTTP/HTTPS

2.2 Pr ´e-requisitos

• Sistema WebScarab

2.3 Metodologia

A abordagem ser á utilizar o proxy do sistema WebScarab para interceptar requisiç ões e analisar seus respectivos cabeçalhos. Desta forma podemos confirmar ou n ão a utilizaç ão de SSL/TLS nos pacotes de autenticaç ão. De acordo com a metodologia OWASP ser ão analisados os seguintes cen ários:

• Envio de dados com o m étodo POST atrav és do protocolo HTTP • Envio de dados com o m étodo POST atrav és do protocolo HTTPS

• Envio de dados com o m étodo POST atrav és do protocolo HTTPS em uma p ágina acess´ıvel via protocolo HTTP

• Envio de dados com o m ´etodo GET atrav ´es do protocolo HTTPS

2.3.1 Configurac¸ ˜ao e uso do WebScarab para realizar o teste

O testador dever á, utilizando o proxy do sistema WebScarab, interceptar as requisiç ões para ent ão, analisar a tr ânsito das informaç ões. Para isso, antes precisamos instalar e configurar o sistema WebScarab, que ser á bastante útil em boa parte dos testes a serem aplicados. Pode-se proceder da seguinta maneira:

(8)

Cap´ıtulo 2. Testing for credentials transport (OWASP-AT-001)

Figura 2.1: utilizando o WebScarab

2. inicializar o sistema Webscarab, clicar na aba proxy e habilitar a opc¸ ˜ao Intercept requests: como mostra a figura 2.1

3. Analisar as requisic¸ ˜oes interceptadas. Como exemplificado em 2.2

(9)

Cap´ıtulo 2. Testing for credentials transport (OWASP-AT-001)

2.4 Execuc¸ ˜ao

Com o procedimento acima descrito, é poss´ıvel analisar as requisiç ões de todas as p áginas do sistema para verificar as poss´ıveis vulnerabilidades descritas no cen ário deste teste 2.3. A an álise é visual, basta observar na primeira linha do cabeçalho da requisiç ão, logo ap ós o m étodo utilizado (POST ou GET). É trivial perceber se foi ou n ão utilizado o protocolo https. No exem-plo utilizado (figura 2.2), constatou-se a n ão utilizaç ão do protocolo de segurança, como con-sequ ência disso, os dados da credencial do usu ário transitam na rede em texto plano.

(10)

Cap´ıtulo 3. Testing for user enumeration (OWASP-AT-002)

3 Testing for user enumeration

(OWASP-AT-002)

3.1 Objetivos

• Enumerar os usu ários v álidos da aplicaç ão

• Auditoria do esquema de mensagens de erro e URL

3.2 Pr ´e-requisitos

• Credinciais v ´alidas (usu ´arios e senhas) do sistema a ser testado

3.3 Metodologia

O escopo deste teste é verificar a possibilidade de coletar e enumerar usu ários v álidos, para que, posteriormente por interm édio de um ataque de força bruta, possamos descobrir as respec-tivas senhas, e ent ão ter acesso a funcionalidades restritas dos sitema. Basicamente a metodolo-gia é testar combinaç ões de credencias v álidas e inv álidas e analisar a partir das mensagens de erro e URLs se o usu ário é v álido ou n ão.

3.4 Execuc¸ ˜ao

Para executar o teste como recomendado pelo projeto OWASP, o testador dever ´a seguir as seguintes etapas:

1. Realizar o teste somente com o usu ´ario incorreto, sem inserir a senha e registrar os resul-tados

2. Realizar o teste com um usu ´ario incorreto e com uma senha qualquer e registrar os resul-tados

3. Realizar o teste com um usu ário v álido e com uma senha incorreta e registrar os resultados Ao executar as etapas enumeradas acima, é poss´ıvel, atrav és das respostas devolvidas pelo sistema testado, chegar em algumas conclus ões quanto a validade ou n ão do usu ário testado. Por exmemplo, se testarmos um usu ário qualquer e o sistema respoder referindo-se somente ao status do usu ário, é poss´ıvel saber se o usu ário inserido é v álido ou n ão.

(11)

Cap´ıtulo 3. Testing for user enumeration (OWASP-AT-002)

´

E poss´ıvel tamb ´em analisar as URLs, como por exemplo, se as respostas do servidor forem semelhantes a estas:

http://www.foo.com/err.jsp?User=baduser\&Error=0 http://www.foo.com/err.jsp?User=gooduser\&Error=2

(12)

Cap´ıtulo 4. Testing for Brute Force (OWASP-AT-004)

4 Testing for Brute Force

(OWASP-AT-004)

4.1 Objetivos

• Classificar tipo de mecanismo de autenticac¸ ˜ao

• Realizar teste de exaust ão (ou força-bruta) por dicion ário

4.2 Pr ´e-requisitos

• Uma ferramenta de Brute Force, por exemplo o Hydra ou o FireForce

4.3 Metodologia

A abordagem a ser utilizada neste ataque é capturar, com aux´ılio do software WebScarab, as requisiç ões no momento da comunicaç ão cliente/servidor e identificar o tipo de mecanismo de autenticaç ão que est á sendo utilizado:

• HTTP Authentication

– Basic Access Authentication – Digest Access Authentication

• HTML Form-based Authentication

Uma vez identificado o mecanismo, o testador dever á utilizar uma ferramenta de bruteforce apropriada (ou a mesma ferramenta com os parametros apropriados) para descobrir senhas de acesso ao sistema. A ferramenta utilizada neste caso foi o software hydra. Informaç ões sobre instalaç ão, configuraç ão e uso podem ser encontrado em http://www.thc.org/thc-hydra/.

Outra ferramenta que pode ser utilizado é o plugin do Firefox FireForce. A instalaç ão é simples e é realizada como qualquer outro plugin do navegador.

4.4 Execuc¸ ˜ao

No caso do testa aplicado no sistema e-SAJ, para autenticaç ão n ão existe nenhum sistema de captcha e as ferramentas conseguem fazer v árias requisiç ões testando as senhas geradas ou

(13)

Cap´ıtulo 4. Testing for Brute Force (OWASP-AT-004)

senhas de dicion ários. A sa´ıda do FireForce é o n úmero de tentativas e o password supostamente correto. Um exemplo de sa´ıda do hydra pode ser observada a seguir:

Hydra (http://www.thc.org/thc-hydra) starting at 2012-01-31 13:19:34 [DATA] 16 tasks, 1 server, 100000000 login tries (l:1/p:100000000),

˜6250000 tries per task

[DATA] attacking service http-post-form on port 80

[80][www-form] host: 172.23.1.55 login: 098.765.432-29 password: 00000013 [80][www-form] host: 172.23.1.55 login: 098.765.432-29 password: 00000009 [80][www-form] host: 172.23.1.55 login: 098.765.432-29 password: 00000011 [80][www-form] host: 172.23.1.55 login: 098.765.432-29 password: 00000012 [80][www-form] host: 172.23.1.55 login: 098.765.432-29 password: 00000015 [80][www-form] host: 172.23.1.55 login: 098.765.432-29 password: 00000007 .

. .

Ap ós as saidas de dados fornecidas pelo bruteforce é necess ário testar o casos onde o a ferramenta obteve sucesso, pois existe a possibilidade do resultado fornecido ser falso positivo.

(14)

Cap´ıtulo 5. Testing for Bypassing Authentication Schema (OWASP-AT-005)

5 Testing for Bypassing

Authentication Schema

(OWASP-AT-005)

5.1 Objetivos

• Contornar esquema de autenticac¸ ˜ao

– Direct page request (forced browsing) – Parameter Modification

– Session ID Prediction

– SQL Injection - Realizar testes de SQL Injection nos formul ários de autenticaç ão

5.2 Pr ´e-requisitos

5.3 Metodologia

Segundo o projeto OWASP existem diversas metodologias que podem ser utilizadas para fazer o bypassing do mecanismo de autenticac¸ ˜ao. Neste caso iremos testar quatro mecanismos:

• Direct page request (forced browsing) • Parameter Modification

• Session ID Prediction

• SQL Injection - Realizar testes de SQL Injection nos formul ários de autenticaç ão

5.4 Execuc¸ ˜ao

• Direct page request (forced browsing) - O Testador dever á tentar acessar uma p ágina que poderia ser acessada somente ap ós o processo de login. Para fazer isso pode-se utilizar a ferramenta w3bfkk0r 1_{, que atrav és de um dicion ário de palavras tenta acessar}

p ´aginas restritas sem autenticar e exibe os resultados ao final.

1_{Informaç ões} _sobre _{configuraç ão} _e _{utilizaç ão} _da _ferramenta _podem _ser _encontradas _em http://www.ngolde.de/w3bfukk0r.html

(15)

Cap´ıtulo 5. Testing for Bypassing Authentication Schema (OWASP-AT-005)

• Parameter Modification - Se a verificaç ão de autenticaç ão for realizada em cima de al-guma parametro, o testador deve modificar este parametro para tentar conseguir se aut-enticar. S ão poss´ıveis duas formas, o parametro sendo passado via URL, onde o testador pode modific á-lo no pr óprio navegador, ou atrav és de requisiç ões http onde pode ser usado o WebScarab para capturar a comunicaç ão e alterar o par âmetro.

• Session ID Prediction - Em sistemas que se baseiam em SESSION ID para controlar a autenticaç ão, o testador dever á tentar descobrir um padr ão na formaç ão desse SID para conseguir se autenticar. Primeiro é preciso ver se o sistema utiliza o SID para autenticaç ão e depois tentar descobrir uma forma de descobrir como se esse SID esta sendo gerado. • SQL Injection - Realizar testes de SQL Injection nos formul ários de autenticaç ão..

Ver 18

Fazendo um teste no sistema e-SAJ utilizando a ferramenta w3bfukk0r, obteve-se a seguinte sa´ıda:

Starting w3bfukk0r 0.2

Scanning http://172.23.1.55/ with 101 words from words.txt Found http://172.23.1.55/cgi-bin/ (not public; HTTP 403) Found 1 directories.

Server runs: Apache/2.2.21 (Win32) mod\_jk/1.2.28 Scan finished (8 seconds).

O que n ão apresenta nenhuma sa´ıda preocupante visto que o único diret ório encontrado n ão é p úblico. Um wget recursivo tamb ém foi utilizado para verificar se alguma p ágina que necessitasse de autenticaç ão poderia ser acessada, por ém tamb ém nada foi encontrado. Foram utilizados tamb ém testes com o sistema de autenticaç ão (tentando substituir dados ou colar um ticket v álido ap ós o logoff de um usu ário v álido) por ém o sistema se apresentou est ável tamb ém sob este aspecto.

Testes manuais de modificaç ão de param êtros e tamb ém via interceptaç ão de cabeçalhos com o WebScarab foram realizados por ém nada foi encontrado. Para o session ID prediction foi realizada uma pesquisa na Internet sobre ataques baseados na geraç ão de tickets do CAS2e novamente n ão foi encontrado nenhum problema grave.

2

(16)

Cap´ıtulo 6. Testing for Vulnerable Remember Password and Pwd Reset

(OWASP-AT-006)

6 Testing for Vulnerable Remember

Password and Pwd Reset

(OWASP-AT-006)

6.1 Objetivos

• Testar func¸ ˜ao de lembrete de senha • Explorar funcionalidade de reset de senha

6.2 Pr ´e-requisitos

• Credinciais v ´alidas (usu ´arios e senhas) do sistema a ser testado • Sistema WebScarab

6.3 Metodologia

Este ataque consiste em verificar se a aplicaç ão web implementa o mecanismo de lembrar senha para tornar o acesso autom ático em visitas futuras e se tem dispon´ıvel um meio de reset de senha para explorar vulnerabilidades. Este teste pressup õe o conhecimento de usernames v álidos para experimentar o reset.

O cen ário deste teste contextualiza-se no momento em que o usu ário tem a necessidade de redefinir sua senha por in úmeros motivos. Falhas na implementaç ão do tr ânsito das informaç ões, na maneira como s ão recuperadas, suas facilidades de manipulaç ão, etc, podem ser aproveitadas por poss´ıveis atacantes.

6.4 Execuc¸ ˜ao

O mecanismo de recuperaç ão de senhas é simples, basta clicar no link “Esqueci minha senha“, como mostra a figura 6.1, inserir o login e ser á enviado automaticamente um e-mail para o respectivo usu ário. No corpo do e-mail teremos tamb ém um link que redireciona o usu ário para o sistema onde poder á criar uma nova senha.

O mecanismo de redefiniç ão de senhas do sistema e-SAJ, por sua vez, é implementado de maneira que o usu ário possa alter á-la sem nenhum aux´ılio externo, como o e-mail, por exemplo.

(17)

Cap´ıtulo 6. Testing for Vulnerable Remember Password and Pwd Reset

(OWASP-AT-006)

Figura 6.1: Elemento DOM location.href vulner ável a injeç ão de c ódigo

A metodologia utilizada é simples, sem outras etapas nem perguntas de confirmaç ão. Para alterar a respectiva senha é necess ário apenas incluir a senha atual e escolher uma nova.

Interessante realizar interceptç ões das requisiç ões no decorrer de todo o transporte das informaç ão, para isso basta utilizar o sistema WebScarab. Ent ão, é necess ário realizar uma an álise com intuito de identificar se existe alguma informaç ão sens´ıvel transitando em texto plano. A execuç ão do teste segue-se de maneira bem manual, ent ão o testador deve realizar a inserç ão e/ou redefiniç ão de senhas e interceptando requisiç ões com intuito de aproveitar-se de poss´ıveis vulnerabilidades. No caso do e-SAJ, n ão encontramos nenhuma vulnerabilidade cr´ıtica. Por ém, um fato que deve ser considerado é que no momento da redefiniç ão das senhas (atual e nova), as mesmas transitam ao servidor em texto plano, como é poss´ıvel verificar na requisiç ão abaixo, que foi interceptada com aux´ılio do software WebScarab. Isso ocorre porque o protocolo de comunicaç ão utilizado é HTTP e n ão HTTPS. Como exemplo podemos analisar uma requisiç ão interceptada com o WebScarab:

POST http://172.23.1.55:80/esajperfil/efetivarAlteracaoSenhaPeloPerfil.do HTTP/1.1

Host: 172.23.1.55

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

(18)

Cap´ıtulo 6. Testing for Vulnerable Remember Password and Pwd Reset

(OWASP-AT-006)

Keep-Alive: 115 Proxy-Connection: keep-alive Referer: http://172.23.1.55/esajperfil/alteraSenhaLoginPeloPerfil.do Cookie: JSESSIONID=B5CCA78B97CA9D9B286BAAEC5AA0333F.CEpt Content-Type: application/x-www-form-urlencoded Content-length: 65} senhaAtual=123456789&senhaNova=novaSENHA&senhaConfirmar =novaSENHA

*Obs.: No payload da requisiç ão est ão as senhas atual: 123456789 e nova: novaSENHA,

sendo transmitidas em texto plano.

O e-SAJ n ão implementa nenhum mecanisco para lembrar senha de modo que possa ser aproveitada no futuro. Caso o navegar seja fechado, para acessar o sistema é necess ário logar-se novamente. Portanto ataques desta natureza s ão dificultados.

(19)

Cap´ıtulo 7. Testing for Logout and Browser Cache Management (OWASP-AT-007)

7 Testing for Logout and Browser

Cache Management

(OWASP-AT-007)

7.1 Objetivos

• Acessar informaç ões sens´ıveis ap ós logout • Reproduzir, no sistema, aç ão pr évia ap ós logout • Analisar tempo de expiraç ão de sess ão de usu ário

7.2 Pr ´e-requisitos

• Sistema WebScarab

7.3 Metodologia

A abordagem deste teste é realizar algumas an álises, como por exemplo, se a funç ão de logout apaga todas as informaç ões cr´ıticas ap ós a sess ão ser encerrada. Tamb ém pode-se anal-isar se o servidor faz as devidas verificaç ões sobre o estado da sess ão, n ão permitindo ao invasor reproduzir alguma aç ão previamente realizada, quando o usu ário ainda estava autenticado. Por fim, observa-se se existe algum tempo limite para expirar a sess ão automaticamente. Tempo esse que deve tamb ém ser verificado se é pr é-configurado no servidor.

7.4 Execuc¸ ˜ao

Em primeiro lugar, como recomendado pelo projeto OWASP, o testador deve verificar se todas as p áginas dos sistema a ser testado possuem a opç ão de logout e se a mesma era encontrado facilmente pelo usu ário. Foram feitas estas verificaç ões no sistema e-SAJ (com um usu ário que possui privil égios de advogado) e constatado que todas as p áginas possuem a respectiva opç ão. Em todas as p áginas pode-se encontrar no canto superior direito a opç ão de logout do sistema, como exemplificado na figura 7.1.

O testador tamb ém deve analisar o comportamento do sistema ap ós aplicar a funç ão de logout. Para isso, pode-se interceptar as requisiç ões e observar atentamente os seus respectivos

(20)

Cap´ıtulo 7. Testing for Logout and Browser Cache Management (OWASP-AT-007)

Figura 7.1: Func¸ ˜ao de logout do sistema e-SAJ

campos, com intuito de entrontrar alguma informaç ão relevante. Como, por exemplo, alterar alguns campos como a data, hor ário, Cache-Control, Pragma, entre outros, e observar se existe alguma falha na autenticaç ão por parte do servidor.

Outra verificaç ão recomentada pelo projeto OWASP é se existe no sistema testado a fun-cionalidade de Timeout Logout. Caso n ão exista, isso apresenta-se como uma falha de segurança.

(21)

Cap´ıtulo 8. Testing for Reflected Cross Site Scripting (OWASP-DV-001)

8 Testing for Reflected Cross Site

Scripting (OWASP-DV-001)

8.1 Objetivos

• Enumerar pontos de entrada de dados do usu ário n ão filtrados • Executar c ódigo-cliente malicioso no contexto da enumeraç ão

8.2 Pr ´e-requisitos

• Ferrementa de varredura de aplicac¸ ˜ao Web, Spider/Crawler • Ferramenta de proxy (WebScarab, BurpSuite, etc)

• Codificador/decodificador de conjunto de caracteres

8.3 Metodologia

Ataques do tipo Reflected Cross Site Scripting exploram a n ão filtragem, cuja responsabili-dade geralmente reca´ı ao lado servidor da aplicaç ão, de entradas fornecidas pelo usu ário, con-vencionalmente, a partir de formul ários. Um c ódigo cliente, Javascript, por exemplo, fornecido como valor de alguma vari ável contida numa requisiç ão HTTP pode ser retornado, pelo servidor de aplicaç ão, em uma resposta HTTP de car áter malicioso.

O procedimento de verificaç ão para esse tipo de XSS consiste em se testar entradas Javascript nos formul ários de consulta da aplicaç ão, assim como o envenenamento de vari áveis na pr ópria URL associada a uma solicitaç ão HTTP - a alteraç ão dos par âmetros de composiç ão da requisiç ão pode ser realizado, quando assim for necess ário, atrav és de uma ferramenta de proxy.Caso o c ódigo seja efetivamente executado pelo navegador, significa que a resposta HTTP retornada pelo servidor refletiu o c ódigo malicioso. Ou seja, a aplicaç ão est á vulner ável.

A constataç ão da condiç ão de XSS n ão-persistente, como tamb ém é conhecido o Reflected XSS, pode ser automatizada por ferramentas. Estas tem como heur´ıstica a an álise da resposta HTTP correspondente a requisiç ão constitu´ıda por dados n ão confi áveis. Analisa-se, portanto, numa abordagem automatizada, o conte údo da resposta HTTP, e n ão sua execuç ão propriamente dita.

(22)

Cap´ıtulo 8. Testing for Reflected Cross Site Scripting (OWASP-DV-001)

8.4 Execuc¸ ˜ao

Antes de fornecer entradas Javascript aos formul ários de consulta da aplicaç ão, faz-se necess ário realizar um mapeamento dos eventuais pontos vulner áveis. Esse tipo de mapeamento, ou enumeraç ão, pode ser realizado manualmente ou, como figura ser o caso de aplicaç ões de maior porte, de modo automatizado. A automatizaç ão desse processo tem como base ferramentas de crawling, ou spidering. Elas percorrem os links da aplicaç ão Web, buscando novas ligaç ões que sejam relevantes ao contexto da estrutura que se deseja montar: a hierarquia da aplicaç ão.

Logo abaixo, pode-se observar a estrutura hier ´arquica do sistema e-SAJ revelada pela ferra-menta ZAP (Zed Attack Proxy):

Figura 8.1: Crawling utilizando a ferramenta ZAP no sistema e-SAJ

Uma vez tendo sido estipulada a estrutura da aplicaç ão, percorrem-se individualmente as p áginas enumeradas, selecionando aquelas que possuem formul ários ou campos de entrada de dados. Para o ataque de XSS n ão-persistente, a atenç ão do testador deve ser voltada à reflex ão dos dados de entrada inseridos nestes formul ários, estes destacados no processo de enumeraç ão anterior. A figura 8.2 ilustra um poss´ıvel vetor para o Reflected XSS.

Durante um teste caixa-preta, como o que aqui se aplica, h á duas opç ões de fornecimento de dados de entrada para a aplicaç ão. A primeira delas, mais convencional, implica em inserir c ódigo JavaScript no formul ário - ou, caso o met ódo HTTP utilizado seja GET, atrav és da URL -, submet ê-lo ao servidor e, ent ão, observar se p ágina de resposta cont ém o excerto de c ódigo antes oferecido. A segunda abordagem, amparada normalmente por uma ferramenta de proxy, baseia-se na intercepç ão da requisiç ão HTTP e inserç ão do c ódigo JavaScript on-the-fly, ou seja, durante a passagem da requisiç ão para o servidor. A verificaç ão da condiç ão de XSS, neste caso, pode ser averiguada pela constataç ão da exist ência do c ódigo, infiltrado na requisiç ão, na resposta HTTP. As figuras de 8.3 à 8.6 ilustram uma sequ ência de capturas de tela que exibe a segunda abordagem.

(23)

Cap´ıtulo 8. Testing for Reflected Cross Site Scripting (OWASP-DV-001)

Figura 8.2: Exemplo de eventual vetor para ataque de Reflected XSS

(24)

Cap´ıtulo 8. Testing for Reflected Cross Site Scripting (OWASP-DV-001)

Figura 8.4: Captura da requisiç ão HTTP atrav és do WebScarab - passo 2

Figura 8.5: Confirmaç ão, na resposta HTTP, da exist ência do c ódigo malicioso fornecido pela requisiç ão HTTP - passo 3

(25)

Cap´ıtulo 8. Testing for Reflected Cross Site Scripting (OWASP-DV-001)

Figura 8.6: Execuç ão efetiva do c ódigo JavaScript que alimentou a entrada do formul ário - passo 4

(26)

Cap´ıtulo 9. Testing for Stored Cross Site Scripting (OWASP-DV-002)

9 Testing for Stored Cross Site

Scripting (OWASP-DV-002)

• Enumerar pontos de entrada de dados do usu ´ario n ˜ao filtrados

• Armazenar e executar c ódigo-cliente malicioso no contexto da enumeraç ão

9.1 Pr ´e-requisitos

• Codificador/decodificador de conjunto de caracteres

9.2 Metodologia

Ataques da classe Stored XSS, ou ataques de Cross Site Scripting persistente, s ão caracter-izados pelo armezenamento do c ódigo malicioso na base de dados da aplicaç ão. Assim sendo, o raio de ataque, em relaç ão ao Reflected XSS, é aumentado. Isso acontece porque as vit´ımas potenciais passam a ser todos os usu ários que acessam a p ágina que faz refer ência ao conte údo malicioso. O servidor de aplicaç ões, quando da recuperaç ão e exibiç ão dos dados para o usu ário, representa para o navegador uma fonte confi ável de dados. Dessa forma, o c ódigo inescrupuloso trazido da base de dados pelo servidor de aplicaç ões é efetivamente executado pelo navegador no contexto do usu ário.

A detecç ão dessa categoria de vulnerabilidade de injeç ão de c ódigo se d á de maneira ligeira-mente similar ao Reflected XSS. Testes caixa-preta envolvendo os par âmetros utilizados em requisiç ões HTTP permitem que seja avaliado, uma vez tendo sido emitida uma requisiç ão HTTP com conte údo malicioso, o armazenamento conclusivo desse c ódigo de entrada na base de dados da aplicaç ão. A confirmaç ão da falha, por sua vez, ocorre pela consulta ao dado suposta-mente armazenado. Se, ao acessar a p ágina que recupera o c ódigo malicioso, este for executado pelo navegador, consagra-se o XSS persistente.

Ressalta-se, entretanto, que, diferentemente do ataque de Reflected XSS, este que aqui se descreve concede maior atenç ão aos formul ários de entrada de dados que ser ão armazenados na estrutura de persist ência da aplicaç ão.

(27)

Cap´ıtulo 9. Testing for Stored Cross Site Scripting (OWASP-DV-002)

9.3 Execuc¸ ˜ao

Conforme mecionado na metodologia do teste de XSS, a averiguaç ão de ataques de Cross Site Scripting persistentes compartilha procedimentos da sua contraparte, os XSS persistentes. Assim sendo, a execuç ão do teste obedece a essa semalhança, resguardando uma diferença: verificaç ão do c ódigo-cliente previamente armazenado. Para o caso do sistema e-SAJ, a t´ıtulo de exemplo, uma eventual falha de Stored XSS, que no final das contas mostrou-se como sendo Reflected XSS, teria sua condiç ão verifica pela consulta de petiç ões de primeiro grau. As figuras 9.1 e 9.2 demonstram essa situaç ão. Observe que a instruç ão inserida no campo nome é tratada, pelo navegador, como um conjunto de caracteres, e n ão como c ódigo Javascript. Em outras palavras, n ão se confirma, embora o c ódigo seja corretamente persistido, a condiç ão de Stored XSS.

(28)

Cap´ıtulo 9. Testing for Stored Cross Site Scripting (OWASP-DV-002)

(29)

Cap´ıtulo 10. Testing for DOM-based Cross Site Scripting (OWASP-DV-003)

10 Testing for DOM-based Cross

Site Scripting (OWASP-DV-003)

– An álise est ática de c ódigo-cliente

• Executar c ódigo-cliente malicioso no contexto da enumeraç ão

10.1 Pr ´e-requisitos

• DOMinator (ferramenta baseada no Firefox para inspeç ão de c ódigo Javascript) • Codificador/decodificador de conjunto de caracteres

10.2 Metodologia

Vulnerabilidades de Cross Site Scripting s ão comumente classificadas em persistentes e n ão-persistentes. Por ém, existe uma terceira categoria para essa modalidade de ataque de injeç ão: DOM-based XSS. Esse ataque se vale da utilizaç ão ing ênua de elementos da árvores DOM (Document Object Model) para execuç ão de c ódigo cliente. Por vezes, em aplicaç ões Web, nota-se o uso de informaç ões fornecidas pelo usu ário, de maneira indireta ou direta, na composiç ão de express ões presentes no c ódigo executado pelo navegador.

O processo de investigaç ão desta vulnerabilidade toma, tradicionalmente, corpo atrav és da an álise manual do c ódigo vulner ável, que est á geralmente dispon´ıvel ao atacante, uma vez que é c ódigo cliente. Entretanto, ainda que escassas, h á algumas ferramentas que amparam esse procedimento de investigaç ão. Para o sistema e-SAJ, foi utilizado o DOMinator, dispon´ıvel em [1]. Sendo uma extens ão do navegador Firefox, ele permite que, à medida que a navegaç ão pela aplicaç ão é realizada, sejam analisados os trechos de c ódigo potencialmente vulner áveis; recon-hecidamente aqueles manipuladores de elementos DOM, como windows.location, location.href, etc.

10.3 Execuc¸ ˜ao

Para a execuç ão deste teste, ser á descrito o procedimento que envolve o uso da ferramenta DOMinator. Baseada no Firefox 3.6.13, ele vem embarcado no bin ário dispon´ıvel no site do projeto. Como ele atua conjuntamente ao Firebug v1.6.2, pode ser necess ário procurar por esta

(30)

Cap´ıtulo 10. Testing for DOM-based Cross Site Scripting (OWASP-DV-003)

vers ão exata deste último para que o DOMinator possa operar satisfatoriamente. A figura 10.1 ilustra o DOMinator em aç ão na p ágina do eSAJ.

Figura 10.1: Firebug em conjunto com o DOMinator

A tarefa do testador, sob posse da ferramenta de apoio para investigaç ão do c ódigo cliente, torna-se percorrer as p áginas da aplicaç ão, analisando, à medida que a navegaç ão acontece, os avisos emitidos no porç ão inferior da janela do navegador. O DOMinator pode ser acessado na aba mais à direita do Firebug.

Pretendendo-se demonstrar as condiç ões de injeç ão de c ódigo em elementos DOM, a figura 10.3 demonstra a identificaç ão da vulnerabilidade pelo DOMinator. Em seguida, ilustrada pela figura 10.4, realiza-se, pelo fornecimento de c ódigo Javascript ao par âmetro classificado como n ão filtrado, a confirmaç ão da brecha diagnosticada.

A URL contida na barra de enderec¸o do navegador ´e apresentada na figura 10.2.

Figura 10.2: URL com Javascript para explorac¸ ˜ao de DOM-based XSS

A parte inserida pelo testador corresponde a subexpress ão ap ós a cerquilha (#), que indica ao navegador que o que a sucede n ão deve ser enviado ao servidor de aplicaç ão. Dessa forma, tem-se uma evas ão no ataque DOM-based, uma vez que o servidor jamais toma conhecimento do c ódigo malicioso sendo executado pelo navegador. O mesmo n ão ocorre com outros tipos de XSS, uma vez que o c ódigo é refletido, ou armazenado na base de dados, permitindo, com isso, que o servidor aplique regras de detecç ão de trechos de c ódigo maliciosos.

A express ão destacada, da cerquilha at é o último caracter da URL, atinge, em algum mo-mento, uma vari ável pertencente à estrutura DOM da p ágina. Quando isso acontece, o c ódigo Javascript é efetivamente executado no contexto do usu ário.

(31)

Cap´ıtulo 10. Testing for DOM-based Cross Site Scripting (OWASP-DV-003)

Figura 10.3: Elemento DOM location.href vulner ável a injeç ão de c ódigo

(32)

Cap´ıtulo 11. Testing for Cross Site Flashing (OWASP-DV-004)

11 Testing for Cross Site Flashing

(OWASP-DV-004)

11.1 Objetivos

• Enumerar pontos de entrada de dados do usu ário (FlashVars) n ão filtrados • Executar c ódigo-cliente malicioso no contexto da enumeraç ão

• Decompilar aplicac¸ ˜ao existente em arquivo SWF

• Garimpar informaç ões sens´ıveis no c ódigo decompilado

11.2 Pr ´e-requisitos

• Decompiladores para ActionScript 2.0 e/ou ActionScript 3.0 (SWFScan, etc)

11.3 Metodologia

Sistemas Web, frequentemente, contam com aplicaç ões constru´ıdas em ActionScript, lin-guagem pertencente à plataforma Flash. Identificadas pela extens ão .swf, essas aplicaç ões tem seu c ódigo executado no lado cliente atrav és de uma m áquina virtual embarcada no pr óprio Flash Player. Por conseguinte, a passagem de par âmetros pelo usu ário para o SWF (Sockwave Flash) ocorre ou pela URL ou, ent ão, por tags HTML. Sobre dados oriundos de fontes externas, desse modo, destacam-se, do ponto de vista de segurança de aplicaç ões, dois aspectos: passagem de par âmetros e usu ário.

Vari áveis Flash, ou FlashVars, e determinadas funç ões cuja operaç ão depende de argumen-tos provenientes de entrada do usu ário, podem, por viabilidade de caracter´ısticas do ActionScript conjuntamente a uma m á codificaç ão, permitir a execuç ão de c ódigo malicioso atrav és do SWF.

Verificaç ões de condiç ão de XSS em aplicaç ões Flash ocorrem por testes caixa-preta, avaliando-se a exist ência de filtragem dos valores passados às FlashVars, ou, alternativamente, por testes caixa-branca, cuja realizaç ão procede a partir da decompilaç ão do arquivo .swf. Analisa-se tamb ém a possibilidade de injeç ão de HTML em objetos TextField.

11.4 Execuc¸ ˜ao

Como o sistema e-SAJ, aplicaç ão Web exemplificadora dos testes relatados neste docu-mento, n ão possui aplicaç ões Flash/ActionScript, recomenda-se, para detalhes de execuç ão de

(33)

Cap´ıtulo 11. Testing for Cross Site Flashing (OWASP-DV-004)

(34)

Cap´ıtulo 12. Testing for Session Management Schema (OWASP-SM-001)

12 Testing for Session Management

Schema (OWASP-SM-001)

12.1 Objetivos

• Analisar atributos associados aos cookies

• Investigar mecanismo de geraç ão de informaç ão de sess ão • Explorar tempo de expiraç ão do cookie

• Classificar tipo de transporte pelos cookies utilizado

12.2 Pr ´e-requisitos

• Ferramenta de proxy (WebScarab, BurpSuite, etc) • Ferrementa de an ´alise de sequ ˆencia de cookies

12.3 Metodologia

O protocolo de comunicaç ão HTTP tem, por natureza, a propriedade de n ão estabelecimento de sess ão. Assim sendo, para que tal caracter´ıstica seja alcançada, criaram-se mecanismos de manutenç ão de estado/sess ão que atuam juntamente ao protocolo. Um desses mecanismos é o Cookie, estrutura de dados respons ável por conter informaç ão de identificaç ão de sess ão. Essa mesma informaç ão identificadora pode, variadamente, ser transmitida de outras formas - por URL ou por campos ocultos (”Hidden Fields”).

Quanto ao gerenciamento de sess ˜ao, portanto, cabe ao testador averiguar as seguintes dire-tivas:

• Os atributos dos cookies s ˜ao adequadamente estabelecidos?

• É poss´ıvel inferir o procedimento de geraç ão dos identificadores de sess ão usando engen-haria reversa?

• Cookies de sess ão apresentam tempo de expiraç ão coerente?

• Os cookies s ão transportados por canal de comunicaç ão seguro? Se sim, necessaria-mente?

(35)

Cap´ıtulo 12. Testing for Session Management Schema (OWASP-SM-001)

12.4 Execuc¸ ˜ao

Ferramentas de proxy, como o WebScarab, permitem que alguns dos questionamentos enu-merados na seç ão de ‘Metodologia‘ sejam testados. S ão inicialmente coletados cookies em quantidade suficiente para posterior an álise. Essa an álise envolve, num primeiro momento, a modificaç ão dos cookies das requisiç ões e exame das respostas respectivamente emitadas pelo servidor; abrange, num segundo instante, observaç ão meticulosa quanto ao padr ão de geraç ão dos identificadores de sess ão e, tamb ém, quanto ao escopo em que os identificadores s ão uti-lizados pela aplicaç ão.

Figura 12.1: Cookies do sistema e-SAJ capturados pelo WebScarab

Respectivamente aos cookies ilustrados em 12.1, obteve-se, novamente pelo WebScarab, um gr ´afico que exibe a dispers ˜ao dos valores de cookies gerados pelo sistema e-SAJ; o mesmo pode ser visualizado em 12.2.

Figura 12.2: Distribuic¸ ˜ao dos valores de cookie num curto intervalo de tempo ´

E poss´ıvel notar que, mesmo num curto intervalo de tempo, a geraç ão dos valores de cookies reflete significativa variabilidade. Isso constitui um ind´ıcio de utilizaç ão de algoritmos robustos, talvez criptogr áficos, na composiç ão dos valores. Uma an álise de previsibilidade mais apurada

(36)

Cap´ıtulo 12. Testing for Session Management Schema (OWASP-SM-001)

exigiria averiguar o c ódifo-fonte do CAS (Central Authentication Service), serviço utilizado pelo e-SAJ para o gerenciamento de sess ão de usu ários.

A seguir, dentre as atividades performadas pelo testador, destaca-se a reproduç ão de uma s érie de requisiç ões leg´ıtimas no contexto de outro usu ário. Esse teste tem por objetivo a tentativa de realizar operaç ões como se fosse a v´ıtima, para isso aproveitando-se dos cookies da mesma. Cabe, neste ponto, uma ressalva: o tempo de expiraç ão do cookie deve ser respeitado. Em outras palavras, a tentativa de sequestro deve ocorrer dentro da janela de expiraç ão. Para ilustrar o que acaba de ser enunciado, recorra à sequencia de figuras de 12.3 à 12.7. Ela reflete o comportamento do sistema e-SAJ quando dessa tentativa.

Figura 12.3: Requisiç ão HTTP contendo cookie v álido para usu ário Advogado

Figura 12.4: Requisiç ão HTTP contendo cookie v álido para usu ário Promotor

Figura 12.5: Adulteraç ão, durante requisiç ão emitada pelo Promotor, do campo Cookie, atribuindo a ele o cookie do Advogado

(37)

Cap´ıtulo 12. Testing for Session Management Schema (OWASP-SM-001)

Figura 12.6: Resposta HTTP do servidor, definido um novo valor de cookie para a sess ˜ao

(38)

Cap´ıtulo 13. Testing for Cookies Attributes (OWASP-SM-002)

13 Testing for Cookies Attributes

(OWASP-SM-002)

13.1 Objetivos

• Analisar atributos associados aos cookies

13.2 Pr ´e-requisitos

• Ferramenta de proxy (WebScarab, BurpSuite, etc)

13.3 Metodologia

Cookies s ão estruturas concebidamente utilizadas para a manutenç ão de estado do usu ário em aplicaç ões Web din âmicas. Os crit érios pelos quais s ão gerados e, adicionalmente, manipu-lados pela aplicaç ão s ão definidos com base em atributos; acerca destes, alguns relacionam-se com aspectos de segurança que devem ser resguardados mediante o trato dessas estruturas, os cookies.

S ão listados os seguintes atributos necess ários ao preenchimento de uma condiç ão segura de gerenciamento de sess ão do usu ário:

• Secure: quando ativado, garante que o cookie ser á estritamente transportado por canal de comunicaç ão seguro (tipicamente SSL/TLS);

• HttpOnly : se assinalado, impede que c ´odigo cliente acesse o cookie. Recomenda-se que seja sempre utilizado, ainda que, atualmente, nem todos os navegadores o suporte; • Domain: restringe o dom´ınio, e sub-dom´ınios, autorizados a manipular o cookie;

• Path: normalmente utilizado conjuntamente ao atributo domain, este atributo designa o caminho de URL para o qual o cookie ´e v ´alido;

• Expires: define tempo de expiraç ão para cookies persistentes. Caso a ele n ão seja definido valor algum, o cookie passa a expirar diante do t érmino da sess ão de navegaç ão.

O teste de atributos de cookie, por conseguinte, d á-se a partir da an álise de respostas HTTP com o cabeçalho Set-Cookie presente. Para essas respostas, verifica-se se h á, nelas, a presenç ão ou n ão dos atributos logo acima descritos. Para os casos em que se mostram pre-sentes, os atributos t êm, do ponto de vista de segurança, sua composiç ão de valores avaliada; quando da aus ência daqueles, o testador infere os impactos dessa car ência.

(39)

Cap´ıtulo 13. Testing for Cookies Attributes (OWASP-SM-002)

13.4 Execuc¸ ˜ao

Cookies, numa mesma aplicaç ão, podem ser sintetizados de acordo com procedimentos dis-tintos. Para o sistema e-SAJ, no contexto da autenticaç ão, obtiveram-se, atrav és da ferramenta de proxy WebScarab, respostas HTTP emitidas pela aplicaç ão - pelo servidor CAS, neste caso. As respostas podem ser observadas nas figuras 13.1 e 13.2.

Figura 13.1: Resposta HTTP associada à operaç ão de login no sistema e-SAJ

Para as duas repostas HTTP expostas em 13.1 e 13.2, pode-se notar a presença dos atrib-utos Expires e Path. A data de expiraç ão do cookie foi estabelecida para dez segundos do dia primeiro de Janeiro de 1970. Essa data, 01/01/1970, refere-se ao unix time[1], ou posix time. Atentemo-nos ao per´ıodo de validade do cookie. No no ato de logout, o CAS invalida o cookie atr áves do atributo Expires, como pode ser visualizado em 13.2.

O atributo Path, por sua vez, n ão foi corretamente definido. Embora aparentemente o cookie seja v álido somente ao caminho “/sajcas“, a n ão adiç ão de um “/” no final da express ão permite que o navegador envie o cookie para qualquer caminho cujo prefixo seja “/sajcas”, como, a t´ıtulo de exemplo, “/sajcas/atacante“.

Adicionemos agora à analise uma terceira resposta HTTP, esta relacionada a um operaç ão ordin ária realizada no sistema e-SAJ. Observe a figura 13.3. O atributo Path foi novamente mal formado.

Quanto aos demais atributos relevantes ao testes, destaca-se que n ão foram encontrados Secure, HttpOnly e Domain. A n ão utilizaç ão de Secure permite que o cookie seja transmitido em conex ões n ão seguras. Caso o cookie carregue consigo informaç ões sens´ıveis em claro, ou mesmo em um padr ão sobre o qual a infer ência é vi ável, h á a possibilidade de comprometimento da sess ão do usu ário. J á a aus ência de HttpOnly torna poss´ıvel ao atacante acessar os cookies

(40)

Cap´ıtulo 13. Testing for Cookies Attributes (OWASP-SM-002)

Figura 13.2: Resposta HTTP relacionada à operaç ão de logout no sistema e-SAJ

Figura 13.3: Resposta HTTP emitada a partir de uma operaç ão de cunho geral no sistema e-SAJ atr áves de c ódigo cliente, como Javascript. Finalmente, a car ência do atributo Domain permite que outros dom´ınios (potencialmente vulner áveis), os quais possuem o caminho “/esaj“ em sua

(41)

Cap´ıtulo 13. Testing for Cookies Attributes (OWASP-SM-002)

(42)

Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)

14 Testing for Exposed Session

Variables (OWASP-SM-004)

14.1 Objetivos

• Analisar atributos associados aos tokens de sess ˜ao

• Investigar mecanismo de geraç ão de informaç ão de sess ão • Inverter m étodo HTTP utilizado em requisiç ões

• Classificar tipo de transporte pelos cookies utilizado

14.2 Pr ´e-requisitos

14.3 Metodologia

Antes de descrever a metodologia deste teste como um todo, atentemo-nos ao fato de que a avaliaç ão de vari áveis de sess ão expostas apresenta, em determinados pontos, sobreposiç ão com outros testes da fam´ılia SM (Session Management) do projeto OWASP. Por exemplo, aspec-tos de gerenciamento de ciclo de vida de cookies e a maneira como s ão transportados.

Prosseguindo, enumeram-se os seguintes itens a serem contemplados pelo presente teste, no que se refere a eventual vulnerabilidade:

• Cifragem e reuso de tokens de sess ão • Proxies e funç ões de caching

• M étodo HTTP sendo utilizado (com maior atenç ão ao GET e ao POST) • Procedimentos de transporte

Para cada item supracitado, h á sa´ıdas, recomendadas pelas OWASP, esperadas de acordo com alteraç ões de dados de entrada ou a forma como os dados s ão fornecidos pelo cliente. A seç ão de execuç ão, logo a seguir, adentra em maiores detalhes sobre o que seriam essas alteraç ões ou o formato de fornecimento de dados.

(43)

Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)

14.4 Execuc¸ ˜ao

14.4.1 Cifragem e reuso de tokens de sess ˜ao

Tokens de sess ão – sejam eles representados por cookies, campos ocultos (hidden fiels), etc – devem, ideal e necessariamente, ser cifrados com base em algoritmos seguros de criptografia. Al ém disso, o algoritmo ou procedimento de cifragem utilizado deve apresentar consider ável variabilidade entres os valores de um token e outro, ainda que a informaç ão se refira a um mesmo usu ário (autenticando-se em diferentes sess ões, por exemplo).

Independente da maneira como o pr óprio token de sess ão é tornado seguro, deve-se, tamb ém, ser levado em consideraç ão a exposiç ão do material cifrado. Essa exposiç ão pode, sob certas circunst âncias, permitir que um atacante utilize um token capturado num ataque de sequestro de sess ão. Em decorr ência disso, destaca-se a necessidade de n ão permitir a reutilizaç ão de tokens, assim como a emiss ão do token de sess ão sempre atrav és de canal de comunicaç ão cifrado.

No caso do sistema e-SAJ, o transporte do token ocorre sempre em texto plano, ou seja, sem HTTPS. Em situaç ão inversa, ou seja, num cen ário em que o e-SAJ, por padr ão, exigisse comunicaç ão com seus elementos de aplicaç ão usando t únel seguro, ainda assim deveria ser testada a condiç ão de troca do endereço de HTTPS para HTTP; isso seria feito na pr ópria barra de endereços do navegador. Averigua-se, por conseguinte, a possibilidade de forçar o tr áfego dos tokens de sess ão sem ser por via segura.

Refira-se ao cap´ıtulo ‘Testing for Cookie attributes‘ para uma an ´alise adicional acerca da variabilidade de valores de cookies oferecida pelo e-SAJ e da tentativa de reutilizar um token de sess ˜ao.

14.4.2 Proxies e func¸ ˜

oes de caching

Tendo em vista que serviços de proxy e caching de dados podem armazenar, segundo crit érios pr óprios de gerenciamento de dados, tokens de sess ão, a vers ão 1.1 do protocolo HTTP fornece diretivas de controle acerca destes tokens, como, por exemplo, “Expires: 0” e “Cache-Control: max-age=0”. Essas duas diretivas exemplificadas s ão utilizadas para que serviços de cache n ão exponham os dados. Com isso, cabe ao testador examinar cada requisaç ão/resposta HTTP para garantir que essas diretivas est ão sendo aplicadas.

No contexto do sistema e-SAJ, foram observados cabeçalhos de requisiç ão e resposta HTTP. Conforme ilustra a figura 14.1, as diretivas “Cache-Control: max-age=0” e “Expires: 0” est ão definidas no transporte dos JSESSIONID’s; a administraç ão dessas diretivas est á sendo feita pelo CAS.

14.4.3 M ´etodo HTTP sendo utilizado

Primeiramente, o m étodo HTTP GET n ão deve ser utilizado quando envolvidas informaç ões sens´ıveis. Em segundo lugar, muitas vezes, é poss´ıvel alterar o tipo de m étodo utilizado, de POST para GET, permitindo que uma determinada falha, XSS – por exemplo –, seja mais facil-mente explorada por um atacante; condiç ões de Cross Site Scripting s ão mais confortavelfacil-mente

(44)

Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)

Figura 14.1: Uso de diretivas para manuseio seguro de tokens de sess ˜ao exploradas a partir de c ´odigo malicioso embutido em URL.

A ferramenta WebScarab oferece a opç ão de intercambiar entres os m étodos HTTP utiliza-dos nas requisiç ões/respostas por ele capturadas. Assim sendo, o testador possui a respon-sabilidade de testar a invers ão de m étodos em tantas requisiç ões/repostas quanto poss´ıvel – dependendo da complexidade, ou porte, da aplicaç ão Web sendo testada, pode ser necess ária uma automatizaç ão desta tarefa, utilizando-se, a saber, um Fuzzer.

A s érie de figuras de 14.2 à 14.5 ilustra uma alteraç ão de m étodo HTTP na opç ão de cadastro do e-SAJ. Observe que modificaç ão se mostra vi ável, demonstrando a fragilidade do e-SAJ neste quesito.

14.4.4 Procedimentos de transporte

Esta subseç ão objetiva responder às seguintes perguntas, algumas delas com escopo j á definido em t ópicos anteriores, sob a perspectiva particular do sistema e-SAJ:

• Como s ˜ao tranferidos os Session IDs?

N ão é poss´ıvel transferir os session ID’s atrav és de GET, de forma que eles n ão ficam expostos em logs de firewalls ou proxys.

• Os Session IDs s ão sempre, por padr ão, enviados atrav és de transporte cifrado?

Codificados pelo CAS. Foram feitos testes de manipulaç ão de cookies para logar em uma sess ão ativa com os valores capturados dos JSESSIONID’s e n ão foi obtido sucesso. • É poss´ıvel persuadir a aplicaç ão a enviar Session IDs por canal inseguro?

(45)

Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)

Figura 14.2: Tela inicial de cadastro de novo usu ´ario do e-SAJ

Figura 14.3: Requisiç ão HTTP POST original emitida pela aplicaç ão S ó é poss´ıvel visualizar os valores codificados pelo CAS.

(46)

Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)

Figura 14.4: Transformaç ão de m étodo POST para GET

Figura 14.5: Alterac¸ ˜ao efetuada com sucesso, confirmada pela tela seguinte de cadastro os Session IDs?

(47)

Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)

• Essas diretivas est ão sempre presentes? Se n ão, quais s ão as exceç ões? Cache-Control: max-age=0 sempre presente.

• Os Session IDs s ão incorporados por requisiç ões GET?

N ão é poss´ıvel fazer a autenticaç ão atrav és de m étodos GET. • O m étodo POST, quando utilizado, pode ser substitu´ıdo pelo GET?

(48)

Cap´ıtulo 15. Testing for Path Traversal (OWASP-AZ-001)

15 Testing for Path Traversal

(OWASP-AZ-001)

15.1 Objetivos

• Contornar permiss ˜oes de acesso a arquivo e diret ´orios

15.2 Pr ´e-requisitos

• UniScan (testes de falha de atravessamento de diret ´orios)

15.3 Metodologia

Tradicionalmente, servidores e aplicaç ões web implementam mecanismos de autenticaç ão para controlar o acesso a arquivos e recursos. Servidores Web tentam limitar os arquivos dos usu ários dentro de um ”diret ório raiz”ou ”raiz do documento web”, que representam um diret ório f´ısico no sistema de arquivos. Os usu ários t êm que considerar esse diret ório como o diret ório base para a estrutura hier árquica da aplicaç ão web. A definiç ão dos privil égios é feita atrav és de Access Control Lists (ACL), que identifica quais usu ários ou grupos ser ão capazes de acessar, modificar ou executar um arquivo espec´ıfico no servidor. Estes mecanismos s ão projetados para impedir o acesso a arquivos confidenciais por parte de usu ários mal-intencionados (por exemplo, o arquivo comum /etc/passwd em uma plataforma Unix), ou para evitar a execuç ão de comandos do sistema.

Com base nessas informaç ões, a metodologia do ataque basicamente é enumerar/mapear todos os endereços que o usu ário é capaz de acessar, para ent ão inserir caracteres especiais com intuito de aproveitar-se de vulnerabilidades na validaç ão server-side e ter acesso a arquivos proibidos para esse respectivo usu ário.

15.4 Execuc¸ ˜ao

O atravessamento de diret órios, ou Path Traversal, envolve essencialmente duas etapas. A primeira delas é a enumeraç ão dos vetores de validaç ão de entrada. S ão vetores dessa categoria aqueles que permitem o envio de arquivos pelo usu ário, formul ários HTML, consultas HTTP GET

(49)

Cap´ıtulo 15. Testing for Path Traversal (OWASP-AZ-001)

e POST, etc. Especificamente para o sistema e-SAJ, um eventual vetor de validaç ão de entrada seria a seç ão Push, que possibilita o envio de processos por um advogado.

A segunda etapa do teste se refere a tentativa de acesssar arquivos, e diret órios, partindo-se dos vetores elencados na primeira fase de teste. Esse processo de verificaç ão realiza-se de forma manual – tarefa dispendiosa quando de uma aplicaç ão web complexa ou de grande porte – ou, alternativamente, de modo autom ático – atrav és de ferramentas como o Uniscan, que anal-isam diferentes possibilidades de acesso a arquivos e diretorios, empregando, tamb ém, variados modos de codificaç ão que, em determinados casos, viabilizam contornar filtros existentes no lado servidor.

Um poss´ıvel vetor para o atravessamento, no contexto do sistema e-SAJ, seria a seç ão de Push. No entanto, a inclus ão de um processo no sistema é intermediada por uma busca. Essa busca interp õe-se entre a seleç ão do processo e a inclus ão do mesmo no e-SAJ. Dessa forma, um atacante é incapaz, nesta seç ão, de testar URLs ou caminhos relativos, verificaç ão necess ária ao teste aqui discutido.

Ressalta-se, contudo, em relaç ão a constataç ão manual desta catagoria de vulnerabilidade, a necessidade de se levar em consideraç ão a maneira como ocorre o percorrimento de di-ret órios e arquivos, que est á associada intrinsicamente ao Sistema Operacional que executa a aplicaç ão Web. N ão confundir ’/’, caracter tipicamente utilizado em sistemas Linux, com ‘\\‘ ou ‘Letra:\caminho\para\arquivo‘, caracteres usualmente vistos em sistemas Windows.

Com vistas à exemplificar a modalidade autom ática de teste, em 15.1 observa-se o Unis-can em aç ão. O UnisUnis-can n ão somente realiza testes acerca do ataque de atravessamento de diret órios, todavia tamb ém ataques referentes à inclus ão de arquivos (LFI), dentre outros.

(50)

Cap´ıtulo 16. Testing for Bypassing Authorization Schema (OWASP-AZ-002)

16 Testing for Bypassing

Authorization Schema

(OWASP-AZ-002)

16.1 Objetivos

• Sobrepujar o esquema de autorizaç ão, tentando-se acessar ar éas restritas ou de maior privil égio

16.2 Pr ´e-requisitos

16.3 Metodologia

Este tipo de ataque concentra-se em verificar como o esquema de autorizaç ão foi implemen-tado para cada funç ão, os privil égios para se ter acesso a funç ões reservadas e recursos para os quais determinadas credenciais n ão possuem a autorizaç ão necess ária.

16.4 Execuc¸ ˜ao

Para este teste ´e necess ´ario responder basicamente cinco perguntas (aqui respondidas de acordo com o sistema e-SAJ):

• É poss´ıvel acessar determinados recuros do sistema sem estar autenticado? N ão. Foram realizados v ários testes nesse ataque e no ataque OWASP-AT-007. • É poss´ıvel acessar alguns recursos ap ós o log-out?

N ão. Foram realizados v ários testes nesse ataque e no ataque OWASP-AT-007. • É poss´ıvel acessar funç ões e recursos autorizados apenas para alguns determinados

pa-peis?

N ão. Foram realizados in úmeros testes manuais. Foram testados, inclusive, a ediç ão de requisiç ões interceptadas com aux´ılio da ferramenta WebScarab. Todas as tentativas foram sem sucesso.

(51)

Cap´ıtulo 16. Testing for Bypassing Authorization Schema (OWASP-AZ-002)

• É poss´ıvel acessar as funç ões administrativas tamb ém se o testador é registrado como um usu ário com privil égios padr ão?

N ˜ao. Pelos mesmos motivos supracitados.

• É poss´ıvel usar estas funcionalidades para um usu ário com um papel diferente e para quem a aç ão deve ser negada?

(52)

Cap´ıtulo 17. Testing for Privilege escalation (OWASP-AZ-003)

17 Testing for Privilege escalation

(OWASP-AZ-003)

17.1 Objetivos

• Sobrepujar o esquema de autorizaç ão, tentando-se acessar ar éas restritas ou de maior privil égio

17.2 Objetivos

• Contornar permiss ˜oes de acesso a arquivo e diret ´orios

17.3 Pr ´e-requisitos

17.4 Metodologia

Ataques desta natureza ocorrem quando um usu ário tem acesso a mais recursos ou fun-cionalidades que s ão normalmente permitidos. Isso geralmente é causado por uma falha na aplicaç ão. O resultado é que o usu ário pode executar aç ões com mais privil égios do que as que realmente poderiam ser acessadas por ele.

Portanto, a metodologia deste ataque é estudar como funciona o esquema de autorizaç ão implementado nesse sistema e aproveitar-se de tal para conseguir acessar recursos n ão permi-dos.

17.5 Execuc¸ ˜ao

A execuç ão deste teste depende das caracter´ısticas do esquema de autorizaç ão da aplicaç ão Web sendo testada. Para efeito do sistema e-SAJ, aplicou-se a metodologia, acima descrita, da seguinte maneira:

• Inicialmente, buscou-se mapear como comportam-se as requisiç ões, interceptadas por in-term édio do software WebScarab, quando usu ários autorizados e n ão autorizados tentam acessar determinadas funcionalidades. Concentrou-se na funcionalidade de “Push”, pois somente o usu ário advogado tem acesso a ela.

(53)

Cap´ıtulo 17. Testing for Privilege escalation (OWASP-AZ-003)

• Depois, foram verificadas as requisiç ões interceptadas quando o usu ário autenticado era um advogado. Posteriormente, procedeu-se o mesmo quando o usu ário era um promotor. • Como n ão foi poss´ıvel edit á-las para acessar a funç ão “Push” com um usu ário de promotor,

a pr óxima tentativa, ent ão, foi copiar uma requisiç ão e uma resposta quando a funcional-idade era acessada com sucesso e colar quando a tentativa era advinda de um usu ário promotor. Tamb ém n ão obteve-se sucesso. Portanto, concluiu-se que o sistema n ão est á suscet´ıvel ao escalonamento.

(54)

Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)

18 Testing for SQL Injection

(OWASP-DV-005)

18.1 Objetivos

• Executar comandos SQL maliciosos nos pontos de entrada enumerados • Explorar informaç ões sens´ıveis alcanç áveis pela injeç ão

18.2 Pr ´e-requisitos

• Ferramentas de automatizaç ão de injeç ão (SQLmap, SqlDumper, etc)

18.3 Metodologia

Ataques de injeç ão de SQL s ão classificados em tr ês categorias, de acordo com o procedi-mento utilizado na injeç ão e o comportaprocedi-mento exibido diante desta. Dessa forma, tem-se:

• Inband: o dado solicitado pelo atacante é retornado pelo mesmo canal de injeç ão de c ódigo. Para o caso de uma aplicaç ão Web, o resultado é exibido na pr ópria p ágina de reposta da aplicaç ão;

• Out-of-band: o dado requerido ´e devolvido por vias indiretas, alternativas, como, por ex-emplo, para o e-mail do atacante;

• Inferential: n ão remete h á uma transfer ência de dados, ou seja, a informaç ão desejada é obtida, ou reconstruida, com base em padr ões de infer ências sobre as consultas efetuadas no banco de dados.

Conhecidas essas categorias, passamos, agora, a nos importar com a caracter´ıstica de re-torno de consulta oferecida pela aplicaç ão. Um aplicaç ão Web pode, quando de uma consulta de sintaxe errada, retornar ingenuamente o erro do pr óprio SGDB (fornecendo detalhes importantes e facilitadores ao atacante) ou, ao contr ário, apresentar uma p ágina de erro gen érica, sobre a qual pouca, ou nenhuma, informaç ão pode ser explicitamente determinada. Para o segundo caso, de ocultaç ão de erro diante de uma consulta, cabe ao testador inferir acerca dos padr ões estruturais das querys e dos resultados l ógicos provenientes das mesmas; este último caso é comumente conhecido como Blind Injection.

(55)

Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)

A principal condiç ão para injeç ão de c ódigo SQL é a n ão filtragem de par âmetros que t êm como origem o usu ário. Seja em consultas, ou mesmo em formul ários de autenticaç ão, se preenchida essa condiç ão, torna-se poss´ıvel testar variaç ões de querys e, de acordo com elas, observar o comportamento da aplicaç ão. Por conseguinte, a constataç ão da injeç ão de SQL pode ser trabalhada manualmente, atentando-se a todas as consultas e par âmetros envolvidos nas mesmas no contexto da aplicaç ão, ou automaticamente – abordagem tradicionalmente empre-gada em situaç ões de Blind Injection, cujo esforço, em termos de n úmero de querys necess árias, é muito alto.

18.4 Execuc¸ ˜ao

Para o teste nesta seç ão tratado, o primeiro passo é elencar os pontos de poss´ıvel injeç ão de c ódigo. No caso do sistema e-SAJ, s ão fontes de dados de interesse do testador os formul ários de autenticaç ão e de consulta de processos ou petiç ões. Cabe, aqui, ser ressaltada a import ância em se verificar formul ário por formul ário, campo por campo. Isso é necess ário porque uma única vari ável n ão filtrada pode representar o comprometimento de toda a infraestrutura existente em torno da aplicaç ão Web.

Na figura 18.1, ilustra-se um tentativa de anexar conte údo SQL à cla úsula de busca, objetivando-se, com isso, averiguar um eventual processamento dessa query pelo SGBD. O sucesso dessa aç ão depende da filtragem ou n ão existente na aplicaç ão. Como pode-se perceber, o sistema e-SAJ exibe uma mensagem de erro personalizada quando o termo de busca cont ém dados n ão correspodentes aos que est ão armazenados no banco, ou, adicionalmente, quando s ão anex-ados comandos SQL ao termo de busca. Note-se a diferença de resultanex-ados entre as buscas realizadas em 18.1 e 18.2.

O insucesso de execuç ão, em um determinado formul ário, de comandos SQL n ão implica na inexist ência de pontos de injeç ão em outros lugares da aplicaç ão. Mesmo diante de uma p ágina de erro personalizada, comportamento apresentado pelo e-SAJ, ainda pode ser poss´ıvel inferir logicamente sobre o processamento das consultas. Essa infer ência, levada a cabo usando como vetor uma vari ável n ão filtrada, remete a uma modalidade mais sofisticada de injeç ão de SQL: Blind Injection. Para testar diversas categorias de ataque de injeç ão SQL, recomanda-se o uso de ferramentas como o SQLmap. Vide figura 18.3.

(56)

Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)

Figura 18.1: Tentativa de injeç ão de comando SQL em formul ário de consulta do e-SAJ

(57)

Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)

Figura 18.3: SQLmap testando injeç ão de SQL em vari áveis da URL de consulta processual do e-SAJ