Requisitos para Realização dos Testes de Segurança

     Antes de vir o Sistema para realizar os Testes de Segurança, devemos entender algumas coisas, não adianta vir pra testes um sistema que não foi implementado nenhum controle de Segurança, que não foi aplicado nenhum método de desenvolvimento e processo seguro, não adianta você testar uma Aplicação sem analisar esses pontos, porque se algum ponto seu teste falhar, pode ter certeza que a Aplicação esta Vulnerável. Não garanta 100% de segurança nos testes, não caia nesse erro, abaixo segue alguns procedimentos antes de entrar na fase de Teste.

Implementar Controles de Segurança (contra XSS, SQL-Injection etc.).

Realiza o Backup do Banco de Dados.

Desativar o Captia

Abuso de Funcionalidades – Métodos de HTTP Trace e Track devem ser desativados caso não for usado.

Versões de Componentes, Banco de Dados, Servidor Web, não deve constar na camada de apresentação.

Arquivos de Log, Paginas duplicatas, Páginas de Teste, .bak, sav, .old, .txt, etc. devem ser limpas do Builder, caso não seja essencial.

Todas as transmissões de Dados Sigilosos devem conter SSL (Protocolo de Camada de Sockets Segura) e TLS (Segurança da Camada de Transporte).

Não deve conter a listagem de arquivos nas Aplicações.

As referências das solicitações HTTP devem vir somente do domínio.

 O sistema não deve fazer o download ou visualizar o conteúdo de um arquivo de configuração, o que pode conter informações vitais, como nomes de usuários e senhas.

As mensagens de erro de login ou senha devem ser únicas.

O usuário deve ser bloqueado depois de inúmeras tentativas de erro de login e senha.

O sistema deve conter um algoritmo de armazenamento de dados Seguro.

Remover os valores de parâmetro 'codificados permanentemente' no HTML como um parâmetro do tipo 'oculto'.

Não deve colocar o caminho do servidor no código html, scripts, etc.

Código de terceiros, não deve está nome de desenvolvedor, telefone, ou qualquer outro dado de terceiro na camada de aplicação.

Página de administrador, não deve está nos mecanismos de busca da internet.

A aplicação não deve responder a comandos externos.

A Aplicação não deve fazer o upload de código fonte ou qualquer outro script.

As pilhas de tratamentos de erros, não devem aparecer na camada de aplicação, informações de tabelas, procedures, select etc.

A aplicação Web deve ser configurado com cookies de sessão com o atributo HttpOnly.

Usuário de Teste deve está fora da black list, caso tenha um controle de acesso não autorizado.

Pontos de Injeção em Aplicações WEB (Segurança)

Existem 4 Pontos de Injeções em Aplicações WEB (POST, GET, COOKIE, HEAD), nesses quatro pontos pode haver pontos de entrada para meu vetor de Ataque, não se limite de testar somente os campo da Aplicação, senão sua Aplicação após os testes poderá esta vulnerável, no momento que não está sendo testado todos os pontos de entrada. 

—HTTP Query String Parameters (GET): input parameters sent in the URL.

—HTTP Body Parameters (POST): input parameters sent in the HTTP body.

—HTTP Cookie Parameters: input parameters sent in the HTTP cookie.

—HTTP Headers: HTTP request headers used by the application.

Testando em Browsers Antigos

Vai a Dica, muita das vezes é necessário testar uma Aplicação em alguma versão do Browser (Firefox e IE antigo), nos sites oficiais dificilmente encontrará, pesquisando na Internet encontrei um site que disponibiliza várias versões do Browser, segue o Link Abaixo:

http://www.oldapps.com/category/browsers

A Ferramenta IBM Rational AppScan e sua cobertura de Testes

A Ferramenta IBM Rational AppScan tem sua cobertura de testes com base na Web Aplication Security Consortium (WASC), que enumera e classifica as ameaças em Aplicações Web (WASC Threat Classification). A Ameaça pode ser uma fraqueza da Aplicação ou um tipo de Ataque.

A WASC Threat Classification se encontra na versão v2.0, ultima atualização feita em 2010, que descreve os ataques e as fraquezas que podem levar ao comprometimento de uma Aplicação WEB, dos seus dados, ou de seus usuários. Este documento serve principalmente como um guia de referência para cada ataque dado ou fraqueza e fornece exemplos de cada Classificação, bem como material de referência útil. Este documento é utilizado por muitas organizações (http://projects.webappsec.org/w/page/13246978/Threat%20Classification).

A Tabela abaixo classifica as Vulnerabilidades relacionadas com a ISO/IEC 27001, e seus respectivos controles.

Teste	Teste	Teste	Arquitetura e Desenvolvimento	Qualidade
Classificação Nome	Enumeração (WASC-TC-v2_0)	Tipo de Ameaça	Controle/Requisitos ASVS	ISO/IEC 27001 Classificado em Sessões
Abuse of Functionality	WASC-42	Ataque	V4. Access Control
Application Privacy Tests	-	Fraqueza	-	1, 5, 8, 17, 18, 19, 23, 24
Application Quality Tests	-	Fraqueza	-	-
Brute Force	WASC-11	Ataque	V8. Error Handling and Logging V2. Authentication	1, 2, 5, 6, 7, 19, 20, 23, 24
Buffer Overflow	WASC-7	Ataque	V5. Input Validation
Content Spoofing	WASC-12	Ataque		1, 2, 5, 6, 8, 17, 18, 23
Credential/Session Prediction	WASC-18	Ataque
Cross-site Request Forgery	WASC-9	Ataque	V2. Authentication	1, 2, 5, 6, 8, 17, 18, 23
Cross-site Scripting	WASC-8	Ataque	V5. Input Validation, V6. Output Encoding/Escaping	1, 2, 5, 6, 8, 17, 18, 23
Denial of Service	WASC-10	Ataque	V3. Session Management, V4. Access Control
Directory Indexing	WASC-16	Fraqueza	V12. Security Configuration	1,5
Format String	WASC-6	Ataque
HTTP Response Splitting	WASC-25	Ataque		1, 2, 5, 6, 8, 17, 18, 23
Information Leakage	WASC-13	Fraqueza		1, 5, 21, 22, 23
Insecure Indexing	WASC-48	Fraqueza
Insufficient Authentication	WASC-01	Fraqueza	V2. Authentication	1, 2, 3, 5, 6, 8, 10, 11, 12, 13, 16, 17, 18, 19, 23, 24
Insufficient Authorization	WASC-02	Fraqueza
Insufficient Session Expiration	WASC-47	Fraqueza
LDAP Injection	WASC-29	Ataque	V6. Output Encoding/Escaping	1, 5, 8, 17, 18, 21, 23
Null Byte Injection	WASC-28	Ataque		1, 5, 17, 18, 23
OS Commanding	WASC-31	Ataque	V5. Input Validation, V6. Output Encoding/Escaping	1, 2, 5, 8, 17, 18, 23
Path Traversal	WASC-33	Ataque	V5. Input Validation V6. Output Encoding/Escaping	1, 5, 17, 18, 23
Predictable Resource Location	WASC-34	Ataque		1, 5, 21, 22
Remote File Inclusion	WASC-05	Ataque	V5. Input Validation, V12. Security Configuration	1, 2, 8, 17, 18, 23
Session Fixation	WASC-37	Ataque		1, 2, 5, 6, 9, 11, 12, 13, 16, 19, 23, 24
SOAP Array Abuse	WASC-35	Ataque
SQL Injection	WASC-19	Ataque	V5. Input Validation, V6. Output Encoding/Escaping	1, 5, 8, 17, 18, 21, 23
SSI Injection	WASC-36	Ataque		1, 5, 8, 17, 18, 21, 23
URl Redirector Abuse	WASC-38	Ataque		-
XML Attribute Blowup	WASC-41	Ataque
XML Entity Expansion	WASC-44	Ataque
XML External Entities	WASC-43	Ataque
XPath Injection	WASC-39	Ataque		1, 5, 8, 17, 18, 21, 23

IBM AppScan e a ISO 27001

A Ferramenta IBM Rational AppScan classifica a ISO 27001 por Sessões em seu relatório, sendo 24 sessões ao todo, posteriormente classifica as vulnerabilidades em uma ou mais sessões. Veremos abaixo as sessões que o AppScan cobre de acordo com a ISO 27001.

Seção - 01

A.6.2.1 Identificação dos riscos relacionados com partes externas

Controle

Os riscos para os recursos de processamento da informação e para a informação da organização oriundos de processos do negócio que envolvam as partes externas devem ser identificados e controles apropriados devem ser implementados antes de se conceder o acesso.

Seção - 02

A.6.2.2 Identificando a segurança da informação quando tratando com os clientes.

Controle

Todos os requisitos de segurança da informação identificados devem ser considerados antes de conceder aos clientes o acesso aos ativos ou às informações da organização.

Seção - 03

A.8.3.3 Retirada de direitos de acesso

Controle

Os direitos de acesso de todos os funcionários, fornecedores e terceiros às informações e aos recursos de processamento da informação devem ser retirados após o encerramento de suas atividades, contratos ou acordos, ou devem ser ajustados após a mudança destas atividades.

Seção - 04

A.10.3.1 Gestão de capacidade

Controle

A utilização dos recursos deve ser monitorada e sincronizada e as projeções devem ser feitas para necessidades de capacidade futura, para garantir o desempenho requerido do sistema.

Seção - 05

A.10.8.1 Políticas e procedimentos para troca de informações

Controle

Políticas, procedimentos e controles devem ser estabelecidos e formalizados para proteger a troca de informações em todos os tipos de recursos de comunicação.

Seção - 06

A.10.9.1 Comércio eletrônico

Controle

As informações envolvidas em comércio eletrônico transitando sobre redes públicas devem ser protegidas de atividades fraudulentas, disputas contratuais, divulgação e modificações não autorizadas.

Seção - 07

A.10.9.2 Transações on-line

Controle

Informações envolvidas em transações on-line devem ser protegidas para prevenir transmissões incompletas, erros de roteamento, alterações não autorizadas de mensagens, divulgação não autorizada, duplicação ou reapresentação de mensagem não autorizada.

Seção - 08

10.9.3 Informações publicamente disponíveis

Controle

A integridade das informações disponibilizadas em sistemas publicamente acessíveis deve ser protegida, para prevenir modificações não autorizadas.

Seção - 09

A.11.2.2 Gerenciamento de privilégios

Controle

A concessão e o uso de privilégios devem ser restritos e controlados.

Seção - 10

A.11.2.3 Gerenciamento de senha do usuário

Controle

A concessão de senhas deve ser controlada por meio de um processo de gerenciamento formal.

Seção - 11

A.11.2.4 Análise crítica dos direitos de acesso de usuário

Controle

O gestor deve conduzir a intervalos regulares a análise crítica dos direitos de acesso dos usuários, por meio de um processo formal.

Seção - 12

A.11.4.2 Autenticação para conexão externa do usuário

 Controle

Métodos apropriados de autenticação devem ser usados para controlar o acesso de usuários remotos.

Seção - 13

A.11.5.2 Identificação e autenticação de usuário

Controle

Todos os usuários devem ter um identificador único (ID de usuário), para uso pessoal e exclusivo, e uma técnica adequada de autenticação deve ser escolhida para validar a identidade alegada por um usuário.

Seção - 14

A.11.5.5 Desconexão de terminal por inatividade

Controle

Terminais inativos(Inactive sessions) devem ser desconectados após um período definido de inatividade.

Seção - 15

A.11.5.6 Limitação de horário de conexão

Controle

Restrições nos horários de conexão (Tempo de Conexão) devem ser utilizadas para proporcionar segurança adicional para aplicações de alto risco.

Seção - 16

A.11.6.1 Restrição de acesso à informação

Controle

O acesso à informação e às funções dos sistemas de aplicações por usuários e pessoal de suporte deve ser restrito de acordo com o definido na política de controle de acesso.

Seção - 17

A.12.2.1 Validação dos dados de entrada

Controle

Os dados de entrada de aplicações devem ser validados para garantir que são corretos e apropriados.

Seção - 18

A.12.2.2 Controle do processamento interno

 Controle

Devem ser incorporadas, nas aplicações, checagens de validação com o objetivo de detectar qualquer corrupção de informações, por erros ou por ações deliberadas.

Seção - 19

A.12.2.3 Integridade de mensagens

Controle

Requisitos para garantir a autenticidade e proteger a integridade das mensagens em aplicações devem ser identificados e os controles apropriados devem ser identificados e implementados.

Seção - 20

A.12.3.1 Política para o uso de controles criptográficos

Controle

Deve ser desenvolvida e implementada uma política para o uso de controles criptográficos para a proteção da informação.

Seção - 21

A.12.4.3 Controle de acesso ao código- fonte de programa

Controle

O acesso ao código-fonte de programa deve ser restrito.

Seção - 22

A.12.5.4 Vazamento de informações

Controle

Oportunidades para vazamento de informações devem ser prevenidas.

Seção - 23

A.15.1.3 Proteção de registros organizacionais

Controle

Registros importantes devem ser protegidos contra perda, destruição e falsificação, de acordo com os requisitos regulamentares, estatutários, contratuais e do negócio.

Seção - 24

A.15.1.4 Proteção de dados e privacidade da informação pessoal

Controle

A privacidade e a proteção de dados devem ser asseguradas conforme exigido nas legislações relevantes, regulamentações e, se aplicável, nas cláusulas contratuais.