Instituto de Cincias Exatas

Departamento de Cincia da Computao

Curso de Especializao em Gesto da Segurana da Informao e
Comunicaes

RENATO COSTA ALVES DE SOUSA

Processo Seguro de Desenvolvimento de Software

Uma abordagem para aumento da segurana das aplicaes Web no Ministrio
Pblico Federal

Braslia
2011
 Renato Costa Alves de Sousa

Processo Seguro de Desenvolvimento de Software

Uma abordagem para aumento da segurana das aplicaes Web no Ministrio
Pblico Federal

Braslia
2011
Renato Costa Alves de Sousa
 Processo Seguro de Desenvolvimento de Software
Uma abordagem para aumento da segurana das aplicaes Web no Ministrio
Pblico Federal

Monografia apresentada ao Departamento

de Cincia da Computao da
Universidade de Braslia como requisito
parcial para a obteno do ttulo de
Especialista em Cincia da Computao:
Gesto da Segurana da Informao e
Comunicaes.

Orientador: Genana Nunes Rodrigues

Universidade de Braslia
Instituto de Cincias Exatas
Departamento de Cincia da Computao

Braslia
2011

3
 Desenvolvido em atendimento ao plano de trabalho do Programa de
Formao de Especialistas para a Elaborao da Metodologia Brasileira
de Gesto da Segurana da Informao e Comunicaes - CEGSIC
2009/2011.
2011 Renato Costa Alves de Sousa. Qualquer parte desta publicao
pode ser reproduzida, desde que citada a fonte.

de Sousa, Renato Costa Alves

Processo Seguro de Desenvolvimento de Software: Uma
abordagem para aumento da segurana das aplicaes Web no
Ministrio Pblico Federal / Renato Costa Alves de Sousa. Braslia: O
autor, 2011. 62 p.; Ilustrado; 25 cm.
Monografia (especializao) Universidade de Braslia. Instituto de
Cincias Exatas. Departamento de Cincia da Computao, 2011.
Inclui Bibliografia.
1. Processo de Desenvolvimento de Software. 2. Segurana 3.
Aplicaes Web.
CDU 004.0561

4
Errata2

5
Ata de Defesa de Monografia
Monografia de Especializao Lato Sensu, defendida sob o ttulo Processo Seguro
de Desenvolvimento de Software: Uma abordagem para aumento da segurana das
aplicaes Web no Ministrio Pblico Federal, por Renato Costa Alves de Sousa,
em 09 de dezembro de 2011, no Auditrio do Departamento de Cincia da
Computao da UnB, em Braslia - DF, e aprovada pela banca examinadora
constituda por:

___________________________________________________________________
Prof. Genana Nunes Rodrigues
Departamento de Cincia da Computao - Universidade de Braslia
Orientador

___________________________________________________________________
Prof. Rodrigo Bonifcio de Almeida
Departamento de Cincia da Computao - Universidade de Braslia

___________________________________________________________________
Prof. Maristela Terto de Holanda
Departamento de Cincia da Computao - Universidade de Braslia

Prof. Dr. Jorge Henrique Cabral Fernandes

Coordenador do Curso de Especializao em Gesto da Segurana da Informao e
Comunicaes CEGSIC 2009/2011

6
Agradecimentos

Agradeo a todos aqueles que

cooperaram direta ou indiretamente
na consecuo do presente trabalho.

7
 Quem chega cedo ao campo de batalha
aguarda a chegada do inimigo e est pronto para combater.

Quem chega tarde ao campo de batalha tem que apressar-se e

j comea o combate com as foras exauridas.

Sun Tzu, em A Arte da Guerra.

8
Lista de Tabelas

Tabela 1 Vulnerabilidades investigadas ..........................................................29

Tabela 2 Vulnerabilidades atendidas ..............................................................47

Tabela 3 - Vulnerabilidades Parcialmente Atendidas.........................................47

Tabela 4 - Vulnerabilidades no atendidas ........................................................48

9
Sumrio

Ata de Defesa de Monografia......................................................................................6

1 Delimitao do Problema .......................................................................................14

1.1 Introduo........................................................................................................14

1.2 Formulao da situao problema (Questes de pesquisa)............................15

1.3 Objetivos e escopo ..........................................................................................16

1.3.1 Objetivo Geral ...........................................................................................16

1.3.2 Objetivos Especficos ................................................................................17

1.3.3 Escopo ......................................................................................................17

1.4 Justificativa ......................................................................................................17

1.5 Hipteses.........................................................................................................19

2 Reviso de Literatura e Fundamentos ...................................................................20

2.1 Estrutura do CLASP ........................................................................................20

2.1.1 Vises do CLASP......................................................................................21

2.1.2 Casos de Uso de Vulnerabilidades ...........................................................22

2.2 Referenciais Conceituais .................................................................................22

2.3 Argumentos do Pesquisador............................................................................23

3 Metodologia............................................................................................................25

4 Resultados .............................................................................................................30

4.1 Causas bsicas de vulnerabilidades que se aplicam ao desenvolvimento de

software do sistema nico.....................................................................................30
10
 4.1.1 Erros de tipo e intervalo ............................................................................31

4.1.2 Problemas de ambiente ............................................................................34

4.1.3 Erros de sincronizao e temporizao ....................................................37

4.1.4 Erros de protocolo .....................................................................................40

4.1.5 Erros gerais de lgica................................................................................44

4.2 Resultado da pesquisa ....................................................................................46

5 Discusso...............................................................................................................49

5.1 Possveis consequncias do no tratamento dos problemas ..........................49

5.1.1 Erros de tipo e intervalo ............................................................................50

5.1.2 Problemas de ambiente ............................................................................51

5.1.3 Erros de sincronizao e temporizao ....................................................51

5.1.4 Erros de protocolo .....................................................................................52

5.1.5 Erros gerais de lgica................................................................................53

5.2 Discusses sobre os resultados ......................................................................53

6 Concluso ..............................................................................................................55

7 Referncias e Fontes Consultadas ........................................................................57

11
Resumo

O presente trabalho tem como objetivo fazer uma anlise dos problemas de
segurana elencados pelo CLASP (Comprehensive, Lightweight Application Security
Process) de forma a identificar quais destes problemas se aplicam arquitetura do
Sistema nico. Assim verificar, dentre os problemas selecionados, quais esto
presentes ou no no processo de desenvolvimento, implantao e operao deste
sistema.
Dessa forma o trabalho ir abordar temas como os requisitos de um processo
seguro para desenvolvimento de software, razes que ocasionam o
desenvolvimento de um software inseguro, as principais prticas que contribuem
para a segurana de uma aplicao, como mitigar as principais falhas de segurana
introduzidas durante as vrias fases do processo de desenvolvimento de software,
entre outros aspectos do desenvolvimento de software, tendo como base o Sistema
nico do Ministrio Pblico Federal.

12
Abstract

This study aims to analyze the security issues listed by the CLASP
(Comprehensive, Lightweight Application Security Process) to identify which of these
issues apply to the architecture of the System. Therefore check, among the selected
problems, which are present or not in the process of development, deployment and
operation of this system.
The work will address issues such as the requirements of a secure process for
software development, reasons that cause the development of an insecure software,
the key practices that contribute to the security of an application, how to mitigate
major security flaws introduced during the various phases of software development,
among other aspects of software development, based on the Sistema nico of
Ministrio Pblico Federal.

13
1 Delimitao do Problema

1.1 Introduo
Com a evoluo dos sistemas de software no acompanhada por uma evoluo
do processo de desenvolvimento desses sistemas, os problemas de segurana
envolvendo computadores e softwares so frequentes, generalizados e muitas vezes
apresentam consequncias srias para as atividades as quais esses sistemas do
suporte. Nos ltimos anos, houve uma facilidade do acesso informao atravs de
meios de comunicao como livros, televiso e internet. Essa facilitao potencializa
um nmero de usurios mal intencionados, e potencializa tambm a capacidades
destes. Isso faz com que as propriedades de segurana da informao que devem
estar presentes em uma aplicao necessitem de uma maior ateno. Ateno esta
que no deve se efetivar apenas durante a operao do sistema, mas sim durante
todo o ciclo de vida do produto: desde a sua concepo at a sua entrada em
produo e operao. Para isso preciso que se estabelea um processo de
desenvolvimento de software que assegure a segurana do produto desde a sua
concepo.
A tarefa de implantar um processo de desenvolvimento padronizado em uma
organizao no tarefa trivial. Envolve uma mudana de paradigma da equipe
envolvida nos projetos. Envolve ainda outro fator mais crtico que o
comprometimento organizacional com a mudana, o que implica em investimento de
recursos no processo, tanto recursos financeiros quanto recursos pessoais.
Porm no basta definir um processo padro, preciso segui-lo em todos os
produtos de software. Alm do mais preciso que esse modelo de processo seja
eficiente, ou seja, que produza realmente os resultados esperados. Para se
conseguir os resultados almejados com a implantao de um processo seguro de
desenvolvimento de software h uma srie de prticas, j testadas com sucesso no

14
mercado que podem auxiliar e incrementar a probabilidade de se desenvolver
softwares seguros.
Este trabalho faz um levantamento das principais causas de insegurana no
processo de desenvolvimento de software no Ministrio Pblico Federal (MPF), mais
especificamente na Procuradoria Geral da Repblica (PGR), sugere boas prticas a
serem implementadas por um processo seguro de desenvolvimento de software, e
apresenta metodologias para se garantir a qualificao do processo implementado.
Para isso o contexto escolhido para a pesquisa foi o do sistema nico, que um
sistema em fase de desenvolvimento na PGR e que atender todo o MPF. O
sistema nico um sistema de gesto integrada de expedientes. Expediente pode
ser entendido como uma categoria genrica de documentos que inclui: autos
administrativos, autos judiciais, manifestaes judiciais, documentos administrativos,
entre outros tipos de documentos organizacionais. Quando totalmente implantado
este sistema gerenciar toda a tramitao de expedientes do MPF, controlando a
tramitao tanto de expedientes fsicos como eletrnicos.
O sistema nico um sistema Web, desenvolvido em Java. Utiliza frameworks
como Struts e Spring para a camada de controle e para prover injeo de
dependncias. Na camada de viso utiliza-se o framework ExtJS, que um
framework de JavaScript. E para a camada de persistncia utilizado o framework
Hibernate em conjunto com o banco de dados Oracle. Como servidor de aplicao o
ambiente utilizado o provido pelo WebLogic, tambm da empresa Oracle. Portanto
um sistema que utiliza diversas ferramentas padres de mercado em sua
arquitetura.

1.2 Formulao da situao problema (Questes de pesquisa)

Atravs das pesquisas nas diversas disciplinas do curso, bem como da
observao direta e participativa do processo de desenvolvimento de software do
Ministrio Pblico da Unio (MPU), mais especificamente da Procuradoria Geral da
Repblica (PGR), rgo central do MPU, verificou-se a necessidade de um
tratamento dos aspectos de segurana da informao durante o desenvolvimento

15
das aplicaes neste rgo, aspectos estes que melhor sero atendidos se
estiverem previstos no processo de desenvolvimento.
Observou-se que os tratamentos de segurana empregados advm de
iniciativas unilaterais de cada desenvolvedor. Apesar dos esforos individuais, essa
prtica pode resultar em possveis falhas de segurana que sero exploradas
durante esse trabalho.

1.3 Objetivos e escopo

O cenrio observado na Procuradoria Geral da Repblica no diferente de
outros rgos da Administrao Pblica Federal: correria para cumprir prazos,
muitas vezes determinados por questes polticas; no definio de um processo
consistente para o desenvolvimento de software; no reconhecimento do setor de
tecnologia da informao como estratgico para o alcance dos objetivos do MPU;
bem como a viso de que a tecnologia da informao apenas um mal necessrio,
entre outros fatores.
Este cenrio introduz uma srie de dificuldades para o desenvolvimento de
aplicaes seguras. fato que uma equipe desmotivada, e no reconhecida pela
alta administrao, mesmo que empenhada em seus afazeres, no ser capaz de
desenvolver de forma unilateral aplicaes seguras.
Para ajudar na concepo de um processo seguro de desenvolvimento de
software possvel adotar algumas das melhores prticas sugeridas pelo CLASP
(Comprehensive, Lightweight Application Security Processo). O CLASP um modelo
de processo de desenvolvimento de software seguro muito reconhecido,
especificado pelo Open Web Application Security Project (OWASP,2010. Em
diversos casos concretos possvel associar o emprego das tcnicas sugeridas por
este modelo com o incremento da segurana das aplicaes desenvolvidas sob
estas prticas.

1.3.1 Objetivo Geral

O objetivo desse trabalho de analisar os aspectos de segurana da
informao do processo de desenvolvimento de software no Ministrio Pblico
Federal, mais especificamente na Procuradoria Geral da Repblica, que a
entidade central deste rgo e de todo o Ministrio Pblico da Unio.

16
 Assim esse trabalho tem como objetivo encontrar as vulnerabilidades
presentes no Sistema nico. Demonstrar que desejvel o emprego das melhores
tcnicas de desenvolvimento de software seguro propostas pela OWASP no
contexto do MPF.
Dessa forma demonstrar que o emprego de tcnicas e melhores prticas no
processo de desenvolvimento de software no MPF pode trazer um ganho de
segurana da informao nas aplicaes desenvolvidas, bem como a reduo de
custos com retrabalho e eventuais falhas de segurana.

1.3.2 Objetivos Especficos

So objetivos especficos desse estudo de caso:
Selecionar os problemas de segurana previstos pelo CLASP que se
aplicam ao caso do Sistema nico.
Pesquisar as vulnerabilidades selecionadas, de acordo com o item
anterior, que no so tratadas pelo Sistema nico.
Apresentar as melhores prticas que podem ser aplicadas no processo
de desenvolvimento de software no MPF.

1.3.3 Escopo
O estudo de caso ser aplicado na equipe de desenvolvimento de software da
PGR. Mais especificamente ser feito um estudo de caso baseado no
desenvolvimento do Sistema nico, atualmente o sistema mais estratgico para o
MPF.

1.4 Justificativa
O desenvolvimento do Sistema nico uma tarefa crtica e de extrema
importncia para a eficincia do Ministrio Pblico Federal no cumprimento do seu
dever perante a sociedade. Visto que um sistema que integrar toda a tramitao
dos processos deste rgo.
Falhas de segurana neste sistema podem incorrer em situaes
constrangedoras para o rgo, bem como comprometer o seu funcionamento, alm
de poder enquadrar o rgo na ilegalidade. Dentre outras possvel citar as

17
seguintes situaes que podem vir acontecer caso vulnerabilidades neste sistema
venham a ser exploradas:
Acesso por pessoas no autorizadas a um processo sigiloso;
Vazamento de informaes no autorizadas para a mdia;
Instabilidade do sistema, comprometendo processos urgentes como
Habeas corpus;
Comprometimento das atividades dos servidores e membros do MPF;
Explorao de vulnerabilidades do sistema usurios mal intencionadas
e hackers.

Esses e outros fatores podem comprometer o funcionamento da organizao,

alm de denegrir sua imagem perante a sociedade.

18
1.5 Hipteses

Verificou-se, atravs de observao participativa, ou seja, a observao

realizada atravs da participao do autor no processo de desenvolvimento de
software, uma iniciativa de estabelecimento de um processo para desenvolvimento
de softwares no MPF. Porm essa iniciativa partiu da prpria equipe de
desenvolvimento devido insatisfao com a qualidade e com a forma como so
conduzidas as atividades de desenvolvimento. Assim, o momento oportuno para a
abordagem, das melhores prticas de segurana no desenvolvimento do processo
proposto ao final desse trabalho.
Atravs da pesquisa realizada neste trabalho espera-se demonstrar:
No h um processo definido para o desenvolvimento de software no MPF;
No se emprega as melhores prticas de desenvolvimento seguro de
software;
H o desconhecimento por parte da equipe de algumas vulnerabilidades que
podem ser introduzidas durante a fase de desenvolvimento;
O CLASP contempla as atividades que asseguram o desenvolvimento de
software com segurana;
A utilizao da linguagem Java, devido ao seu nvel de amadurecimento,
auxilia na preveno de diversas vulnerabilidades.

19
2 Reviso de Literatura e Fundamentos

A segurana das aplicaes no est ligada somente a tcnicas de segurana

da linguagem de programao. preciso haver uma abordagem voltada para
segurana durante todo o processo de desenvolvimento.
Esta abordagem deve abranger aspectos intrnsecos prpria infraestrutura
da aplicao, como servidores, linguagem de programao, segurana de rede,
entre outros fatores. Porm deve abranger tambm os aspectos extrnsecos, como o
processo de desenvolvimento, a qualificao da equipe no quesito de
desenvolvimento com segurana, alm da aplicao das melhores prticas de
segurana no desenvolvimento de software.
O Open Web Application Security Project (OWASP) explora as melhores
prticas que podem ser aplicadas no desenvolvimento de software para garantir a
segurana da informao. O Comprehensive, Lightweight Application Security
Processo (CLASP), que numa traduo livre seria Processo Leve e Abrangente de
Segurana de Aplicaes, um conjunto de componentes de processo orientados a
atividade e baseados em papis, cujo ncleo composto por melhores prticas para
agregar segurana no ciclo de vida de desenvolvimento de software, j em
andamento ou em fase inicial, de forma estruturada, repetvel e mensurvel.

2.1 Estrutura do CLASP

O CLASP projetado de forma a facilitar a integrao de suas atividades com

um processo de desenvolvimento de software existente. Para isso cada atividade do
CLASP dividida em componentes de processos discretos e ligado a um ou mais

20
papis no projeto. Dessa forma, o CLASP prov orientao aos participantes do
projeto que facilitam a integrao das melhores prticas em sua forma de trabalho.
O que, de acordo com afirmao do prprio CLASP, resulta em aumentos
incrementais de segurana facilmente realizvel, repetvel e mensurvel.
Outro item que aumenta a usabilidade do CLASP e facilita a utilizao de suas
melhores prticas em um processo j existente a definio de um dicionrio de
vulnerabilidades. Esse dicionrio ajuda a equipe de desenvolvimento evitar ou tratar
erros especficos, tanto de projeto quanto de codificao, erros esses que podem
conduzir a vulnerabilidades de segurana. O ponto forte desse dicionrio de
vulnerabilidades sua taxonomia flexvel, que uma estrutura de classificao que
permite a equipe de desenvolvimento rapidamente localizar a informao de vrias
perspectivas. Como exemplo pode-se citar a busca por: tipo do problema; categoria
do tipo de problema; perodo de exposio; consequncias da vulnerabilidade
eventualmente explorada; plataformas e linguagens de programao afetadas;
avaliao do risco, entre outras formas de localizao da informao desejada.
O CLASP pode ser didaticamente estruturado da seguinte forma:
Vises do CLASP
Recursos do CLASP
Casos de Uso de Vulnerabilidades

2.1.1 Vises do CLASP

Os processos do CLASP so estruturados em cinco nveis de perspectiva
chamados de vises. Essas vises so decompostas em atividades que por sua vez
contm componentes de processos. Essa estrutura Vises > Atividades >
Componentes de Processos permite um rpido entendimento dos processos do
CLASP, como os componentes interagem entre si, e como aplicar estes conceitos
ao ciclo de vida de desenvolvimento de software especfico.
As vises do CLASP so as seguintes:
Conceitos
Viso baseada em papis
Viso de avaliao de atividades
Viso de implementao de atividades
Viso de vulnerabilidades

21
2.1.2 Casos de Uso de Vulnerabilidades
Os Casos de Uso de Vulnerabilidades do CLASP descrevem condies sob as
quais servios de segurana podem se tornar vulnerveis nas aplicaes. Os Casos
de Uso do CLASP fornecem aos usurios exemplos, especficos e de fcil
entendimento, da relao de causa e efeito entre o projeto e implementao sem
conscincia de segurana e as possveis vulnerabilidades nos servios bsicos de
segurana por exemplo: autenticao, confidencialidade, disponibilidade,
responsabilidade e no repdio.
Os Casos de Uso de Vulnerabilidades do CLASP so baseados nos seguintes
componentes de arquitetura mais comuns:
Unix Monoltico
Mainframe Monoltico
Arquitetura distribuda (HTTP(S) e TCP/IP)
Este trabalho, devido ao contexto da aplicao que uma aplicao WEB,
concentrar seus esforos no terceiro componente de arquitetura listado, ou seja, na
arquitetura distribuda.
Pode-se entender os Casos de Uso do CLASP como uma ponte entre a viso
de conceitos do CLASP e o dicionrio de vulnerabilidades (na Viso de
Vulnerabilidades), uma vez que eles provm exemplos especficos de servios de
segurana se tornando vulnerveis nas aplicaes.

2.2 Referenciais Conceituais

Um software pode ser composto por apenas algumas poucas dezenas de linhas
de cdigo construdas por um programador em poucas horas, bem como pode ser
composto por milhes de linhas de cdigo, imagens, dados de configurao,
documentao etc, resultantes de um laborioso processo envolvendo centenas de
pessoas que trabalham de forma coordenada durante vrios anos. Existe, portanto,
uma variedade de tipos de software, mas conforme Stair e Reynolds (2006), os
softwares podem ser classificados em dois tipos principais: software de sistema, que
so os que controlam as operaes bsicas de um computador (sistema opera-
cional, dentre outros) e software de aplicao para fins especficos, como, por
22
exemplo, o que realiza o controle financeiro de uma empresa especfica. O software
de aplicao pode ser chamado simplesmente de aplicao ou aplicativo e o foco
desse texto.
Um processo de software um conjunto de atividades e resultados associados,
desenvolvidos ciclicamente (como qualquer processo) em uma organizao
produtora de software, e que busca gerar um software com qualidade ou atributos
esperados. Segundo Sommerville (2005), so atividades fundamentais comuns a
todos os processos de software:
Especificao: as funcionalidades do software e as restries em sua operao
devem ser previamente definidas em alguma fase do processo.
Desenvolvimento: o processo deve fazer com que o software a ser produzido
atenda s suas especificaes.
Validao: o processo deve validar o software, para garantir que ele faa o que
o cliente deseja.
Evoluo: o processo deve permitir que software, durante sua evoluo ao
longo de vrias verses, continue a atender peridica mudana de
necessidades de seus clientes e usurios.
Toda organizao adota um processo de desenvolvimento de software, mesmo que
ele seja catico. A melhoria de processos de produo de software depende, muitas
vezes, de envolvimento de consultores em melhoria de processo.

2.3 Argumentos do Pesquisador

Para se implementar software seguro preciso superar uma srie de problemas
durante o desenvolvimento. A resoluo desses problemas requer a utilizao de
processos consistentes. possvel citar, de forma livre, algumas caractersticas que
espera-se encontrar em um processo de desenvolvimento de software seguro, por
exemplo:
Um processo seguro deve cobrir todo o ciclo de vida do software, desde os
requisitos iniciais, passando pelo projeto, desenvolvimento, entrega,
manutenes corretivas e evolutivas, ou seja, todas as fases do ciclo de vida do
software.
O processo deve ser bem definido para que novos utilizadores possam
compreend-lo, suport-lo, mant-lo e aprimor-lo. Todos os produtos e todas as
atividades do processo devem poder ser medidos com preciso.

23
 O processo deve possuir um dono, deve ser suportado e estar sempre
disponvel, alm de ser constantemente atualizado para refletir as mudanas no
ambiente organizacional.
O processo deve ser econmico e prtico de se utilizar e servir para o
desenvolvimento de uma grande variedade de tipos de produtos.
O processo deve estabelecer e manter a integridade do produto durante todo o
ciclo de vida, comeando com os trabalhos de requisitos e projeto incluindo
rigoroso gerenciamento de configurao e de implantao.
O processo tambm deve fornecer os meios para assegurar a integridade e
honestidade de todas as pessoas envolvidas no processo de desenvolvimento,
melhoria, testes e implantao do produto.
Alm dos requisitos apresentados, um processo deve possibilitar a sua
customizao. Para ser amplamente aplicvel, um processo seguro de
desenvolvimento deve suprir as necessidades de uso de cada organizao em que
venha a ser aplicado. Isso significa permitir s equipes de software ajustar o
processo para que possam usar novos mtodos, ferramentas e tecnologias. A
organizao deve ser capaz de acomodar os detalhes especficos de seu negcio
dentro do processo, especificar o mtodo e as tecnologias que o seu pessoal ir
utilizar.
Esses so alguns dos requisitos para um processo seguro de desenvolvimento
de software. A segurana de um processo requer prticas de Engenharia de
Software, treinamento extensivo, trabalho consistente e disciplinado, dados
compreensveis e gerenciamento capaz e efetivo alm de treinamentos de suporte.
O processo que atender aos requisitos listados apresentar grandes chances de
desenvolver produtos com qualidade e segurana.

24
3 Metodologia

Para atingir os objetivos descritos no primeiro captulo, a pesquisa se dedica

a identificar as melhores prticas previstas pelo CLASP que se aplicam ao caso do
sistema em questo e analisar, em forma de estudo de caso, o desenvolvimento de
desse sistema estratgico para o Ministrio Pblico Federal, que o Sistema nico,
assim chamado, pois ser um sistema complexo que unificar toda a tramitao de
processos dentro do rgo.
A pesquisa tomar como base para a anlise dos aspetos de segurana do
processo de desenvolvimento de software do MPF as melhores prticas descritas no
CLASP. O Sistema nico j se encontra em desenvolvimento e alguns dos seus
mdulos j esto em produo. um sistema que faz o controle da tramitao dos
expedientes do MPF. Entenda-se por expediente no contexto da aplicao como a
categoria mais abrangente dos documentos que tramitam no MPF, suas
subcategorias seriam: documentos administrativos, autos administrativos, autos
judiciais, entre outras subcategorias de expedientes. O atual processo de
desenvolvimento no contempla, pelo menos no explicitamente, os aspectos de
segurana. Assim, a pesquisa pode vir a contribuir de forma ativa com a definio do
processo e com o incremento da segurana da aplicao.
Os problemas de segurana em software no so facilmente classificados em
categorias distintas. Um problema de uma categoria pode desencadear
consequncias em diversas outras categorias. Por exemplo, um defeito de
disponibilidade, dependendo das circunstancias, pode muito bem ser um defeito de
segurana. Entender o ncleo do risco geralmente requer uma ampla noo
arquitetural do problema, porm algumas vezes requer um entendimento de
detalhes especficos do cdigo envolvido.
25
 Apesar disso, o CLASP apresenta um catlogo que classifica os temas que
podem levar a problemas de segurana. Este catlogo chamado pelo modelo de
dicionrio de vulnerabilidades.
O dicionrio de vulnerabilidades do CLASP identificou cento e quatro tipos de
problemas, entenda-se por problemas, causas bsicas de vulnerabilidades. Estes
cento e quatro tipos de problemas foram divididos em cinco categorias de alto nvel.
Apesar dessa diviso, um tipo de problema pode ser classificado em mais de uma
categoria. As cinco categorias so:
Erros de tipo e intervalo
Problemas de ambiente
Erros de sincronizao e temporizao
Erros de protocolo
Erros gerais de lgica
Nem todos os cento e quatro tipos de erro so aplicveis ao contexto do
Ministrio Pblico Federal. Alguns so at aplicveis ao MPF como um todo, porm
no se aplicam ao desenvolvimento de software no que se refere ao caso restrito
pesquisado neste trabalho. Assim, esse trabalho faz uma analise dos tipos de erros
que se aplicam ao caso estudado, e verifica atravs de pesquisas, e participao
ativa no desenvolvimento de software do Sistema nico quais os tipos de problemas
de segurana da informao que so levados em considerao, ou no, durante o
processo de desenvolvimento deste sistema.
A categoria dos dados coletados qualitativa e quantitativa. No que tange a
abordagem qualitativa, feita uma abordagem das principais consequncias dos
problemas de segurana no tratados durante a fase de desenvolvimento. E no que
tange a abordagem quantitativa, feita uma anlise do nvel de maturidade do
processo de desenvolvimento do Sistema nico segundo as prticas sugeridas pelo
CLASP.
A anlise do nvel de segurana do processo feita atravs de entrevistas
com integrantes da equipe de desenvolvimento, alm de pesquisa participativa, ou
seja, com a participao direta na equipe de desenvolvimento, em busca de
informaes que possam revelar se determinado problema, elencado pelo CLASP,
levado em considerao ou no durante o processo de desenvolvimento.

26
 A equipe na qual este trabalho se concentra composta por cerca de doze
pessoas, podendo variar em alguns momentos de acordo com frias e mudanas de
equipe. Devido a alguns obstculos no decorrer da pesquisa, como muitos
integrantes de frias, muitas demandas para uma equipe pequena, greves, entre
outros percalos, as entrevistas puderam ser realizadas apenas com trs integrantes
desta equipe. O que d um total de quatro envolvidos (trs entrevistados e o autor),
quantia relativamente pequena, porm os trs entrevistados trabalham pode-se dizer
desde o comeo do Sistema nico, portanto possuem ampla experincia neste
sistema.
As entrevistas consideram so realizadas da seguinte maneira: o autor
apresenta cada uma das trinta vulnerabilidades a cada um dos entrevistados, suas
opinies podem ser de que o item atendido, parcialmente atendido ou no
atendido. Em cada um dos itens, o autor apresenta ao entrevistado uma explicao
baseada no CLASP, ou em mais fontes quando necessrio.
Caso a explicao no seja suficiente para formar a opinio do entrevistado,
so feitas pesquisas em cdigos-fonte, sistema de arquivos, servidores e outas
fontes at que se chegue a uma concluso. Caso no se chegue a uma concluso o
entrevistado pode deixar a resposta em branco, situao que se verificou com um
entrevistado em um item apenas. No caso de um entrevistado no chegar a uma
concluso o autor poderia promover um debate entre mais de um entrevistado para
discutir o item em questo, porm optou-se por no abrir esta possibilidade para que
as opinies no fossem influenciadas de alguma forma. Dessa forma, a metodologia
do trabalho pode ser sintetizada como nos pargrafos a seguir.
A questo de pesquisa ser: Qual o nvel de aderncia do processo de
desenvolvimento de software do Ministrio Pblico Federal aos aspectos de
segurana da informao elencados pelo CLASP?
Sero investigados diversos aspectos de segurana envolvidos no processo
de desenvolvimento de software. A formada da pesquisa ser o de um estudo de
caso sobre o processo de desenvolvimento de software no Ministrio Pblico
Federal de forma a observar quais problemas de segurana da informao so
levados em considerao durante a fase de desenvolvimento de software.
Os dados levantados durante a pesquisa sero qualitativos e quantitativos.
Para fazer o levantamento dos dados sero utilizadas diversas fontes, pode-se citar
27
como exemplo de fontes consultadas: a anlise do atual processo de
desenvolvimento, revises bibliogrficas, entrevista, consulta de stios oficiais na
internet. A coleta desses dados ser feita atravs de entrevistas com integrantes da
equipe de desenvolvimento com o objetivo de verificar quais problemas de
segurana da informao so identificados e atendidos durante a fase de
desenvolvimento.
Os problemas de segurana da informao previstos pelo CLASP que se
aplicam ao caso de desenvolvimento em estudo e que sero verificados nas
entrevistas e atravs de anlise participativa so os contidos na Tabela 1.

28
 Tabela 1 Vulnerabilidades investigadas

Erros de tipo e intervalo Problemas de Ambiente

Desateno ao caso padro (default) do Switch Busca atravs de caminho relativo
Cross-site scripting Basear-se no nvel de escopo de pacote
Injeo de comando Publicao de dados privados ao utilizar classes internas
Injeo por reflexo Confiana nos eventos de sistema
Vazamento de informaes atravs da clonagem de
SQL injection classes
Desserializao de dados no confiveis Vazamento da informao atravs de serializao
Estouro do buffer esttico interno

Erros de protocolo Erros gerais de lgica

Falha na criptografia de dados Comparao invs de atribuio
Armazenamento de senhas em formato recupervel Delimitao incorreta de blocos de cdigo
Usar campos referenciados para autenticao Omisso da instruo break
Utilizar um algoritmo de criptografia j quebrado ou
no mais seguro Limpeza inadequada no lanamento de excees
Uso de sistema de senhas Exceo no capturada
Utilizao de apenas uma forma de autenticao
No aplicao do envelhecimento de senhas

Erros de sincronizao e temporizao

Comparao de classes por nome
Passagem de objetos mutveis para mtodos no
confiveis
Vazamento acidental de informaes sensveis
atravs de mensagens de erro
Vazamento acidental de informaes sensveis
atravs de dados enviados
Condies de concorrncia em ambientes Multi-
threaded

29
4 Resultados

Essa seo apresenta uma anlise dos tipos de erros que se aplicam ao caso
estudado, e verifica atravs de pesquisas, e participao ativa no desenvolvimento
de software do sistema nico, quais os tipos de problemas de segurana da
informao que so levados em considerao, ou no, durante o processo de
desenvolvimento deste sistema.
As vulnerabilidades a seguir foram selecionadas entre os cento e quatro tipos
elencados pelo CLASP. O critrio de escolha das vulnerabilidades se deu de acordo
com sua aplicabilidade ao sistema. H itens elencados pelo CLASP que no se
aplicam ou que no fazem muito sentido na arquitetura do Sistema nico.

4.1 Causas bsicas de vulnerabilidades que se aplicam ao

desenvolvimento de software do sistema nico.
Atravs de leitura e pesquisas com base na seo de vulnerabilidades
elencadas pelo CLASP, fez-se uma seleo de quais tipos de problemas so
pertinentes arquitetura, implementao e execuo do Sistema nico. Esse
trabalho resultou na seleo de trinta itens dentre os cento e quatro tipos de
vulnerabilidades previstas pelo CLASP.
Assim como apresentado na Tabela 1, as sees seguintes organizam os trinta
itens selecionados de acordo com as categorias de problemas previstos pelo
CLASP. Dentro de cada categoria realizada uma breve explicao de cada
problema, o perodo de exposio, ou seja, em que momento essa vulnerabilidade
introduzida bem como a preveno e mitigao sugeridas pelo CLASP.

30
4.1.1 Erros de tipo e intervalo

Desateno ao caso default no Switch

A no considerao do caso padro (default) no comando de deciso
conhecido como Switch/Case pode conduzir a erros de lgica complexo, alm de
poder conduzir a situaes inesperadas relativas segurana.
Perodo de exposio
Implementao: essa falha uma questo simples de lgica introduzida
durante a fase de implementao.
Preveno e mitigao
Implementao: assegurar que no existe clusula Switch/Case que no trate
o caso default.

Cross-site scripting (XSS)

uma modalidade de ataque em que scripts maliciosos, geralmente
JavaScripts, so injetados em stios confiveis. Os atacantes se aproveitam da
confiabilidade de determinado site para executar cdigo na mquina dos usurios.
Perodo de exposio
Implementao: se houver funcionalidades em que permitido ao usurio
inserir cdigos HTML que outros usurio vero, como edio de texto ou
BBCode, Cross-site scripting s pode ser dissuadido na faze de
implementao.
Preveno e mitigao
Implementao: construir um analisador para assegurar que nenhum
contedo postado por usurios contenha tags de scripts.

Injeo de comando
A injeo de comando um problema no qual um processo induzido a
chamar processos escolhidos pelo atacante. Isso feito atravs da injeo de
cdigos de controle nos dados do sistema.
Perodo de exposio

31
 Implementao: essa falha introduzida quase sempre durante a fase de
implementao.
Preveno e mitigao
Projeto: sempre que possvel utilizar chamadas a bibliotecas de forma a no
chamar processos externos.
Implementao: construir um analisador para assegurar que nenhum
contedo postado por usurios contenha tags de scripts.

Injeo por reflexo

A injeo por reflexo um problema no qual uma entrada de dados usada
para construir uma String que ser usada por uma API de reflexo de classes.
Atravs da manipulao dos dados um atacante pode fazer com que classes
inesperadas sejam carregadas, ou que mtodos ou campos no desejados sejam
acessados em um objeto.
Perodo de exposio
Implementao: essa falha introduzida atravs da utilizao de dados
externos para compor valores que sero usados em operaes de reflexo.
Preveno e mitigao
Projeto: usar mtodos alternativos para satisfazer os requisitos sem utilizar
reflexo.
Implementao: evitar a utilizao de dados externos para gerao de Strings
que sero usadas em operaes de reflexo.

SQL injection
A injeo de SQL um problema no qual comandos SQLs so injetados nos
dados de entrada de forma a afetar a execuo de comandos SQL pr-definidos.
Perodo de exposio
Implementao: essa falha introduzida quando no se mitiga durante a fase
de implementao as possibilidades de se executar SQL injection.
Preveno e mitigao

32
 Implementao: usar checagem extensiva e rigorosa de todas as entradas de
dados de usurios que sero usadas por comandos SQLs. Utilizao de
frameworks que faam esse tipo de tratamento automaticamente.

Desserializao e dados no confiveis

Este um problema pouco conhecido pelos desenvolvedores. Consiste
basicamente na desserializao de objetos/dados anteriormente serializados e que
no podem ser supostos como confiveis. O princpio que insere esse risco o de
que dados que no so confiveis no podem ser assumidos como seguros.
A serializao um processo que se no usado corretamente abre margens
para diversas falhas. A principal delas que na serializao padro os dados so
trafegados em claro, assim dados do tipo privado, ou seja, que no deveriam ser
acessados diretamente, so facilmente expostos por uma serializao sem
criptografia.
Perodo de exposio
Implementao: no utilizar as funcionalidades de serializao e
desserializao segura de uma linguagem pode criar problemas de
integridade de dados.
Implementao: no utilizar corretamente a proteo atravs dos mtodos de
acesso pode criar problemas de integridade de dados.
Implementao: no proteger os objetos de funes padro sobrecarregadas
que podem fazer a serializao bruta, em claro, de um objeto pode trazer
problemas de confidencialidade de dados.
Implementao: no tornar os atributos transientes em alguns casos pode
causar problemas de confidencialidade de dados.
Preveno e mitigao
Especificao de Requisitos: uma biblioteca de desserializao que prov um
framework de criptografia para proteger os dados serializados pode ser
usada.
Implementao: usar recursos de assinatura da linguagem de programao
para garantir que os dados desserializados no foram violados.

33
 Implementao: ao desserializar dados popular um novo objeto em vez de
somente desserializar, a intenso que o dado flua atravs da validao
segura de entrada.
Implementao: definir explicitamente readObject() como final para prevenir a
desserializao.
Implementao: tornar atributos transientes para proteg-los da
desserializao.

4.1.2 Problemas de ambiente

Busca atravs de caminho relativo

Algumas funes realizam busca relativa a partir de um caminho especificado.
O resultado da busca sobre esse caminho pode no ser o esperado. Por exemplo, a
funo WinExec dos sistema operacional Windows pode usar o caractere de espao
como delimitador, dessa forma o resultado C:\Program.exe, dependendo da
implementao, pode ser considerado um resultado vlido para a busca C:\Program
Files\Bar.exe.
Perodo de exposio
Implementao: essa falha introduzida quase sempre durante a fase de
implementao.
Preveno e mitigao
Implementao: usar somente funes que requerem o caminho explcito
para se evocar objetos no sistema de arquivo.

Basear-se no nvel de escopo de pacote

Os pacotes da linguagem Java no so inerentemente fechados, portanto
confiar neles para segurana de cdigo no uma boa prtica. O propsito do
escopo de pacote o evitar acesso acidental. Portanto essa funcionalidade prov
uma facilidade para o desenvolvimento de software e no um recurso de segurana.
Perodo de exposio
34
 Do projeto Implementao: essa falha uma questo de estilo, por isso
importante no permitir acesso direto s variveis e proteger os objetos.
Preveno e mitigao
Do projeto Implementao: os dados devem ser privados, estticos e finais
sempre que cabvel e possvel. Isso ir garantir que o cdigo est protegido
contra instanciao prematura, evitando acesso indevido e adulterao.

Publicao de dados privados ao utilizar classes internas

A mquina virtual Java no tem noo de classes internas, portanto classes
internas so providas apenas com o nvel de segurana de pacote. Por outro lado, a
classe interna tem acesso a todos os atributos de sua classe externa, inclusive se a
classe foi declarada como privada.
Perodo de exposio
Implementao: essa falha uma falha simples de lgica introduzida durante
a fase de implementao.
Preveno e mitigao
Implementao: usar classes seladas protege em relao encapsulao no
paradigma de orientao a objetos, portanto protege o cdigo de ser herdado
de maneiras imprevisveis.
Implementao: classes internas no provm segurana. Portanto no se
deve reduzir o nvel de segurana da classe interna em relao classe
externa.

Confiana nos eventos de sistema

Segurana baseada em eventos do sistema operacional ou de outros
sistemas insegura e pode ser adulterada. Eventos so mensagens de sistemas
que podem prover dados de controle para programas que esto escutando esses
eventos. Porm eventos geralmente no possuem nenhum tipo de controle de
autenticao que permite verificar se estes so originados de uma fonte confivel.
Por exemplo, uma aplicao rodando no Windows pode enviar uma mensagem para

35
qualquer janela no mesmo Desktop. Portanto, basear a segurana em eventos no
uma boa prtica.
Perodo de exposio
Do projeto implementao: confiar em informaes no autenticadas para
prover autenticao uma falha de projeto.
Preveno e mitigao
Do projeto implementao: nunca se deve confiar, ou se basear, em
informaes de eventos para garantir segurana.

Vazamento de informaes atravs da clonagem de classes

Classes clonveis so efetivamente classes abertas, uma vez que os dados
desta no podem ser escondidos. Classes que no negam explicitamente a
clonagem podem ser clonadas por qualquer classe sem a execuo do mtodo
construtor. Isso certamente oferece certo grau de risco, visto que em muitos casos
aspectos de segurana de um objeto so validados no construtor.
Perodo de exposio
Implementao: isso um problema de estilo que deve ser adotado na
implementao de cada classe.
Preveno e mitigao
Implementao: deve-se tornar as classes no clonveis atravs da definio
da funo clone() como final e do lanamento de excees como
java.lang.CloneNotSupportedException() quando a classe no puder ser
clonada.
Implementao: se for necessrio que a classe seja clonvel, deve-se
assegurar que o mtodo final e que lana super.clone().

Vazamento da informao atravs de serializao

Classes serializveis so efetivamente classes abertas, uma vez que os
dados desta no podem ser escondidos. Classes que no negam explicitamente a

36
serializao podem ser serializadas por qualquer classe, que por sua vez pode fazer
uso dos dados da classe serializada.
Perodo de exposio
Implementao: isso um problema de estilo que deve ser adotado na
implementao de cada classe.
Preveno e mitigao
Implementao: deve-se tornar as classes no serializveis atravs da
definio da funo writeObject() como final e do lanamento de excees
explicitamente evitando a serializao.
Implementao: assegurar a no serializao dos objetos.

Estouro do buffer esttico interno

Um atributo esttico no definido como final pode ser visualizado e editado
de diversas maneiras no seguras. Os atributos no final que no sejam privados
podem ser lidos e alterados diretamente por cdigos arbitrrios, ou seja, sem passar
pelos mtodos de acesso Get e Set. Isso pode gerar situaes de inconsistncia,
como o estouro do buffer reservado s variveis estticas.
Perodo de exposio
Do projeto implementao: isso um problema de lgica simples que pode
facilmente ser evitado com simples proteo.
Preveno e mitigao
Do projeto implementao: todo atributo esttico deve ser tambm final e
privado.

4.1.3 Erros de sincronizao e temporizao

Comparao de classes por nome

A prtica de se determinar o tipo de um objeto baseado em seu nome
perigosa do ponto de vista de segurana. Um cdigo malicioso pode propositalmente
reutilizar nomes de classes de forma a parecerem confiveis.
Perodo de exposio
37
 Implementao: essa falha uma falha simples de lgica introduzida durante
a fase de implementao.
Preveno e mitigao
Implementao: deve-se utilizar a equivalncia de classes para determinar o
tipo. Invs de usar nomes de classe para determinar se um objeto de um
tipo especfico, deve-se usar o mtodo getClass() e fazer as devidas
comparaes.

Passagem de objetos mutveis para mtodos no confiveis

Enviar como argumento dados mutveis e no clonados pode resultar na
alterao ou deleo daqueles dados pela funo chamada, colocando a funo de
origem, que chamou a outra funo, em um estado indefinido. Em situaes em que
um cdigo desconhecido chamado e faz referncia a um dado que pode ser
alterado, este cdigo externo pode fazer alteraes sobre os dados enviados. Se os
dados no foram clonados anteriormente, pode-se ter em mos dados modificados
que podem no ser vlidos no contexto de execuo.
Perodo de exposio
Implementao: essa falha uma falha simples de lgica introduzida durante
a fase de implementao.
Preveno e mitigao
Implementao: deve-se clonar, ou seja, fazer um backup de todos os dados
mutveis antes de retornar a referncia para estes. Dessa forma, uma cpia
vlida dos dados mantida para uso da classe, independente das alteraes
que possam ser feitas sobre os dados trafegados.

Vazamento acidental de informaes sensveis atravs de

mensagens de erro
Mensagens do servidor precisam ser tratadas antes de serem mostradas ao
usurio. Uma vez que a primeira tentativa foi falha, a primeira coisa que um atacante
utiliza para o planejamento do prximo ataque a informao do erro provido pelo
servidor. Por exemplo, algum que almeje um ataque de SQL Injection geralmente

38
executa testes no servidor em busca de informaes que possam facilitar o sucesso
do ataque.
Perodo de exposio
Implementao: essa falha uma falha simples de lgica introduzida durante
a fase de implementao.
Preveno e mitigao
Implementao: cada erro deve ser analisado de forma a retirar as
informaes sensveis das mensagens que sero exibidas ao usurio.
Implantao: informaes de depurao no devem estar presentes em uma
verso de produo.

Vazamento acidental de informaes sensveis atravs de dados

enviados
O vazamento de informaes sensveis atravs de envio de dados se refere a
transmisso de dados os quais so sensveis por si s ou que possam uteis para a
explorao das vulnerabilidades do sistema. Este tipo de problema pode ocorrer de
inmeras maneiras. A preveno mais eficaz para este tipo de problema tem uma
mxima que diz que uma informao que no necessria para a funcionalidade em
questo deve ser extrada, o que alm de contribuir para diminuir a sobrecarga de
informaes alm de evitar o vazamento de informaes sensveis.
Perodo de exposio
Especificao de requisitos: a sada de dados deve ser definida na fase de
especificao de requisitos.
Implementao: a deciso final de quais dados sero enviados executada
na fase de implementao.
Preveno e mitigao
Especificao de requisitos: deve-se especificar a sada de dados de forma
que nenhum dado sensvel seja fornecido atravs das funcionalidades.
Implementao: nesta fase deve-se assegurar que os dados possivelmente
sensveis definidos na especificao de requisitos sejam verificados.

39
Condies de concorrncia em ambientes Multi-threaded
Se duas threads de execuo utilizam um recurso simultaneamente, existe a
possibilidade deste ser utilizado em um estado invlido, que por sua vez pode tornar
o estado de execuo indefinido.
Perodo de exposio
Projeto: se o projeto no previr a utilizao de uma linguagem de
programao que facilite a implementao com threads, os riscos de
problemas desse gnero aumentam consideravelmente.
Preveno e mitigao
Projeto: utilizar funcionalidades de bloqueio. Implementar formas de bloqueio
de recursos em cdigos que alterem ou leiam dados persistentes em
ambientes multi-threaded.

4.1.4 Erros de protocolo

Falha na criptografia de dados

A falha na criptografia de dados faz com que no se tenha as garantias de
confidencialidade, integridade e no repdio que uma implementao correta de
criptografia proporciona. A omisso em criptografar dados ao trafeg-los por uma
rede, nos dias atuais de ataques generalizadas nas redes, pode ser considerada
como uma aceitao da quebra de confidencialidade e os demais atributos
garantidos pela criptografia.
Perodo de exposio
Especificao de requisitos: criptografia deve ser um requisito de sistemas
que transmitem dados.
Projeto: a criptografia deve ser projetada como parte da arquitetura do
sistema.
Preveno e mitigao
Especificao de requisitos: a criptografia deve ser deve ser especificada
como parte integrante do sistema.
Projeto: deve-se assegurar que a criptografia esta integrada ao projeto do
sistema e no somente como substituta dos soquetes.
40
Armazenamento de senhas em formato recupervel
O armazenamento de senhas em um formato que possa ser recuperado as
torna alvo do ataque de reuso de senha por usurios maliciosos. Se um
administrador de um sistema puder recuperar a senha diretamente, ou utilizar fora
bruta sobre a informao disponvel, ele pode utilizar a senha em outras contas.
Perodo de exposio
Projeto: a forma de armazenamento e utilizao de senhas uma deciso de
projeto.
Implementao: a deciso de quais algoritmos de sero utilizados pra
criptografar ou fazer hash da senha geralmente uma deciso deixada a
cargo da implementao.
Preveno e mitigao
Projeto/Implementao: deve-se assegurar que sejam usados algoritmos
fortes e no reversveis para a criptografia a proteo das senhas
armazenadas.

Usar campos referenciados para autenticao

Campos referenciados por uma requisio HTTP podem facilmente ser
alterados, portanto no uma forma segura de checagem de integridade de
mensagens. Uma ao, que de outra forma no poderia ser executada, pode ser
carregada como se tivesse sido validada pelo servidor caso se confie apenas nas
nos campos referenciados por uma requisio HTTP simples.
Perodo de exposio
Projeto: mtodos para autenticao de requisies so geralmente definidos
na fase de projeto.
Preveno e mitigao
Projeto: deve-se utilizar outras formas de autorizao que no podem ser
facilmente adulteradas.

41
Utilizar um algoritmo de criptografia j quebrado ou no mais
seguro
A utilizao de algoritmos de criptografia que j foram quebrados ou que no
so mais considerados seguros um risco desnecessrio que pode resultar no
vazamento de informaes sensveis.
Perodo de exposio
Projeto: a deciso de quais algoritmos de criptografia sero utilizados
geralmente tomada na fase de projeto.
Preveno e mitigao
Projeto: deve-se utilizar algoritmos criptogrficos que so atualmente
considerados fortes por especialistas na rea.

Uso de sistema de senhas

O uso de sistema de senhas como meio principal de autenticao pode ser
sujeito a diversas falhas e deficincias, cada uma delas reduzindo a eficincia do
mecanismo. A falha no mecanismo de autenticao ir quase sempre resultar em
atacantes serem autorizados como usurios vlidos.
Perodo de exposio
Projeto: na fase de projeto em que os mecanismos de autenticao e suas
protees so concebidos.
Preveno e mitigao
Projeto: deve-se utilizar um protocolo de senhas de conhecimento nulo (zero-
knowledge) como o SRP - Secure Remote Password.
Projeto: deve-se assegurar que as senhas sero armazenadas de uma forma
segura e que no so reversveis, por exemplo, utilizar Hash para armazenas
as senhas e no o texto em claro.
Projeto: implementar envelhecimento de senha.
Projeto: utilizar-se de um mecanismo para determinar a fora da senha para
no permitir senhas fracas.

42
Utilizao de fator nico de autenticao
A utilizao de apenas uma forma de autenticao comumente apenas
senha pode levar a riscos que podem comprometer a integridade do sistema. A
utilizao de fator duplo de autenticao trs consigo muitos benefcios de
segurana da informao.
Perodo de exposio
Projeto: na fase de projeto em que os mecanismos de autenticao e suas
protees so concebidos.
Preveno e mitigao
Projeto: deve-se utilizar esquemas de autenticao mltiplos e
independentes. Pode-se adotar, por exemplo, o mecanismo de autenticao
baseado em tokens de assinatura digital. Assim garante-se que se o
mecanismo de autenticao baseado em senha falhar preciso que se
corrompa tambm o mecanismo de autenticao do token para que o sistema
seja comprometido.

No aplicao do envelhecimento de senhas

Se no for implementado um mecanismo de envelhecimento de senhas os
usurios tendero a manter a mesma senha por um longo perodo de tempo. Quanto
mais velha for uma senha, maiores so as chances de que est seja descoberta.
Perodo de exposio
Projeto: o suporte ao envelhecimento de senhas deve ser adicionado na fase
de projeto do desenvolvimento.
Preveno e mitigao
Projeto: deve-se assegurar que o envelhecimento de senhas esteja presente
no desenvolvimento dos sistemas, incluindo um alerta anterior ao tempo de
expirao da senha.

43
4.1.5 Erros gerais de lgica

Comparao ao invs de atribuio

Na maioria das linguagens de programao, a instruo de comparao
muito semelhante instruo de atribuio. Por isso, podem ser facilmente
confundidas. Este erro um erro de tipografia e pode causar problemas na
execuo da aplicao.
Perodo de exposio
Implementao: muitos erros de lgica podem conduzir a este tipo de
problema. Esta pode ser exacerbada pela falta ou mal uso de tecnologias que
possam mitigar esse problema.
Preveno e mitigao
Do Projeto implantao: muitas IDEs e produtos de anlise esttica podem
detectar este problema.

Delimitao incorreta de blocos de cdigo

Em muitas linguagens de programao ou as chaves so opcionais ou em
algumas situaes elas se tornam opcionais. Como o caso do Java, em que a
delimitao atravs de chaves opcional nas estruturas de deciso como IF/ELSE.
O que torna possvel a insero de erros onde um delimitador era supostamente pra
existir, porm foi esquecido ou vice-versa.
Perodo de exposio
Implementao: este um erro de lgica simples introduzido durante a fase
de implementao.
Preveno e mitigao
Implementao: deve-se sempre usar a delimitao de forma explcita, alm
de se utilizar ferramentas de anlise esttica de cdigo para forar esta
prtica.

44
Omisso da instruo break
Omitir intencionalmente a instruo break para que se possa testar varias
vezes um comando switch indistinguvel de um erro, portanto no deve ser
utilizado no desenvolvimento de aplicaes. Algumas linguagens executam
automaticamente o teste apenas uma vez, porm no o caso de linguagens como
C e Java. Nestas linguagens, uma vez encontrado o caso testado todas as
instrues subsequentes so executadas, o que pode confundir muitos
programadores.
Perodo de exposio
Implementao: muitos erros de lgica podem conduzir a este tipo de
problema. Esta pode ser exacerbada pela falta ou mal uso de tecnologias que
possam mitigar esse problema.
Preveno e mitigao
Do Projeto implantao: muitas IDEs e produtos de anlise esttica podem
detectar este problema.
Implementao: a funcionalidade de omitir intencionalmente a instruo de
break pode ser mais clara com a utilizao da instruo IF/ELSE, tornando
a implementao mais segura.

Limpeza inadequada no lanamento de excees

Causar uma mudana de fluxo, atravs do lanamento de uma exceo, em
algumas situaes pode deixar o cdigo em um estado indesejvel, o que pode
gerar falhas de segurana, como por exemplo, deixar uma thread em estado de
bloqueio.
Perodo de exposio
Implementao: este um erro de lgica simples introduzido durante a fase
de implementao.
Preveno e mitigao
Implementao: se a sada de um loop ou de uma funo feita atravs do
lanamento de uma exceo preciso se certificar de que foi feito a limpeza
corretamente ou deve-se sair do programa. Deve-se utilizar o lanamento de
excees de forma cautelosa.

45
Exceo no capturada
Quando uma exceo lanada e no capturada, o processo tem a
possibilidade de decidir se o dado problema ou evento merece uma mudana no
fluxo de execuo.
Perodo de exposio
Implementao: geralmente esse problema causado pelo uso de APIs
externas ou de uma API que o programador no esteja familiarizado.
Preveno e mitigao
Implementao: deve-se capturar todas as excees relevantes de forma a
garantir o estado de execuo da aplicao em todos os momentos.

4.2 Resultado da pesquisa

As entrevistas foram feitas com trs integrantes da equipe de desenvolvimento.
Todos os entrevistados possuem ampla experincia e conhecimento do processo de
desenvolvimento do sistema em tela. Dessa forma foi possvel saber com relativa
facilidade se determinado problema tratado ou no durante o desenvolvimento e
operao do Sistema nico.
As respostas apresentadas se dividiram em: atendido, parcialmente atendido e
no atendido. As Tabelas 2, 3 e 4 representam o resultado da pesquisa. Cada tabela
representa um tipo de resposta. Assim a Tabela 2 representa as vulnerabilidades
que foram consideradas atendidas, a Tabela 3 representa as parcialmente atendidas
e a Tabela 4 mostra as vulnerabilidades que no esto sendo atendidas no Sistema
nico.

46
 Tabela 2 Vulnerabilidades atendidas

Erros de tipo e intervalo Problemas de Ambiente

SQL injection Busca atravs de caminho relativo
Publicao de dados privados ao utilizar
classes internas
Confiana nos eventos de sistema
Estouro do buffer esttico interno

Erros de protocolo Erros gerais de lgica

Armazenamento de senhas em formato recupervel Comparao invs de atribuio
Usar campos referenciados para autenticao Omisso da instruo break
Uso de sistema de senhas

Erros de sincronizao e temporizao

Comparao de classes por nome
Condies de concorrncia em ambientes Multi-
threaded

Tabela 3 - Vulnerabilidades Parcialmente Atendidas

Erros de tipo e intervalo Problemas de Ambiente
Desateno ao caso padro (default) do Switch Basear-se no nvel de escopo de pacote
Injeo de comando
Desserializao de dados no confiveis

Erros de protocolo Erros gerais de lgica

Utilizar um algoritmo de criptografia j quebrado ou
no mais seguro Delimitao incorreta de blocos de cdigo
No aplicao do envelhecimento de senhas Exceo no capturada

Erros de sincronizao e temporizao

Vazamento acidental de informaes sensveis
atravs de mensagens de erro

47
 Tabela 4 - Vulnerabilidades no atendidas
Erros de tipo e intervalo Problemas de Ambiente
Vazamento de informaes atravs da
Cross-site scripting clonagem de classes
Vazamento da informao atravs de
Injeo por reflexo serializao

Erros de protocolo Erros gerais de lgica

Limpeza inadequada no lanamento de
Falha na criptografia de dados excees
Utilizao de apenas uma forma de autenticao

Erros de sincronizao e temporizao

Passagem de objetos mutveis para mtodos no
confiveis
Vazamento acidental de informaes sensveis
atravs de dados enviados

48
5 Discusso

De um total de trinta problemas que foram investigados neste estudo de caso,

observou-se que:
Nove no so atendidos;
Doze so atendidos;
E nove so parcialmente atendidos;
Em relao aos problemas atendidos considerou-se que estes no
apresentam risco considervel de virem a se tornar falhas de segurana, portanto as
consequncias da explorao destes problemas no sero analisadas.
Os parcialmente atendidos assim foram classificados devido a pelo menos
uma das seguintes razes: porque apresentam um risco pequeno de serem
explorados, porque esto em processo de migrao do seu tratamento devido a uma
mudana arquitetural ou porque alguns levam em considerao e outros no durante
a fase de desenvolvimento. Dessa forma a anlise das possveis falhas de
segurana ser feita apenas em relao aos problemas mais relevantes para o
contexto do sistema pesquisado.
J os problemas que, de acordo com as pesquisas e com os conhecimentos
do pesquisador, foram considerados no atendidos sero analisados em mais
detalhe as consequncias de sua possvel explorao na seo seguinte.

5.1 Possveis consequncias do no tratamento dos problemas

A anlise das possveis consequncias do no atendimento aos problemas
relatados pelo CLASP ser feita atravs de uma seo deste mesmo modelo que
so os Casos de Uso de Vulnerabilidades.
49
 A seo de Casos de Uso de Vulnerabilidades do CLASP faz uma anlise
substancial das consequncias da explorao dos tipos de erros elencados na
seo de vulnerabilidades. A anlise feita sob diversas perspectivas, como quais
so os servios de segurana afetados, a categoria do tipo de problema e as
consequncias de sua explorao. Alguns problemas no so analisados na seo
de Casos de Uso de Vulnerabilidades, nestes casos a anlise ser feita a partir de
outras fontes de pesquisa.

5.1.1 Erros de tipo e intervalo

Cross-site scripting (XSS)

So afetados os servios de segurana: confidencialidade e controle de
acesso.
Consequncias:
Confidencialidade: o ataque mais comum relativo a cross-site scripting
o vazamento de informaes armazenadas em cookies do usurio.
Controle de acesso: em algumas circunstncias, quando combinado
com outras falhas, pode ser possvel a execuo de cdigos no
computador da vtima.

Injeo de comando
afetado o servio de segurana: controle de acesso. Este um problema que
foi considerado pela pesquisa como parcialmente atendido, porm achou-se
relevante a anlise de suas possveis consequncias.
Consequncias:
Controle de acesso: a injeo de comandos permite ao atacante a
execuo de comandos e cdigos de seu interesse.

Injeo por reflexo

afetado o servio de segurana: controle de acesso.
Consequncias:

50
 Controle de acesso: a injeo de comandos permite ao atacante a
execuo de comandos e cdigos de seu interesse.

5.1.2 Problemas de ambiente

Vazamento de informaes atravs da clonagem de classes

afetado o servio de segurana: confidencialidade.
Consequncias:
Confidencialidade: uma classe que pode ser clonada pode ser produzida
sem executar o mtodo construtor, que geralmente onde se encontra
validaes de estado e aes da classe.

Vazamento da informao atravs de serializao

afetado o servio de segurana: confidencialidade.
Consequncias:
Confidencialidade: um atacante pode serializar uma classe para
transform-la em um array de bytes, dessa forma pode extrair os dados
importantes desta.

5.1.3 Erros de sincronizao e temporizao

Passagem de objetos mutveis para mtodos no confiveis

afetado o servio de segurana: integridade.
Consequncias:
Integridade: dados presentes no objeto podem ser violados pela fonte
no confivel, assim comprometendo a integridade da informao, bem
como pode levar o sistema a um estado indefinido dependendo do tipo
de violao da informao.

Vazamento acidental de informaes sensveis atravs de

mensagens de erro
51
 afetado o servio de segurana: confidencialidade. Este um problema que
foi considerado pela pesquisa como parcialmente atendido, porm achou-se
relevante a anlise de suas possveis consequncias.
Consequncias:
Confidencialidade: este problema pode revelar informaes sensveis
que podem ser usadas posteriormente por um atacante, facilitando
assim o seu ataque. Alm de poder expor informaes confidenciais
armazenadas no servidor.

Vazamento acidental de informaes sensveis atravs de dados

enviados
afetado o servio de segurana: confidencialidade.
Consequncias:
Confidencialidade: dados sensveis, que no sejam necessrios
funcionalidade, portanto no precisariam ser expostos, podem ser
revelados de forma perigosa, comprometendo a confidencialidade da
informao.

5.1.4 Erros de protocolo

Falha na criptografia de dados

So afetados os servios de segurana: confidencialidade, integridade e no
repdio.
Consequncias:
Confidencialidade: o no emprego correto dos sistemas de criptografia
faz com que a informao no tenha garantia de confidencialidade.
Integridade: a integridade da informao trafegada e armazena pelo
sistema tambm no pode ser garantida caso no se utilize
corretamente a criptografia desses dados.
No repdio: tambm conhecido como prestao de contas, ou seja,
garantir que cada um responsvel pelo que faz dentro do sistema, este
atributo da informao no pode ser garantido sem a criptografia.
52
Utilizao de fator nico de autenticao
afetado o servio de segurana: autenticao.
Consequncias:
Autenticao: em um sistema de fator nico de autenticao caso a
chave secreta seja descoberta o atacante tem acesso autenticao
completa, como se fosse o prprio dono da chave. Em um sistema de
duplo fator de autenticao preciso o acesso chave da outra forma
de autenticao, o que dificulta muito mais o possvel ataque.

5.1.5 Erros gerais de lgica

Limpeza inadequada no lanamento de excees

afetado o servio de segurana: implementao.
Consequncias:
Implementao: o lanamento de uma exceo quebra o fluxo normal
de execuo das instrues, portanto lanar uma exceo de forma e
no momento incorreto pode deixar o sistema em um estado
inadequado.

5.2 Discusses sobre os resultados

De posse do resultado das pesquisas pode-se observar que dentre os trinta
itens selecionados da lista de vulnerabilidades do CLASP doze esto sendo levados
em considerao de forma significativa no processo de desenvolvimento dos MPF.
O que d um ndice de quarenta por cento de aderncia.
Porm houve ainda nove itens que esto sendo parcialmente atendidos. O que
d um ndice de trinta pontos percentuais. Os itens que foram classificados como
parcialmente atendidos tm sua ocorrncia incerta.
Os itens de maior preocupao so os problemas que no esto sendo
levados em considerao durante o desenvolvimento do sistema em tela. Foram
nove os itens que no so atendidos, o que d um ndice de trinta por cento.

53
Percentual significante para um sistema que lida com informaes sensveis e
muitas vezes sigilosas, como o caso do sistema pesquisado.

54
6 Concluso

Atravs da pesquisa foi possvel ter uma noo do nvel de aderncia do

sistema nico com as melhores prticas sugeridas pelo CLASP. Apesar de a
pesquisa ter se concentrado numa parte dos problemas listados pelo CLASP de
maior relevncia para o caso do MPF, foi possvel ter uma viso bem descritiva do
caso estudado, uma vez que os tipos de problemas selecionados foram os mais
significativos para o desenvolvimento do sistema estudado.
Observou-se um nvel de aderncia, considerando os problemas atendidos e
os parcialmente atendidos, de setenta por cento s melhores prticas do CLASP.
Pode-se considerar neste clculo os itens parcialmente atendidos, pois estes
apresentam um risco pequeno de serem explorados, esto em processo de
migrao do seu tratamento devido a uma mudana arquitetural ou alguns
desenvolvedores levam em considerao e outros no durante a fase de
desenvolvimento.
Em relao aos demais itens, a pesquisa constatou que trinta por cento no
so levados em considerao durante o processo de desenvolvimento do MPF. O
que um percentual relativamente alto visto a natureza sigilosa de algumas
informaes manipuladas pelo sistema pesquisado. necessrio, portanto que seja
dedicada uma ateno a estas prticas de forma que venham a ser contempladas
pelo processo de desenvolvimento.
H problemas que no esto sendo atendidos que podem trazer transtornos
considerveis aos atributos de segurana da informao, comprometendo a
confidencialidade, integridade, autenticidade e no repdio da informao

55
processada pelo sistema. o caso, por exemplo, do problema de Cross-site
scripting, que um problema no levado em considerao atualmente, mas que
pode permitir que usurios maliciosos executem cdigos nas mquinas dos demais
usurios do sistema. Outro problema que atualmente no levado em considerao
e que pode acarretar em falhas na confidencialidade dos processos judiciais tratados
pelo sistema a falha na criptografia de dados. Este problema se torna mais grave
no caso de processos sigilosos, que apesar de assim serem considerados,
atualmente no so criptografados. O sigilo desses processos um requisito de
extrema importncia no sistema, visto que o MPF lida com diversos processos desta
categoria, que caso venham a ter seu contedo exposto podem gerar srios
problemas instituio.
Uma observao que pode ser feita que a linguagem Java evita boa parte
dos tipos de problemas previstos no CLASP. o caso, por exemplo, do tipo de
problema SQL Injection, que devido a frameworks e linguagem utilizada para o
desenvolvimento do sistema (Java) foi considerado como atendido por todos os
entrevistados e pelo prprio pesquisador. H outros exemplos que pode-se
considerar como atendido pelo correto emprego da linguagem supracitada, como:
condies de concorrncia ao se utilizar multi-threads, comparao de classes por
nome, entre outros problemas. H tambm itens que foram considerados como
parcialmente atendidos devido equipe no levar em considerao, porm so bem
tratados pela linguagem, como o caso de excees no capturadas. Assim,
quando acompanhada de conhecimento e correta utilizao, pode-se considerar a
linguagem Java como uma excelente ferramenta para auxlio na manuteno da
segurana da informao nos sistemas.
Apesar de alguns requisitos de segurana ainda no serem atendidos, o
sistema apresentou um bom percentual de aderncia s principais prticas. Alm
disso, a pesquisa em questo, acompanhada de outras pesquisas e trabalhos
futuros, pode servir de base para a instituio melhorar o processo de
desenvolvimento em relao segurana da informao.

56
7 Referncias e Fontes Consultadas

G. HOGLAND AND G. MCGRAW, Exploiting Software: How to Break Code, Addison-

Wesley, 2004.
MCGRAW, GARY. Bridging the Gap between Software Development and Information
Security. IEEE SECURITY & PRIVACY, 2004.
DAVIS, NOOPUR, MICHAEL HOWARD, WATTS HUMPHREY, GARY MCGRAW,
SAMUEL T. REDWINE, JR., GERLINDE ZIBULSKI, CAROLINE
GRAETTINGER. Processes to Produce Secure Software, 2004.
NUNES, FRANCISCO JOS BARRETO E BELCHIOR, ARNALDO DIAS. Um
Processo Seguro para Desenvolvimento de Software. UNIFOR, 2006.
GEHRING, ROBERT A. "Software Patents" - IT-Security at Stake? Technical
University of Berlin, 2001.

ALBERTS, C.; DOROFEE, A. Managing Information Security Risks: The OCTAVE

Approach. [S.l.]: Addison Wesley, 2002. 512 p.

GUERRA, E. Os Sete Pecados do Controle de Acesso para aplicaes Java EE.

MUNDOJAVA (revista no. 28), Editora Mundo, 2008.

ORACLE. Site oficial. Disponvel em:

<http://www.oracle.com/technetwork/java/javaee/overview/index.html>. Acesso
em: 20 out. 2011.

ANDERSON, R. Security Engineering: a guide to building dependable distributed

systems. USA: John Wiley and Sons, 2001. 612 p.

ARAJO, Aletia Patrcia Favacho. Infra-Estrutura de TI: GSIC201 (Notas de Aula),

V.2. Curso de Especializao em Gesto da Segurana da Informao e
57
 Comunicaes: 2009/2011. Departamento de Cincias da Computao da
Universidade de Braslia. 2010. 40 p.

GONDIM, J. J. C. Ataques, Intruses e Investigao Forense em Sistemas de

Computao: Parte 1 - Vulnerabilidades e Ataques. [S.l.], Maio 2008. 38 p.

GONDIM, J. J. C. Ataques, Intruses e Investigao Forense em Sistemas de

Computao: Parte 2 - Introduo Auditoria de Sistemas. [S.l.], Maio 2008. 36
p.

GUERRA, E. Os sete pecados do controle de acesso para aplicaes Java EE.

Mundo java. Curitiba, n. 28, p.26-33, 2008.

HANSMAN, S.; HUNT, R. A taxonomy of network and computer attacks. Computers

& Security, February 2005. Disponvel em:
<http://linkinghub.elsevier.com/retrieve/pii/S0167404804001804>. Acesso em:
setembro de 2011.

HOLANDA, Maristela Terto; FERNANDES, Jorge Henrique Cabral. Segurana no

Desenvolvimento de Aplicaes. Curso de Especializao em Gesto da
Segurana da Informao e Comunicaes: 2009/2011. Departamento de
Cincias da Computao da Universidade de Braslia. 2010.

HOWARD, M.; LIPNER, S. The Security Development Lifecycle: SDL: a process for
developing demonstrably more secure software. USA: Microsoft, 2006.

ISO/IEC. ISO/IEC FDIS 27005 - Information technology Security Techniques -

Information security risk management. [S.l.], 2007.

ISO/IEC. ISO/IEC FDIS 27005 - Information technology - Security Techniques -

Information

IT GOVERNANCE INSTITUTE. COBIT 4.1. ed. USA, 2007. Disponvel em:

<http://www.itgi.org>. Acesso em: julho de 2011.

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS - ABNT. Norma ABNT

ISO/IEC NBR 27005:2008.

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS ABNT. Norma ABNT

ISO/IEC NBR 27002:2005.

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS - ABNT. Norma NBR-

ISO/IEC 27001:2006.

CERT.BR. Cartilha de Segurana para Internet. Disponvel no site:

http://cartilha.cert.br/conceitos/sec7.html#subsec7.1. Acesso em: 13/11/2008.

DIAS, CLUDIA. Segurana e Auditoria da Tecnologia da Informao. Axcel Books.

Rio de Janeiro, 2000.
58
INSTRUO NORMATIVA N 1 DO GABINETE DE SEGURANA INSTITUCIONAL
DA PRESIDNCIA DA REPBLICA, de 13 de junho de 2008. Disciplina a
Gesto de Segurana da Informao e Comunicaes na Administrao
Pblica Federal, direta e indireta, e d outras providncias.

NAKAMURA, EMILIO TISSATO; GEUS, PAULO LCIO. Segurana de Redes: em

ambien-tes cooperativos. 2. ed. So Paulo: Futura, 2003.

TANENBAUM, A. S. Redes de Computadores. ed. Rio de Janeiro: Campus, 1997.

SOARES, L. F. G.; LEMOS G.; COLCHER, S. Redes de Computadores: das LANs,

MANs e WANs  as redes ATM. ed. Rio de Janeiro: Campus, 1995.

59
Apndice B Orientaes para
composio, impresso e
encadernao da monografia

Este documento apresenta o modelo padro de monografia a ser usada no

CEGSIC 2009/2011. Adote-o para escrever o seu trabalho usado processadores de
texto, como o Microsoft Word, Br Office ou Open Office Writer.
No altere a formatao padro deste documento, que deve ter Tipo: Arial 12
no texto normal do documento; Margens da pgina: superior 3,0 cm, inferior 2,0 cm,
direita 2,0 cm, esquerda 3,0 cm; Notas de rodap justificadas em ambos os lados,
usando Fonte 10; Entre linhas (espao): 1,5 cm; Formato de papel: A4.
O recuo no incio de cada pargrafo deve ser mantido.
Na composio da sua monografia em verso final evite usar figuras com
vrias cores, pois a impresso deve ser feita em preto-e-branco, usando-se apenas
uma das faces do papel, isto , no faa impresso frente e verso quando for
entregar a verso final da monografia. Apenas a folha que contm a terceira capa
dever ter impresso em duas faces, que no seu verso contm a ficha catalogrfica.
Note, no entanto, que a verso da monografia para a defesa deve ser
entregue impressa em ambas as fases, encadernada em espiral. A numerao de
pginas inicia-se a partir da falsa folha de rosto, em algarismos arbicos, mas s
impressa na segunda pgina aps o sumrio.
A entrega da monografia em verso digital deve ser feita em formato PDF.
Fica a critrio do autor a proteo do documento contra cpia e impresso.

60