Escolar Documentos
Profissional Documentos
Cultura Documentos
1 Introdução.................................................................................................................................... 4
1.1 Princípios de segurança........................................................................................................... 7
1.2 Visão geral do ciclo de desenvolvimento seguro......................................................................8
1.2.1 Requisitos.............................................................................................................................. 8
1.2.2 Análise e Projeto.................................................................................................................... 9
1.2.3 Implementação...................................................................................................................... 9
1.2.4 Testes................................................................................................................................... 10
1.2.5 Implantação......................................................................................................................... 10
1.3 OWASP.................................................................................................................................. 10
2 Requisitos de Segurança de Software......................................................................................12
2.1 Engenharia de requisitos segura............................................................................................13
2.2 Categorização de segurança..................................................................................................14
2.2.1 Categorização dos tipos de informação..............................................................................15
2.2.2 Categorização do sistema...................................................................................................16
2.3 Classificação da informação...................................................................................................17
2.4 Especificação de requisitos de segurança.............................................................................18
2.5 Casos de Abuso...................................................................................................................... 19
3 Arquitetura Segura de Software.................................................................................................21
3.1 Frameworks de segurança.....................................................................................................22
3.2 Princípios de arquitetura segura.............................................................................................23
3.3 Análise da Superfície de Ataque.............................................................................................24
3.4 Modelagem de Ameaças........................................................................................................ 25
3.5 Arquitetura Segura.................................................................................................................. 27
4 Implementação segura de software...........................................................................................31
4.1 Erros comuns no desenvolvimento de software.....................................................................31
4.2 Vulnerabilidades das aplicações web.....................................................................................33
4.2.1 Injeção de código.................................................................................................................34
4.2.2 Cross site scripting............................................................................................................... 36
4.2.3 Buffer overflow..................................................................................................................... 39
4.2.4 Falha na autenticação e no gerenciamento de sessões.....................................................40
4.2.5 Referência Insegura a Objetos............................................................................................41
4.2.6 Cross site request forgery....................................................................................................42
4.2.7 Segurança configurada incorretamente...............................................................................43
4.2.8 Criptografia insegura...........................................................................................................43
4.2.9 Falha na Restrição de Acesso a URL..................................................................................44
4.2.10 Encaminhamentos e Redirecionamentos não validados...................................................44
4.2 Validação de estradas............................................................................................................. 45
5 Testes de Segurança................................................................................................................. 47
5.1 Testes de software.................................................................................................................. 47
5.2 Metologias de Teste de Segurança.........................................................................................48
5.2.1 Caixa Branca....................................................................................................................... 48
5.2.2 Caixa Preta.......................................................................................................................... 49
5.2.3 Diferenças entre caixa branca e caixa preta.......................................................................50
5.2.4 Fuzzing................................................................................................................................ 50
5.2.5 Escaneamento de vulnerabilidades e testes de Invasão.....................................................51
5.3 Testes de Segurança em software..........................................................................................51
5.3.1 Mecanismo de validação de entradas.................................................................................51
5.3.2 Teste de defesa para injeção de código..............................................................................52
5.3.3 Teste de defesa para o não repúdio....................................................................................53
5.3.4 Teste de defesa para o Spoofing.........................................................................................53
5.3.5 Teste de falha de software...................................................................................................53
5.3.6 Teste de validação do mecanismo de criptografia...............................................................53
5.3.7 Teste de defesa para Buffer Overflow.................................................................................54
5.3.8 Teste de defesa para escalonamento de privilégios...........................................................54
5.4 Documentação de vulnerabilidades e Rastreabilidade...........................................................54
1 Introdução
Com as facilidades da internet e o aumento da confiança em redes IP para comércio eletrônico e
telecomunicação, os projetistas de sistemas em software hoje devem estar atentos não somente aos usuários,
mas também aos adversários. Desde 1999, com a criação do Grupo de Resposta a Ataques (GRA) no
SERPRO, os incidentes de segurança em rede têm recebido um tratamento de acordo com referências
nacionais e internacionais (CERT.Br, CERT/Coordination Center, AusCERT). No entanto, devido à mudança na
anatomia dos ataques, agora explorando intensamente vulnerabilidades das aplicações, ações para construir
sistemas mais seguros devem estar integradas ao ciclo de desenvolvimento de software, em especial na
engenharia de requisitos, na análise e projeto, na implementação, nos testes e na implantação do sistema.
Os desafios de desenvolver software atendendo aos requisitos básicos de segurança
(confidencialidade, integridade e disponibilidade), somados aos problemas que comumente estão presentes na
produção de software de qualidade, requerem que as partes interessadas do sistema sejam treinadas e
conscientizadas de suas responsabilidades.
Diversas referências apontam que a maior parte das vulnerabilidades ocorrem na camada de
aplicação:
"75% dos novos ataques têm como foco a aplicação" - Gartner Group
"92% das vulnerabilidades estão na aplicação" - NIST
Figura 1.1
A figura 1.2 mostra o conceito de segurança em camadas. Este princípio defende a ideia de que a
segurança não é uma única solução, mas sim uma gama de controles que devem ser aplicados em várias
camadas.
Figura 1.2
A figura descreve a proteção relativa aos Sistemas Operacionais, que vão desde as permissões de
acesso aos arquivos até a instalação e execução de programas. A parte que envolve a camada de rede
(tomando como base as camadas 1 a 4 do modelo OSI) possui diversos mecanismos de proteção que
poderiam ser estudados em um curso específico de segurança em redes. Esses mecanismos vão desde ACLs
(Access Control List) até a detecção e prevenção de intrusão. Na criação de um banco de dados também
precisamos aplicar mecanismos de controle, como a configuração adequada do SGBD e controle dos
privilégios (GRANTS) de acesso. Assim como o servidor de aplicação deve ser devidamente configurado para
evitar certos tipos de ataques, como é o caso dos ataques que realizam acesso direto a recursos do servidor.
Figura 1.3
Por outro lado, a linha azul representa a sofisticação do ataque que vem aumentando ao longo do
tempo. Quanto mais sofisticados são os ataques, maior é o impacto negativo causado nas organizações.
Portanto, esta pesquisa mostra que há alguns anos atrás um agente malicioso precisava possuir um
conhecimento muito maior para realizar ataques pouco sofisticados, ao contrário do que ocorre hoje, onde é
necessário ter muito menos conhecimento da tecnologia para realizar ataques sofisticados.
Uma falsa sensação de segurança é alimentada por afirmativas erradas (ou mitos ) relacionadas à
segurança de aplicações. As pessoas que não possuem um conhecimento técnico sobre os controles de
segurança podem se iludir e acreditar que suas aplicações estão seguras.
O primeiro mito é que colocar firewalls protegendo o servidor garantirá a segurança da aplicação.
Tipicamente o firewall atua até a camada de transporte, ou seja, é capaz de aplicar regras com base nos
protocolos desta camada e das que estão abaixo dela: MAC, ARP, RARP, IP, ICMP, IGMP, TCP, UDP e suas
Figura 1.4
Um documento elaborado pela Watsonhall1 mostra os 10 maiores mitos em relação a segurança de
páginas web. São eles:
1. Os desenvolvedores irão lidar com as questões de segurança;
2. Ninguém está interessado em atacar nosso site;
3. Estamos seguros porque utilizamos SSL;
4. Nós não usamos produtos Microsoft, por isso estamos seguros;
5. Estamos seguros porque temos um firewall;
6. Nós temos um backup, não há o que se preocupar;
7. Nossos dados estão criptografados;
8. Tudo que você precisa é de um teste de penetração anual;
9. Nossos usuários possuem desktops totalmente atualizados;
10. Temos um acordo de nível de serviço (SLA) com a nossa empresa de hospedagem.
O intuito desse treinamento é justamente mostrar que a segurança deve ser incorporada no ciclo de
desenvolvimento de software e quebrar esses mitos!
1 https://www.watsonhall.com/methodology/top10-website-security-myths.pl
Confidencialidade
Propriedade de que a informação não será disponibilizada ou divulgada a indivíduos, entidades ou
processos não autorizados. Consiste na proteção dos dados contra divulgação não autorizada.
A confidencialidade de sistemas de informação está relacionada às áreas de propriedade intelectual,
covert channels1, análise de tráfego e criptografia.
A propriedade intelectual se refere às invenções, trabalhos literários e outros, que são protegidos por
uma lei de copyright e por patentes.
A análise de tráfego é uma quebra da confidencialidade que pode ser realizada pela análise do
volume, taxa, fonte e destino das mensagens, mesmo que estejam criptografadas. O aumento do tráfego em
uma determinada parte da rede pode indicar que um evento importante está ocorrendo.
A criptografia envolve o ciframento da mensagem para que esta não possa ser lida por uma entidade
não autorizada. O atacante pode ter o conhecimento do algoritmo, mas se não conhecer a chave,
teoricamente não conseguirá reverter a operação de criptografia. Um algoritmo de criptografia
computacionalmente seguro é aquele em que o tempo de quebra é maior que o tempo de vida útil da
informação e o custo para quebrar é maior que o valor da informação.
Integridade
Propriedade de salvaguarda da exatidão e completeza de ativos. É a garantia de que os dados
recebidos estão exatamente como foram enviados por uma entidade autorizada. Significa que não houve
modificação, inserção, exclusão nem repetição da informação, ou seja, os dados se mantêm consistentes.
Disponibilidade
Propriedade de um sistema ou de um recurso do sistema ser acessível e utilizável sob demanda por
uma entidade autorizada.
Autenticação
A garantia de que a entidade se comunicando é aquela que ela afirma ser. Essa garantia pode ser
fornecida por meio de três maneiras diferentes:
1. por aquilo que a entidade conhece: usuário/senha, por exemplo.
2. por aquilo que a entidade possui: um certificado digital, um cartão, etc.
3. por aquilo que a entidade é: envolve biometria. Por exemplo: reconhecimento facial e impressão
digital.
A autenticação de múltiplos fatores é um processo de autenticação que requer mais de um tipo de
credencial do usuário, por exemplo, combinação de uso de usuário/senha com certificado digital.
Autorização
A autorização se refere aos direitos e privilégios concedidos a um usuário ou processo. Depois que a
autenticação é realizada, a autorização é responsável por habilitar o acesso aos recursos ou ativos de
informação.
Não repúdio
Oferece proteção contra negação, por parte de uma das entidades envolvidas em uma comunicação,
1 Definição de covert channels segundo a iso/IEC 27002: são caminhos não previstos para conduzir fluxo de informações, mas que no entanto
podem existir num sistema ou rede. Por exemplo, a manipulação de bits no protocolo de pacotes de comunicação poderia ser utilizada como
um método oculto de sinalização.
1.2.1 Requisitos
Na macroatividade de Requisitos, o Analista de Requisitos realiza as atividades de Definir Visão,
Analisar Sistema, Especificar Requisitos, Especificar Arquitetura, todas elas voltadas para buscar o
entendimento e a representação da solução que o Cliente deseja com o produto de software.
Quando um levantamento de requisitos é bem feito, poderá aumentar as chances do produto ser
entregue conforme as expectativas que o cliente criou sobre o sistema. Nesta etapa, é fundamental saber
quais informações serão tratadas pelo sistema, bem como fazer uma avaliação de riscos inicial com o objetivo
de verificar as necessidades de controles de segurança para o sistema.
Uma aplicação que lida com dados públicos, em que a indisponibilidade dos dados afeta poucos
usuários, com certeza necessita de menos investimentos em segurança do que uma aplicação que possui
dados críticos ao negócio, onde a indisponibilidade dos dados pode afetar negativamente diversos usuários.
Ter essa ideia no início do projeto é fundamental para se estimar o escopo, tempo e custo das atividades de
segurança. Podemos dividir esta atividade em duas etapas:
1 http://psds.portalcorporativo.serpro/psds/
2 http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
1.2.3 Implementação
Na macroatividade de Implementação, o Implementador executa as atividades Implementar Solução e
Integrar Unidades de Implementação. É nesta macroatividade que os requisitos do Cliente serão realmente
"transformados" em um produto, ou em uma solução funcional.
Testes de invasão
Este tipo de teste submete ataques reais à aplicação e verifica como ela se comporta diante do uso
inesperado do sistema. O objetivo é determinar se um ataque é realmente praticável na aplicação. Pela
característica de execução destes testes, é necessário que haja um ambiente preparado e com infraestrutura
de rede isolada e devidamente configurada. É importante que o Gestor de Negócio seja o solicitante destes
testes, pois ele será capaz de identificar restrições de tempo, horário, ambiente e disponibilidade da aplicação.
1.2.5 Implantação
Na macroatividade de Implantação do sistema, o Gestor de Negócio, Cliente, Desenvolvedor, Gestor
de Infraestrutura, Líder de Projeto e Suporte Operacional são responsáveis por Planejar a Implantação.
Planejar a implantação do produto de software consiste em elaborar o Plano de Implantação que será a base
para a preparação do ambiente e a entrega e/ou disponibilização do produto ao Cliente.
Na implantação da solução, devemos nos preocupar com a configuração segura do servidor. Este
assunto envolve o gerenciamento de patches, hardening do servidor e o gerenciamento de configuração. No
que se refere ao servidor de aplicação, as atividades de segurança incluem o uso de um firewall de aplicações
web (Web Application Firewall ou WAF) e filtros HTTP(S), tais como ModSecurity (para o Apache) e URL Scan
(para o IIS).
1.3 OWASP
Neste curso iremos trabalhar com diversos documentos, conceitos e ferramentas que estão
disponíveis em uma iniciativa aberta para tratar aspectos de segurança de aplicações web, chamada Open
Web Application Security Project (OWASP). Esta associação congrega especialistas de empresas privadas,
órgãos governamentais, instituições acadêmicas e voluntários de todo o mundo. Esta comunidade trabalha na
criação de artigos, metodologias, documentação, ferramentas e tecnologias para aprimorar a segurança das
aplicações web.
Apesar de grandes empresas apoiarem a OWASP, ela não é afiliada a nenhuma delas e é uma
organização independente que se mantém através de eventos, doações e venda de materiais. Este aspecto é
importante, pois afasta as influências e pressões organizacionais e garante que as informações sobre a
segurança de aplicações sejam imparciais, sem preferências por determinado produto ou tecnologia
proprietária. A OWASP pode ser acessada no endereço www.owasp.org .
Existem muitos projetos em andamento na comunidade e qualquer interessado pode contribuir com
eles. Neste curso iremos estudar alguns dos principais projetos da OWASP. Para termos uma visão geral,
abaixo segue uma lista de projetos da OWASP que serão abordados durante o curso:
TOP 10: este documento teve sua primeira versão lançada em 2004 e é atualizado periodicamente a cada 3
anos, sendo a ultima versão a de 2010. O documento faz um levantamento das 10 vulnerabilidades que mais
ocorrem em aplicações web. Para cada uma delas é mostrado como ocorrem e como evitá-las.
WebGoat: é uma aplicação intencionalmente vulnerável que pode ser instalada em uma máquina local para
estudar ou ensinar como os ataques ocorrem em um aplicação real.
Quick Reference, ou Guia de referência rápida: este documento consiste em uma lista de verificação de
controles de segurança, independentes de linguagem de programação. Cada item está relacionado a uma
categoria específica, por exemplo: controle de sessões, autenticação, validação de dados de entrada/saída,
gerenciamento de configuração, etc.
Enterprise Security Application Programming Interface (ESAPI): consiste em uma API que fornece a
especificação das principais funções de segurança que devem ser utilizadas pelo desenvolvedor. Ela possui
versão implementada para as tecnologias JAVA, .NET, PHP, ASP clássico, ColdFusion, Python, Objective C e
Ruby.
Testing Guide, ou Guia de testes: este documento descreve como realizar cada tipo específico de teste para
verificar se os controles de segurança foram implementados na aplicação, bem como a eficácia desses
controles.
Software Assurance Maturity Model (SAMM): este documento pode ser utilizado para avaliar uma
organização quanto à maturidade de seus processos de segurança no desenvolvimento ou para contribuir na
implementação das atividades.
Figura 2.1
Todas essas atividades são essenciais para um ciclo de desenvolvimento. Porém, para garantir que o
sistema a ser construído tenha os controles de segurança necessários à proteção de suas informações,
devemos acrescentar algumas atividades na engenharia de requisitos:
1- categorização de segurança do sistema
2- especificação de requisitos de segurança
3- descrição dos casos de abuso
Figura 2.2
A figura 2.2 inclui mais 3 atividades de segurança para formar a chamada engenharia de requisitos
segura. O grande benefício dessas atividades é antecipar a preocupação com a segurança do sistema.
primeiramente com o entendimento da necessidade de segurança do sistema por meio da
categorização de segurança;
em seguida com a especificação dos requisitos de segurança que deverão ser implementados; e
SISTEMA ESCOLA
Caso de Uso 01: Realizar Inscrição
Sumário: Aluno usa o sistema para realizar inscrição em disciplinas.
Ator Primário: Aluno
Atores Secundários: Sistema de Faturamento
Pré-condições: O Aluno está identificado pelo sistema.
Fluxo Principal
1. O Aluno solicita a realização de inscrição.
2. O sistema apresenta as disciplinas disponíveis para o semestre corrente e que o aluno atende aos pré-
requisitos.
3. O Aluno seleciona as disciplinas desejadas e as submete para inscrição.
4. Para cada disciplina selecionada, o sistema aloca o aluno em uma turma que apresente uma oferta para tal
disciplina.
5. O sistema informa as turmas nas quais o Aluno foi alocado. Para cada alocação, o sistema informa o
professor, os horários e os respectivos locais das aulas de cada disciplina.
6. O Aluno confere as informações fornecidas.
7. O sistema envia os dados sobre a inscrição do aluno para o Módulo de Faturamento e o caso de uso
termina.
1 http://www.nist.gov/
2 http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
Pós-condição: O aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas, ou foi
adicionado a uma ou mais listas de espera.
1) Aluno
A pré-condição do caso de uso indica que o sistema realiza a autenticação dos alunos para que eles
possam solicitar a matrícula. Os dados que são armazenados de cada aluno não estão detalhados, mas com
certeza o sistema possui um registro de todos os alunos. Portanto, o primeiro tipo de informação descrito no
caso de uso são as informações sobre os Alunos.
A confidencialidade dessa informação cresce a medida em que os dados pessoais importantes do
aluno são requeridos pelo sistema. Um sistema que guarda a matrícula do aluno mais o seu nome terá
diferente impacto na confidencialidade do que um sistema que necessita do CPF, número de identidade, título
de eleitor, endereço, telefones e, em alguns casos, a conta bancária. Para dar continuidade ao nosso exemplo,
iremos supor que os dados dos alunos são: matrícula, nome e data de nascimento.
2) Inscrição
A segunda informação tratada pelo sistema é a Inscrição. Esta informação consiste no relacionamento
entre o aluno e as disciplinas que irá cursar no semestre. Podemos notar que o atributo de segurança mais
relevante desta informação é a integridade, pois uma alteração indevida nas inscrições tem um impacto
relevante ao sistema. Devemos garantir que a inscrição do aluno se mantenha consistente, íntegra, para que
no primeiro dia de aula todos consigam se deslocar às salas das disciplinas que se matricularam. Ao passo
que a confidencialidade dessa informação é pouco relevante para o sistema e poderia até mesmo ser
considerada pública.
3) Disciplina
As informações que são apresentadas pelo sistema aos seus usuários também devem ser
classificadas. Percebam que as informações referentes às disciplinas somente são consultadas neste caso de
uso. O cadastramento, alteração e exclusão provavelmente são tratados em outro caso de uso responsável
por manter as informações sobre disciplinas.
No nosso exemplo, iremos considerar que essa informação é pública e que a perda de integridade
possui um impacto alto (com o raciocínio semelhante aos das informações sobre inscrição).
4) Turma
O caso de uso especifica que os alunos serão alocado nas turmas. Haverá um relacionamento entre o
aluno e a turma. A integridade dessa informação é importante para a segurança do sistema. Iremos englobar
5) Lista de espera
O fluxo alternativo (4) descreve a possibilidade de um aluno entrar em uma fila de espera. A quebra de
confidencialidade dessa fila causa menos impacto que a de integridade. O objetivo é impedir que um aluno
espertinho "fure a fila" de espera.
Depois de identificarmos todos os tipos de informação tratados pelo caso de uso devemos aplicar a
metodologia à cada um dos tipos de informação. Esta metodologia consiste em avaliar o impacto da perda de
confidencialidade, integridade e disponibilidade das informações e atribuir os níveis ALTO, MÉDIO, BAIXO e
NÃO SE APLICA1.
Impacto
Confidencialidade Integridade Disponibilidade
Tipos de informação
Tabela 2.1
Esta tabela representa a categorização de segurança dos tipos de informação do Caso de Uso 01.
Essa metodologia deve ser repetida para todos os casos de uso do sistema, até termos todas as informações
do sistema avaliadas. Porém, passaremos para o passo seguinte da metodologia considerando apenas as
informações descritas no Caso de Uso 01.
1 De acordo com o FIPS 199, a confidencialidade é o único atributo de segurança na qual se pode atribuir o
impacto “não se aplica”, usado nos casos em que as informações são públicas.
Esta categorização do sistema servirá de base para a seleção dos requisitos de segurança do sistema,
para a aceitação/avaliação de riscos e seleção dos controles. A dificuldade desta tarefa está na avaliação de
impacto de cada atributo. É de se esperar que o Analista de Requisitos pergunte: "Mas o que significa um
impacto ALTO, MÉDIO ou BAIXO?". Esta resposta deverá ser obtida com o próprio cliente e exige a definição
desses critérios pelas partes interessadas.
Uma outra forma de obter a categorização do sistema é por meio de uma metodologia de Análise do
Impacto no Negócio (BIA - Business Impact Analysis).
1 http://www.planalto.gov.br/ccivil_03/decreto/2002/D4553.htm
Tabela 2.3
O Decreto 4.553 define alguns requisitos de segurança que devem ser atendidos pelos sistemas que
produzem, manuseiam, transmitem, mantêm e guardam informações sigilosas. Vejamos esses requisitos em
seus artigos 45 a 48.
Art. 45. Os equipamentos e sistemas utilizados para a produção de documentos com grau de sigilo ultra-
secreto só poderão estar ligados a redes de computadores seguras, e que sejam física e logicamente isoladas
de qualquer outra.
Art. 46. A destruição de dados sigilosos deve ser feita por método que sobrescreva as informações
armazenadas. Se não estiver ao alcance do órgão a destruição lógica, deverá ser providenciada a destruição
física por incineração dos dispositivos de armazenamento.
Art. 47. Os equipamentos e sistemas utilizados para a produção de documentos com grau de sigilo secreto,
confidencial e reservado só poderão integrar redes de computadores que possuam sistemas de criptografia e
segurança adequados a proteção dos documentos.
Art. 48. O armazenamento de documentos sigilosos, sempre que possível, deve ser feito em mídias removíveis
que podem ser guardadas com maior facilidade.
Podemos observar que, como foi dito antes, o Decreto 4.553 é bem geral e inclui requisitos voltados
para a área de segurança de redes e segurança física. Esses requisitos especificam as diretrizes gerais dos
controles de segurança que devem ser aplicados. Esta é a característica que deve ser seguida por uma
Política de Segurança de um sistema de informação.
Figura 2.3
A partir deste Diagrama, que descreve as ações normais entre os autores e o sistema, podemos
construir o Diagrama de Caso de Abuso. Para isso, devemos agora imaginar as situações de abuso do
sistema, ou seja, vestir a camisa de um usuário malicioso que tentará, de várias formas, usar a aplicação de
uma maneira diferente da qual foi projetada. Isto retoma a ideia das Ameaças que estudamos no início deste
Módulo.
Figura 2.5
Por meio desta técnica, juntamos os requisitos de segurança não funcionais levantados para o sistema
escolar com os casos de abuso identificados. O sistema deve ter certeza de que os dados a ele enviados
foram submetidos pelo aluno previamente identificado. Isto consiste na validação dos dados de origem e
dificulta que um aluno mal intencionado consiga fraudar uma inscrição ou burlar os pré-requisitos da disciplina.
No caso da lista de espera, podemos definir que o sistema será capaz de inserir alunos na lista mas
nunca excluí-los. Portanto, o requisito não funcional de segurança "detectar alterações nos dados" irá dificultar
a ameaça de burlar lista de espera.
1 Fayad, M. Schmidt, Object-Oriented Application Frameworks - Communications of the ACM, New York, v. 40, n.10, p. 32-38, Oct. 1997.
1 Acerca de manutenção, temos tanto o processo que envolve a definição de chaves difíceis de serem deduzidas, como o processo de
substituição das chaves com determinada frequência.
2 Segundo a ABNT NBR ISO/IEC 17799:2005, Covert channels são caminhos não previstos para conduzir um fluxo de informações, mas que
no entanto podem existir num sistema ou rede.
1 http://msdn.microsoft.com/en-us/library/ms972812.aspx
1 http://sunset.usc.edu/csse/TECHRPTS/PhD_Dissertations/files/ChenY_Dissertation.pdf
2 http://www.microsoft.com/security/sdl/discover/design.aspx
Nível 1B
Nível 2A
Nível 2B
Nível 4
Nível 3
Requisitos de Verificação
Nível 2A
Nível 2B
Nível 1B
Nível 3
Nível 4
Re quis itos de V e r ificação
1 http://psds.portalcorporativo.serpro/psds/psdsplugin/guidances/guidelines/gerenciamento_riscos_arquiteturais_D12EA0F6.html
Figura 3.3
Hoje em dia, a maior parte dos relatos de incidentes que envolvem brechas de segurança apresentam
uma característica em comum: são ataques que exploram alguma vulnerabilidade na camada de aplicação. A
análise das vulnerabilidades invariavelmente indica um dos seguintes procedimentos para apontar a causa da
violação: falhas de projeto, questões de codificação (implementação), questões de configuração inadequada e
operações, com a prevalência de ataques que exploram vulnerabilidades de codificação da aplicação.
Geralmente os hackers mais experientes possuem um conhecimento abrangente, que vai desde o
funcionamento dos protocolos de rede até a implementação e uso de frameworks. Portanto é necessário que o
desenvolvedor saiba como os seus códigos podem ser explorados e as técnicas defensivas de codificação,
incluindo o gerenciamento de memória, análise estática e dinâmica de código, revisão por pares e segurança
no processo de geração da build. Além disso, o desenvolvedor deve conhecer os 25 erros de codificação mais
comuns que deixam a aplicação vulnerável (CWE/SANS Top 25) e as 10 vulnerabilidades mais comuns
(OWASP TOP 10).
1 http://www.mitre.org/
2 http://cwe.mitre.org/top25/index.html
String sqlQuery = " SELECT * FROM USERS WHERE user_id = ' " + usuario.Text + " ' AND user_pass = ' " +
senha.Text + " '
Se um atacante fornecer o nome do usuário como ' OR 1=1 -- a consulta final que será submetida ao
bando de dados será:
String sqlQuery = “ SELECT * FROM USERS WHERE user_id = ' “ + ' OR 1=1 -- + “ ' AND user_pass = ' “ +
senha.Text + “ '
A informação em vermelho será ignorada por conta do comentário --
Figura 43
A figura 4.4 ilustra como um mecanismo de codificação dos dados evita um ataque de SQL Injection,
transformando os parâmetros enviados pelos usuários em uma sequência literal de caracteres.
Figura 4.4
A OWASP está desenvolvendo um projeto de tutoriais em vídeo para explicar de forma bem didática
as vulnerabilidades apresentadas pelo OWASP TOP 10. No segundo episódio desta série de tutoriais são
apresentadas as vulnerabilidades de injeção de código. Os vídeos estão no youtube e seus endereços estão
na página do projeto: https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series
Figura 4.5
O atacante consegue realizar a persistência do script XSS através de diversas formas, como: envio de
um formulário contendo script XSS, manipulação dos parâmetros de uma requisição GET ou POST, através de
uma vulnerabilidade de SQL Injection presente na aplicação e manipulação dos campos presentes em uma
requisição SOAP quando se utiliza Web Services. A figura 4.6 mostra um caso onde o usuário acessa a página
vulnerável que renderiza o script XSS persistido."
Figura 4.6
A falha está presente tanto na camada de controle que não realizou a validação dos dados de entrada,
como na camada de apresentação que não codificou os dados exibidos na página, permitindo que o script
XSS persistido seja renderizado no browser do usuário.
O XSS refletido é um tipo de ataque semelhante ao XSS persistido, porém a entrada de dados do
usuário não é armazenada em uma base de dados, ela é somente incluída na resposta do servidor para o
Figura 4.7
As consequências de um ataque de XSS bem sucedido variam bastante e são graves. Os atacantes
podem executar um script no browser da vítima e:
roubar informações de autenticação;
roubar informações da sessão do usuário, possibilitando que ele se passe por alguém já autenticado;
pichar sites;
redirecionar os usuários a páginas maliciosas;
inserir conteúdo hostil.
Os erros comuns no desenvolvimento de softwares que estão associados aos ataques de XSS estão
listadas na tabela 4.4.
OWASP Top 10 CWE/SANS Top 25
A2 - Cross site scripting CWE/SANS 04 - Validação imprópria de entrada de dados durante a geração da página web
Tabela 4.7
Os controles de segurança que podem ser adotados para evitar os ataques de XSS incluem:
tratar as saídas (output) para o cliente usando escaping ou encoding de caracteres, fazendo com que o
script submetido pelo atacante seja tratado como um mero texto a ser renderizado pelo browser.
validar todas as entradas de dados por meio de um lista branca. Essas entradas incluem os
cabeçalhos, cookies, URL, campos do formulário, campos escondidos, etc. Essa validação deve
decodificar qualquer valor codificado (encoding) e verificar o tamanho, os caracteres, o formato e as
regras de negócio do dado de entrada antes de ser aceito.
utilizar frameworks que fornecem proteção contra XSS, seguindo as bibliotecas padronizadas pela
empresa (vide item 3.1).
A figura 4.8 mostra como um esquema de validação de dados pode impedir a persistência de um
scripts XSS.
A figura 4.9 mostra como um processo de codificação de caracteres pode impedir que um script XSS
persistido seja renderizado no browser do usuário. As técnicas de prevenção apresentados no tópico anterior
Figura 4.9
Figura 4.10
1 Para entender melhor a relação do buffer overflow com as aplicações web customizadas, leia o artigo
disponível em: https://www.whitehatsec.com/articles/mythbusting_buffer_overflow.shtml
2 Uma lista de funções banidas e suas substitutas para a linguagem C e C++ está disponível em:
https://buildsecurityin.us-cert.gov/bsi-rules/home.html
3 http://en.wikipedia.org/wiki/Address_space_layout_randomization
4 http://en.wikipedia.org/wiki/Data_Execution_Prevention
5 http://en.wikipedia.org/wiki/Executable_space_protection
A forma mais simples de prevenir a referência insegura a objetos é evitar expor as funcionalidades
internas da aplicação usando referências que podem ser facilmente manipuladas. Algumas estratégias para
controle incluem:
usar uma referência indireta aos objetos, por meio de um índice ou um mapa de referências, onde
uma entrada genérica (por exemplo um código) é mapeada internamente para a localização real do
objeto ou da funcionalidade;
1 tudo que vem após o marcador "?" na URL contendo um ou mais parâmetros compostos por campo/valor, ex: http://www.exemplo.com?
field1=value1&field2=value2
1 Além da validação de entradas, o desenvolvedor precisa conhecer outras práticas de codificação defensiva. Para isso, está disponível um
guia de consulta rápida no endereço https://wiki.serpro/unidades/cetec/seguranca/seguranca-no-desenvolvimento/recomendacoes-
owasp/Guia_de_Referencia_Rapida_v1.2.pdf
Figura 5.1
Testes Funcionais
Os testes funcionais têm como objetivo assegurar que o software atende às expectativas do usuário,
ou seja, estão de acordo com os requisitos especificados. Eles podem ser divididos em testes unitários,
integração, lógico e regressão.
Unitário: é o primeiro teste a ser conduzido para verificar se o software funciona corretamente. Ele é realizado
pelo desenvolvedor durante a fase de implementação. Cada parte do software é testada isoladamente para
verificação de erros de build, de compilação ou da lógica de programação. Este tipo de teste é realizado mais
facilmente quando a arquitetura do software é modular, com alta coesão e baixo acoplamento. Os benefícios
dos testes funcionais incluem:
validar a lógica funcional;
encontrar complexidades, ineficiências, e vulnerabilidades no código (credenciais explícitas, etc.)
alta cobertura de testes
Integração: diferentemente dos testes unitários, que verificam cada parte do software, os testes de integração
avaliam a "soma de todas partes", ou seja, a agregação de todas as unidades que formam o sistema. O
objetivo é identificar problemas que ocorrem quando as partes são combinadas.
Lógico: tem o objetivo de validar a precisão da lógica de processamento do software. A validação manual de
todas as linhas ou fazer o debug do código tem o benefício de testar grande parte do software (consegue uma
alta cobertura) para descobrir problemas no código.
Regressão: este tipo de teste tem o objetivo de garantir que alterações no software (mudanças corretivas ou
evolutivas) não interferiram negativamente nas funcionalidades anteriores. A implementação de um controle
de segurança pode negar uma funcionalidade disponível anteriormente. Por meio dos testes de regressão
podemos verificar:
que a correção de um bug não introduziu nenhum outro bug;
que os requisitos especificados continuarão a ser atendidos após modificações;
que o código não modificado não seja impactado;
Testes de Performance
São conduzidos para verificar se o sistema atende aos acordos de nível de serviço (ANS) e
expectativas do negócio. Um controle de segurança necessário pode vir a impactar na performance do
software. É necessário realizar um teste de performance para identificar o(s) gargalo(s) do sistema e fazer
ajustes finos (conhecidos como tunning) no código, no sistema operacional e no hardware, para otimizar o uso
dos recursos.
Testes de Segurança
Enquanto os testes funcionais são conduzidos para verificar que o software está de acordo com o que
foi especificado, os testes de segurança têm o objetivo de causar falhas no software, verificando sua
resiliência. O foco é detectar a presença e efetividade de controles de segurança implementados no software.
Os envolvidos nos testes de segurança devem ter o foco em subverter o sistema, achando novos caminhos
para atacar o software. É importante que esses profissionais tenham capacitação adequada, inclusive em
relação à ética no serviço executado, pois é comum que eles tenham acesso a informações críticas do
sistema.
Existem três aspectos envolvidos nos ataques hackers: motivação, oportunidades e os meios. A
motivação inclui obter fama, dinheiro ou vingança. As oportunidades que eles têm consistem nas
vulnerabilidades existentes nos sistemas e os meios incluem as ferramentas e o conhecimento do atacante.
Durante os testes de segurança são analisados principalmente dois dos aspectos: as oportunidades e os
meios.
Figura 5.2
Como podemos ver na figura 5.2, os testes de caixa branca são capazes de detectar defeitos ou bugs
no código, falhas na arquitetura do software ou desvio de padrões arquiteturais previamente definidos. A partir
desses apontamentos o desenvolvedor corrige o código-fonte. Em um processo de análise de código
descentralizada, em que os testes são conduzidos por uma equipe diferente da de desenvolvimento, os
responsáveis pelos testes podem abrir requisições de mudança e elaborar recomendações de correção.
A vantagem dos testes de caixa branca é a cobertura ou abrangência que consegue atingir. De posse
do código-fonte, é possível analisar todos fluxos de execução do programa. A desvantagem é a alta
complexidade, pois as ferramentas de revisão de código geralmente costumam gerar muitos falsos positivos,
ou seja, situação em que a vulnerabilidade apontada pela ferramenta é improcedente. Com isso é necessário
que o desenvolvedor ou a equipe de testes avalie todos os resultados gerados pela ferramenta. Outra
desvantagem é a baixa viabilidade, pois nem sempre é possível ter acesso ao código-fonte da aplicação.
Listas de ferramentas para análise de código podem ser acessadas em:
http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Tabela 5.1
5.2.4 Fuzzing
Outra metodologia de testes de segurança é o Fuzzing2, também conhecido como teste de injeção de
falhas. Fuzzing consiste em um teste de força bruta em que entradas inesperadas (aleatórias ou
pseudoaleatórias) são submetidas ao software e o seu comportamento é observado. O objetivo dos testes de
fuzzing é disparar um comportamento inseguro ou inesperado no software por meio da entrada de dados. Ele
é capaz de indicar a efetividade dos mecanismos de validação de entrada.
O fuzzing pode ser usado tanto para testar aplicações quanto para testar protocolos e formatos de
arquivos. Dentre as falhas identificadas por meio dos testes de fuzzing estão: buffer overflows, execução de
código, exceções não tratadas e DoS. Os endereços a seguir mostram dois exemplos reais de
vulnerabilidades que poderiam ter sido identificadas pelos testes de fuzzing:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0599
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1788
Os testes de fuzzing podem ser divididos em duas técnicas diferentes: dumb fuzzing e smart fuzzing.
Quando os dados de entrada que serão usados nos testes forem realmente aleatórios, sem nenhuma relação
com o software, protocolo ou arquivo que será analisado, a técnica utilizada é a dumb fuzzing. Quando os
dados de entrada são gerados a partir de uma estrutura já conhecida do software, protocolo ou formato de
1 http://www.blackhat.com/presentations/bh-usa-09/VELANAVA/BHUSA09-VelaNava-
FavoriteXSS-SLIDES.pdf
1 https://wiki.serpro/unidades/cetec/seguranca/seguranca-no-
desenvolvimento/treinamentos/TestesDeFuzzingParaSeguran_c3_a7aDasAplica_c3_a7_c3_b5esWeb/
2 csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
1 http://www.governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-interoperabilidade
2 csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
3 https://buildsecurityin.us-cert.gov/bsi-rules/home.html
4 É uma fragilidade que torna um sistema suscetível a um ataque ou a um dano.
5 https://buildsecurityin.us-cert.gov/bsi-rules/home.html