Análise Estática do Framework Demoiselle do Governo

Federal com Ênfase em Segurança de Aplicações Web

Alexandre F. De Menezes1, Gisele Rodrigues M. Ferreira2

Especialização em Sistemas Orientados a Objetos – Universidade Católica de Brasília,

D.F.
alexandre.fmenezes@gmail.com, gisele.ferreira@gmail.com

Abstract. The relevance of software systems is increasing. Systems are already

embedded in a huge amount of tools, becoming invisible to users and also
essential to their lives and businesses. System security should is not a luxury
but a necessity. The number of reports of vulnerabilities that affect software
systems and impact businesses increases every year. Given this scenario of
insecure software, we studied the use of static analysis, with emphasis on
security, in a framework from the Federal Government, where several
vulnerabilities were found.

Resumo. A relevância dos sistemas de software é cada vez maior. Sistemas já

são integrados em uma quantidade imensa de utensílios tornando-se invisível
aos usuários assim como essencial para suas vidas ou negócios. A segurança
dos sistemas não deve ser um luxo, mas uma necessidade. Os relatos de
vulnerabilidades que afetam sistemas e impactuam os negócios aumenta a
cada ano. Tendo em vista o cenário de insegurança que permeia os sistemas
de software foi realizado um estudo de análise estática com ênfase em
segurança em um framework do governo federal, onde foram constatadas
diversas vulnerabilidades que comprometem sua utilização.

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.

Concluída tal etapa, foi realizada a análise em busca de vulnerabilidades, sendo

primeiramente utilizada as ferramentas de automação para descoberta de bugs e em
seguida realizada a validação das informações obtidas afim de determinar o impacto das
vulnerabilidades localizadas.

3. Definições e conceitos chave

De forma a delimitar os conceitos chave da segurança, interpretados de muitas formas, o
trabalho utilizará as seguintes definições estabelecidas por normas e entidades
especialistas em segurança da informação[3],[4],[5]:
• vulnerabilidade: falha presente na aplicação que pode ser explorada por uma
entidade e que resulta em danos aos usuários ou ambiente;
• ameaça: algo que possa provocar danos;
• ativo: tudo que possua valor para uma entidade;
• risco: é determinado pela possibilidade de efetivação de uma ameaça;
• segurança da informação: proteger a informação visando garantir:
o integridade: “completude da informação e dos métodos de processamento”;
o disponibilidade: “garantia que os usuários autorizados obtenham acesso à
informação”;
o e confidencialidade: “garantia que a informação é acessível somente por
pessoas autorizadas.”;

4. Segurança mais que necessidade

De acordo com McGraw[2], problemas de segurança em software são algo comum, tal
situação é cada vez mais evidente aos órgãos que coordenam e analisam a segurança em
ambientes de TI, como o CERT, OWASP, SANS dentre outros.
McGraw[2] aponta que o impacto de segurança em sistemas modernos de
software atualmente é maior que no passado devido a três ameaças.
• Conectividade: o aumento do número de hosts na rede aumenta o número de
vetores de ataque. Pessoas, negócios e governos estão cada vez mais dependentes de
tecnologia. Aplicações estão migrando para o ambiente online. Grandes empresas
ganharam mais dois problemas: web services e SOA;
• Extensibilidade: característica que permite ao sistema agregar novas
funcionalidades, como o acréscimo de módulos ou plugins;
• Complexidade: a quantidade de linhas de código em sistemas é cada vez maior,
assim como as dificuldades em gerencia-lo.
 De forma a elevar o nível de segurança de um sistema tornando-o mais
gerenciável, é necessário a adoção de medidas de segurança durante todo o ciclo de
desenvolvimento de software. A norma ISO 17799[5] recomenda que, durante a
especificação de requisitos de novos sistemas ou na melhoria de sistemas já existentes,
também sejam especificados requisitos e controles de segurança e tais controles devem
refletir o valor dos ativos de informação envolvidos em um possível dano ao negócio.

Desde o ano de 2000 o SANS Institute and the National Infraestructure

Protection Center juntamente com o FBI (Federal Bureau of Investigation) divulgam
uma lista com as 20 principais vulnerabilidades de segurança em aplicações. Este estudo
é utilizado por muitas empresas de forma a priorizar recursos que assegurem seus
sistemas. A importância da realização constante desta pesquisa se justifica pelo
dinamismo e evolução das ameaças e dos sistemas. Recursos e ameaças inexistentes
hoje rapidamente se concretizam e se propagam pela web, exigindo que todos se
mantenham atualizados.

O SANS alerta que independente de tecnologia, as aplicações possuem falhas de

segurança. Ameaças como Remote File Include, SQL Injection, XSS e CSRF estão no
topo da lista de principais vulnerabilidades. De forma a delimitar e estabelecer quais
destas vulnerabilidades possuem maior impacto, o presente trabalho fez uso dos estudos
OWASP Top Ten 2007[6] e Top 20 Internet Security Problems, Threads and Risks[7],
com as seguintes categorias web applications e zero day attacks.
Para exemplificar a insegurança existente nos mais variados sistemas de
software serão apresentados brevemente três cenários de vulnerabilidades.
O primeiro cenário tratará do microblog Twitter[8] que permite a seus usuários
enviar e receber atualizações de pequenas mensagens de texto, além de possibilitar
publicidade, notícias e manifestações. O Twitter Search, um pequeno aplicativo
integrado ao Twitter, possuía uma vulnerabilidade que permitia ataques de XSS, ataque
que permite o envio de código malicioso através de um aplicativo web permitindo a
execução de scripts no cliente, onde de acordo com Naraine[8], permitia um cracker
assumir o controle das contas de suas vítimas além de possibilitar a propagação de um
worm pela rede. A efetivação de tal ameaça impacta na imagem do serviço além de
poder afetar a credibilidade de diversos usuários que utilizam o serviço. Um cracker em
posse de uma conta poderia manifestar atitudes ofensivas em nome de uma empresa,
podendo acarretar ações judiciais a mesma.
O segundo cenário para exposição de possíveis vulnerabilidades envolve o
aplicativo Joomla.O Joomla é um CMS muito conhecido e utilizado da comunidade de
TI. É um sistema extensível e modular, onde usuários e desenvolvedores podem efetuar
diversas modificações no sistema. Sua arquitetura de mais alto nível caracterizada como
LAMP: Linux, Apache, MySQL, PHP, agrega ao sistema os benefícios de estabilidade e
segurança da plataforma como também uma série de ameaças e vulnerabilidades
relacionadas a mesma. Iniciativas de terceiros como o SELinux ou AppArmor, agregam
maior segurança quanto ao acesso de usuários a recursos do sistema. O hardering de
módulos do PHP fornecido pelo projeto PHP Suhosin aumenta a proteção quanto à
funções de baixo nível que podem resultar em buffer overflow ou em vulnerabilidades
na manipulação de String. Além de diversos módulos de segurança que podem ser
habilitados ou instalados no servidor httpd apache. É importante observar que a
aplicação de tais técnicas não tornam o sistema invulnerável, mas sua implementação
colabora para que o sistema se torne mais robusto como definido no conceito defense in
depth[3], que determina que caso um mecanismo de segurança falhe, outros podem
supri-lo, garantindo a proteção do sistema.
Foi relatado em 1 de agosto de 2009 no site Milw0rm[9], domínio que serve
como repositório de exploits para diversos sistemas, uma vulnerabilidade que explora
uma falha de SQL Injection no sistema Joomla, tal ataque consiste em submeter um
comando SQL através de dados de entrada disponibilizados a um cliente. A exploração
desta vulnerabilidade compromete a integridade dos dados armazenados, através da
exposição de informações indevidas, além de possibilitar a modificação de sites
gerenciados pelo CMS.
O terceiro cenário relata uma falha de buffer overflow, caracterizada quando um
sistema tenta alocar mais dados que um buffer pode suportar. O cenário de estudo é
uma vulnerabilidade apresentada no web browser Firefox. A vulnerabilidade descrita
em Milw0rm[10] faz uso de um script que, se executado no browser, interrompe sua
utilização de forma abrupta. Apesar desta falha não ser classificada como de alto
impacto, não comprometendo dados do usuário nem permitindo acesso ou elevação de
privilégio no sistema, inviabiliza momentaneamente a utilização do browser acarretando
prejuízo de usabilidade.
Os exemplos acima reforçam a tese de que segurança em sistemas de software é
essencial para o sucesso dos negócios. De acordo com a pesquisa, CSO Prioritize
Security Spending[1], realizada pelo Meta Group, o investimento na área de segurança
vem aumentando apesar da diminuição do orçamento corporativo, o que demonstra a
importância desta área. Empresas que negociam ou pretendem incluir ações na bolsa de
valores norte-americana, por exemplo, precisam estar de acordo com os requisitos da lei
Sarbanes Oxley[1]. No mercado brasileiro, instituições financeiras devem seguir um
acordo internacional denominado Basiléia, que entre algumas de suas características cita
mecanismos de segurança e auditoria em sistemas.
Desta forma já se observam projetos e metodologias que visam aumentar o nível
de segurança no desenvolvimento de software em meios acadêmicos, comunitários,
organizacionais e governamentais.
O projeto OWASP[3], por exemplo, é focado na melhoria de segurança de
aplicações, visando informar pessoas e organizações, além de possuir apoio de
organizações como Symantec, Nokia, HP, Microsoft, SalesForce dentre muitos outros.
O projeto OWASP já possui mais de 130 núcleos espalhados pelo mundo.
O Computer Emergency Response Team, CERT[13] foi desenvolvido para
coordenar a comunicação de especialistas de segurança e evitar incidentes na Internet,
buscando sempre aumentar sua participação frente a novas ameaças e funções críticas.
No Brasil, a instituição está representada pelo CERT.br[22] que é administrado pelo
Comitê Gestor da Internet no Brasil CGI.br.
5. Cenário de segurança
Estatísticas disponibilizadas pelo CERT.br[14] relatam que a quantidade de incidentes
relatados, somente nos meses de abril a junho do ano de 2009, foram de 298.191
ataques ou tentativas de ataques, sendo que apenas 1,84% destes correspondem a
ataques web, caracterizado pela instituição como: "comprometimento de servidores web
ou desconfiguração de páginas."

O estudo do CERT.br ajuda a analisar o impacto de ameaças em ambientes de

produção. Ao se verificar a baixa representação de ataques web na rede brasileira, pode-
se, equivocadamente, concluir que os sistemas são seguros. Porém deve-se observar que
o hábito de relatar ataques não é algo comum, conforme constatado pelo próprio
CERT.br, principalmente em grandes empresas. Além disso, como o número de
incidentes é muito grande, a análise do percentual de ataques web é pouco significativa,
o que não é verdade se analisar os números absolutos.
Estudos e tecnologias específicas também auxiliam na descoberta e análise de
ameaças e seus impactos agregando assim segurança como parte essencial do projeto.
Dentre estes estudos estão o projeto Top Ten[3], do OWASP, o Security Development
Lifecycle (SDL), da Microsoft[15], e o Long[16], disponibilizado pelo CERT.
O trabalho Top Ten Project[3], realizado pelo OWASP, documenta as principais
ameaças de aplicações web, é adotado por diversas empresas no mundo. Este documento
serve como referência sobre as vulnerabilidades mais comuns em aplicações web e trata
a codificação segura ao longo do ciclo de desenvolvimento de software.
O Security Development Lifecycle (SDL) da Microsoft[15] define que um
sistema seguro deve possuir as seguintes características:
• Secure by design: segurança como parte integral do processo de desenvolvimento
de software, existindo em todo o ciclo de vida da aplicação;
• Secure by default: componentes devem ser executados com o mínimo de
permissões além de possibilitarem a segurança em profundidade (defense in depth);
• Secure by deployment: realizar análise de segurança que permita aos responsáveis
configurar um nível de segurança “ideal”. Fornecer documentação para
implementação de características de segurança;

O estudo de Long[16], disponibilizado pelo CERT, analisa características de

segurança da linguagem Java, onde o autor demonstra utilidades que podem ser
comprometidas ou implementadas de forma inapropriada. É verificado pelo autor que a
linguagem Java é em sua essência segura, pois, não possui manipulação de ponteiro de
forma explícita, limites de array e strings possuem verificação automática e referência a
objetos nulos ocasionam em advertência. Além disso, operações aritméticas são
realizadas independente de plataformas e possuem verificações de bytecode que
asseguram as verificações de todas as características citadas.

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.

Ferramentas de análise de código auxiliam na identificação e localização de

falhas e bugs permitindo que os programadores tornem seu código mais seguro. A
revisão de código lista os principais problemas de segurança do software, tornando o
trabalho mais simples e eficiente. A utilização de ferramentas de análise estática torna-
se importante, pois várias linguagens de programação não foram e não são projetadas
com segurança, tornando os sistemas ainda mais vulneráveis.

Para o desenvolvimento de software , é recomendado por McGraw[2] a

utilização de ferramentas de análise estática de código por estarem, atualmente, mais
maduras que no passado. Sua origem é datada na época do advento de utilitários do
sistema Unix como grep, pipe, wc, top, less, regex, quando eram utilizadas em conjunto
realizam a busca de determinado padrão no conteúdo de um arquivo. McGraw[2] em
seu livro Security Software aborda com mais detalhes esta escala evolutiva.
Conforme observado no estudo, On the Value of Static Analysis for Fault
Detection in Software, realizado por Zheng[18], ferramentas de análise estática são
efetivas na identificação de defeitos em nível de código. Elas podem localizar muitos
padrões de falha em um tempo muito curto, porém necessitam ser configuradas
conforme regras do negócio que mudam de ambiente para ambiente. Os avisos gerados
por estas, muitas vezes geram falsos positivos, onde a ferramenta relata um bug que não
existe, e falsos negativos, onde o programa contém um bug mas a ferramenta não o
detecta. De forma a tornar a utilização de ferramentas de análise estática mais proveitosa
e maximizar seus resultados, é importante que os desenvolvedores possuam um
conhecimento mínimo quanto à segurança, visto que as ferramentas não substituem o
discernimento humano.
É aconselhável que a adoção de ferramentas de análise estática seja desde os
estágios iniciais no ciclo de desenvolvimento de software, tendo em vista a antecipação
de descoberta de falhas. Isto promove um rápido feedback, quando comparado a
descoberta de bugs em estágios avançados do desenvolvimento.
Almazan[19] aponta em seu estudo, A Comparison of Bug Finding Tools for
Java, que a análise estática de código efetuada por um conjunto de ferramentas equilibra
a quantidade de falsos positivos e falsos negativos gerados pelas ferramentas. A
utilização de várias ferramentas também colabora na realização da análise, pois estas
tendem a se complementar cobrindo testes não efetuados por outros ou realizando e
analisando testes de forma diferenciada. A correlação de eventos colabora para uma
análise mais rica do sistema.
Existem diversas ferramentas de análise estática de código dentre as quais
destacam as utilizadas no desenvolvimento deste trabalho:
• FindBugs: utiliza análise estática de código para detectar violações de boas práticas
e também realiza análises de fluxo de dados para identificação de referências nulas.
Esta ferramenta utiliza um conjunto de técnicas, onde se busca equilibrar precisão,
eficiência e usabilidade;
• PMD: realiza apenas a análise sintática do código fonte, sendo que as principais
verificações efetuadas, no módulo padrão, são as de convenções linguísticas. Possui
plugins que tornam fácil sua customização e edição de regras, além de plugins
específicos para detecção de problemas de segurança;
• LAPSE: ferramenta para auxiliar tarefas de auditoria em aplicações JEE sobre
vulnerabilidades comuns tais como: SQL Injection, XSS, Cookie poisoning,
manipulação de parâmetros dentre outros;
• Checkstyle: auxilia os desenvolvedores a manter um padrão de codificação,
identificando duplicação de código, problemas em classes, entre outros.
• Code Analysis Plugin (CAP): plugin que realiza a análise de dependência entre
pacotes e classes de um projeto java. O projeto foi baseado em um artigo publicado
por Robert Martin[18], onde o autor analisa aspectos de robustez, sustentabilidade e
reusabilidade em sistemas orientados a objetos. As métricas estabelecidas pelo autor
para aferição do resultado fazem uso da utilização de segmentação do projeto como
um todo em aferência acoplada, inferência acoplada e instabilidade.
A escolha de ferramentas como PMD e Checkstyle foi tomada tendo em vista a
observação realizada no estudo de Holzmann[11], que menciona que o “estilo” de
programação afeta o reconhecimento de falhas pelas ferramentas de análise estática e
também o relatório de erro apresentado por estas.

7. Estudo de caso: Demoiselle framework

O projeto Demoiselle[20] teve origem em uma parceria entre a Companhia de
Informática do Paraná (CELEPAR) e o Serpro que teve como o objetivo avaliar o
framework Java utilizado pelo primeiro.

O projeto é caracterizado como um framework integrador sendo responsável por

agregar frameworks especialistas, seu objetivo é padronizar e com isso aumentar a
produtividade, manutenibilidade e compatibilidade no desenvolvimento de software.
Sua utilização visa facilitar a escolha e utilização de outros frameworks além de garantir
a interoperabilidade dos sistemas entre os ministérios e autarquias do governo federal.
Segue abaixo uma imagem que demonstra a arquitetura de um framework integrador.
 Figura 1. Arquitetura de framework integrador
A padronização é caracterizada como cerne do projeto conforme consta no site
do projeto: "a idéia é que, a partir de um framework e de uma arquitetura de referência,
um conjunto de requisitos gere uma aplicação que possa ser mantida por qualquer um
que conheça os dois primeiros."[20]

O framework é segmentado em módulos, podendo sua utilização ser efetuada em

camadas específicas do código sem que para isto outra tome conhecimento. A escolha
desta arquitetura visa garantir a independência evolutiva de cada módulo além de
promover seu reuso colaborativamente conforme idealizado. O framework conta
atualmente com o apoio de instituições como CELEPAR, UFPR, DataInfo, Prodepa,
Prodemge e o Centro de Competência em Software Livre (CCSL), estando aberto a
qualquer instituição ou indivíduo que se interesse pelo mesmo.

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.

Analisar aspectos de segurança no código através da identificação de boas

práticas assim como localizar possíveis falhas e determinar o seu impacto no sistema
fazem parte do escopo do presente trabalho.

7.1. Relato dos problemas encontrados

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

De forma a verificar a adequação do framework Demoiselle as normas linguísticas da

linguagem Java e determinar se as ferramentas de análise estática de código podem
gerar falsos positivos, conforme relatado no capítulo 5, foram executados os plugins
Checkstyle e PMD. Foram observados diversos alarmes, conforme demonstra a tabela
abaixo:
Ferramenta Número de Alarmes

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.

Deve-se observar que, conforme relatado no estudo de Almazan[19], a

ferramenta PMD gera um número elevado de alarmes em sua saída.

A execução das ferramentas Findbugs e Lapse auxiliou a identificar problemas

de segurança em métodos do framework. Foi observado durante a execução das
ferramentas alarmes com diversos níveis de criticidade como, por exemplo, a não
constatação de encerramento da conexão com o banco de dados (Statement) no método
execute da classe JDBCGenericDAO. Assim como erros mais sutis como verificado
pelo plugin LAPSE que detectou duas vulnerabilidades de SQL Injection, conforme
observado na tabela a seguir e abordado na seção 6.1.3:

Ferramenta Número de Alarmes

Findbugs 14

Lapse 2
Tabela 2. Bugs detectados pelas ferramentas de análise estática

As principais vulnerabilidades identificadas estão melhor explicadas nas seções

que se seguem.

7.1.2 Retorno inadequado

Nesta primeira seção que trata de vulnerabilidades do projeto Demoiselle é verificado a

quebra de um dos pilares da segurança da informação que possibilita a violação da
integridade dos dados, através da manipulação dos dados obtidos de um método descrito
a seguir.
O “segmento de código 1” referente a classe ApplicationRuntimeException, onde
o método getArguments faz retorno direto de um array ao objeto invocador, demonstra
uma vulnerabilidade que possibilita a um atacante manipular os dados do array.
public Object[] getArguments() {
return this.arguments;
}

Segmento de Código 1. Retorno de array vulnerável.

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;
}

Segmento de Código 2. Retorno adequado de um array.

7.1.3 Validação imprópria

Esta seção demonstra a não conformidade do projeto Demoiselle na validação da query
SQL recebida para execução em um SGBD, assim como discute o impacto da escolha
da interface Statement para execução de comandos SQL.
A validação imprópria de entrada de dados, apontada como um dos 25 erros
mais perigosos no desenvolvimento de software pelo SANS[6]. No framework
estudado, esta falha pode ser verificada em diversos métodos das classes de persistência
do framework como, por exemplo, nas implementações JPAGenericDAO,
JDBCGenericDAO e HibernateGenericDAO. É demonstrado no “segmento de código
3”, onde a String SQL, recebida pelo método execute é verificada apenas como null.
Não foi feita qualquer validação conteúdo da string como, por exemplo, caracteres de
escape ou outro tipo de validação. Um usuário mal intencionado poderia comprometer a
integridade dos dados além de poder obter acesso completo a base de dados do sistema.
Uma outra falha também relacionada ao pacote de persistência trata da
manipulação da conexão com o banco de dados, implementada pela classe
JDBCGenericDAO. Neste caso, diversos métodos que lidam com a conexão com o
banco de dados não a encerram adequadamente ao finalizar sua utilização. Tal prática
pode acarretar alocação de recursos desnecessários ao servidor comprometendo seu
desempenho.

public final int execute(String sql) throws

PersistenceJDBCException {
 if (sql == null) throw new
PersistenceJDBCException("SQL is null");
...
Statement st =
JDBCUtil.getInstance().getConnection().
createStatement();
result = st.executeUpdate(sql);
...}

Segmento de Código 3. Segmento de código vulnerável a SQL Injection.

Documentos que analisam a prevenção de SQL Injection disponibilizados pelo

projeto OWASP[3], assim como estudos de recursos da linguagem Java realizados por
Long[16] e Williams[17] recomendam a utilização da interface PreparedStatement da
API JSE. Sua vantagem se encontra através da utilização de um objeto que representa
uma query SQL pré-compilada que aumenta o desempenho do comando SQL além de
ser mais seguro contra ataques de SQL Injection, tendo em vista que o usuário
informará os parâmetros necessários para execução do comando.
Portanto, a sugestão para correção da vulnerabilidade apresentada é efetuar a
validação dos dados de entrada assim como realizar a utilização da interface
PreparedStatement pelo framework. A validação de entrada pode ser efetuada através da
implementação da API ESAPI disponibilizada pelo projeto OWASP[2] conforme
demonstra o “segmento de código 4”.

public final int execute(String sql) throws

PersistenceJDBCException {
String trustedQuery =
ESAPI.encoder().encodeForSQL(
new OracleCodec(), sql);
...
PreparedStatement pst =
JDBCUtil.getInstance().getConnection().
createStatementPreparedStatement();
result = pst.executeUpdate(sql);
...}

Segmento de Código 4. Segmento de código que implementa defesa a SQL

Injection.
7.1.4 Tratamento inadequado de exceção

Nesta seção é exemplificado um caso de tratamento de exceção inadequado, onde a

ocorrência de uma exceção pode causar efeitos indesejados a um sistema.
O método getFieldByName da classe JDBCGenericDAO possui um tratamento
de exceção inadequado. A captura da exceção, além de não prover mecanismos de
recuperação de falha, retorna null o que propicia uma exceção de NullPointerException.
 O tratamento adequado da exceção inclui o registro do problema em um log para
consulta futura e, ou a recuperação do erro ou a sinalização adequada do problema para
o método cliente.
A não conformidade de tal característica pode implicar no vazamento de
informações internas do sistema além de poder acarretar a interrupção da aplicação de
forma abrupta, através de uma exceção de RunTime (NullPointerException).
private Field getFieldByName(A object, String
name) throws PersistenceJDBCException {
...
} catch (SecurityException e) {
return null;
}
}

Segmento de Código 5. Captura inadequada no lançamento de exceção.

7.1.5 Utilização inadequada de cookie

Outro problema observado trata da manipulação de cookies, onde é definido em nível de

código o tempo de vida do cookie. O padrão recomendado, de forma a assegurar uma
melhor utilização de tal recurso seria efetuar a utilização de cookies não persistente, não
informando o tempo de vida do mesmo. Tal característica garante que o cookie seja
descartado com o encerramento do browser, evitando o furto de informações pessoais
e/ou a personificação de usuário.
A utilização de httpOnly também é recomendada a fim de se evitar ataques de
XSS. Tal recurso impede a utilização do cookie por scripts. Outro recurso recomendado
é a utilização da flag secure que indica ao browser que o cookie somente será
transmitido em conexões seguras, que utilizem SSL.
public static final void
saveCookie(HttpServletResponse response, String
cookieName, String cookieValue, String path) {
int maxAge = (10000 + 3600) * 24 * 30;
saveCookie(response, cookieName, cookieValue,
path, maxAge);}

Segmento de Código 6. Implementação insegura do TTL de um cookie.

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