-Ciclo de Desenvolvimento de software seguro-

Um software seguro aquele que satisfaz os requisitos implcitos e explcitos de

segurana
em condies normais de operao e em situaes decorrentes de atividade maliciosa
de usurios. Para isso, deve resultar de um ciclo de desenvolvimento que considere
aspectos de segurana em todas as suas fases (McGraw, 2006; Kissel et al., 2008):

1 Na etapa de especificao, requisitos explcitos de segurana devem ser

enumerados
e requisitos funcionais devem ser avaliados para verificar se no introduzem uma
vulnerabilidade no sistema.
2 Atividades comumente realizadas na fase seguinte, a de projeto, incluem o
mapeamento
do modelo de dados para estruturas lgicas e fsicas, a definio de padres
de interface a serem utilizados, a escolha de elementos de hardware e software que
faro parte da soluo e o desenho da topologia a ser adotada.
3 Para minimizar vulnerabilidades de codificao, os desenvolvedores devem ser
treinados
em tcnicas gerais de programao segura e nas especificidades das linguagens
com as quais trabalham.
4 Testes de segurana so fundamentalmente diferentes de testes funcionais e, por
isso, devem ser feitos por profissionais especializados.
5 Por fim, e no menos importantes, encontram-se a implantao do sistema no
ambiente de produo e a manuteno.

-Metodologia de teste de invaso-

O trabalho propriamente dito comea com a fase de reconhecimento, cujo objetivo

levantar qualquer tipo de informao que possa auxiliar no teste de invaso.
Assim, nesta etapa, o auditor busca identificar, por exemplo, servidores que
suportam a
aplicao, sistemas operacionais instalados, linguagens de programao empregadas,
nomes
de potenciais usurios do sistema, regras de formao de identificadores de
usurio, configuraes
de softwares, conveno utilizada na atribuio de nomes de mquinas, dentre muitas
outras informaes. Todo esse levantamento realizado de diversas maneiras,
incluindo
testes no prprio ambiente, testes indiretos e pesquisa em fontes de informao
externas. q O prximo passo, o de mapeamento, consiste em relacionar tudo que foi
coletado na etapa
anterior e criar um mapa da aplicao, que reflita a estruturao dos arquivos
componentes,
as funcionalidades ofertadas, os pontos de entrada de informao e as tecnologias
utilizadas.

1 Levantamento de informaes culminam na revelao de informaes relevantes a

um atacante. Exemplo: exibio de comando SQL ao usurio, devido a erro causado por
sintaxe incorreta.
2 Gerenciamento de configurao parmetros definidos de maneira insegura em
qualquer das plataformas que compem a aplicao permitem subverter mecanismos de
segurana ou obter acesso direto infraestrutura subjacente. Exemplo: servidor
SSL/TLS
que aceita cifras nulas na proteo do canal.
3 Autenticao fraquezas que permitem que um atacante seja reconhecido como um
usurio legtimo do sistema, sem conhecimento prvio da senha. Exemplo: tela de
autenticao
vulnervel injeo de SQL.
4 Gerenciamento de sesses tem origem no tratamento inseguro dos identificadores
de sesso em algum ponto do ciclo de vida deles, resultando em acesso no
autorizado
a funcionalidades e informaes. Exemplo: uso de nmeros sequenciais para
identificadores
de sesso.
5 Autorizao vulnerabilidades que possibilitam que algum sem os devidos
privilgios
realize uma operao ou acesse uma informao. Exemplo: sistema que desabilita
itens
de menu de acordo com verificao inicial de privilgios, mas que no valida as
requisies,
quando realizadas.
6 Lgica de negcios erros na implementao das regras de negcio fornecem um
caminho para que elas no sejam honradas por usurios maliciosos. Exemplo: loja de
comrcio eletrnico que no verifica se o preo de um produto negativo.
7 Validao de dados esta classe engloba os problemas decorrentes do uso de
informaes
fornecidas por usurios, sem as validaes necessrias, e pode acarretar desde
o vazamento de informaes at o comprometimento de outros usurios do ambiente.
Exemplo: informao usada diretamente na construo de uma consulta SQL,
permitindo
a injeo de comandos arbitrrios.
8 Negao de servio falhas que podem ser usadas para impedir o uso da aplicao,
normalmente, pela exausto de recursos. Exemplo: sistema que no verifica memria
disponvel antes de realizar alocao dinmica.
9 Web services e AJAX de modo geral, so afetados por variaes das
vulnerabilidades
tradicionais, com algumas peculiaridades de cada tecnologia. Exemplo: web service
que
no valida se a mensagem bem formada, antes de process-la.

Contramedidas

Para evitar que uma aplicao padea de vulnerabilidades relacionadas a controles

implementados no lado cliente, as seguintes melhores prticas devem ser observadas:
1 Parta da premissa de que todos os usurios da aplicao so maliciosos e, por
isso,
toda informao fornecida por eles deve ser validada no servidor, imediatamente
antes de ser utilizada.
2 No assuma que informaes armazenadas em campos escondidos no podem ser
alterados por um usurio, uma vez que no esto visveis.
3 Implemente controles no lado cliente da aplicao, apenas para evitar que um
usurio bem intencionado submeta, por erro, formulrios com campos inconsistentes
e consuma banda de rede desnecessariamente.
4 Nunca espere que todos os parmetros previstos sejam recebidos como parte
da requisio. Usurios maliciosos podem remover um ou mais itens, antes de
submet-la aplicao.