Académique Documents
Professionnel Documents
Culture Documents
1. Introdução
Em um mundo globalizado, cada vez mais dependente de recursos tecnológicos, a web e
os sistemas de software são utilizados para facilitar a realização de trabalhos, tornando-
os mais ágeis, eficazes e competitivos. A disponibilização de recursos pela rede
representa em muitos casos, a vitalidade dos negócios. Sistemas bancários, de aviação,
espacial e comunicação, por exemplo, teriam sérias limitações ou nem existiriam sem as
facilidades e recursos proporcionados por sistemas de software.
Softwares já não atendem somente a web ou organizações, seu papel já é muito
mais importante. Sistemas são integrados em carros, celulares, sistemas bancários,
lavadouras, aviões dentre uma quantidade imensa de utensílios, tornando-se invisível
aos usuários. O conhecimento em torno de um sistema é definido por McGraw[2] como
o poder de uma nação, onde a capacidade de desenvolvimento e sua a utilização são
fatores críticos.
Sistemas seguros não devem ser um luxo, mas uma necessidade. O ônus
decorrente do investimento em segurança ao longo de um projeto será compensado por
uma redução de bugs no sistema e contenção de atividades maliciosas caracterizando
assim um retorno sobre o investimento (ROI).
Porém, tornar um ambiente seguro não é uma tarefa fácil. A arquitetura das
aplicações está cada vez mais complexa e sistemas podem ser interligados e prover
serviços para outros como estabelecido no conceito de Arquitetura Orientada a Serviços
(SOA) e webservices. A infra-estrutura pode ser migrada para as nuvens (cloud
computing), e cada vez mais, recursos estão sendo aprimorados e desenvolvidos para
facilitar e agilizar processos. É relatado por McGraw[2] que sistemas legados, por
exemplo, escritos em Cobol, possuem diversas ameaças tendo em vista a limitação de
recursos de segurança implementados pela linguagem
Estabelecer um ambiente totalmente seguro é algo impossível pois a tecnologia é
algo em constante ascensão assim como as pragas que a atormentam. O objetivo de
todos que lidam com segurança é prover e gerenciar da melhor forma os riscos
relacionados a seus ativos. Planejar, implementar e avaliar ações corretivas são tarefas
que devem ser executadas periodicamente.
Desta forma considerando a importância e dificuldades expostas para o
desenvolvimento de um software seguro, este artigo relata os resultados da análise da
qualidade de código de um projeto open source cujo objetivo é destacar falhas que
possam comprometer aspectos de segurança das aplicações.
O restante do artigo está assim organizado: na próxima seção está relatada a
metodologia utilizada para execução do trabalho. Após apresentação de definições e
conceitos relacionados à área de segurança de aplicações, foi desenvolvida uma
motivação para desenvolvimento seguro de aplicações. Em seguida, foram apresentados
conceitos e ferramentas que permitiram a execução da análise estática de código. Por
fim, foi apresentado o estudo de caso, os resultados da análise de código do sistema
escolhido e considerações finais.
2. Método de pesquisa
De forma a adquirir o conhecimento necessário sobre os problemas de segurança que
permeiam o desenvolvimento de software, foi realizado o levantamento das principais
ameaças que assolam os ambientes web e enterprise em referências bibliográficas e
entidades especializadas no tema. As vulnerabilidades documentadas nas referências[3]
[6] foram filtradas de forma a serem alvo da busca no software escolhido
A próxima etapa foi a pesquisa de ferramentas de auxílio à identificação das
vulnerabilidades classificadas, sendo selecionadas apenas aquelas de maior relevância,
conforme estudo disponibilizado por Almazan[19]. Foram verificadas também, nesta
fase, contra-medidas afim de se contornar falsos positivos e falsos negativos gerados
pela análise das ferramentas, conforme observado no estudo SATE 2008[21].
Após o levantamento das questões de segurança relacionadas ao
desenvolvimento de sotfware, foi iniciada a busca de um software de relevância para
estudo de caso. Foi selecionado o framework Demoiselle do governo federal, tendo em
vista seu objetivo de se tornar referência para o desenvolvimento de sistemas no
governo federal, bem como incentivar sua utilização aos fornecedores de software do
governo.
O trabalho de análise do código teve início com a verificação de conformidade
linguística do framework, a fim de determinar desvios de codificação que possam
influenciar a identificação de vulnerabilidades pelas ferramentas.
Além dos estudos já citados, existe ainda o estudo de Williams[17] que descreve
várias técnicas de programação maliciosa, onde é demonstrado, por exemplo, a
possibilidade de inserir e esconder falhas em aplicações JEE, além de técnicas, como o
controle e restrição de APIs, que auxiliam no processo de construção do software
evitando a subversão de bibliotecas e limitando seu acesso a outros recursos.
6. Análise de código
Conforme já apresentado, de forma a aumentar a qualidade dos sistemas de software,
diversos estudos e recursos são disponibilizados à comunidade. Ferramentas de análise
estática, análise binária e engenharia reversa são outros instrumentos que auxiliam a
aprimorar a segurança das aplicações ainda em tempo de desenvolvimento. Por outro
lado, ferramentas para realização de testes de penetração efetuam a prova de conceito
das medidas de segurança adotadas, durante o processo de desenvolvimento, além de
colaborarem para descoberta de novas falhas ao verificar o comportamento do sistema
quando exposto à situações subversivas.
A opção de estudo de tal sistema foi considerada tendo em vista sua pretensão de
se tornar base para o desenvolvimento de sistemas no governo federal além de
incentivar sua utilização a fornecedores de software do governo. A avaliação de código
fonte do sistema colabora para o desenvolvimento do projeto servindo como estudo de
segurança complementar, auxiliando a estabelecer métricas para validar a qualidade do
projeto além de poder ser utilizado para verificar o impacto de falhas de segurança. É
importante observar que o presente trabalho não visa analisar profundamente questões
arquiteturais ou de engenharia do sistema bem como se exime de avaliar características
ideológicas do projeto.
Serão apresentados agora os dados obtidos com a pesquisa, sendo que para realização da
atividade foram utilizadas ferramentas de análise estática, citadas no item 5, ocorrendo
em paralelo análise dos resultados obtidos.
7.1.1 Análise de estática
PMD 351
Checkstyle 9304
Tabela 1. Verificação de convenções linguísticas.
Cabe ressaltar que os alarmes, ou avisos, listados na tabela 1 não devem ser
julgados como não adequação por completo às normas linguisticas da linguagem Java.
Foi observado que grande parte dos alarmes gerados refere-se a uma grande quantidade
de caracteres por linha, adição de tabulação em algumas linhas e não referência de
variáveis, exceção e retorno esperado pelo Javadoc.
Findbugs 14
Lapse 2
Tabela 2. Bugs detectados pelas ferramentas de análise estática
A forma mais adequada seria retornar uma cópia do array original a fim de
evitar a manipulação de dados da aplicação, o que poderia acarretar inconsistência de
dados.
public Object[] getArguments() {
Object[] copyOf = Arrays.copyOf(arguments,
arguments.length);
return copyOf;
}
8. Conclusão
Frente às diversas ameaças de segurança que permeiam os sistemas de software torna-se
importante analisar as vulnerabilidades de sistemas com relevância para a comunidade.
De forma a conscientizar os envolvidos com o desenvolvimento de software a assegurar
suas aplicações, foi conduzido um estudo de análise de vulnerabilidades do framework
do governo federal Demoiselle. Para o estudo foram utilizadas ferramentas de análise
estática de código como PMD, Findbugs e LAPSE.
Foi observado, conforme a conclusão do estudo SATE 2008[21], que a análise
humana é melhor que a análise automática das ferramentas para identificação de
vulnerabilidades relevantes no código. O relato de vulnerabilidades pelas ferramentas,
em sua maioria, necessita de conhecimento pré-eliminar para detecção, análise e
correção das vulnerabilidades e falhas encontradas. Esta constatação demonstra a
importância de educar os desenvolvedores a respeito de questões de segurança no
desenvolvimento de software, além de demonstrar a relevância da utilização destas
ferramentas para obtenção de maturidade aos que se habilitem a utilizar tais recursos.
Não foi analisada a escolha de APIs externas assim como sua junção com o
código do projeto Demoiselle. Tal análise poderá ser realizada em trabalhos futuros que
observem questões arquiteturais e realizem a análise estática das APIs em questão,
podendo também ser efetuado um estudo de análise binária do sistema demonstrando
sua integração e/ou utilização com outros. Conforme observação realizada por
McGraw[2], sistemas de software moderno agregam características como complexidade
e extensibilidade que colaboram para o aumento do cenário de insegurança.
Observado o nível de criticidade das vulnerabilidades encontradas nos módulos
da camada de persistência (JPA, Hibernate, JDBC), recomenda-se a substituição dos
respectivos módulos do framework até que sejam disponibilizados patches ou fixes para
tais problemas. Quanto às demais vulnerabilidades constatadas, recomenda-se notificar
a comunidade dos riscos de seguir a implementação default do framework, além de
fornecer em uma próxima release as correções adequadas para sua utilização.
Referência bibliográfica
[1] Tissato, Nakamura Emilio. Lício, Geus de Paulo. (2007) “Segurança de Redes: em
ambientes cooperativos”, Ed. Novatec
[2] McGraw, Gray. (2006) “Software Security - Building Security In”, Ed. Addison-
Wesley
[3] OWASP: Principle, Threat Agent, Vulnerability (2009), http://www.owasp.org.
[4] Cartilha de Segurança para Internet (2009), http://cartilha.cert.br./glossario/,
CERT.br.
[5] ISO/IEC 17799. (2001) “Tecnologia da Informação – Código de Prática para Gestão
da Segurança da Informação”. Agosto.
[6] SANS Institue: “Top 20 Internet Security Problems, Threats and Risks” (2009),
http://www.sans.org/top20/.
[7] Stock, Van Der Andrew. Williams, Jeff. Wichers, Dave. (2007) “Top 10 2007”,
http://www.owasp.org/index.php/Top_10_2007.
[8] Twitpwn, (ab)using twitter since 2008! (2009), http://twitpwn.com/.
[9] Milw0rm (2009), http://milw0rm.com/exploits/9324.
[10] Milw0rm (2009), http://milw0rm.com/exploits/9158.
[11] Holzmann, G.J. “The Power of Ten: Rules for Developing Safety-Critical Code”,
http://www.eecs.umich.edu/~imarkov/10rules.pdf
[12] NetworkWorld (2009), http://www.networkworld.com/news/2008/103008-morris-
worm.html.
[13] CERT (2009), http://www.cert.org/meet_cert/.
[14] Incidentes Reportados ao CERT.br, abril a junho de 2009,
http://www.cert.br/stats/incidentes/2009-apr-jun/tipos-ataque.html.
[15] SDL Microsoft ,
http://www.microsoft.com/brasil/security/guidance/topics/lifecicle/sdl.mspx.
[16] Long, Fred. (2005) “Software Vulnerabilities in Java”, CERT, October.
[17] Williams, Jeff (2009). “Enterprise Java Rootkits: hardly anyone watches the
developers”, July.
[18] Martin, Robert (1994) “OO Design Quality Metrics – An Analysis of
Dependencies”. October
[19] Almazan, B. Christian (2000) “A Comparison of Bug Finding Tools for Java” ,
University of Maryland, College Park.
[20] Demoiselle Framework (2009),
http://www.frameworkdemoiselle.gov.br/menu/framework/sobre/.
[21] Okun, Vadim. Gaucher, Romain, Black, E., Paul (2009) “Static Analysis Tool
Exposition (SATE) 2008”, U.S Departament of Commerce & National Institute of
Standards and Technology., United States.
[22] Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil
(2009), http://www.cert.br