Blog de acompanhamento ao projecto de 3º ano de NTC, no ano lectivo de 2010/2011.
09
Jun 11


Começamos por relembrar os parâmetros de segurança que o grupo se comprometeu a testar, delineados no post Módulo 6 - testes:

  1. Copiar urls internos sem login para tentar aceder às páginas;
  2. Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas;
  3. Colocar valores inválidos nos campos de input e analisar a resposta do sistema;
  4. Tentar aceder directamente a ficheiros e directórios;
  5. Testar Captcha, submissões em massa;
  6. Manter registos de tentativas falhadas;
  7. Verificar encriptação na base de dados de palavras-chave. Tentar assegurar existência de salt;
Vamos passar a apresentar os resultados dos testes, assim como soluções que as problemáticas apresentadas nos levaram, entretanto, a implementar, de forma a aumentar a segurança no site.

1. Copiar urls internos sem login

Felizmente, o Drupal permite configurar o acesso quer a páginas quer a funcionalidades (base ou providencias por módulos) mediante o tipo de utilizador. Neste caso, os utilizadores do nosso site dividem-se em 3 tipos:
  • Utilizador anónimo/não registado
  • Utilizador autenticado/registado
  • Administrador

Sendo que o utilizador anónimo apenas tem acesso à página inicial, à ferramenta de criação e aos nós do tipo imagem, blog e fórum, embora possa apenas visualizar o conteúdo destes. A notar que na versão final haverão imagens de destaque na página inicial a que o utilizador anónimo poderá aceder. Quando às páginas de blog e de fórum, o acesso a elas será bloqueado na apenas na versão final, não se tratando no entanto de uma falha de segurança de grande gravidade.

 


2. Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas

Assim como no ponto 1, o acesso a certas funcionalidades e áreas exclusivas está limitado, tanto pelo tipo de utilizador como pela autoria e relação entre o utilizador com sessão iniciada e a página a ser visualizada. Assim, a título de exemplo, só o utilizador a que a página de perfil pertença tem acesso ao botão de edição de perfil no mesmo. Da mesma maneira, é impossível aceder à página principal de qualquer utilizador que não seja o que tem a sessão iniciada, já que o contéudo dessa é determinado pelo utilizador que tem a sessão iniciada.

 


3. Colocar valores inválidos nos campos de input e analisar a resposta do sistema

Este era, à partida, o ponto onde poderiam existir mais problemas. Isto devido à integração do Drupal com a ferramenta de edição e, mais especificamente, aos formulários aí presentes que poderiam não funcionar, em termos de verificação dos seus dados, ao mesmo nível de segurança dos formulários do Drupal.

Assim, testou-se a submissão de código HTML, PHP e JavaScript, tanto no formulário de login, registo e de gravação de imagem. Em todos os casos, todo o código é passada como texto simples, não havendo a hipótese de injecção de código através deste método. O mesmo acontece nos formulários nativos do Drupal.

Exemplo de tentativa de injecção de código HTML, PHP e JS.
 


4. Tentar aceder directamente a ficheiros e directórios

O acesso a directórios é impossível (o servidor retorna sempre um erro 403 - falta de permissões). Quanto a ficheiros, é possível a um utilizador que tenha conhecimento da estrutura de directórios e dos nomes dos ficheiros aceder aos mesmos, nomeadamente a todas as imagens e ficheiros svg gerados pelo editor. Contudo, há que notar que esses ficheiros são gravados com o formato nome dado à imagem pelo utilizador + timestamp unix (número único; Ex: 1306854392) + extensão do ficheiro. Assim, a menos que o utilizador tenha tido acesso ao nome do ficheiro (dentro de uma sessão iniciada, por exemplo), ser-lhe-há extremamente difícil de ganhar acesso aos ficheiros directamente. Mais, mesmo que consiga ter assim acesso aos ficheiros, não ganha com isso mais do que ganharia se fosse um utilizador registado, já que esses podem fazer download desses ficheiros de forma livre. Quando às permissões de escrita do servidor, só se encontram ligadas onde tal é necessário para o funcionamento da aplicação, como na pasta de ficheiros.

 


5. Testar Captcha, submissões em massa
 
(Devido a constrangimentos de tempo e de horários, não se pode testar a submissão em massa de conteudos.)

Convém notar neste ponto uma mudança importante, relativa à aplicação testada relativamente à usabilidade. O módulo usado nesses testes, captcha, foi abandonada, assim como o foi o método de captcha através de perguntas matemáticas. No seu lugar, foi adoptado o serviço anti-spam Mollom, que oferece mais opções a nível de segurança, como por exemplo:

  • Verificação automática do contéudo submetido (se for considerado spam, o contéudo é automaticamente recusado. Caso o contéudo não seja obviamente spam nem contéudo genuíno, é pedido o preenchimento de um captcha);
  • Personalização do tipo de verificação por formulário de submissão (permite que alguns formulários sejam controlados por captcha e outros pela análise de contéudo);
  • Mais informação sobre o serviço pode ser consultada aqui.
Utilizando o modo de teste do módulo (que permite testar o comportamento do mesmo mediante vários tipos de contéudo), a performance deste encontrou-se dentro do “publicitado”.
 
 

6. Manter registos de tentativas falhadas

A resolução deste ponto esteve implementada desde a instalação inicial do CMS, já que este contém de raiz uma série de tabelas que registam todos os eventos no sistema, incluindo tentativas de acesso inválidas e, integrado com o módulo Mollom já mencionado, estatísticas relativas a tentativas de spam bloqueadas.


 Excerto da página de registos.

 

7. Verificar encriptação na base de dados de palavras-chave. Tentar assegurar existência de salt

Para garantir a encriptação das palavras-chave e apesar do Drupal já realizar uma encriptação MD5, foi instalado o módulo Secure Password Hashes, que utiliza a framework Portable PHP password hashing para passar as palavras-chave gravadas por múltiplas rondas de hashing e salting.
 
 
Em adição a todos esses parâmetros, o site foi passado por duas ferramentas de testes de segurança de sites: Websecurify e Acunetix Web Vulnerability Scanner. Ambos passam o site por uma bateria de testes de segurança, incluindo:
  • Injecção SQL;
  • Local and Remote File Include;
  • Cross-site scripting;
  • Cross-site Request forgery;
  • Session Security;
  • Analizador de scripts (segurança de AJAX e aplicações Web 2.0);
  • Teste de ferramentas de penetração;
Os resultados de ambos foram bastante positivos. O Websecurify encontrou 59 erros, mas nenhum considerado grave. Os erros encontrados foram relativos a emails presentes dentro de ficheiros de script (informação relativa aos autores do script geralmente incluída no início do ficheiro, comentada) e a funcionalidade activa de auto-complete nos formulários de login e registo. O relatório completo pode ser consultado, em formato PDF, no link disponibilizado no fim do post. O Acutinex só revelou 4 erros e todos relativos a vulnerabilidades no servidor MySQL.

Convem mencionar, por último, que foi também implementado um módulo que permite controlar de forma mais exacta as sessões,Persistent Login, que implementa a opção “remember me” aquando do login que cria um cookie que controla a sessão para o utilizador. Se essa opção não for seleccionada, a sessão do utilizador é terminada aquando do fecho do browser.

Links:
Relatório de segurança do Websecurify
Relatório de segurança Acutinex (screenshot da aplicação)

 


Junho 2011
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2
3
4

5
6
7
8
9
10
11

12
13
14
15
16
17
18

19
20
21
22
23
24
25

26
27
28
29
30


arquivos
pesquisar blog
 
blogs SAPO