Sala de Aula4 _ Estacio

Prévia do material em texto

Segurança de Aplicações
Aula 4: Conceitos de vulnerabilidades em código fonte: Como
identi�car vulnerabilidades no software” e Bugs de
implementação versus defeitos arquiteturais
Apresentação
A atividade de planejamento tem diversos desa�os, como o detalhamento das regras de negócio, escolha da linguagem de
programação, alocação de equipe, gestão de recursos e estabelecimento de cronograma. Além disso, outras atividades
fazem parte do projeto e são bastante complexas, como a detecção e correção de vulnerabilidades.
O ideal é criar um programa sem vulnerabilidades. No entanto, esta é uma tarefa muito difícil de ser obtida. Muitas dessas
vulnerabilidades já são de domínio público e, portanto, com o devido planejamento e treinamento da equipe, é possível
mapeá-las e fazer o devido tratamento. Algumas dessas vulnerabilidades estão associadas a escolhas da arquitetura do
sistema e podem conduzir a erros (bugs).
Objetivos
Identi�car vulnerabilidades no software”;
Diferenciar bugs de implementação de defeitos arquiteturais.
Como identi�car vulnerabilidades no software
O processo de desenvolvimento de software” é complexo. Para atender os prazos, às vezes, algumas etapas não são
executadas da melhor forma. Quando essa decisão é tomada conscientemente, ela é chamada de débito técnico (será tratada
posteriormente em um momento oportuno).
No entanto, algumas partes podem seguir adiante sem a devida observação. São as chamadas vulnerabilidades que são
pontos fracos no projeto.
Elas podem ter sido deixadas por descuido dos programadores – por falta de tempo adequado para analisar o código, ou
mesmo por falta de conhecimento técnico para programar determinado módulo – ou, em uma situação mais perigosa, foram
deixadas para serem exploradas de forma fraudulenta.
De qualquer modo, sempre que existirem vulnerabilidades em um sistema, existirão riscos para os que o utilizam, tanto
prestadores de serviço como usuários.
Existem muitas ações fraudulentas que já são devidamente mapeadas, mas
que, ainda assim, são aplicadas constantemente. Muitos desses ataques
atingem os seus objetivos. Do ponto de vista dos desenvolvedores de
software”, é necessário investir em treinamento e direcionamento para
evitar que tais vulnerabilidades ocorram.
Do ponto de vista de gestores, é necessário incluir tempo para efetuar testes especí�cos para evitar que tais fragilidades
estejam no sistema, e tratar do tema de forma explícita com a incorporação no projeto das melhores práticas já conhecidas.
 A importância de identi�car vulnerabilidades
É importante identi�car as vulnerabilidades associadas ao desenvolvimento de software”, pois enquanto estiverem presentes o
sistema e os dados dos usuários estarão em risco. A maioria das vulnerabilidades de segurança de software” é causada por
tipos conhecidos de defeitos de software”, e a maioria de suas vulnerabilidades surge de causas comuns. (HOUSEHOLDER et al,
2017).
Uma forma de identi�car essas vulnerabilidades é pesquisar pelas listas das principais vulnerabilidades disponíveis em domínio
público. Algumas das fontes mais conhecidas de vulnerabilidade incluem:
Banco de dados nacional de vulnerabilidades (INFORMATION TECHNOLOGY LABORATORY, 2020);
SANS Top 20 (CIS Critical Security Controls, 2020).
Além disso, temos outras listas de vulnerabilidade. Veja.
Clique nos botões para ver as informações.
Injeção (Injection);
Autenticação quebrada (Broken Authentication);
Exposição de dados con�denciais (Sensitive Data Exposure);
Entidades externas XML (XML External Entities);
Controle de acesso quebrado (Broken Access Control);
Con�guração incorreta de segurança (Security Miscon�guration);
XSS de script entre sites (Cross-Site Scripting XSS);
Desserialização insegura (Insecure Deserialization);
Usando componentes com vulnerabilidades conhecidas;
Registro e monitoramento insu�cientes (Insu�cient Logging & Monitoring).
10 principais vulnerabilidades da OWASP 
Aplicativos da Web;
Serviços de Sistema Operacional: Windows, UNIX e Mac OS;
software” de backup;
software” antivírus;
Servidores de gerenciamento;
software” de banco de dados.
Vulnerabilidades do lado do servidor 
Navegadores da Web;
software” de escritório;
software” de e-mail;
Media players.
Vulnerabilidades do lado do cliente 
Direitos de usuário excessivos nos sistemas;
Conectar dispositivos não autorizados nos sistemas da empresa;
Exposição a e-mails maliciosos (Phishing).
Vulnerabilidades de políticas de segurança 
Aplicativos de mensagens instantâneas;
Aplicativos de compartilhamento ponto a ponto (bluetooth).
Vulnerabilidades de aplicativos 
A importância de identi�car vulnerabilidades
Saiba mais
Há ainda Ataques do dia Zero, uma vulnerabilidade de segurança que ainda não é tão conhecida e, portanto, não foi corrigida.
Portanto, as vulnerabilidades estão relacionadas tanto com questões técnicas como com políticas de segurança.
Dada a complexidade dos projetos de desenvolvimento de software, o processo de identi�cação de vulnerabilidades não é
trivial. É por isso que é tão importante que essa atividade seja contemplada no planejamento do projeto, para que a equipe seja
treinada para detectar e corrigir essas vulnerabilidades, além de ter um direcionamento explícito de quais testes devem ser
feitos.
Em especial, a OWASP está relacionada com questões técnicas. Um método para descobrir tais vulnerabilidades inclui revisões
por pares e ferramentas de veri�cação de código. É fundamental que sejam feitos investimentos em treinamentos especí�cos
para os membros da equipe.
 Métodos de detecção de vulnerabilidades
 Clique no botão acima.
A capacitação dos desenvolvedores de software” é essencial para identi�car e corrigir as vulnerabilidades dos
sistemas. Além disso, deve-se fazer uso de programas e métodos para detectar vulnerabilidades, como, por exemplo:
Revisão dos controles atuais: As equipes de desenvolvimento, devidamente orientadas pela gerência do projeto,
devem implementar recursos nos sistemas que reduzam o impacto das vulnerabilidades relacionadas aos
controles de acesso, como, por exemplo, criar hierarquia de privilégios para que os usuários possam ter acesso a
determinadas sessões do sistema.
A ausência desse tratamento pode abrir possibilidade de ataques que explorem:
Escalonamento de privilégios;
Logins não autorizados;
Acesso a informações con�denciais;
Susceptibilidade a malware.
Atividades executadas externamente ao sistema (como a condução de relatórios con�denciais) podem receber um
tratamento explícito; por exemplo, o registro no sistema de cópias impressas (arquivo de logs) e mensagens de
advertência sobre a implicação legal no uso da informação.
Revisões do código: As revisões devem procurar por código (ou a ausência de código) que possa permitir uma
vulnerabilidade, como estouros de buffer (buffer over�ow), rotinas de tratamento de erros e falta de regras de
validação de campo inadequadas;
Testes: Devem ser executados em todas as etapas do desenvolvimento. Sempre devem ser direcionados para
detectar vulnerabilidades, tais como estouros de buffer, falhas de injeção e vazamento de informações. Existem
diversos tipos de teste, mas o mais importante é na elaboração dos cenários, ou seja, criar situações em que o
sistema estará exposto;
Ferramentas de veri�cação de código estático: Existem padrões de vulnerabilidades no código fonte que são
facilmente detectáveis por ferramentas disponíveis no mercado (muitas delas, gratuitamente). Algumas fornecem
exemplos de como corrigir o código para evitar vulnerabilidades. Abaixo, segue uma lista de algumas dessas
ferramentas:
Lint e Splint: Aplicada para a linguagem C;
Jlint, Soot, FindBugs: Aplicada para a linguagem Java;
Oink, Flaw�nder: Aplicada para a linguagem C++;
JsLint: Aplicada para a linguagem JavaScript;
pylint, pyChecker: Aplicada para a linguagem Python.
Ferramentas de veri�cação de código dinâmico: Têm como objetivo a veri�cação do código paraidenti�car
vulnerabilidades enquanto o programa está em execução, bem como irá interagir com outros processos e com o
próprio sistema operacional. Normalmente, são executadas em um ambiente controlado para que o teste não
seja comprometido por interferências externas. Algumas dessas ferramentas injetam trechos de código para
monitorar o desempenho, a pilha de chamadas, o rastreamento de execução, objetos instanciados e variáveis.
Além desses métodos para detecção de vulnerabilidades, é necessário também levar em consideração o ambiente em
que as aplicações vão executar. Por exemplo, para aplicações que executam na web é necessário rastrear aplicativos e
páginas associados ao sistema e pesquisar por vulnerabilidades. Alguns exemplos de produtos de código aberto são:
WebScarab e Paros Proxy.
 Conclusão
A existência de vulnerabilidades nos sistemas fragiliza a segurança dos dados armazenados de usuários e do próprio sistema,
permitindo a fraudadores explorá-las para cometer crimes. Portanto, é fundamental que suas detecção e correção façam parte
do projeto de desenvolvimento para fornecer proteção adequada a esses sistemas.
Os desenvolvedores devem receber treinamento especí�co e fazer uso de ferramentas de veri�cação de vulnerabilidades.
Bugs de implementação versus defeitos arquiteturais
Defeitos de software”, comumente conhecidos como bugs, são um sério
desa�o para o funcionamento correto do sistema. Trata-se do resultado de
um erro de codi�cação detectado na execução dos testes. A arquitetura de
software” de um sistema, por sua vez, descreve como o sistema é
estruturado, sendo importante para compreender seu comportamento.
As escolhas sobre a arquitetura de um sistema afetam seu desempenho, a di�culdade para fazer sua manutenção e, de um
modo geral, seu sucesso. Existem vários estilos arquitetônicos, como podemos ver abaixo. (SOMMERVILLE, 2011)
Clique nos botões para ver as informações.
As responsabilidades da aplicação são separadas em camadas bem de�nidas.
Arquitetura em camadas 
A gerência de todos os dados do sistema é feita através de um repositório central em que todos os componentes do
sistema podem acessá-los. Os componentes interagem apenas por meio do repositório.
Arquitetura de repositório 
O funcionamento do sistema está organizado em serviços, sendo que cada serviço é prestado por um servidor. Os
clientes, por sua vez, são usuários desses serviços e acessam os servidores para utilizá-los.
Cliente-servidor 
Os dados são processados de modo que cada componente de processamento (�ltro) execute uma transformação. Os
dados �uem (como em um duto) de um componente para outro para processamento.
Arquitetura de duto e �ltro 
A arquitetura de um sistema de software” não precisa ser limitada a um único estilo. Um outro importante padrão de arquitetura
de software” é o MVC – Modelo, Visão e Controle.
 O projeto de software
Também conhecido pela expressão “Design de software””, consiste em conceituar os requisitos de software”, incluindo a
arquitetura, em documentos, de tal modo que sejam compreensíveis pelos desenvolvedores.
A partir da documentação do projeto, passa-se para o planejamento do desenvolvimento do software”, quando os requisitos do
usuário passam a ser itens que devem ser implementados da melhor forma possível. Os principais resultados - chamados de
“artefatos” - do projeto de software” são:
1
Especi�cação de requisitos de software
Neste documento é descrito o comportamento esperado do
sistema na forma de requisitos funcionais e não funcionais.
Esses requisitos devem ser detalhados de modo que os
desenvolvedores possam entendê-los para poder programar e
relacioná-los aos requisitos de negócios.
2
Design arquitetural (Design de alto nível)
O projeto de arquitetura do sistema é dividido em uma visão
menos abstrata representada por subsistemas e módulos e,
além disso, as interações entre eles é descrita.
3
Projeto detalhado
Os componentes da arquitetura do projeto, tais como
subsistemas e módulos, são detalhados de modo a viabilizar
suas implementações e a forma como vão interagir entre si.
Os objetivos da arquitetura e do projeto de software se combinam no sentido de que a primeira está focada na estrutura do
sistema, enquanto a segunda foca nos detalhes da implementação. Ambas formam o mesmo sistema.
A arquitetura faz parte do projeto de software, mas nem todo projeto
é arquitetônico. A de�nição da linha que separa arquitetura de
software (projeto arquitetônico) e projeto detalhado (projeto não
arquitetônico), na prática, é do arquiteto de software. Não há uma
formalização para determinar essa distinção.
É natural que o projeto de software evolua com o tempo, pois não há como o arquiteto de software desenvolver um sistema
completamente. Essa evolução ocorre nos estágios de implementação do sistema.
Nesse processo de revisão, as melhores práticas são identi�cadas e podem ser incorporadas em outros projetos da
organização. (MARANZANO et al, 2005)
 Decisões para evitar vulnerabilidades
 Clique no botão acima.
Os sistemas são cada vez mais complexos, tanto sob o aspecto do escopo como de escalabilidade. Esse cenário cria um grande
desafio para evitar vulnerabilidades que podem ter sua origem como consequências de erros na implementação e de falhas no
projeto. Infelizmente, não existe uma forma para garantir que um sistema seja implementado sem nenhum erro, mas existem
algumas recomendações que auxiliam nesse processo. (ALLEN, 2007)
Ao invés de controle centralizado, os pontos de controle podem ser feitos frequentemente;
Devido ao aumento da integração entre sistemas, a capacidade de fazer alterações em larga escala �ca
comprometida. Portanto, é necessário construir cenários em que, quando problemas surgirem, seja possível
sincronizar a implementação da solução com o cuidado de não desestabilizar o que está funcionando
corretamente;
Outro ponto que deve ser levado em consideração é a respeito da política de segurança de acesso, pois a
inclusão do novo sistema não pode criar inconsistências entre as políticas de segurança.
De um modo geral, é menos custoso para o desenvolvimento do software identi�car e corrigir falhas de projeto no
início do processo do que corrigir implementações após a implantação.
É por isso que, além do treinamento da equipe de desenvolvimento e planejamento explícito da gerência pelo
tratamento de vulnerabilidades, é necessário incluir a geração de cenários que simulem situações pelas quais o
sistema �cará exposto, e utilizar essas informações para identi�car e corrigir eventuais problemas, ou mesmo fazer
revisões da arquitetura do sistema.
 Conclusão
O planejamento do desenvolvimento de software envolve muitas etapas, entre elas a escolha da arquitetura do sistema.
No entanto, devido às várias situações que podem acontecer ao longo do projeto, pode ser necessário fazer revisões de
arquitetura e do projeto de software para reduzir as chances de entregar um sistema para o cliente com vulnerabilidades que
podem se transformar em falhas. Em alguns casos, os testadores podem identi�car defeitos com mais facilidade usando
informações sobre a arquitetura do software.
Atividade
1. Algumas informações de uma organização são consideradas con�denciais, portanto, o acesso deve ser dado apenas para
pessoas com a devida autorização. Algumas situações, no entanto, ocorrem externamente ao sistema. Selecione a opção mais
adequada para evitar que uma informação con�dencial impressa possa ser encontrada em um local inadequado, como uma
lixeira que qualquer um poderia acessar:
a) Não é possível tratar essa situação, pois depende completamente do comportamento do usuário.
b) O sistema só pode dar acesso à informação para usuários que tenham determinado tempo de experiência na organização.
c) O sistema deve imprimir explicitamente uma mensagem com as implicâncias legais de acessar o relatório de forma indevida; além
disso, deve registrar em um arquivo de log quem teve acesso ao mesmo.d) Os funcionários da limpeza devem receber orientações explícitas para destruir papéis que estejam nas lixeiras.
e) Os dados dos relatórios devem ser criptografados.
2. Um dos métodos para tentar identi�car as vulnerabilidades de um sistema são os testes. A respeito de testes de software,
selecione a opção correta:
a) Devido à gestão racional dos recursos disponíveis no projeto, o ideal é que os testes sejam executados quando o software estiver
completo.
b) A criação de cenários é fundamental para que os testes sejam eficazes.
c) Os testes mais importantes são os unitários.
d) Os testes mais importantes são os de integração.
e) Os testes devem ser feitos sempre que for detectada uma vulnerabilidade do sistema.
3. As vulnerabilidades representam um risco real para os sistemas, pois fraudadores podem ter acesso a dados dos usuários,
ou da organização, e utilizá-los para cometer crimes. Nesse sentido, selecione a opção correta sobre o método de identi�cação
de vulnerabilidades que se baseia na análise comportamental do sistema enquanto interage com outros processos.
a) Revisão dos controles atuais.
b) Revisões do código.
c) Testes.
d) Ferramentas de verificação de código estático.
e) Ferramentas de verificação de código dinâmico.
4. A arquitetura de um software é um aspecto fundamental para compreender seu funcionamento. Existem muitos estilos de
arquitetura de software. Selecione a opção correta em que a arquitetura é um exemplo de padrão no qual a visão apresentada é
a organização conceitual de um sistema.
a) Arquitetura em camadas.
b) Arquitetura de repositório.
c) Cliente-servidor.
d) Arquitetura de duto.
e) Arquitetura de filtro.
5. O projeto de software direciona o planejamento da execução das diversas etapas do ciclo de desenvolvimento. A respeito de
seus artefatos, selecione a opção correta:
a) A Especificação de Requisitos de software implementa os requisitos funcionais.
b) A Especificação de Requisitos de software descreve como os componentes do sistema vão interagir entre si.
c) O Design Arquitetural documenta detalhadamente como os componentes do sistema vão interagir entre si.
d) O Design Arquitetural descreve como o sistema é dividido em componentes e como eles interagem entre si.
e) Projeto Detalhado descreve os requisitos funcionais e não-funcionais do sistema.
6. Decisões relacionadas ao projeto de um sistema têm impacto sobre a existência de vulnerabilidades neste sistema. Apesar
de não existir uma forma que garanta a implementação sem erro de um sistema, algumas recomendações auxiliam nesse
processo. Selecione a opção correta que minimiza as chances das ocorrências de vulnerabilidades no sistema.
a) Fazer um controle centralizado para garantir a coerência das revisões.
b) Desenvolver sistemas isolados, pois a integração com outros sistemas aumenta a probabilidades de erros.
c) Simular cenários baseados na arquitetura MVC, pois o seu espectro de cobertura trata de todas as situações a que o sistema pode ser
submetido.
d) Simular cenários contextualizados nas situações em que o sistema será usado.
e) Devido à limitação de recursos – financeiros, tempo e pessoas com a devida qualificação –, os testes devem ser executados nas etapas
inicial e final do projeto de software.
Notas
Referências
ALLEN, J. Why is Security a Software Issue?, EDPACS, 36:1, 1-13, DOI: 10.1080/07366980701500734, 2007.
HOUSEHOLDER, A.D. et al. The CERT guide to coordinated vulnerability disclosure. Technical report, Carnegie Mellon
University, United States, 2017.
INFORMATION TECHNOLOGY LABORATORY. Vulnerabilities. Disponível em: https://nvd.nist.gov/vuln. Acesso em: 18 jun. 2020.
MARANZANO, J.F. et al. Architecture reviews: practice and experience. in IEEE Software, vol. 22, no. 2, pp. 34-43, March-April
2005, doi: 10.1109/MS.2005.28.
OWASP Top Ten. Disponível em: https://owasp.org/www-project-top-ten/. Acesso em: 18 jun. 2020.
javascript:void(0);
javascript:void(0);
javascript:void(0);
SANS. CIS Critical Security Controls. Disponível em: https://www.sans.org/critical-security-controls/. Acesso em: 18 jun. 2020.
SOMMERVILLE, I. Engenharia de Software. 9.ed. Pearson, 2011. p. 108-115.
Próxima aula
Segurança de software e gerenciamento de riscos
Engenharia reversa e técnicas de análise de caixa cinza.
Explore mais
Leia o texto Os 10 principais da OWASP.
Leia o texto Ataques na Internet .
Leia o texto Software Engineering Body of Knowledge (SWEBOK) .
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);