Modelo de Monografia do CEGSIC 2009/2011

Instituto de Ciências Exatas
Departamento de Ciência da Computação
Curso de Especialização em Gestão da Segurança da Informação e
Comunicações
MARCOS PONTES DA SILVA
Java EE e a Segurança Cibernética atuando nos aplicativos web
Segurança em aplicações web
Brasília
2011
Marcos Pontes da Silva
Java EE e a Segurança Cibernética atuando nos aplicativos web
Segurança em aplicações web
Brasília
2011
Marcos Pontes da Silva
Java EE e a Segurança Cibernética atuando nos aplicativos web
Segurança em aplicações web
Monografia apresentada ao Departamento
de
Ciência
da
Computação
da
Universidade de Brasília como requisito
parcial para a obtenção do título de
Especialista em Ciência da Computação:
Gestão da Segurança da Informação e
Comunicações.
Orientadora: Prof.ª Dr.ª Genaína Nunes Rodrigues
Universidade de Brasília
Instituto de Ciências Exatas
Departamento de Ciência da Computação
Brasília
Novembro de 2011
Desenvolvido em atendimento ao plano de trabalho do Programa de
Formação de Especialistas para a Elaboração da Metodologia Brasileira
de Gestão da Segurança da Informação e Comunicações - CEGSIC
2009/2011.
© 2011 Marcos Pontes da Silva. Qualquer parte desta publicação pode
ser reproduzida, desde que citada a fonte.
Silva, Marcos Pontes da
Java EE e a Segurança Cibernética atuando nos aplicativos web:
Segurança em aplicações web / Marcos Pontes da Silva. – Brasília: O
autor, 2011. 87 p.; Ilustrado; 25 cm.
Monografia (especialização) – Universidade de Brasília. Instituto de
Ciências Exatas. Departamento de Ciência da Computação, 2011.
Inclui Bibliografia.
1. Controle de acesso. 2. Código seguro 3. Vulnerabilidades.
I. Título.
CDU 004.056
Errata
Dedicatória
Dedico esta monografia ao Deus único e verdadeiro, criador do céu, da terra e
do mar, e de tudo que existe no universo; o qual é a fonte de toda ciência e
sabedoria.
Dedico também a minha esposa Magali e minhas filhas Mônica e Maiara.
Agradecimentos
Agradeço ao Deus único e verdadeiro, a minha esposa Magali e minhas filhas
Mônica e Maiara, a toda coordenação do CEGSIC-2009/2011, a minha orientadora
Prof.ª Dr.ª Genaína Nunes Rodrigues, ao Prof. Dr. Jorge Henrique Cabral
Fernandes, e a todos os funcionários da reitoria da universidade “Z” que cooperaram
de algum modo comigo.
Quem semeia entre lágrimas,
colherá com alegria.
Salmo 126, verso 5, Bíblia Sagrada.
Se alguém precisar de sabedoria, peça a Deus,
ele dá a todos liberalmente.
Epístola de S. Tiago 1, verso 5, Bíblia Sagrada.
O temor do Senhor é o princípio da sabedoria,
e a ciência do Santo a prudência.
Provérbios 9, verso 10, Bíblia Sagrada
Crê no Senhor Jesus Cristo,
e serás salvo, tu e a tua casa.
Atos dos Apóstolos 16, verso 31, Bíblia Sagrada
Lista de Figuras
Figura 1: API da plataforma Java EE 5 nos contêineres (ORACLE, 2011) ............... 27
Figura 2: Relações entre os contêineres Java EE 6 (ORACLE, 2011) ..................... 27
Figura 3: Arquitetura modelo 2 - MVC (KURNIAWAN, 2004) ................................... 29
Figura 4: Código escondido não protege (GUERRA, 2008) ..................................... 31
Figura 5: Código do EJB sem proteção (GUERRA, 2008) ....................................... 32
Figura 6: Código com proteção só na fachada (GUERRA, 2008) ............................. 33
Figura 7: Códigos que fazem muita coisa sem proteção (GUERRA, 2008) .............. 33
Figura 8: Código servlet AJAX sem proteção (GUERRA, 2008) ............................... 34
Figura 9: Código de autenticação com servidor de aplicações (GUERRA, 2008)..... 35
Figura 10: Código com dados sem proteção (GUERRA, 2008) ................................ 36
Figura 11: Vulnerabilidades. Fonte: (OSVDB, 2010) ................................................ 38
Figura 12: Ataque ao sítio da UFRJ (ALMEIDA, 2011) ............................................. 69
Figura 13: Código do parâmetro visível na URL - 1 (SILVA, 2011)........................... 71
Figura 14: Código do parâmetro visível na URL - 2 (SILVA, 2011)........................... 71
Figura 15: Visões do CLASP. Adaptado de OWASP(2010). ................................... 83
Figura 16: Mapa conceitual do software com código seguro (SILVA, 2011) ............. 84
Lista de Tabelas
Tabela 1 – Plano de Coleta de Dados. ..................................................................... 47
Tabela 2 – Pesquisa Sobre Segurança no Desenvolvimento de Software ............... 48
Tabela 3 – Sumário das Entrevistas Realizadas ...................................................... 49
Tabela 4 – Relação: Coleta de Dados X Apêndices ................................................. 50
Tabela 5 – Variáveis X Nível de Segurança ............................................................. 54
Sumário
Errata ......................................................................................................................... 3
Dedicatória ................................................................................................................. 5
Agradecimentos ......................................................................................................... 6
Lista de Figuras ......................................................................................................... 8
Lista de Tabelas ......................................................................................................... 9
Sumário ................................................................................................................... 10
Resumo ................................................................................................................... 14
Abstract.................................................................................................................... 15
1 Delimitação do Problema ...................................................................................... 16
1.1 Introdução ...................................................................................................... 16
1.1.1 Norma ...................................................................................................... 17
1.1.2 Institutos de Segurança............................................................................ 17
1.1.3 Metodologia de Desenvolvimento Seguro ................................................ 18
1.1.4 Plataforma do Java Edição Empresarial ................................................... 18
1.2 Citações ......................................................................................................... 18
1.3 Formulação da Situação Problema ................................................................. 19
1.4 Objetivos e Escopo ......................................................................................... 19
1.4.1 Objetivo Geral .......................................................................................... 21
1.4.2 Objetivos Específicos ............................................................................... 21
1.4.3 Escopo ..................................................................................................... 21
1.5 Justificativa ..................................................................................................... 21
1.6 Hipótese ......................................................................................................... 22
1.7 Organização do Trabalho ............................................................................... 22
2 Revisão de Literatura e Fundamentos................................................................... 23
2.1 Referencial Teórico......................................................................................... 25
2.1.1 Contêineres ou API .................................................................................. 26
2.1.2 Algumas Possibilidades de Risco no Controle de Acesso ........................ 30
2.2 Referenciais Conceituais das Disciplinas do CEGSIC .................................... 37
2.3 Referenciais Produzidos Pelos Próprios Cursistas ......................................... 38
2.3.1 Autenticação e Autorização em Aplicativos Web ...................................... 38
2.4 Argumentos do Pesquisador ........................................................................... 40
3 Metodologia .......................................................................................................... 42
3.1 Tipo de Pesquisa ............................................................................................ 42
3.2 Plano da Pesquisa .......................................................................................... 43
3.2.1 Pesquisa Bibliográfica .............................................................................. 43
3.2.2 Preparo do Questionário .......................................................................... 44
3.2.3 Coleta de Dados ...................................................................................... 44
3.2.4 Documentação e Estruturação dos Resultados ........................................ 45
3.2.5 Validação e Análise dos Resultados ........................................................ 45
4 Resultados ............................................................................................................ 46
4.1 Setor de Desenvolvimento de Aplicações ....................................................... 46
4.2 A Pesquisa ..................................................................................................... 47
5 Discussão ............................................................................................................. 51
5.1 Sugestão de Melhorias ................................................................................... 52
5.2 Validade da Construção ................................................................................. 53
5.3 Validade Interna ............................................................................................. 55
5.4 Validade Externa ............................................................................................ 56
6 Conclusões e Trabalhos Futuros ........................................................................... 57
6.1 Conclusões ..................................................................................................... 57
6.2 Trabalhos Futuros .......................................................................................... 58
Referências e Fontes Consultadas .......................................................................... 60
Glossário .................................................................................................................. 64
A ........................................................................................................................... 64
B ........................................................................................................................... 64
C .......................................................................................................................... 64
D .......................................................................................................................... 64
H .......................................................................................................................... 64
I ............................................................................................................................ 64
J ........................................................................................................................... 64
M .......................................................................................................................... 65
N .......................................................................................................................... 65
O .......................................................................................................................... 65
R .......................................................................................................................... 65
S ........................................................................................................................... 65
T ........................................................................................................................... 65
U .......................................................................................................................... 65
W .......................................................................................................................... 65
X ........................................................................................................................... 65
Apêndice A – Ataque de Hackers............................................................................. 66
A.1 Hackers vazam informações de funcionários do Exército Brasileiro ............... 66
A.2 Polícia Federal investiga ataques de hackers na internet ............................... 67
A.3 Hackers atacaram as páginas de 105 sítios da web na UFRJ ........................ 69
Apêndice B – Exemplo de URL com Código Visível ................................................. 71
Apêndice C – Controle de Acesso em Aplicações Java EE...................................... 72
Apêndice D – Demonstração de Alguns Tipos de Ataques em Código Java EE ...... 78
Apêndice E – Processo de Desenvolvimento Seguro CLASP .................................. 82
Apêndice F – Mapa Conceitual: Desenvolvimento do Software com Código Seguro84
Apêndice G – Código-fonte de Uma Aplicação Web Sem Código Seguro ............... 85
Resumo
Com o desenvolvimento de novas tecnologias, ocorre também o crescimento
constante de vulnerabilidades e ameaças aos sistemas de informação e
comunicação. Temos então o desafio no desenvolvimento de aplicações de software
seguro para a internet, também, conhecido como web. Tal desafio pode ser ilustrado
pelo fato dos institutos existentes na internet, tais como OWASP Top 10 (OWASP,
2011) e SANS (2009), que divulgam constantemente sobre ataques contra
vulnerabilidades em aplicações web. Segundo o SANS (2009), os ataques
ultrapassam mais de 60% do total de tentativas observadas na internet. A
informação é um ativo importante e valioso para os negócios da organização.
Portanto, há a necessidade de proteger esse ativo de forma a garantir sua
confidencialidade, integridade e disponibilidade. Neste sentido, a primeira ação que
deve ser tomada em segurança da informação é estabelecer políticas e
procedimentos sobre como proteger a informação. Os fatos acima mencionados
motivaram essa pesquisa por meio de um estudo de caso no âmbito da APF,
abordando vulnerabilidades em aplicações Java EE.
Abstract
With the development of new technologies, there is also the growing number
of vulnerabilities and threats to information systems and communications. As a result,
we have the challenge in developing secure software applications, particularly for the
Internet, also known as the web. Such a challenge can be illustrated by the fact that
the existing institutions on the Internet, such as the OWASP Top 10 (OWASP, 2011)
and SANS (2009), show constant attacks on vulnerabilities in web applications.
According to the SANS (2009), the attacks exceeded more than 60% of all observed
attempts on the Internet. Information is an important and valuable asset to the
organization's business. Therefore, there is the need to protect this asset in order to
ensure its confidentiality, integrity and availability. In this sense, the first action to be
taken into information security is to establish policies and procedures to protect
information. The above facts motivated this research through a case study in the
Federal Public Administration (FPA), addressing vulnerabilities in Java Enterprise
Edition applications.
16
1 Delimitação do Problema
1.1 Introdução
O tema principal deste trabalho é “Java EE e a Segurança Cibernética
atuando nos aplicativos web”. A importância deste tema está no fato de haver
ocorrido um aumento de ataques aos sistemas aplicativos web das organizações
públicas e privadas. A problemática são os ataques aos aplicativos web, onde a
maior ocorrência são os ataques de “Injeção de SQL” e “XSS – Cross-Site Scripting”.
Logo, como se desenvolve aplicativos web seguros na plataforma Java EE?
A segurança da informação atua por meio de ações relacionadas à proteção
das informações manipuladas por sistemas de informação. Segundo Dias (2000), os
objetivos da Segurança da Informação envolvem, sobretudo, a manutenção da
confidencialidade, da disponibilidade e da integridade das informações, variando de
acordo com a natureza do sistema e com o nível de impacto que uma falha de
segurança possa apresentar.
Muitos especialistas ainda pensam que ao aplicar criptografia para proteger a
integridade dos dados em um software, o mesmo torna-se seguro. Na verdade, esse
software ao aplicar apenas uma das características de segurança, não pode, de fato,
ser considerado seguro. A segurança de software não pode ser confundida com
software seguro, isto é, apresentar características de segurança no software não
garante que o mesmo seja seguro (MCGRAW, 2004).
É mais barato construir software seguro do que corrigir problemas de
segurança após a entrega do software como produto final, e sem mencionar os
custos consequentes da falha de segurança (OWASP, 2010).
Neste trabalho de monografia, com base em quatro recursos com aspectos
diferentes, que estão relacionados com a Segurança da Informação e Comunicação,
acredita-se que operando os mesmos em conjunto, promoverá a mitigação de riscos
e vulnerabilidades nos aplicativos web. São eles: NORMA ABNT NBR ISO/IEC
17
27002:2005, institutos de segurança, metodologia de desenvolvimento seguro, e a
plataforma Java EE.
1.1.1 Norma
A Seção 12 da NORMA ABNT NBR ISO/IEC 27002:2005, referente à
segurança na aquisição, desenvolvimento e manutenção de Sistemas de
Informação, enfatiza as características e desafios gerais que se aplicam ao
desenvolvimento de aplicações de software para o ambiente internet/web. Segundo
tal norma, todos os requisitos de segurança devem ser identificados na fase de
levantamento de requisitos do projeto. Deve-se garantir que os requisitos de
segurança sejam identificados e acordados antes da aplicação no projeto.
1.1.2 Institutos de Segurança
Estes são alguns dos institutos de segurança de renome internacional, que
contribuem grandemente para a mitigação de vulnerabilidades: SANS e OWASP.
Segundo o SANS (SysAdmin, Audit, NetWork, Security) Institute (SANS,
2009) em seu documento The Top Cyber Security Risks: “Ataques contra
[vulnerabilidades de] aplicações web constituem mais de 60% do total das tentativas
observadas na Internet. Essas vulnerabilidades estão sendo amplamente exploradas
para converter web sites confiáveis em web sites maliciosos, que fornecem conteúdo
explorável no lado do cliente e vulnerabilidades em aplicações web...”.
Na lista da OWASP Top 10 – 2010 (OWASP, 2011), contém a relação dos
“dez maiores riscos críticos em segurança de aplicações web”, onde estão
relacionados riscos tais como:
1. Injection (injeção de código SQL);
2. XSS - Cross-Site Scripting (execução de código script no navegador da
vítima);
3. Broken Authentication and Session Management (Falha na Autenticação e
no Gerenciamento de Sessão);
4. Insecure Direct Object References (Referência insegura direta a objetos);
5. CSRF - Cross-Site Request Forgery (Força o envio de uma requisição préautenticada a um servidor web vulnerável);
6. Security Misconfiguration (configuração incorreta de segurança);
7. Insecure Cryptographic Storage (Armazenamento criptográfico inseguro);
8. Failure to Restrict URL Access (Falha na Restrição de Acesso à URL);
18
9. Insuficient Transport Layer Protection (Proteção da camada de transporte
insuficiente);
10. Unvalidated
Redirects
and
Forwards
(Redirecionamentos
e
encaminhamentos não validados).
1.1.3 Metodologia de Desenvolvimento Seguro
A utilização de um modelo de processo para desenvolvimento de aplicativos
de software seguro é um pré-requisito, a fim de minimizar riscos e vulnerabilidades.
Um modelo de processo de desenvolvimento de software seguro bastante
conhecido é o CLASP (Comprehensive, Lightweight Application Security Process)
(OWASP, 2011), que é um conjunto de componentes de processo dirigido por
atividade e baseado em regras, as quais articulam práticas para construção de
software seguro, permitindo o ciclo de vida de desenvolvimento do software de
maneira estruturada, com repetição e mensuração, especificado pela OWASP (Open
web Application Security Project), um instituto mundial sem fins lucrativos (OWASP,
2011). Temos uma demonstração resumida do processo CLASP no apêndice “E”.
1.1.4 Plataforma do Java Edição Empresarial
A plataforma do Java EE, “Java Platform Enterprise Edition” (ORACLE, 2011)
hoje se encontra na versão 6, é um padrão para o desenvolvimento de aplicações
web. É uma tecnologia que torna possível projetar, desenvolver, empacotar e
implantar aplicações empresariais baseadas em componentes. A plataforma oferece
um modelo multicamada distribuída, com a possibilidade de reutilização de
componentes, transferência de dados feita em XML, um modelo de segurança
unificado e um flexível controle transacional.
O fato de ser uma especificação aberta possibilita que aplicações sejam
desenvolvidas sem vínculo com nenhum fornecedor específico. Portanto, pode-se
criar um único arquivo para toda uma aplicação. Ao implantá-lo em um application
server (servidor de aplicações), este se encarrega de desempacotá-lo e instanciar
um aplicativo web e as entidades de sua aplicação.
1.2 Citações
Uma definição de software seguro:
19
“Um software seguro é um software livre de vulnerabilidades,
que funciona da maneira pretendida e que essa maneira
pretendida não compromete a segurança de outras
propriedades requeridas do software, seu ambiente e as
informações manipuladas por ele (DHS, 2006).”
1.3 Formulação da Situação Problema
Neste contexto, temos como situação problema o controle de acesso, o qual é
um fator extremamente importante para a segurança de aplicações corporativas,
pois caso não seja desenvolvido corretamente, a confidencialidade e a integridade
das informações podem ser comprometidas.
Essas são algumas das perguntas que fazem parte da situação problema:
1. Como o Java EE e a Segurança Cibernética podem atuar nos aplicativos
web para mitigar vulnerabilidades?
2. Como codificar com segurança o controle de acesso?
3. Como os institutos de segurança poderão contribuir com o controle de
acesso?
4. Como prevenir para que os dados não sejam acessados indevidamente?
Hoje, segundo Guerra (2008), várias aplicações ainda possuem problemas no
emprego do controle de acesso, deixando a aplicação vulnerável a ataques. Para
explorar e entender esse problema na prática fez-se um levantamento da situação
atual na Gestão de Segurança da Informação e Comunicação na universidade
pública Z, com foco no nível de segurança no desenvolvimento de aplicações, o
objetivo é obter um mapeamento correto na reitoria da Universidade Z, mais
especificamente no setor de desenvolvimento de software da administração central
(InfoTIC).
O Governo Federal têm determinado que todos os órgãos públicos utilizem o
software livre. Por ser uma plataforma livre e gratuita, de notoriedade mundial, a
InfoTIC adotou o Java EE como uma das ferramentas para a produção de software
web e corporativo.
1.4 Objetivos e Escopo
Temos o objetivo de estudar algumas das diversas causas da falta de
segurança nas aplicações web, e procurar alertar a todos os funcionários
desenvolvedores de aplicações, sejam aplicações desktop ou para a web, da
20
existência de informações e técnicas para mitigar vulnerabilidades no software,
fornecidas pelos institutos de segurança, os quais devem ser inseridos na
codificação do software aplicativo.
A verificação continuada dos institutos de segurança na web tais como
OSVDB (Open Source Vulnerability Database), OWASP Top 10 - 2010 (OWASP,
2010), etc., divulgam constantemente uma lista de vulnerabilidades que ocorrem
com
maior
frequência,
auxiliando
dessa
forma,
a
prevenção
contra
as
vulnerabilidades dos softwares.
Ao desenvolver sistemas para atender o mais rápido possível às
necessidades dos usuários, as funcionalidades de segurança geralmente não são
priorizadas. Os usuários do sistema corporativo não têm uma percepção real da
segurança do sistema e, normalmente, só descobrirão a existência de uma falha
quando for tarde demais (GUERRA, 2008).
Esse problema começa cedo no ciclo de desenvolvimento, pela má
especificação dos requisitos de segurança. Porém, existem também os casos de
mau uso, em que se especifica como o sistema deve responder na tentativa de usos
não legítimos com intenções maliciosas (GUERRA, 2008).
A segurança é ignorada na fase de testes, devido ao fato dos profissionais
não estarem informados sobre as vulnerabilidades existentes, a fim de que
verifiquem se os requisitos de segurança foram desenvolvidos corretamente
(GUERRA, 2008).
Devido à frequência de ataques contra as aplicações terem se tornado
comum (veja anexo A), tais como, indisponibilidade, perda de integridade, perda de
confidencialidade, etc., resolveu-se estudar a utilização em conjunto de quatro
recursos para produção de um software seguro, como segue:
a. A plataforma de programação “Java EE”;
b. Um modelo de processo para desenvolvimento seguro de aplicativos
de software;
c. Aplicar as informações e técnicas para mitigar vulnerabilidades, que
estão disponíveis nos institutos de segurança;
d. NORMA ABNT NBR ISO/IEC 27002:2005, Seção 12.
Avalia-se a possibilidade de que a união de tais recursos, conforme o
apêndice “F” (vide Figura 16), proporcionarem um desenvolvimento de aplicativo
web seguro com codificação segura.
21
1.4.1 Objetivo Geral
Realizar um estudo de caso para avaliar requisitos de segurança em sistemas
web no setor de desenvolvimento da reitoria (InfoTIC) na universidade Z1.
1.4.2 Objetivos Específicos
São objetivos específicos deste estudo de caso (YIN, 2005):
1. Mostrar os principais erros cometidos no emprego do controle de acesso
em plataformas Java EE, que podem comprometer a confidencialidade e a
integridade das informações acessadas pela aplicação.
2. Abordar algumas formas de se criar uma solução para o controle de
acesso.
3. Mostrar como inserir código seguro em aplicação web, mas também
discutir a aplicabilidade e limitações dos modelos de controle de acesso
em aplicações Java EE.
1.4.3 Escopo
O estudo de caso está limitado ao setor de desenvolvimento e manutenção de
softwares aplicativos da reitoria da Universidade Z, composta por algumas equipes
de analistas de tecnologia da informação, os quais tem a missão de desenvolver
novos aplicativos web, para substituir alguns dos aplicativos legados. Tal
substituição decorre do fato de que esses aplicativos tornaram-se obsoletos, e
conforme os casos terão suas bases de dados migradas para uma base mais atual.
1.5 Justificativa
A escolha do tema da pesquisa se deve aos incidentes de segurança da
informação que vêm aumentando consideravelmente ao longo dos últimos anos, e
assumem as formas mais variadas, como por exemplo acesso não autorizado,
infecção por vírus, ataques “denial of service” contra redes e sistemas, furto de
informação proprietária, invasão de sistemas, fraudes internas e externas, uso não
autorizado de redes sem fio, entre outras (veja anexo A). A Plataforma Java EE é
utilizada para o desenvolvimento de aplicações web, e está sendo adotada pela
InfoTIC como ferramenta de desenvolvimento.
1
"O nome da instituição onde foi realizada a pesquisa foi trocado por questões de segurança da
informação".
22
A viabilidade da execução da pesquisa se deve ao fato de ser um dos
membros da equipe de desenvolvimento (InfoTIC).
A importância do desenvolvimento da pesquisa será a obtenção do resultado,
o
qual
permitirá
aos
desenvolvedores
de
aplicações
web
em
Java,
o
desenvolvimento seguro com codificação segura.
Com base no que foi mencionado no subitem 1.3, será mostrado neste
trabalho, procedimentos concisos e relevantes, para que a codificação segura possa
ser feita mediante o estabelecimento de critérios e métodos para elaboração de
sistemas aplicativos com segurança da informação, na reitoria da universidade Z.
1.6 Hipótese
Falta conhecimento das equipes de desenvolvimento da InfoTIC sobre a
maneira de usar questões de segurança da plataforma Java EE, no contexto
corporativo da reitoria da Universidade Z.
1.7 Organização do Trabalho
 Capítulo 2 apresenta uma revisão de literatura e de fundamentos, onde são
tratados os principais conceitos relacionados à codificação segura dos
softwares, vulnerabilidades existentes, a escolha da plataforma Java EE
como padrão para desenvolvimento de novos aplicativos, normas existentes e
padrões disponíveis nos institutos de segurança na internet.
 Capítulo 3 apresenta a metodologia, o estudo de caso, onde obteremos as
informações com capacidade de adicionar valor a processos, produtos e
serviços, que serão avaliados.
 Capítulo 4 apresenta os resultados da pesquisa realizada por meio do estudo
de caso.
 Capítulo 5 apresenta uma discussão em torno da segurança da Informação e
dos resultados obtidos no estudo de caso.
 Capítulo 6 apresenta as conclusões, contribuição e trabalhos futuros, onde
são mencionados os resultados da análise, as limitações e o público alvo da
pesquisa. Também são sugeridos os trabalhos futuros.
23
2 Revisão de Literatura e Fundamentos
O nome web vem do termo world wide web (www) que representa um sistema
de informações mundial distribuído, no qual as informações são "ligadas" umas às
outras por links de hipertexto. Desenvolvimentos mais recentes desta tecnologia têm
permitido distribuir, junto com as informações, objetos e programas que realizam
atividades junto ao cliente consumidor da informação. Os servidores estão ganhando
novas capacidades que os tem permitido também executar programas, acessar
bancos de dados corporativos e se comunicar com outros objetos da rede. O
desenvolvimento de aplicações seguras no ambiente web, é o que está sendo
tratado neste trabalho.
Para construir software seguro é necessário o conhecimento básico dos
princípios de segurança. Em virtude das limitações cronológicas, e dado o grande
volume de informações sobre o assunto, os conceitos de segurança serão
abordados de forma superficial, porém abrangente neste trabalho.
O objetivo da segurança em aplicações é manter a confidencialidade,
integridade e disponibilidade dos recursos de informação, a fim de permitir que as
operações de negócios sejam bem sucedidas. Esse objetivo é alcançado por meio
do emprego de controles de segurança.
São propriedades de um software seguro (Braz, 2008; DHS, 2006):
• Disponibilidade: o software deve estar sempre operacional e acessível para
os usuários autorizados sempre que necessário.
• Integridade: o software deve estar sempre protegido contra modificações
não autorizadas.
• Confidencialidade: no contexto da segurança do software, confidencialidade
se aplica para o próprio software e para os dados que ele manipula.
24
Duas propriedades adicionais associada aos usuários humanos podem ser
requeridas para as entidades de software que agem como usuário, como agentes
proxies e web services (DHS 2006):
• Responsabilização: toda ação relevante de segurança de um “softwarecomo-usuário”
deve
ser
registrada
e
acompanhada,
com
atribuição
de
responsabilidade. Este acompanhamento deve ser possível durante e depois dos
registros das ações que ocorrem.
• Não repúdio: a habilidade de prevenir o software-como-usuário de negar
responsabilidade sobre ações desempenhadas.
Existe uma diferença fundamental entre a abordagem adotada por uma
equipe de desenvolvimento e a abordagem que é adotada por alguém que está
interessado em atacar uma aplicação (OWASP, 2010). Uma equipe de
desenvolvimento, normalmente, desenvolve uma aplicação com base naquilo que
ela pretende fazer. Isso significa criar uma aplicação para executar tarefas
específicas baseadas em requisitos funcionais e casos de uso documentados.
Por outro lado, um hacker está mais interessado no que a aplicação pode ser
levada a fazer, e partem do princípio de que "qualquer ação não expressamente
proibida, é permitida". Para resolver isso, alguns elementos adicionais precisam ser
integrados nas fases iniciais do ciclo de vida do software. Estes novos elementos
são requisitos de segurança e casos de abuso (OWASP, 2010).
É importante que as equipes de desenvolvimento de aplicações web
entendam que os controles do lado cliente, como validação de entrada de dados no
cliente, campos ocultos e controles de interface (combo box, radio buttons),
fornecem pouco ou nenhum benefício de segurança (OWASP, 2010).
Um atacante pode usar ferramentas como proxies do lado do cliente, como o
OWASP WebScarab (OWASP, 2011), Burp ou ferramentas de captura de pacotes
de rede, como o Wireshark, para analisar o tráfego de aplicativo e enviar requisições
manipuladas, burlando todas as interfaces. Além disso, o Flash, os Applets Java e
demais objetos que trabalham no lado cliente podem ser compilados e analisados
em busca de falhas (OWASP, 2010).
As falhas de segurança de software podem ser introduzidas em qualquer fase
do ciclo de desenvolvimento de software, inclusive:

Não identificar as necessidades de segurança no início;

Criação de arquiteturas conceituais que possuem erros de lógica;
25

Usando práticas ruins de codificação que introduzem vulnerabilidades
técnicas;

Implantação do software de modo inapropriado;

Inserção de falhas durante a manutenção ou atualização.
Além disso, é importante entender que as vulnerabilidades de software podem
ter um escopo muito além do próprio software. Dependendo da natureza do
software, da vulnerabilidade e da infraestrutura de apoio, os impactos de uma
exploração bem sucedida podem comprometer qualquer ou todos os seguintes
aspectos:

O software e sua informação associada;

O sistema operacional dos servidores associados;

O banco de dados de backend;

Outras aplicações em um ambiente compartilhado;

O sistema do usuário;

Outros softwares que o usuário interage.
2.1 Referencial Teórico
Java EE (Java Edição Empresarial) é uma plataforma de programação para
servidores na linguagem de programação Java (ORACLE, 2011). Difere-se da
plataforma Java Standard Edition (Java SE) pela adição de bibliotecas que fornecem
funcionalidade para desenvolver software Java distribuído, tolerante a falhas e
multicamada, baseada amplamente em componentes modulares executando em um
servidor de aplicações.
A plataforma Java EE é considerada um padrão de desenvolvimento já que o
fornecedor de software (plugins, drivers, etc.) nesta plataforma deve seguir
determinadas regras se quiser declarar os seus produtos como compatíveis com
Java EE.
Ela contém bibliotecas desenvolvidas para o acesso a base de dados, RPC
(Remote Procedure Calls), CORBA, etc.
Conforme Wagner e Machado (2010, p. 6), o Java possui um alto nível de
segurança devido às aplicações funcionarem de forma “stand Box”, nenhuma
aplicação burla os requisitos de segurança especificados na linguagem Java, pois
elas não tem acesso diretamente ao Sistema Operacional, desta forma elas são
obrigadas a pedir que a Maquina Virtual Java aloque recursos do Sistema
26
Operacional para a aplicação, assim essas requisições da aplicação passam pelas
políticas de segurança especificadas na linguagem. No entanto, às vezes é
necessária a utilização de linguagem de baixo nível para obter acesso direto ao nível
de hardware.
Padrões de códigos, guias de segurança, normas de codificação e
orientações de segurança devem ser seguidas no intuito de evitar erros de códigofonte. Os padrões de desenvolvimento tais como:
i.
Facade que atua como uma camada mediadora entre a regra de
negócio da aplicação e a interface gráfica, permitindo que caso
regras de negócios mudem em algum determinado momento, isso
não impacte na reestruturação de toda a aplicação novamente;
ii.
Data Access Object (DAO) que permite a separação de código
destinado à manipulação de dados do banco de dados para a
aplicação, assim diminuindo a interferência da estrutura do banco
diretamente na aplicação desenvolvida.
Testes de unidade devem ser realizados com preocupações com a segurança
em mente, podendo ser utilizado o firebug para tais testes. Erros de segurança
relatados em software similares serão usados como uma referência, inclusive os
mencionados pelos institutos de segurança.
Devido a essas características a plataforma é utilizada principalmente para o
desenvolvimento de aplicações corporativas.
2.1.1 Contêineres ou API
Os contêineres ficam localizados entre os componentes e os clientes,
provendo serviços transparentes para ambos, incluindo serviços transacionais e
pooling de recursos (veja Figuras 1 e 2).
27
Figura 1: API da plataforma Java EE 5 nos contêineres (ORACLE, 2011)
Figura 2: Relações entre os contêineres Java EE 6 (ORACLE, 2011)
A plataforma Java EE contém uma série de especificações e containers, cada
uma com funcionalidades distintas:
a. JDBC (Java Database Connectivity), utilizado no acesso a bancos de
dados. A API permite chamar comandos SQL a partir de métodos na
linguagem de programação Java. A API JDBC pode ser usada em um
enterprise bean quando se tem um bean de sessão de acesso a banco de
dados. Também pode ser usada a partir de um servlet ou uma página
JSP para acessar o banco de dados diretamente, sem passar por um
28
enterprise bean. A API JDBC tem duas partes: uma interface em nível de
aplicativo utilizado pelos componentes de aplicativo para acessar um
banco de dados, e uma interface de provedor de serviços para anexar um
driver JDBC para a plataforma Java EE.
b. Servlets são utilizados para o desenvolvimento de aplicações · web com
conteúdo dinâmico. Ele contém uma API que abstrai e disponibiliza os
recursos do servidor · web de maneira simplificada para o programador. A
classe servlet estende as capacidades dos servidores que hospedam
aplicativos que são acessados por meio de um modelo de programação
de solicitação-resposta.
c. JSP (JavaServer Pages), uma especialização do servlet que permite que
conteúdo dinâmico seja facilmente desenvolvido. Uma página JSP é um
documento baseado em texto que contém dois tipos de texto: dados
estáticos (que podem ser expressos em qualquer formato baseado em
texto, como HTML, WML e XML) e elementos JSP, que determinam como
a página constrói o conteúdo dinâmico.
d. JTA (Java Transaction API) é uma API que padroniza o tratamento de
transações dentro de uma aplicação Java.
e. EJB
(Enterprise
JavaBeans),
utilizado
no
desenvolvimento
de
componentes de software. Eles permitem que o programador se
concentre nas necessidades do negócio do cliente, enquanto questões de
infraestrutura,
segurança,
disponibilidade
e
escalabilidade
são
responsabilidades do servidor de aplicações.
f. JPA (Java Persistence API) é uma API que padroniza o acesso a banco
de dados através de mapeamento Objeto/Relacional dos Enterprise
JavaBeans. Se o cliente termina, ou se o servidor é desligado, o
gerenciador de persistência garante que os dados da entidade sejam
salvos.
g. JSF (JavaServer Faces) é um framework do Java EE, que contém um
conjunto de componentes pré-fabricados de interface de usuário (IU) para
web, possuindo um modelo de programação orientado a eventos.
h. JMA (JavaMail API) envia notificações de e-mail. A API JavaMail tem
duas partes: uma interface em nível de aplicativo utilizado pelos
componentes de aplicativo para enviar e-mail, e uma interface de
29
provedor de serviços. A plataforma Java EE inclui JavaMail com um
prestador de serviço que permite que os componentes do aplicativo
enviem e-mail para a internet.
i. JNDI
(Java
Naming
and
Directory
Interface)
fornece
nomes
e
funcionalidade de diretório, permitindo que os aplicativos acessem vários
nomes e serviços de diretório, incluindo nomes existentes e serviços de
diretório como o LDAP, NDS, DNS e NIS. Ele fornece aplicativos com
métodos para executar operações de diretório padrão, como associar
atributos de objetos e busca de objetos usando seus atributos. Usando
JNDI, uma aplicação Java EE pode armazenar e recuperar qualquer tipo
de objeto Java, permitindo as aplicações Java EE coexistirem com muitas
aplicações legadas e sistemas.
Um aplicativo Java web pode ser projetado no modelo 1 ou modelo 2. O
modelo 1 é para aplicativos muito pequenos, que não irão crescer em complexidade
e consistem apenas em páginas JSP. Cada página JSP referencia outra página JSP,
tornando a manutenção muito difícil à medida que o aplicativo cresce.
A arquitetura no modelo 2 é o modelo de projeto recomendado para
aplicativos de tamanhos médios e grandes, e é baseado no padrão controlador de
visualização do modelo (Model View Controller, MVC). Uma arquitetura do modelo 2
(veja Figura 3) é indicada pela presença de um servlet controlador entre o browser
do cliente e as páginas JSP (ou servlets que apresentam o conteúdo).
Figura 3: Arquitetura modelo 2 - MVC (KURNIAWAN, 2004)
30
Aplicativos modelo 2 são mais flexíveis e fáceis de manter e de estender,
porque
as
visualizações
não
referenciam
umas
às
outras
diretamente
(KURNIAWAN, 2004). O servlet controlador modelo 2 fornece um ponto único de
controle para segurança e registro (logging) e, frequentemente, encapsulam dados
que chega a um formulário usável pelo back-end modelo MVC.
Conforme Stair e Reynolds (2006), um software pode ser classificado em dois
tipos principais: software de sistema, que controlam as operações básicas de um
computador (sistema operacional, dentre outros); e software de aplicação para fins
específicos, como, por exemplo, o que realiza o controle financeiro de uma empresa
específica. O software de aplicação pode ser chamado simplesmente de aplicação
ou aplicativo e é o foco deste trabalho.
Conforme destaca Fernandes (2010), um software de aplicação, em geral, é
parte de um sistema automatizado, e serve para automatizar um processo
organizacional. Um software de sistema, por outro lado, automatiza um processo
computacional que usualmente não teria viabilidade de ser executado por um ser
humano, por exemplo, o processamento de pacotes do IP (Internet Protocol) em um
dispositivo de redes de computadores.
2.1.2 Algumas Possibilidades de Risco no Controle de Acesso
a. Risco 1 – Código Escondido Não Garante a Proteção
Alguns desenvolvedores acreditam que se numa aplicação web, ocultarem
alguns elementos da interface, tais como botões, campos de texto, links, etc., de
forma tal que somente o administrador do aplicativo terá acesso a esses
componentes, isso trás segurança ao mesmo (GUERRA, 2008). Apesar do botão
não ser exibido para outro usuário, nada impede que o mesmo acesse a URL e
execute uma ação sem permissão, tal como a alteração de um parâmetro que
identifica o usuário numa consulta do aplicativo (veja Figura 4).
31
Figura 4: Código escondido não protege (GUERRA, 2008)
Temos um exemplo no apêndice “B” (veja Figuras 13 e 14), nas quais o
usuário acessa a URL deixada por outro usuário que fez compra anteriormente num
sítio de comércio eletrônico, a qual fica cacheada no navegador, e modifica o código
uma ou mais vezes, para saber quais informações constam dos outros clientes.
Portanto, isso não basta para garantir a segurança de acesso, é necessário
também uma verificação junto ao servidor de sistemas web, se o usuário tem
autorização para acessar essas informações.
b. Risco 2 – Código do EJB Sem Proteção
Nas aplicações, o controle de acesso é tratado como uma característica
funcional, de forma em que as funcionalidades que não são permitidas não estejam
disponíveis no menu, e as tentativas inválidas de acesso sejam broqueadas, seria o
suficiente (GUERRA, 2008).
Porém, a segurança é uma característica não funcional e precisa ser
considerada durante toda a arquitetura do sistema aplicativo a ser desenvolvido.
Qualquer ponto de entrada possível deve ser considerado (veja Figura 5).
32
Figura 5: Código do EJB sem proteção (GUERRA, 2008)
Não se deve deixar toda a segurança na camada web, pois os EJB são
disponibilizados remotamente e podem ser acessados. Os EJB devem disponibilizar
somente interfaces locais, para não serem acessados remotamente. Se o acesso
remoto for necessário, as regras de controle de acesso devem ser movidas ou
replicadas para a camada EJB. Todo software aplicativo deve ter sua camada de
proteção, independentemente de haver outra na rede. A junção da camada de
proteção da rede e dos aplicativos ajuda a diminuir as vulnerabilidades (GUERRA,
2008).
c. Risco 3 – Código Com Proteção Só na Fachada
Essa vulnerabilidade é semelhante com a anterior (GUERRA, 2008), porém
ao invés de colocar o controle de acesso na camada web, o mesmo foi colocado na
fachada. Porém, algumas aplicações deixam o EJB protegido pela fachada sem
configurações de segurança e abertos para acesso remoto. Dessa forma, alguém
não autorizado pode acessar EJB contendo regras de negócio sem ter as
credenciais para isso (veja Figura 6).
33
Figura 6: Código com proteção só na fachada (GUERRA, 2008)
Tanto o acesso a EJB com interface remota, serviços web e mensagens JMS,
devem ter na porta de entrada da aplicação, mesmo quando não seja utilizada, a
obrigação do usuário ser autenticado e verificado se possui autorização para o
acesso.
d. Risco 4 – Códigos Que Fazem Muita Coisa Sem Proteção
Isso ocorre (GUERRA, 2008), quando numa aplicação web existe um servlet
que pode realizar várias ações, sendo que as ações são determinadas por um
parâmetro. Nas aplicações EJB, juntamente com o uso do padrão de projeto
Command, onde o EJB recebe um comando como parâmetro para ser executado
(veja Figura 7).
Figura 7: Códigos que fazem muita coisa sem proteção (GUERRA, 2008)
34
Esse risco acontece quando o controle de acesso controla apenas a
execução do servlet ou método, independentemente do que será executado nele. No
EJB, se o usuário executar algum comando utilizando o método, então ele pode
executar qualquer comando. Isso acontece por que a permissão é dada para
execução do método, independente de qual comando é enviado (GUERRA, 2008).
Se numa aplicação web, um mesmo servlet realiza todas as operações CRUD
(Create, Read, Update, Delete) de uma determinada entidade, baseada em um
parâmetro enviado chamado “action”. Se o usuário deve possuir acesso apenas à
leitura enviando “action=read”, ele pode enviar “action=delete” para a exclusão de
um registro, pois o controle de acesso é feito apenas ao servlet e não considera o
parâmetro “action” recebido. Assim, quem acessa um, tem acesso a todos
(GUERRA, 2008).
e. Risco 5 – Código Servlet AJAX Sem Proteção
O AJAX deixa as aplicações mais interativas (GUERRA, 2008), mas deixa
brecha na segurança. Esse risco acontece quando o controle de acesso é aplicado
apenas para os servlets da aplicação e as funcionalidades do AJAX ficam de fora.
Geralmente, os servlets AJAX nem verificam se o usuário está ou não autenticado.
Como não é acessado diretamente pelos usuários, um teste funcional não detecta
um problema como esse. Os servlets AJAX podem revelar dados relevantes para um
próximo ataque, tais como identificadores de banco de dados.
Figura 8: Código servlet AJAX sem proteção (GUERRA, 2008)
35
A solução está em criar um mecanismo que abranja os dois tipos de acesso
na camada web ou no posicionamento do mecanismo de controle na camada de
negócios (veja Figura 8).
f. Risco 6 – Código de Autenticação Com Servidor de Aplicações
Isso acontece em aplicações desktop (GUERRA, 2008), os quais acessam
servidores de aplicação, onde o controle de acesso é feito totalmente utilizando a
lógica da interface. Ao proteger-se o acesso aos EJB e não deixar aberto a qualquer
pessoa é criado um perfil relativo àquela aplicação que possui o acesso a tudo que
qualquer usuário pode precisar. Portanto, a autenticação com o servidor de
aplicações é realizada utilizando credenciais da aplicação (a aplicação se autentica)
e não de seus usuários (veja Figura 9).
Figura 9: Código de autenticação com servidor de aplicações (GUERRA, 2008)
Tendo posse da biblioteca cliente dos EJB, um atacante pode criar uma
aplicação que usa qualquer funcionalidade da forma que quiser. A senha de
autenticação da aplicação estará, provavelmente, embutida em algum componente
da aplicação ou em algum arquivo de configuração. Se o inimigo possui a aplicação,
ele acessa qualquer coisa.
A solução é implementar o controle de acesso no servidor e basear-se nas
credenciais dos usuários, tendo-se o cuidado de onde são armazenadas.
36
g. Risco 7 – Código Com Dados Sem Proteção
Um grande erro cometido no controle de acesso, é controlar as permissões
das funcionalidades e ignorar os dados que são acessados e manipulados. Isso
ocorre quando o desenvolvedor fica preso aos mecanismos de controle de acesso
fornecidos pela plataforma Java EE, cujas granularidades são métodos em EJB e
URL em aplicações web. Como exemplo, temos a seguinte regra: um vendedor só
pode acessar as vendas realizadas por ele. Fica complicado imaginar perfis de
acesso para controlá-las (GUERRA, 2008); (veja Figura 10).
Figura 10: Código com dados sem proteção (GUERRA, 2008)
Concluí-se que o controle de acesso padrão do Java EE (RBAC) não é
suficiente neste caso. Portanto, é necessário utilizar o RBAC com contextos em
situações simples e o ABAC em situações mais complexas.
É extremamente importante quando se for definir o controle de acesso em
uma aplicativo:
1. levantar os requisitos de controle de acesso e escolher o modelo mais
adequado para o caso;
2. escolha um local na arquitetura onde o componente de controle de acesso
cubra todas as entradas possíveis da aplicação.
37
2.2 Referenciais Conceituais das Disciplinas do CEGSIC
O software, conforme Holanda e Fernandes (2011, p. 10), são partes
inerentes à automação dos processos de sistemas de informação e de processos da
infraestrutura computacional. Se esses processos de sistemas de informação e de
infraestrutura computacional falham, sejam por causas acidentais, como erro de um
operador humano ou erros na programação do software, seja por causas
intencionais, como ataques por um hacker, vários são os problemas que podem ser
gerados. De fato, pode-se dizer que, de forma complementar aos incidentes de
segurança decorrentes de falhas ou ataques do componente humano no trato da
informação, a grande maioria dos demais incidentes de segurança da informação
tem sua origem nas vulnerabilidades presentes no software. Um dos principais
fatores causadores dessas vulnerabilidades é a codificação ingênua do software por
um programador, quando o mesmo considera basicamente os cenários positivos de
execução de um código, sem se preocupar com o caso de usuários maliciosos.
O grande problema em relação às aplicações web, conforme Holanda e
Fernandes (2011, p. 16), é que a rede de comunicações pode estar segura apenas
com firewall, e controle de acesso, mas, mesmo assim, um usuário mal intencionado
pode, através de entrada de dados em um formulário web, executarem vários tipos
de ataques que escapam completamente ao controle da equipe de segurança em
redes. O problema da segurança das aplicações web, e a dificuldade que as
abordagens de segurança em redes de computadores têm para alcançar essa
segurança são descritos em mais detalhes em trabalhos como Paiva e Medeiros
(2008).
Os institutos de segurança na web atualizam continuamente suas listas com
os tipos mais frequentes de riscos, ataques e vulnerabilidades em aplicações web.
Como pode ser observado no gráfico da Figura 11, disponibilizado pelo OSVDB2, os
ataques de XSS (Cross-Site Scripting) e Injeção de SQL, CSRF (Cross-site request
forgery), Inclusão de arquivo, DoS e overflow vem acontecendo com freqüência ao
longo dos anos.
O objetivo do projeto OSVDB é fornecer informações exatas, detalhadas,
atuais e de maneira imparcial sobre informações técnicas de vulnerabilidades e
segurança. É um projeto open source e independente com uma base de dados
2 OSVDB – Open Source Vulnerability Database
38
criada para auxiliar a comunidade nos assuntos relacionados à Segurança. O projeto
visa promover a colaboração entre as empresas e indivíduos de maneira maior e
mais aberta, eliminando redundâncias nas obras, e reduzindo as despesas inerentes
com o desenvolvimento e a manutenção de vulnerabilidades internas de Bases de
Dados.
Figura 11: Vulnerabilidades. Fonte: (OSVDB, 2010)
2.3 Referenciais Produzidos Pelos Próprios Cursistas
2.3.1 Autenticação e Autorização em Aplicativos Web
Aplicativos web são formados por diversos recursos, como páginas
dinâmicas, estáticas, imagens, downloads, uploads, processos, relatórios etc. E na
maioria delas existe a necessidade de controlar o acesso dos usuários a estes
recursos, restringindo-o somente para aqueles previamente identificados e
autenticados.
Autenticação representa a forma como o usuário prova quem realmente ele
é, e a Autorização é utilizada para verificar se o determinado usuário previamente
autenticado possui permissão para usar, manipular ou executar o recurso em
questão.
Segundo Franzini (2011), temos algumas possibilidades mostradas abaixo
(das mais simples às mais sofisticadas), seus comentários e algumas referências
apresentando
possibilidades,
documentações
e
tutoriais
de
possíveis
implementações, ficando a cargo dos projetistas responsáveis pela aplicação julgar
e selecionar aquela que satisfaz um determinado escopo/projeto em específico:
39
a. Servlet Filter
A forma mais básica e rápida de implementar controle de usuários seria através
da construção e configuração manual de servlet filters. Existentes desde a versão
2.3 da especificação, os filters possibilitam a interceptação, manipulação e
redirecionamento do pedido HTTP antes que ele chegue ao seu destino real.
Com base em sua funcionalidade, seria muito simples construir um filtro
específico para o determinado contexto da aplicação fazendo o controle de
acesso aos recursos da aplicação. E para aqueles que prezam a simplicidade,
mas com flexibilidade, também podem usar o filter para implementar mecanismos
mais elaborados e flexíveis, combinando os filters com arquivos XML. São várias
as opções de implementações: Filtros para servlets (OLMOS, 2011), Utilizando
Servlet Filter com JavaServer Faces (SACRAMENTO, 2011), Autenticação e
Autorização sem JAAS utilizando hierarquia de Perfis de Acesso – Parte I
(FERNANDES, 2011).
b. Phase Listener
Para as aplicações escritas em JavaServer Faces, além da opção de usar
servlets filters, estas podem utilizar um recurso especifico do JSF chamado de
phase listener que é responsável por interceptar e oferecer mecanismos de
manipulações referentes às mudanças de eventos ocorridas no ciclo de vida da
especificação. Relacionado ao contexto de autenticação e autorização, ela está
bem adequada a implementações de controle de usuários, oferecendo ao
projetista da aplicação mais uma opção arquitetural. São várias as opções de
implementações: Filtrando requisições com PhaseListener (LAZOTI, 2011),
Controlando o acesso em aplicações JSF - PhaseListener (MACEDO, 2011),
Login - autenticação e autorização usando JavaServer Faces (MOREIRA, 2011).
c. JAAS
Define um modelo padrão Java EE de regras de como a aplicação web pode
definir e gerenciar controle de acesso. Baseado em especificação e
implementado por todos os containers compatíveis, o JAAS é a solução 100%
portável indicada pela especificação para ser usada. Nele existem diferentes
níveis em opções de autenticação que são baseados na definição ROLES (*),
40
que são resumidamente grupos de usuários. A base de dados dos usuários
credenciados pode estar em arquivos XML, bancos de dados relacionais, LDAP,
etc. São várias as opções de implementações: Tutorial de JASS (VIANA, 2011),
Security - Como Usar JAAS Com Tomcat 6 (PASSOS, 2011), Autenticação e
Autorização: JAAS com JDBC Realm (JEVEAUX, 2011), Realm Configuration
HOW-TO (ASF, 2011).
d. jGuard
Framework proprietário construído em cima do JAAS oferecendo alguns
automatismos, facilidades e integrações interessantes com alguns componentes
JEE sendo um boa opção a ser considerada.
e. Spring Security
Um dos maiores frameworks da atualidade que oferece um leque muito amplo
em recursos para se implementar autenticação e autorização. É uma solução
profissional, mais difícil e complexa sendo que o framework oferece uma
variedade incrível de opções arquiteturais.
2.4 Argumentos do Pesquisador
O setor de desenvolvimento de aplicações corporativas (InfoTIC) da reitoria
da universidade Z, nos permitiu observar e acompanhar as dificuldades durante a
implementação de aplicativos web.
A plataforma Java EE faz o casamento do código Java com o HTML, por meio
das páginas em JSP, para o desenvolvimento de aplicações web. Neste contexto, é
possível realizar operações dinâmicas, tais como fazer uma consulta no banco de
dados sobre o curso e disciplinas nas quais o aluno esteja matriculado, e em poucos
segundos, obter-se o resultado na janela do navegador web (browser).
A utilização de uma metodologia de desenvolvimento de software seguro, é
um pré-requisito para o desenvolvimento de aplicações.
Porém, como os institutos de segurança alertam sobre as diversas
vulnerabilidades e suas consequências, isso motivou o estudo de caso, no ambiente
de trabalho, a fim de que possamos mitigar essas vulnerabilidades nos aplicativos
que são desenvolvidos na plataforma Java EE.
41
O instituto OWASP, oferta gratuitamente um código Java que, anexado ao
aplicativo web (OWASP Enterprise Security API - ESAPI), ajuda prevenir contra
diversas vulnerabilidades (OWASP, 2011).
No apêndice “F”, temos uma mapa conceitual, onde se mostra como
desenvolver um software com código seguro (veja Figura 16).
42
3 Metodologia
3.1 Tipo de Pesquisa
Esta pesquisa utiliza o método de estudo de caso com tipo de dados
qualitativo, pois é descritiva. Segundo Yin (2005), o estudo de caso pode abordar
aspectos qualitativos e também quantitativos. Também, segundo Yin (2005), além
do seu uso para fins exploratórios, o estudo de caso pode ser aplicado para fins
descritivos e para fins explanatórios, conforme a estrutura de pesquisa adotada.
Conforme Yin (2005) é importante que o estudo de caso empregue mais de
uma fonte de evidência para a constatação do que ocorre em determinado fato. As
fontes de evidência existentes são documentos, registros em arquivos, entrevistas,
observação direta, observação participante e artefatos físicos.
Os sistemas aplicativos web da universidade são cliente-servidor. Quando os
setores e unidades necessitam que seja desenvolvido algum sistema de aplicação,
os diretores responsáveis pelas unidades enviam um memorando via e-mail para o
diretor da InfoTIC, solicitando este tipo de serviço. O diretor da InfoTIC verifica quais
analistas estão disponíveis para desenvolver o serviço, formando a equipe que ficará
responsável pelo desenvolvimento da nova aplicação.
Há também na universidade Z, sistemas isolados, que atendem interesses
específicos das unidades, que foram desenvolvidos e são mantidos por funcionários
terceirizados, contratados conforme interesse do diretor da unidade. Estes sistemas
estão fora da responsabilidade da TIC.
Será analisado o sistema corporativo SGA. O SGA (Sistema de Gestão
Acadêmica) abrange somente uma unidade da universidade, ou seja, o Instituto de
Economia. O sistema de aplicação será acessado e operado pela web (veja
43
apêndice “G”). Neste apêndice está uma cópia do código-fonte, onde mostramos
uma codificação sem segurança.
Através deste trabalho tem-se o objetivo de estudar a forma de como
desenvolver e codificar com segurança um aplicativo web, na linguagem de
programação Java, utilizando os recursos seguintes:
 A plataforma Java EE;
 Uma metodologia de desenvolvimento seguro;
 As informações sobre vulnerabilidades que podem ser mitigadas;
 NORMA ABNT NBR ISO/IEC 27002:2005, referente à Seção 12.
A partir desta pesquisa serão selecionados os procedimentos considerados
pertinentes para elaboração de um tutorial 3, onde serão incluídos processos,
procedimentos e técnicas para ajudar na análise e desenvolvimento de aplicativos
com segurança da informação, utilizando-se o Java EE.
Foi realizado o estudo de caso, a fim de aprofundar os conceitos sobre o
tema, com a coleta de dados em campo, cujos dados coletados tiveram como fonte
de evidências as entrevistas, questionários, observação direta, observação
participante, e análise de documentos.
A documentação neste estudo de caso são artigos em revista, na mídia de
massa, e informativos de comunidade.
Como ferramentas foram realizadas as anotações das evidências em um
arquivo com a utilização de um editor de texto. Os questionários que foram
distribuídos numa ocasião foram devolvidos em outro dia posterior.
A pesquisa foi realizada no setor de análise e desenvolvimento de sistemas
aplicativos corporativos (InfoTIC), da reitoria da universidade Z, junto aos analistas e
programadores, os quais compõem as equipes ali existentes.
3.2 Plano da Pesquisa
3.2.1 Pesquisa Bibliográfica
Escolheu-se para a realização deste estudo de caso uma pesquisa
bibliográfica, como sendo uma das fontes de evidência, que permitiu um
aprofundamento sobre os conceitos envolvidos no tema, a descrição de casos e
3
Apêndices “C” , “D” e “E”.
44
suas respectivas análises e a apresentação de medidas para mitigar as
vulnerabilidades nas aplicações web (veja Capítulo 2 e apêndices “C” e “D”).
A pesquisa está fundamentada em trabalhos científicos, em documentos
técnicos e internet, além de outros trabalhos apresentados em congressos ou
revistas especializadas, o que denota a relevância atribuída ao estudo do tema.
Para tanto, procedeu-se a uma coleta de artigos e trabalhos nas áreas tanto
da segurança da informação quanto da formulação e implementação de políticas de
caráter público e organizacional, tais como os institutos de segurança.
Restringiu-se esta pesquisa ao universo conceitual baseado no referencial
teórico e na análise de casos ocorridos dentro da Administração Pública Federal,
onde os dados são tratados dentro de uma premissa de realidade e atualidade (veja
apêndice “A”).
3.2.2 Preparo do Questionário
Devido a pouca disponibilidade de tempo, optou-se por fazer um questionário
contendo dez questões ao todo, as quais trarão como resultado, o nível de
conhecimento sobre segurança de software dos funcionários que fazem o
desenvolvimento de aplicações web. Havia o propósito de entrevistar dez
funcionários do setor de desenvolvimento.
3.2.3 Coleta de Dados
1) Qual a metodologia utilizada para o desenvolvimento do software web?
2) Quais são os critérios de segurança adotados no desenvolvimento de
software web em Java EE?
3) Qual o nível de abrangência dos sistemas aplicativos web em Java EE na
universidade?
4) Como são utilizados os sistemas aplicativos web em Java EE na
universidade?
5) As aplicações web em Java EE podem sofrer algum tipo de ameaça?
6) Quais são os principais riscos e vulnerabilidades de uma aplicação web em
Java EE?
7) Como evitar a ocorrência de um ataque de Injeção de SQL numa aplicação
web em Java EE?
8) Como se faz para evitar o ataque de Cross-site scripting (XSS) numa
aplicação web em Java EE?
45
9) O que é um desenvolvimento de software com código seguro?
10) As informações dos Institutos de segurança sobre vulnerabilidades são
utilizadas nas aplicações que desenvolve?
3.2.4 Documentação e Estruturação dos Resultados
As fontes de dados foram: analistas e programadores pertencentes ao
InfoTIC, revisões bibliográficas, entrevista, consulta de sitio na internet.
Os dados foram armazenados em dois arquivos de planilha, sendo que uma
(veja Tabela 2) contém as perguntas, o nome do funcionário entrevistado, a
linguagem de programação na qual desenvolve o sistema de aplicação, e as
respostas. Uma nota é atribuída a cada funcionário, conforme a resposta dada, de
modo que se a resposta estiver de acordo com cada questão, se ganha 1 ponto,
caso contrário 0. Na outra planilha (veja Tabela3) fica a nota total de cada
funcionário entrevistado. A partir deste total de notas é realizada uma média, que
corresponde ao nível de conhecimento de segurança em aplicações web.
3.2.5 Validação e Análise dos Resultados
Os dados foram coletados utilizando o seguinte plano:
i) Técnica: Entrevista, observação (participante), e documentos.
ii) Local: InfoTIC, situado na reitoria da universidade Z.
iii) Fonte: Analistas e Programadores de TI, questionário, entrevista.
iv) Data: Período de 15/08/2011 até 31/10/2011.
v) Hora: Entre 09:00 h até as 16:00 horas.
A validação e análise dos resultados é consequência natural da coleta de
dados, pois a partir das evidências documentais, resposta dos questionários e
entrevistas, obteremos um resultado. O resultado irá demonstrar se a hipótese é
verdadeira ou não.
46
4 Resultados
Com o intuito de comprovar a hipótese, foi realizado um estudo de caso com
a participação de quatro analistas e três programadores, os quais são funcionários
do setor de desenvolvimento, sendo que somente os analistas foram capacitados no
final de 2010 na plataforma Java EE 5, onde aprenderam a utilizar as ferramentas
seguintes: o JDK 6, o servidor de aplicações JBoss 5, o framework JBoss-Seam 2.0,
a IDE4 Eclipse 3.4, um sistema gerenciador de banco de dados MySQL 5.
O percentual de funcionários entrevistados é de 13,5% do total de
funcionários da TIC. As entrevistas ocorreram em dias e horas diferentes, e
demoraram aproximadamente uma hora cada uma.
4.1 Setor de Desenvolvimento de Aplicações
A TIC é composta por um total de 30 analistas e 22 técnicos, sendo que
somente 9 técnicos trabalham com programação e os outros 13 trabalham com
infraestrutura. A administração da TIC definiu que a InfoTIC utilize o método de
desenvolvimento conhecido como Processo Unificado (RUP 5).
A TIC foi criada em meados de 2009, com funcionários já pertencentes à
universidade, que agora corresponde a 11,5% dos funcionários da TIC, os quais
foram admitidos através de concurso público, e tomaram posse antes de 2009. Os
demais 88,5% foram admitidos através de concurso público, e tomaram posse entre
fevereiro a novembro de 2010. A TIC está vinculada a uma pró-reitoria.
Somente
8
analistas
e
mais
2
programadores
trabalham
com
desenvolvimento em Java, outros 11 analistas e mais 4 programadores
4
5
IDE – Integrated Development Enviroment (ambiente integrado para desenvolvimento de software).
RUP – Rational Unified Process.
47
desenvolvem em PHP, outros 7 analistas e mais 2 programadores desenvolvem em
ASP, e os 5 analistas restantes desenvolvem em outras linguagens.
O percentual de funcionários que desenvolvem em Java corresponde a
exatamente 19,2% dos funcionários que fazem desenvolvimento.
O percentual de funcionários que desenvolvem em outras linguagens é de
80,8%. Sendo que 28,8% desenvolvem em PHP, 17,3% desenvolvem em ASP e
34,6% desenvolvem em outras linguagens tais como “C”, “C++”,
“JavaScript”,
“HTML”, “DELPHI”, “Visual Basic 6”, etc.
Temos um sistema SGA, cujo nome do projeto é “SisGestaoAcademica”, o
qual foi desenvolvido para web, com JavaServer Pages (JSP), ide NetBeans 6.5, jdk
6, servidor web Apache Tomcat 6 na porta 80 (veja apêndice “G”). Neste apêndice
está uma cópia do código-fonte, onde mostramos uma codificação sem segurança.
A InfoTIC tem um total de dez equipes, sendo três equipes com
desenvolvimento em Java, quatro equipes com desenvolvimento em PHP, duas
equipes com desenvolvimento em ASP, e uma equipe para suporte nas outras
linguagens de programação (Delphi 7, Visual Basic 6, Access, etc.).
As equipes formadas em Java são: EQP01 composta de dois analistas e dois
programadores; EQP02 composta de dois analistas; EQP03 composta de quatro
analistas. As sete equipes restantes trabalham nas outras linguagens de
programação.
Por enquanto, o PHP é utilizado como linguagem principal para o
desenvolvimento de aplicações web, pois as equipes nomeadas de EQP04 até
EQP10, ainda não foram capacitadas na plataforma Java EE.
4.2 A Pesquisa
Para realizar a pesquisa, foi feito um plano de coleta de dados, conforme
pode ser visto na Tabela 1.
Técnica
Tabela 1 – Plano de Coleta de Dados.
Local
Fonte
Data
Hora
Entrevista,
InfoTIC (reitoria da
Analista,
De
Entre as
Observação
universidade Z)
Programador,
15/08/2011 9h até às
participante,
Questionário,
até
Documentação.
Entrevista.
31/10/2011
16h
48
Foram distribuídos questionários e também foram realizadas entrevistas,
cujas respostas foram armazenadas num arquivo gerado por um editor de texto. Na
Tabela 2 podemos ver as perguntas e respostas obtidas dos funcionários que foram
entrevistados. As respostas das 10 questões estão nas colunas por funcionário.
Tabela 2 – Pesquisa Sobre Segurança no Desenvolvimento de Software 6
Pesquisa sobre a utilização de segurança no desenvolvimento do software na universidade Z.
COLETA DE DADOS
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
Qual a metodologia utilizada para o desenvolvimento do software web ?
Quais são os critérios de segurança adotados no desenvolvimento de software web em Java EE?
Qual o nível de abrangência dos sistemas aplicativos web em Java EE na universidade?
Como são utilizados os sistemas aplicativos web em Java EE na universidade?
As aplicações web em Java EE podem sofrer algum tipo de ameaça?
Quais são os principais riscos e vulnerabilidades de uma aplicação web em Java EE?
Como evitar a ocorrência de um ataque de Injeção de SQL numa aplicação web em Java EE?
Como se faz para evitar o ataque de Cross-site scripting (XSS) numa aplicação web em Java EE?
O que é um desenvolvimento de software com código seguro?
As informações dos Institutos de segurança sobre vulnerabilidades são utilizadas nas aplicações que desenvolve?
RESPOSTAS
FUNC1 / ANALISTA
FUNC2 / ANALISTA
JAVA
1
NOTA 1
2
NOTA 2
3
NOTA 3
4
NOTA 4
5
NOTA 5
6
NOTA 6
7
NOTA 7
8
1
1
DIVERSOS, ALGUNS
LOCALIZADOS NA
UNIDADE, OUTROS
ABRANGEM TODA A
UNIVERSIDADE
1
1
MVC
1
1
PARA TODA A
UNIVERSIDADE
INJEÇÃO DE SQL,
CROSS-SITE
SCRIPTING (XSS)
1
ATAQUES DOS
HACKERS
1
1
1
9
1
AINDA NÃO, MAS
PRETENDEMOS
UTILIZAR
0
9
0
DESENVOLVIMENTO
BASEADO NUMA
METODOLOGIA
SEGURA COMO O
OWASP
1
APENAS ALGUNS
1
9
MVC
LOGIN E SENHA
COM PERFIL DE
ACESSO
1
TODA A
UNIVERSIDADE
REITORIA
INTRANET OU
INTERNET
1
1
VALIDAR O
CONTEÚDO DOS
CAMPOS "INPUT"
1
1
UTILIZA O CONTENT
SEGURITY POLICY
DO GOOGLE
NÃO SABE
0
0
MINIMIZAR TODAS AS
NÃO SABE
VULNERABILIDADES
1
0
8
Os nomes dos funcionários nas Tabelas
informação.
NÃO SABE
0
0
NÃO
0
6
TRIAGEM DOS
REQUISISTOS
0
CRIPTOGRAFIA,
GERENCIA DE
PERMISSÕES, LOGIN
1
TODA A
UNIVERSIDADE E
PÚBLICO EXERNO
1
ACESSO A ÚLTIMAS
NOTÍCIAS, ACESSO
OUTROS SISTEMAS
NÃO SABE
FUNC7 /
PROGRAMADOR
PHP
1
TODA A
UNIVERSIDADE E
PÚBLICO EXERNO
0
1
ACESSO A ÚLTIMAS
NOTÍCIAS, ACESSO
OUTROS SISTEMAS
0
SIM,
CONSTANTEMENTE
SIM
1
TRIAGEM DOS
REQUISISTOS
0
1
1
SIM
FUNC6 /
PROGRAMADOR
PHP
SEGUIR PADRÕES,
TRATAR STRINGS DE
CONSULTA DE
CRIPTOGRAFIA,
BANCO DE DADOS,
GERENCIA DE
CUIDADO COM A
PERMISSÕES, LOGIN
SAÍDA DOS DADOS
PARA EVITAR O XSS
1
ACESSO AS
TABELAS DO BANCO INVASÃO AO
DE DADOS, ACESSO SERVIDOR DE
DE UMA PÁGINA VIA APLICAÇÃO
GET
AINDA NÃO
0
1
VALIDAR TODOS OS
UTILIZAR PREPARED
UTILIZAR
DADOS RECEBIDOS
STATEMENT OU
INTERROGAÇÃO NO
PELO APLICATIVO VIA
NAMED PARAMETERS
SQL
GET OU POST
O MESMO ANTERIOR NÃO OUVIU FALAR
COM A ATIVAÇÃO DO NESSE TIPO DE
ESCAPE
ATAQUE
FUNC5 /
PROGRAMADOR
PHP
0
1
1
DESDE
CONFORME A
DEPARTAMENTOS
FINALIDADE DE CADA
SIGA , SAM
ATÉ TODA A
UM
UNIVERSIDADE
1
1
1
SIM, CASO NÃO SEJA
SIM, INDEPENDENTE UTILIZADA ALGUMA
SIM
DA LINGUAGEM
TÉCNICA DE
SEGURANÇA
1
1
1
1
NOTA 10
NOTA TOTAL
JAVA
RUP
LOGIN E SENHA COM LOGIN, REGISTRO DE
LOGIN E SENHA
CRIPTOGRAFIA MD5 LOG
DESENVOLVIMENTO
PADRÃO MAIS
CUIDADOS
INFORMADOS PELOS
INSTITUTOS DE
SEGURANÇA
10
JAVA
RUP
NOTA 8
NOTA 9
6
RUP
FUNC4 /
ANALISTA
JAVA
FUNC3 / ANALISTA
1
0
SIM,
CONSTANTEMENTE
1
DoS, SNIFFING,
XSS, SQL INJECTION, FALHAS NÃO
BRUTE FORCE, DDOS REVISADAS PELOO
DESENVOLVEDOR
1
1
DoS, SNIFFING,
FALHAS NÃO
REVISADAS PELOO
DESENVOLVEDOR,
XSS
1
USO DE
COMPONENETES
ESPECÍFICOS QUE
GERENCIAM A
FUNÇÕES NATIVAS
CONEXAO COM O
DO BANCO DE DADOS
BANCO DE DADOS,
EVITAR
CONCATENAÇÃO DE
STRINGS
0
0
1
USO DE
COMPONENETES
ESPECÍFICOS QUE
GERENCIAM A
CONEXAO COM O
BANCO DE DADOS,
EVITAR
CONCATENAÇÃO DE
STRINGS
0
USA A FUNÇÃO
HTMLENTITIES DO
PHP
NÃO SABE
NÃO SABE
0
SEGUIR PADRÕES E
RECOMENDAÇÕES
DE SEGURANÇA E
CONHECER BEM OS
RECURSOS DA
LINGUAGEM DE
PROGRAMÇÃO QUE
UTILIZA
1
0
0
DESENVOLVIMENTO
OBJETIVO, EVITAR
CONEXÕES ABERTAS,
SERVIDOR COM BOA
INFRAESTRUTURA DE
SEGURANÇA
DESENVOLVIMENTO
OBJETIVO, EVITAR
CONEXÕES ABERTAS,
SERVIDOR COM BOA
INFRAESTRUTURA DE
SEGURANÇA
1
1
MANTER AS
BIBLIOTECAS
UTILIZADAS SEMPRE
ATUALIZADAS
NÃO SABE
1
5
NÃO SABE
0
5
0
5
2 e 3 foram trocados por motivo de segurança da
49
A Tabela 3 reflete os dados coletados na pesquisa feita na Tabela 2, onde as
respostas dos funcionários entrevistados, com nomes fictícios, revelam o
conhecimento de algumas vulnerabilidades e riscos que podem afetar uma aplicação
web. Porém, a maioria das vulnerabilidades existentes ainda são desconhecidas
pelos funcionários que foram entrevistados. As notas levaram em consideração tudo
o que está relacionado com o desenvolvimento de uma aplicação segura.
Na Tabela 3 é exibida a média das notas, cujo valor ficou em 6,7 (escala de
0,0 a 10), sendo esse o valor correspondente para o nível de conhecimento de
segurança em aplicações web.
Tabela 3 – Sumário das Entrevistas Realizadas7
Nível de conhecimento
Entrevistado
Linguagem de
de segurança em
Programação
aplicações web
Nota (0,0 a 10)
Func1 - Analista
Java EE
9
Func2 - Analista
Java EE
9
Func3 - Analista
Java EE
8
Func4 - Analista
Java EE
6
Func5 - Programador
PHP / JOOMLA
5
Func6 - Programador
PHP / JOOMLA
5
Func7 - Programador
PHP / JOOMLA
5
MÉDIA DAS NOTAS =>
6,7
Na Tabela 4, podemos verificar a relação que existe entre os itens da coleta
de dados da pesquisa e conteúdo exemplificado nos apêndices desta monografia.
Somente os itens 3, 4 e 10 não tiveram nenhum tipo de relação com o conteúdo
disponibilizado nos apêndices.
7
Os nomes dos funcionários nas Tabelas 2 e 3 foram trocados por motivo de segurança da
informação.
50
Tabela 4 – Relação: Coleta de Dados X Apêndices
DADOS COLETADOS
1. Qual a metodologia utilizada para o desenvolvimento do
software web?
2. Quais são os critérios de segurança adotados no
desenvolvimento de software web em Java EE?
3. Qual o nível de abrangência dos sistemas aplicativos web em
Java EE na universidade?
4. Como são utilizados os sistemas aplicativos web em Java EE
na universidade?
5. As aplicações web em Java EE podem sofrer algum tipo de
ameaça?
6. Quais são os principais riscos e vulnerabilidades de uma
aplicação web em Java EE?
7. Como evitar a ocorrência de um ataque de Injeção de SQL
numa aplicação web em Java EE?
8. Como se faz para evitar o ataque de Cross-site scripting
(XSS) numa aplicação web em Java EE?
9. O que é um desenvolvimento de software com código
seguro?
RELAÇÃO
Apêndice E
Apêndice C
Nenhuma
Nenhuma
Apêndice D
Apêndices B, C
eD
Apêndice D
Apêndice D
Apêndice F
10. As informações dos Institutos de segurança sobre
vulnerabilidades são utilizadas nas aplicações que
desenvolve?
Nenhuma
51
5 Discussão
A Gestão de Segurança da Informação e Comunicação abrange um grande
número de opções, onde a plataforma Java EE e os institutos de segurança tais
como OWASP e SANS, podem contribuir grandemente.
A reitoria da universidade Z, em atenção dada às recomendações da
Instrução Normativa 04/2010 (IN4) e outras orientações no âmbito da contratação e
execução dos serviços de TI, com o objetivo de melhorar o processo de governança
em tecnologia da informação (TI) na administração pública, gerou um movimento no
sentido de criar condições que busquem desenvolver, atualizar e revisar
constantemente o processo de gestão dos recursos de TI nas instituições públicas.
A pesquisa serviu para avaliarmos o nível de conhecimento que os
desenvolvedores de aplicações da InfoTIC possuem para produzir um software
seguro e com codificação segura.
A média das notas exibida na Tabela 3, obtidas pelas respostas ao
questionário na Tabela 2, mostram que o conhecimento sobre codificação segura na
InfoTIC, está em um nível médio.
Verificou-se que as informações e técnicas para evitar vulnerabilidades
disponíveis nos institutos de segurança, tais como OWASP e SANS, não foram
utilizados pelos funcionários do desenvolvimento de software, por não saberem
sobre a existência dos tais institutos.
Devido ao fato da maioria dos funcionários serem pessoas recémconcursadas, é normal haver certa falta de habilidade dos mesmos, pois muitos
terminaram a faculdade há pouco tempo, e não tiveram tempo de adquirir a
experiência necessária nessas novas tecnologias, incluindo o Java EE, que têm
52
evoluído gradativamente, com inúmeros recursos novos, exigindo assim uma
atualização constante a cada dia que passa.
O resultado da pesquisa não invalida a hipótese, pois o nível médio de
conhecimento sobre codificação segura demonstra que falta algum conhecimento
de como usar questões de segurança na plataforma Java EE.
Na verdade, a segurança de 100% é utópica, mas a prática de Gestão da
Segurança da Informação e Comunicação no desenvolvimento do software
aplicativo com codificação segura, proporcionará uma redução bastante significativa
das vulnerabilidades e riscos que poderiam ocorrer em uma aplicação web.
Apesar da citação feita pelo órgão internacional DHS(2010), que foi
mencionado na seção 1.2 do capítulo 1 desta monografia, referente ao que
chamamos de software seguro, se conclui que a segurança do software é um
objetivo constante a ser alcançado, pois a cada dia que passa surgem novas
vulnerabilidades.
Da mesma forma que acontece com as empresas de software que criam
antivírus para combater os vírus de computador que já existem, a cada dia são
criados novos vírus que ainda não possuem o antivírus. Ou seja, uma luta constante
que nunca termina.
Em setembro de 2011, foi detectado num sistema desenvolvido em ASP a
vulnerabilidade conhecida como “Injeção de SQL”, porém, esta falha já foi mitigada.
5.1 Sugestão de Melhorias
Para melhorar o nível de segurança no desenvolvimento das aplicações web,
a reitoria da universidade “Z” precisa continuar investindo na qualificação
dos
demais analistas e programadores para o aprendizado e também reciclagem do
seguinte:
 Programação em Java EE, incluindo segurança e código seguro para
aplicações web;
 Aplicação das informações e técnicas de mitigação de vulnerabilidades
recomendadas pelo instituto de segurança OWASP;
 Observação da NORMA ABNT ISO/IEC 27002:2005 – Seção 12;
 Metodologia para desenvolvimento seguro do software CLASP.
53
A utilização desses recursos em conjunto contribui grandemente para reduzir
as brechas existentes, mitigando assim, a maioria das vulnerabilidades e riscos nas
aplicações web desenvolvidas na plataforma Java EE.
Em relação à implementação da segurança, pode-se considerar que todos os
requisitos de segurança e o design especificado sejam implementados de maneira
correta, através da utilização de linguagem de programação segura e da utilização
de padrões, guias e normas de codificação (WAGNER & MACHADO, 2010).
A Reitoria da Universidade Z, deve criar uma política para desenvolvimento
de aplicações com código seguro em conformidade com o que é demonstrado no
mapa conceitual do software com código seguro no apêndice “F” (veja Figura 16), a
fim de que a InfoTIC melhore o nível de desenvolvimento de aplicações web com
segurança.
No processo de desenvolvimento seguro, logo de início, durante a concepção,
deve-se levantar todas as possibilidades de riscos que poderiam atacar um software
de aplicação, seja web ou desktop, de modo que sejam levantados todos os
requisitos de segurança que forem necessários. Deve-se definir qual banco de
dados será utilizado, qual servidor de aplicações será utilizado, qual sistema
operacional será utilizado no servidor web, qual a plataforma de desenvolvimento,
também se deve solicitar ao setor de infraestrutura todos os recursos necessários
para proteger as aplicações que ficarão no servidor, tais como firewall, antivírus,
monitoramento da rede, back-up, etc.
5.2 Validade da Construção
O constructo é verdadeiro (veja Tabela 5), as variáveis evidenciadas,
mostram o nível de segurança existente no setor de desenvolvimento da reitoria da
universidade Z, após a conformidade com o mapa conceitual de desenvolvimento de
software com codificação segura (veja Figura 16).
Com relação ao Objetivo Geral, foi realizado um estudo de caso que avaliou
alguns dos requisitos de segurança (veja Tabela 2).
Os Objetivos Específicos também foram avaliados. Mostrou-se no apêndice
“D”, e também no item 2.1.2, os principais erros na implementação e riscos do
controle de acesso. Abordamos também algumas formas de se criar uma solução
para o controle de acesso. Mostramos no apêndice “C” como inserir código seguro
em aplicações web.
54
Temos como fonte de evidência documental, o apêndice “A”, que relata os
ataques realizados pelos hackers; onde o item A.3 (veja Figura 12) exibe uma
alteração na interface da página de um dos sítios da UFRJ; e também temos outras
fontes de evidências documentais relacionados aos sítios do governo, tais como o
item A.1 referente ao Exército Brasileiro e o item A.2 referente aos sítios da
Presidência da República, Senado e Receita Federal.
Temos como fonte de evidência a entrevista, as respostas dadas a cada
pergunta do questionário (veja Tabelas 2 e 3 – Capítulo 4), onde o funcionário
entrevistado “Func6” relata resumidamente como procede para conseguir que uma
aplicação fique segura durante a sua operação. As perguntas foram pertinentes, de
modo que foi possível saber qual o nível de segurança que os desenvolvedores da
InfoTIC possuem até esse momento para o desenvolvimento de aplicações seguras.
Temos como fonte de evidência a observação participativa, onde o fato de
participar de uma das equipes de desenvolvimento em Java EE, constatou-se as
dificuldades na implementação de segurança no software aplicativo, pois os cursos
de capacitação não ensinam como desenvolver aplicativos com segurança, mas
apenas explicam quais os recursos disponíveis na plataforma Java EE. Também, se
pôde observar a dificuldade para configurar um servidor de aplicações, tais como o
Apache Tomcat 6 ou JBoss 6. Caso sejam mal configurados, podem gerar alguma
vulnerabilidade.
Tabela 5 – Variáveis X Nível de Segurança
VARIÁVEIS
Equipe de
desenvolvimento
Sistema aplicativo
Plataforma
DESCRIÇÃO
NÍVEL DE SEGURANÇA
EQP02 (Func1)
6,7
SGA
7
Java EE
10
NORMA NBR ISSO/IEC
Norma
27002:2005
Instituto de segurança
Metodologia de
desenvolvimento
10
OWASP
10
CLASP
10
Média do nível de segurança =>
8,9
55
Essas são as conclusões relativas às variáveis da Tabela 5:

Na variável plataforma, segundo Wagner e Machado (2010, p. 6), o Java
possui um alto nível de segurança devido às aplicações funcionarem de
forma “stand Box’. Por isso ganhou nota 10 no nível de segurança.

Na variável norma, conforme consta na Seção 12 da NORMA ABNT NBR
ISO/IEC 27002:2005, enfatiza que todos os requisitos de segurança
devem ser identificados na fase de levantamento de requisitos do projeto.
Por isso ganhou nota 10 no nível de segurança.

Na variável
instituto de segurança, temos as Melhores Práticas de
Codificação Segura OWASP e a lista da OWASP Top 10 – 2010, que
contém a relação dos “dez maiores riscos críticos em segurança de
aplicações web” (OWASP, 2011). Por isso ganhou nota 10 no nível de
segurança.

Na variável metodologia de desenvolvimento, temos o CLASP, que é um
modelo de processo de desenvolvimento de software seguro, permitindo o
ciclo de vida de maneira estruturada, com repetição e mensuração,
especificado pela OWASP (OWASP, 2011). Por isso ganhou nota 10 no
nível de segurança.

Na variável equipe de desenvolvimento, temos que levar em conta o fator
humano, o qual devidamente treinado para reconhecer e mitigar
vulnerabilidades, poderá mitigar a maioria das vulnerabilidades numa
determinada aplicação. Por isso ganhou nota 6,7 no nível de segurança.

Na variável sistema aplicativo, temos o software em desenvolvimento, o
qual depende de todas as demais variáveis para ser desenvolvido com
segurança e código seguro. Por isso ganhou nota 7 no nível de segurança.
5.3 Validade Interna
A validade interna deste estudo de caso demonstra que os dados
pesquisados refletem o nível do padrão de segurança na InfoTIC, no que diz
respeito à implementação de aplicações com segurança embutida no código-fonte
do sistema desenvolvido.
A equipe de desenvolvimento após tomar conhecimento das regras
enumeradas na NORMA NBR ISSO/IEC 27002:2005, e também tomarem
56
conhecimento das informações e técnicas para mitigar vulnerabilidades fornecidos
pelo instituto OWASP, e também adotarem uma metodologia para desenvolvimento
de software seguro, e tomarem conhecimento das técnicas de segurança do Java
EE, verificou-se a melhoria no desenvolvimento de aplicações web seguras com
código seguro. Ou seja, o nível de codificação segura melhorou, conforme consta na
Tabela 5.
Os dados coletados (veja Tabela 3) têm relação direta com a hipótese
analisada, pois foi constatado por meio das entrevistas e questionários, que os
desenvolvedores em Java não possuíam o conhecimento de uma codificação
segura, tanto em Java como nas vulnerabilidades que são passadas como
parâmetros nas páginas dos aplicativos web.
Os resultados mostraram que a hipótese têm validade, porém existe a
necessidade de que todos os funcionários do desenvolvimento sejam treinados para
utilizar todos os recursos citados acima.
5.4 Validade Externa
A validade externa não ocorre, apesar dos resultados da pesquisa provarem
que a hipótese é verdadeira, pois estatisticamente não podemos generalizar que da
mesma forma como acontece com a InfoTIC na reitoria da universidade Z, o mesmo
possa estar acontecendo nos setores de desenvolvimento de aplicações de outros
órgãos públicos da Administração Pública Federal.
57
6 Conclusões e Trabalhos Futuros
6.1 Conclusões
Neste trabalho fizemos um estudo de caso sobre o Java EE e Segurança
Cibernética atuando em aplicações web, o qual consistiu em verificar a ocorrência
da falta de conhecimento das equipes de desenvolvimento da InfoTIC sobre a
maneira de usar questões de segurança da plataforma Java EE, dentro do contexto
corporativo da reitoria da Universidade Z.
Conduzimos entrevistas com funcionários da InfoTIC para verificar o nível de
conhecimento de segurança e utilização da codificação segura nas aplicações
desenvolvidas com Java EE, no contexto de uma universidade federal.
Apresentamos os resultados alcançados por meio de um estudo de caso, com
tipo de dados qualitativo, pois é descritivo.
Apesar do resultado da pesquisa validar a hipótese, constatou-se, que se os
desenvolvedores aplicarem todo o conhecimento adquirido neste trabalho para
desenvolvimento de software, será produzido um software seguro com codificação
segura. Os conhecimentos são:

Codificação segura por meio das técnicas de mitigação ofertadas pelo
Instituto OWASP;

Metodologia de desenvolvimento seguro como o CLASP;

NORMA ABNT NBR ISO/IEC 27002:2005 - Seção 12;

Plataforma Java EE com programação segura no código.
58
Esses conhecimentos, quando aplicados em conjunto, permite a redução das
brechas existentes, mitigando assim, a maioria das vulnerabilidades e riscos nas
aplicações web desenvolvidas na plataforma Java EE. Desse modo, os aplicativos
que forem desenvolvidos após o conhecimento deste trabalho de monografia, terão
um nível de segurança bem maior do que o resultado da pesquisa.
A contribuição desse trabalho é alertar as equipes de desenvolvimento quanto
à ocorrência de diversos tipos de vulnerabilidades e risco aos quais as aplicações
web estão sujeitas a sofrer. Os dados coletados permitiram analisar o que ocorre
durante o desenvolvimento de uma aplicação web.
Verificou-se que a Reitoria da Universidade Z, através da equipe de
desenvolvimento, precisa adotar uma política para desenvolvimento de aplicações
com código seguro. Pois apesar das equipes de desenvolvimento utilizar alguma
metodologia de desenvolvimento de software, ela sozinha por si não será suficiente
para garantir e minimizar as brechas na Segurança da Informação dos aplicativos
web.
No capítulo 2 e nos apêndices “C” e “D”, a partir da análise de documentos
advindos do estudo de caso, são demonstradas várias possibilidades de
desenvolvimento de aplicações com código seguro e código inseguro. Esse material
serve como exemplo para outros funcionários da Administração Pública Federal, que
trabalham na Área de Tecnologia da Informação e Comunicação ou até na Gestão
de Segurança da Informação e Comunicação.
As limitações desse estudo de caso é o fato de que a InfoTIC é um setor novo
dentro da universidade Z 8, que ainda se encontra em fase de estruturação. Outra
limitação foi o tempo para desenvolver esta monografia.
6.2 Trabalhos Futuros
O estudo de caso realizado neste trabalho não esgotou o tema. A
necessidade de desenvolvimento de aplicativos para web com código seguro possui
muitas facetas.
O Java EE certamente é a plataforma mais indicada para produzir software
aplicativo seguro, pois não se limita apenas ao código Java, mas também abrange
8
O nome da instituição onde foi realizada a pesquisa foi trocado por questões de segurança da
informação.
59
tudo que se relacionam com HTML, XHTML, XML, JSF, JSP, JavaScript, CSS,
Criptografia, WebServices, etc.
Foi lançado em meados de 2011, o Java 7, trazendo assim novos desafios de
implementação de sistemas aplicativos seguros e com codificação segura.
A utilização do MDA e UML por meio de transformações, que permita gerar
aplicações seguras na plataforma Java EE é outro desafio, principalmente com a
aplicação de código seguro.
60
Referências e Fontes Consultadas
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Tecnologia da
informação - Técnicas de segurança - Código de prática para a gestão da
segurança da informação: ABNT NBR ISO/IEC 27002:2005. 2a. ed. Rio de
Janeiro, 2005.
ALMEIDA, Marcelo. Ataque deixa 105 sites da UFRJ desfigurados. Disponível em:
<http://www.zone-h.com.br/news/id/447> Acessado em: setembro de 2011.
ASF - APACHE SOFTWARE FOUNDATION. Realm Configuration HOW-TO.
Disponível em: <http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html>.
Acessado em: julho de 2011.
BRAZ, Fabrício. Segurança de Aplicações. Especialização em Ciência da
Computação: Gestão da Segurança da Informação e Comunicações.
Universidade de Brasília, 2008.
DHS - Department of Homeland Security. Security in the Software Lifecycle. 2006.
Disponível
em:
https://buildsecurityin.us-cert.gov.
Acessado
em:
novembro/2010.
DIAS, Cláudia. Segurança de Auditoria da Tecnologia da Informação. Rio de
Janeiro: Axcel Books do Brasil, 2000.
FERNANDES, Dave. Autenticação e Autorização sem JAAS utilizando hierarquia de
Perfis
de
Acesso
–
Parte
I.
Disponível
em:
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=6161&hl=>.
Acessado em: julho de 2011.
FERNANDES, Jorge Henrique Cabral. Sistemas, Informação e Comunicação:
GSIC050 (Notas de Aula). Curso de Especialização em Gestão da Segurança
da Informação e Comunicações: 2009/2011. Departamento de Ciências da
Computação da Universidade de Brasília. 2010. 51 p.
61
FRANZINI, Fernando. Autenticação e autorização em aplicativos web. Disponível
em:
http://imasters.com.br/artigo/14152/javaweb/autenticacao_e_autorizacao_em_a
plicativos_web>. Acessado em: julho de 2011.
GABINETE DE SEGURANÇA INSTITUCIONAL DA PRESIDÊNCIA DA
REPÚBLICA. Instrução Normativa GSI No. 1, de 13 de junho de 2008 :
Disciplina a gestão de segurança da informação e comunicações na
administração pública federal, direta e indireta, e dá outras providências.
Brasília, junho 2008. Publicada no DOU No. 115, de 18 Jun 2008 – Seção 1.
Disponível em: <http://dsic.planalto.gov.br/legislacaodsic>. Acesso em: Agosto
de 2009.
GUERRA, Eduardo. Os sete pecados do controle de acesso para aplicações Java
EE. Mundo Java. Curitiba, n. 28, p.26-33, 2008.
HOLANDA, Maristela Terto; FERNANDES, Jorge Henrique Cabral. Segurança no
Desenvolvimento de Aplicações: GSIC701 (Notas de Aula). Curso de
Especialização em Gestão da Segurança da Informação e Comunicações:
2009/2011. Departamento de Ciências da Computação da Universidade de
Brasília. 2011. 43 p.
JEVEAUX, Paulo C. M. Autenticação e Autorização: JAAS com JDBC Realm.
Disponível em: < http://jeveaux.com/2009/autenticacao-e-autorizacao-jaas-comjdbc-realm/>. Acessado em: julho de 2011.
KURNIAWAN, Budi. Programando em JavaServer Faces. Rio de Janeiro: Editora
Ciência Moderna Ltda. 2004.
LAZOTI, Rodrigo.
Filtrando requisições com PhaseListener. Disponível em:
<http://rodrigolazoti.com.br/2008/09/01/filtrando-usuarios-logados-em-jsf-comphaselistener/>. Acessado em: julho de 2011.
MACEDO, Ciro. Controlando o acesso em aplicações JSF - PhaseListener.
Disponível em: < http://ciromacedo.blogspot.com/2008/06/controle-de-acessono-jsf.html>. Acessado em: junho de 2011.
MCGRAW, G. Software security. In IEEE Security and Privacy, March/April 2004,
pages 32-35.
MOREIRA, Leandro. Login - autenticação e autorização usando JavaServer Faces
(jsf). Disponível em: < http://archsofty.blogspot.com/2008/11/login-autenticao-eautorizao-usando.html>. Acessado em: junho de 2011.
OLMOS,
Cesar.
Filtros
para
servlets.
Disponível
<http://www.guj.com.br/articles/11>. Acessado em: agosto de 2011.
em:
ORACLE.
Java
EE
at
a
Glance.
Disponível
em:
<http://www.oracle.com/technetwork/java/javaee/overview/index.html>. Acesso
em: março de 2011.
62
ORACLE.
Java
EE
6
Technologies.
Disponível
em:
<http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html>.
Acesso em: agosto de 2011.
ORACLE.
The
Java
EE
5
Tutorial.
Disponível
em:
<http://download.oracle.com/javaee/5/tutorial/doc/ >. Acesso em: agosto de
2011. http://download.oracle.com/javaee/6/tutorial/doc/bnacj.html#bnack
ORACLE.
The
Java
EE
6
Tutorial.
Disponível
em:
<http://download.oracle.com/javaee/6/tutorial/doc/ >. Acesso em: agosto de
2011.
OSVDB.
Padrões
de
Vulnerabilidades.
Disponível
<http://osvdb.org/vuln_standards>. Acessado em: setembro de 2011.
em:
OWASP. CLASP Project. Disponível em: http://www.owasp.org/index.php/ Category:
OWASP_CLASP_Project. Último acesso em janeiro de 2011.
OWASP. How to add validation logic to HttpServletRequest. Disponível em:
<https://www.owasp.org/index.php/How_to_add_validation_logic_to_HttpServletR
equest>. Acessado em: agosto de 2011.
OWASP. Melhores Práticas de Codificação Segura OWASP: Guia de Referência
Rápida.
2010.
Disponível
em:
<http://www.owasp.org/index.php/Secure_Coding_Practices>. Último acesso
em: julho de 2011.
OWASP. OWASP Top 10: The Ten Most Critical web Application Security Risk.
2010.
Disponível
em:
<http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project>.
Último acesso em: julho de 2011.
OWASP. WebScarab . Software para análise de aplicativos web. Disponível em:
<https://www.owasp.org/index.php/webScarab_Getting_Started>. Acesso em:
julho de 2011.
PAIVA, Alan e MEDEIROS, Indiana Belianka Kosloski. Uma abordagem de caso de
integração entre os processos de Tratamento de Incidentes de Segurança
Computacionais e Desenvolvimento de Software. Monografia de
especialização. Brasília: Departamento de Ciência da Computação da
Universidade de Brasília. 2008.
PASSOS, Antonio. Java Security - Como Usar JAAS Com Tomcat 6. Disponível em:
<http://pt.scribd.com/doc/7571690/Java-Security-Como-Usar-JAAS-ComTomcat-6>. Acessado em: maio de 2011.
PINCEL, Paulo. Polícia Federal investiga ataques de hackers na internet. Disponível
em:
<http://www.piauihoje.com/noticias/policia-federal-investiga-ataques-dehackers-na-internet-29700.html>. Acessado em: setembro de 2011.
63
WAGNER, Rosana; MACHADO, Alencar. Níveis de segurança para processos de
desenvolvimento de software seguro. Universidade Federal de Santa Maria
(UFSM),
Santa
Maria
–
RS.
2010
Disponível
em:
<http://www.sirc.unifra.br/artigos2010/7.pdf>. Acessado em: 28 out. 2011.
SACRAMENTO, Wendell M. Utilizando Servlet Filter com JavaServer Faces.
Disponível
em:
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=5331>. Acessado
em: julho de 2011.
SANS. SANS 2009: The Top Cyber Security Risks. Disponível em:
<http://www.sans.org/top-cyber-security-risks >. Acessado em: janeiro de 2011.
SECRETARIA DE LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO DO
MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO. INSTRUÇÃO
NORMATIVA No. 4, DE 12 DE NOVEMBRO DE 2010: Dispõe sobre o processo
de contratação de Soluções de Tecnologia da Informação pelos órgãos
integrantes do Sistema de Administração dos Recursos de Informação e
Informática (SISP) do Poder Executivo Federal. Brasília, novembro de 2010.
Publicada no DOU No. 218, de 16 nov 2010 – Seção 1. Disponível em:
<http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativano-04-de-12-novembro-de-2010/IN SLTI MP 04 2010 - V1.PDF>. Acesso em:
setembro de 2011.
SPRINGSOURCE.
Spring
Security.
Disponível
em:
<http://static.springsource.org/spring-security/site/>. Ultimo acesso em julho de
2011.
STAIR, Ralph; REYNOLDS, George. Princípios de Sistemas de Informação. Editora:
Cengage Learning. Sexta Edição 2006.
TAGIAROLI, Guilherme. Hackers vazam informações de funcionários do Exército
Brasileiro.
Atualizada
20/06/2011.
Disponível
em:<http://tecnologia.uol.com.br/ultimas-noticias/redacao/2011/06/20/hackersvazam-informacoes-de-funcionarios-do-exercito-brasileiro.jhtm>. Acessado em:
agosto de 2011.
TERRA,
Ricardo.
Segurança
da
Internet.
Disponível
em:
<http://www.ricardoterra.com.br/publicresources/PALESTRASegurancaInternet.
pdf>. Ultimo acesso em julho de 2011.
VIANA,
Fábio.
Tutorial
de
JASS.
Disponível
<http://www.guj.com.br/articles/184>. Ultimo acesso em julho de 2011.
em:
YIN, R. K. Estudo de Caso: Planejamento e Métodos. 3. ed. Porto Alegre: Bookman.
2005.
64
Glossário
A
ABNT – Associação Brasileira de Normas Técnicas.
APF – Administração Pública Federal.
API – Application Programming Interface (Interface de Programação de Aplicativos).
B
Banco de dados (base de dados) – é um conjunto de registros dispostos em
estrutura regular que possibilita a reorganização dos mesmos e armazenagem de
informação.
C
CLASP – Comprehensive, Lightweight Application Security Process.
CSRF – Cross-Site Request Forgery.
D
DoS – Denial of Service (negação de serviço).
H
HTTP – Hypertext Transfer Protocol.
I
IDE
–
Integrated
Development
Enviroment
(ambiente
desenvolvimento de software).
IEC – International Electrotechnical Commission.
IN – Instrução Normativa.
Informar - Ato de prover uma informação.
Informação - Significado que um agente extrai de um dado.
ISO – International Organization for Standardization.
J
Java EE – Java Enterprise Edition .
JDK – Java Development Kit.
integrado
para
65
M
MDA – Model Drive Architecture.
N
NBR – Norma Brasileira.
O
ORACLE – Empresa de software norte-americana.
OSVDB – Open Source Vulnerability Database.
OWASP – Open web Application Security Project.
R
RBAC – Role Based Access Control Model.
RPC – Remote Procedure Calls.
RUP – Rational Unified Process (Processo Unificado Racional)
S
SANS – Institute. Instituto SANS (SysAdmin, Audit, NetWork, Security).
SDK – Software Development Kit.
SQL – Structured Query Language.
SQL Injection – Injeção de SQL.
T
TIC – Tecnologia da Informação e Comunicação.
U
URL – Uniform Resource Locator .
W
WWW – World Wide web.
X
XSS – Cross-Site Scripting.
66
Apêndice A – Ataque de Hackers
A.1 Hackers vazam informações de funcionários do Exército
Brasileiro
Hackers brasileiros (TAGIAROLI, 2011) vazaram neste sábado (18/06/2011)
informações de quase um mil membros do Exército Brasileiro. O ataque foi feito pelo
Fatal Error Crew, mesmo grupo que atacou o site da presidência da República no
início deste ano. Eles próprios fizeram a divulgação para a imprensa, enviando por
e-mail um link com vários dados de funcionários da Força Armada.
As informações vazadas pelo Fatal Error Crew contêm o nome, número de
CPF, função e um número que, supostamente, tem relação com o cadastro militar de
funcionários da corporação. Os dados foram adquiridos por meio de um ataque à
base de dados do "Gestor de Controle de Distribuição da Água”.
Consultado sobre a divulgação de informações nesta segunda-feira (20), o
Centro de Comunicação Social do Exército informou que o Centro de Coordenação
para Tratamento de Incidentes de Rede do Exército já está trabalhando no caso e
que os dados não comprometeram a página principal da Força Armada.
Eles conseguiram as informações de um banco de dados do Exército a partir
de um ataque conhecido como injeção de SQL. Esse tipo de ação consiste,
basicamente, na exploração de falhas que levam usuários avançados de
programação a acessar o que quiserem dentro de um banco de dados.
Apesar da divulgação das informações, o grupo, consultado pela reportagem,
afirmou que não usará os dados para o mal. “Nós só queríamos expor a falta de
segurança dos servidores do Exército Brasileiro.” Além disso, um dos membros do
67
grupo, afirmou que essa não ser a primeira vez em que eles conseguiram acessar
dados do órgão e que vários outros sites do Governo do Brasil são vulneráveis.
A.2 Polícia Federal investiga ataques de hackers na internet
A Polícia Federal anunciou oficialmente nesta sexta-feira (24) que começou a
investigar a série de ataques de hackers a sites do governo nos últimos dia. Após o
ataque aos sites da Presidência, do Senado e da Receita Federal, classificados
como o maior da história da rede no Brasil, os hackers derrubaram na madrugada
desta sexta a página na internet do Instituto Brasileiro de Geografia e Estatística
(IBGE).
Segundo informações da assessoria de imprensa da Polícia Federal, as
investigações já estão em curso. Na quinta-feira, ao G1, a Polícia Federal havia
afirmado que o órgão reunia informações para monitorar as ações dos hackers. Não
serão divulgadas informações sobre a investigação para não prejudicar o trabalho
dos agentes da corporação, segundo a assessoria da PF.
O site do Ministério da Cultura também apresentou instabilidade, em
decorrência da sobrecarga de acessos por um único usuário. A equipe de
infraestrutura do ministério trabalha com a possibilidade de que o site tenha sido
alvo de hackers, mas não confirma o caso como um novo ataque. Após detectar e
neutralizar a ameaça, o site voltou a funcionar normalmente.
A página do Ministério do Esporte ficou fora do ar na manhã desta sexta, mas
por volta das 9h o acesso estava normalizado. A assessoria de imprensa da pasta
havia informado na quinta que tiraria o site do ar para que seja feita uma varredura.
Segundo a assessoria, o procedimento é padrão para o trabalho de rastreamento.
A assessoria da Empresa Brasileira de Infraestrutura Aeroportuária (Infraero),
vinculada ao Ministério da Defesa, afirma que o página da autarquia foi tirada do ar
propositalmente para reforço na segurança, para evitar possíveis ataques de
hackers.
Grupo nacionalista
No ataque ao site do IBGE, os hackers deixaram uma mensagem em que se
denominam como um grupo nacionalista, “que deseja fazer do Brasil um país
68
melhor’”. O Fail Shell, nome do grupo que "pichou" o site do IBGE, promete ainda
realizar neste mês o maior ataque a sites do governo da história.
Ao pé da página, os hackers ainda negaram ter relações com os grupos
LulzSec ou Anonymous no Brasil, que seriam "grupos sem qualquer ideologia",
segundo a mensagem deixada pelos hackers.
O LulzSecBrazil é apontado como o responsável pelos ataques que
derrubaram sites do governo na madrugada de quarta-feira (22). Foi o maior ataque
sofrido pelo governo, com mais de 2 bilhões de tentativas de acesso em um curto
período de tempo, segundo o Serviço Federal de Processamento de Dados (Serpro).
O órgão informou que o ataque não causou danos às informações disponíveis nas
páginas e partiu de servidores localizados na Itália.
A ação realizada pelos hackers na página do IBGE é diferente da que
derrubou os portais da Presidência e do governo brasileiro na quarta. No caso do
IBGE, foi feita uma “pichação” no site, ou uma alteração de página. Para derrubar os
portais do governo, os hackers utilizaram sistemas que faziam múltiplas tentativas de
acesso ao mesmo tempo, técnica batizada de “negação de serviço” e conhecida
pelas iniciais em inglês DDoS (Distributed Denial of Service).
Grupo contrário
O canal de comunicação usado pelo LulzsecBrazil foi fechado por volta das
22h desta quinta (23). A decisão foi tomada pelos administradores da rede que
também hospeda o canal usado pela operação do Lulzsec original.
Antes, o grupo divulgou na internet arquivos com supostos dados de políticos,
como a presidente Dilma Rousseff, o prefeito de São Paulo, Gilberto Kassab, o
ministro da Educação, Fernando Haddad, e o prefeito do Rio de Janeiro, Eduardo
Paes.
Um possível indício do surgimento de um grupo de piratas contrários ao
LulzSecBrazil é a divulgação de um documento que acusa um hacker de ser líder do
movimento brasileiro. Ele seria Al3XG0, um conhecido criminoso digital envolvido
com o roubo de senhas bancárias e cartões de crédito e que mantinha um site que
pegava informações de brasileiros usando uma falha no site do Ministério do
Trabalho. O documento indica também nome, RG e CPF de uma pessoa que,
segundo o texto, seria o hacker Al3XG0. Há ainda um link para uma fotografia,
supostamente do hacker.
69
O LulzSecBrazil teria ligações com o LulzSec, responsável por ataques
recentes a empresas de videogame como Sony e Nintendo, às redes de televisão
americanas Fox e PBS e a órgãos governamentais americanos como a CIA (agência
de inteligência americana) e o FBI (polícia federal), além do serviço público de saúde
britânico, o NHS.
A.3 Hackers atacaram as páginas de 105 sítios da web na UFRJ
Em 03/04/2007, segundo Almeida (2011), o grupo de crackers conhecidos
como SegmentationFault, invadiu um servidor da Universidade Federal do Rio de
Janeiro rodando FreeBSD. O servidor hospedava cerca de 105 sites os quais
tiveram a página inicial alterada (defaced).
Imagem da invasão deixada nas páginas da UFRJ.
yes… UFRJ FOI HACKEADA!
Nós hackeamos seu servidor admin. desculpe =).
defaced by S4P0
root@acd:/root# uname –a;id;uptime;pwd
FreeBSD acd.ufrj.br 4.8-RELEASE FreeBSD 4.8-RELEASE #2: Tue Aug 10 17:57:12 EST 2004
[email protected]:/usr/src/sys/compile/ACD_UFRJ i386
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest)
11:51 up 20:28, 5 users, load aver¬ages: 0,16 0,34 0,47
/root
[ Contact us ]
IRC.GigaChat.NET
#SegFault
Você pode ver a lista dos ataques a empresas famosas ou do governo brasileiro realizadas pelo grupo
SegmentationFault aqui.
Lista dos sites da UFRJ quer foram atacados.
Aqui você pode ver a lista geral dos ataques do grupo SegmentationFault no mundo.
Figura 12: Ataque ao sítio da UFRJ (ALMEIDA, 2011)
70
Esta foi o maior ataque contra uma instituição federal registrado no Brasil. O
líder do grupo conhecido como s4p0, não quis revelar a falha explorada, pois diz que
existem outros sites com a mesma falha e pretende atacá-los em breve.
O grupo SegmentationFault é um dos grupos mais ativos do Brasil tendo
atacado mais de 3000 sites ao redor do mundo, destes mais de 500 são sites do
governo ou empresas famosas.
71
Apêndice B – Exemplo de URL com
Código Visível
Figura 13: Código do parâmetro visível na URL - 1 (SILVA, 2011).
Figura 14: Código do parâmetro visível na URL - 2 (SILVA, 2011).
72
Apêndice C – Controle de Acesso em
Aplicações Java EE
A plataforma Java EE adota um modelo de controle de acesso baseado em
papéis, o qual é conhecido como RBAC (Role Based Access Control).
O mecanismo de autenticação da plataforma Java EE é padronizada para
aplicações web, em como as credenciais dos usuários podem ser enviadas ao
servidor. Nas aplicações EJB não existe padrão, mas caso seja um ponto de entrada
para a aplicação (com EJB remoto), é preciso autenticar quem faz o acesso.
Em uma aplicação web, as configurações de segurança são feitas no
deployment descriptor (arquivo web.xml). É importante que as permissões sejam
atribuídas de acordo com os padrões de URL ou servlets. Todos os papéis (roles)
utilizados pela aplicação devem ser declarados a partir do elemento <security -role>
As permissões são atribuídas através de elementos <security-constraint>, que
declaram a abrangência da mesma em um elemento <web-resource-collection > e
os papéis que podem acessá-la como o elemento <auth-constraint>. A listagem 1
apresenta o trecho de um deployment descriptor para exemplificar a configuração de
segurança em uma aplicação web.
Listagem 1 (GUERRA, 2008): (com segurança)
<security-constraint>
<web-resource-collection>
<web-resource-name>Nome restrição</web-resource-name>
<url-pattern>/admin/*.servlet</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
73
<security-role>
<role-name>admin</role-name>
</security-role>
Em uma aplicação EJB (GUERRA, 2008), o controle de acesso é feito através
da permissão para invocação a métodos. Antes de ser lançado o EJB 3, essa
configuração podia ser feita no deployment descriptor (arquivo ejb-jar.xml). A
listagem 2 mostra um exemplo de como fazer essa configuração.
Todos os papéis utilizados na configuração precisam ser declarados no
elemento <security-role>. O elemento <method-permission> dá a permissão de
acesso a um ou mais métodos de um EJB. Também é possível especificar os
parâmetros do método (para o caso de sobrecarga) e se ele pertence a uma
interface local ou remota.
Se a aplicação já utilizar EJB 3, é possível fazer essa configurações de
segurança por meio de anotações. A anotação @RolesAllowed permite especificar
quais são os perfis autorizados a acessar o método anotado. As anotações
@PermitAll e @DenyAll dão respectivamente autorização a todos os usuários e
bloqueia qualquer acesso. Essas configurações podem ser sobrepostas por
configurações no deployment descriptor no momento do deploy.
Listagem 2 (GUERRA, 2008): (com segurança)
<assembly-descriptor>
<security-role>
<role-name>admin</role-name>
</security-role>
<method-permission>
<role-name>admin</role-name>
<method>
ejb-name>Fachada</ejb-name>
<method-name>criarConta</method-name>
</method>
</method-permission>
</assembly-descriptor>
Além da segurança declarativa, a plataforma Java EE fornece uma API para a
aplicação realizar verificações de forma programática.
74
Na aplicação web, os métodos que se referem à segurança podem ser
encontrados na classe HTTPServletRequest, sendo os métodos seguintes:
O
método
getUserPrincipal(),
que
retorna
uma
instância
do
java.security.Principal, que corresponde ao usuário
O método isUserInRole(), que verifica se o usuário pertence a um
determinado grupo de usuários.
Numa aplicação EJB, os métodos ficam na classe EJBContext, e seus
métodos são os seguintes:
O método getCallerPrincipal(), que possui funcionalidade análoga ao método
getUserPrincipal() da aplicação web.
O método isCallerInRole(), que possui funcionalidade análoga ao método
isUserInRole() da aplicação web.
Porém,
os métodos acima mencionados,
são utilizados mais para
funcionalidades do que segurança. Por exemplo: exibir um campo, um botão ou link,
somente se o usuário for um administrador ou verificar se o usuário não é um
supervisor.
Em uma aplicação web, as informações sobre o usuário podem ser mantidas
em sua sessão, ficando acessíveis em qualquer parte da aplicação web. Uma das
opções para implementar o controle de acesso (GUERRA, 2008) na camada web de
um aplicativo é a utilização de um “filtro”. O filtro intercepta cada requisição e verifica
se o usuário possui permissão de acesso antes de ela começar a ser processada
pelo servlet responsável. O filtro deve ser configurado para interceptar os servlets
que devem ser protegidos no arquivo “web.xml”. A listagem 3 apresenta um exemplo
de como deveria ser configurado um filtro para controle de acesso. No exemplo, o
filtro recupera um objeto com dados do usuário da sessão, o mapa de parâmetros
recebidos e a URI acessada pelo usuário e chama um método na classe
AccessControlPolicy, a qual irá ou não autorizar o acesso. Caso o acesso não seja
autorizado, uma exceção será lançada com os dados do acesso realizado.
Listagem 3 (GUERRA, 2008): (com segurança)
public class AccessControlFilter implements Filter{
private AccessControlPolicy policy;
public void init(FilterConfig filterConfig){
policy = new AccessControlPolicy();
75
}
Public void doFilter(ServletRequest request,
ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpSession session = ((HttpServletRequest) request).getSession();
User user = (User) session.getAttribute(“user”);
Map parameters = request.getParameterMap();
String uri = ((HttpServletRequest) request).getRequestURI();
}
If (policy.authorizeAccess(user, uri, parameters)){
Chain.doFilter(request, response);
} else {
throw new AccessControlViolationException(user, uri, parameters);
}
public void destroy(){
}
}
A implementação do controle de acesso em aplicações EJB é um pouco mais
complicada (GUERRA, 2008), por não existir um local centralizado onde as
informações sobre o usuário possam ficar mais acessíveis. Uma das formas de se
fazer isso é utilizar o mecanismo de autenticação do container, porém recuperar o
usuário utilizando o método getCallerPrincipal() e implementar um controle de
acesso próprio. Porém, existe a desvantagem de caso sejam necessárias outras
informações do usuário ausentes na instância de Principal recuperada, elas deverão
ser recuperadas a cada acesso. Outra possibilidade é manter um stateful session
bean como fachada para os acessos a aplicação, onde inicialmente recebe as
credenciais e autentica o usuário e faz uma verificação da permissão a cada acesso
feito.
A listagem 4 mostra um exemplo de como essa estratégia pode ser criada.
No constructor do bean é criada uma instância de AccessControlPolicy, sendo essa
a classe responsável por autorizar ou não o acesso de acordo com um modelo de
controle de acesso adotado. O método authenticateUser() é responsável por
autenticar o usuário e armazená-lo na variável user, a qual irá manter esse estado
durante as chamadas de método devido à natureza stateful do bean. Todo método
de uma das business interface do bean será interceptado pelo método
verifyAccess(), devido à anotação @AroundInvoke. Esse método só permite que o
76
método seja chamado caso o método authorizedAccess() confirme que o usuário foi
autenticado e possui aquela permissão. Esse método além de receber o método
chamado também recebe os seus parâmetros, permitindo assim que os dados
recebidos sejam levados em consideração pelo controle de acesso. O EJB
BusinessSession
negócio
ilustra outros beans que possuem efetivamente as regras de
e são acessados pelos clientes através da fachada. Esses beans
protegidos pela fachada devem possuir apenas interface local, para que a
verificação do controle de acesso não venha a ser contornada.
Listagem 4 (GUERRA, 2008): (com segurança)
@Stateful
public class SecurityFacadeBean implements SecurityFacadeRemote{
@EJB
private BusinessSessionLocal businessSessionBean;
@EJB
private AuthenticationLocal authenticationBean;
private User user;
private AccessControlPolicy policy;
public SecurityFacadeBean({
policy = new AccessControlPolicy();
}
public void authenticateUser(User user){
if (authenticationBean.authenticateUser(user)){
this.user = user;
} else {
throw new AuthenticationException(user);
}
}
@AroundInvoke
public Object verifyAccess( InvocationContext ) throws Exception {
final Method method = context.getMethod();
final Object[] parameters = context.getParameters();
if (method.getName().equals(“authenticateUser”) ||
(user != null &&
policy.authorizeAccess(user,method,parameters))){
return context.proceed();
} else {
throw new AccessControlViolationException(
user,method, parameters);
}
77
}
public void executeBusinessRule(){
BusinessSessionBean.businessRule();
}
//outros métodos do negócio
}
78
Apêndice D – Demonstração de Alguns
Tipos de Ataques em Código Java EE
Para mitigar um ataque de Injeção de SQL, segundo Terra(2011), temos que
compreender que o objetivo do hacker é injetar um comando SQL ou algum
comando como o valor de entrada de algum campo de um formulário web. Todos os
parâmetros passados são direcionados para o banco de dados, de modo que o
atacante pode manipular com as tabelas e dados diretamente.
Exemplo em Java da codificação com vulnerabilidade em JDBC (sem
segurança), que era praticada pelas equipes de desenvolvimento da InfoTIC na
universidade Z:
public boolean onLogon(String nome, String senha){
boolean result = false;
Connection conn = null;
try {
conn = ServiceLocator.getConnection();
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery("select a from USUARIO where NOME = '"
+ nome + "' and SENHA = '" + senha + "'");
result = rs.next();
...
} catch (SQLException e) {
...
} finally {
...
}
return result;
}
RESULTADOS1 (sem segurança):
ESPERADO: nome:joao e senha:maria
Quando submetido à query será montada como a seguinte:
79
select a from USUARIO where NOME = ‘joao’ and SENHA = ‘maria’
NÃO ESPERADO: nome:xyz’-- e senha:
Quando submetido à query será montada como a seguinte:
select a from USUARIO where NOME = ‘xyz’-- and SENHA = ‘’
RESULTADOS2 (sem segurança):
ESPERADO: nome:daniel e senha:catarina
Quando submetido à query será montada como a seguinte:
select a from USUARIO where NOME = ‘daniel’ and SENHA = ‘catarina’
NÃO ESPERADO: nome: z e senha: w’ or 1=1-Quando submetido à query será montada como a seguinte:
select a from USUARIO where NOME = ‘z’ and SENHA = ‘w’ or 1=1--‘
Exemplos que podem mitigar essa vulnerabilidade (com segurança), que
passaram a ser utilizados pela InfoTIC da universidade Z:
1) Utilizando JDBC e PreparedStatement
String txtSQL = "select a from USUARIO where NOME = ? “
+ ” and SENHA = ? ";
conn = ServiceLocator.getConnection();
PreparedStatement pst = conn.prepareStatement(txtSQL);
pst.setString(1,nome);
//se essas duas linhas forem omitidas,
pst.setString(2,senha);
//o PreparedStatement fica vulnerável,
ResultSet rs = pst.executeQuery();
result = rs.next();
2) Utilizando Named Parameters em JPA ou Hibernate
String txtSQL = "select a from USUARIO where NOME = ‘:nome’ “
+ ” and SENHA = ‘:senha’ ";
q = entityManager.createQuery(txtSQL);
q.setParameter(“nome”, nome);
q.setParameter(“senha”, senha);
80
Ataque de XSS Cross Site Scripting, segundo Terra(2011), é uma
vulnerabilidade tipicamente encontrada em aplicações web, que permitem injeção de
código por usuários maliciosos em páginas vistas por outros usuários. Temos por
exemplo código HTML e scripts executados no lado do cliente (JavaScript).
Exemplo em Java da codificação com vulnerabilidade (sem segurança), que
era praticada pelas equipes de desenvolvimento da InfoTIC na universidade Z:
1) Utilizando código JSP vulnerável a um ataque XSS refletido
<% String usuarioID = request.getParameter(“id”); %>
...
ID do Usuario: <%= usuarioID %>
2) Utilizando código SERVLET vulnerável a um ataque XSS refletido
Out.writeln(“Pesquisa por:” + request.getParameter(“q”));
3) Utilizando código SERVLET vulnerável a um ataque XSS armazenado
String txtSQL = "select a from USUARIO where NOME = ? “
+ ” and SENHA = ? ";
conn = ServiceLocator.getConnection();
PreparedStatement pst = conn.prepareStatement(txtSQL);
pst.setString(1,nome);
pst.setString(2,senha);
ResultSet rs = pst.executeQuery();
result = rs.next();
OBS.: Esse exemplo é o mesmo utilizado para evitar a injeção de SQL.
Porém o mesmo não previne contra o XSS armazenado, pois os dados vêm do
banco de dados e são enviados para a página HTML (ou JSP) sem a validação :
out.writeln(“<tr><td>” + rs.getString(“nome”)+“<tr><td>” + rs.getString(“comentário”)
+“<td><tr>” );
Exemplos de códigos que previnem contra o escape de
caracteres (com
segurança), que mitigam essa vulnerabilidade, que passaram a ser utilizados pela
InfoTIC da universidade Z:
81
a. Escape de caracteres sensíveis a JSP , HTML e XML
//JSF comandos seguros
<h:outputText value=”#{param.nome}”/>
<h:outputText escape=”true” value=”#{param.nome}”/>
// o parâmetro escape possui o valor padrão igual a “true”.
//JSP comandos seguros
<c:out value=”#{param.nome}”/>
<c:out escapeXml=”true” value=”#{param.nome}”/>
// o parâmetro escapeXml possui o valor padrão igual a “true”.
//JSF comandos inseguros, pois não utiliza o escape
<h:outputText escape=”false” value=”#{param.nome}”/>
//JSP comandos inseguros, pois não utiliza o escape
${param.nome}”/>
<c:out escapeXml=”false” value=”#{param.nome}”/>
b. Filtro que permite caracteres autorizados
//Esse código deve ser utilizado dentro de um ServletFilter, a fim de permitir
//que toda a aplicação a utilize.
//A expressão só permite o uso de espaços e os caracteres: a-zA-Z_0-9’-‘e”
//sejam passados adiante
String strExemplo = “[\\s\\w-,]*”;
Pattern padrão = Pattern.compile(strExemplo);
Validate(stringToValidate, padrao);
A conjunção de três fatores contribui grandemente para que haja segurança
cibernética nos aplicativos web, tais como: boas práticas de codificação,
metodologia adequada (projeto, arquitetura, etc.), e testes.
82
Apêndice E – Processo de
Desenvolvimento Seguro CLASP
O processo CLASP (OWASP, 2010), é apresentado através de cinco níveis
de perspectivas chamado Visões CLASP. Estes pontos de vista são divididos em
atividades, que por sua vez contêm componentes do processo.
Na Figura 15, conforme Holanda e Fernandes (2011, p. 26), vemos a
organização de cima para baixo por peças que interagem, e como aplicá-los ao seu
ciclo de vida do desenvolvimento de software específico. Estas são as Visões
CLASP:
I. Visão de Conceito;
II. Visão Baseado em Regras;
III. Visão de Avaliação de Atividades;
IV. Visão de Implementação de Atividades;
V. Visão de Vulnerabilidade.
. A Visão Conceitual (I) apresenta uma visão geral de como funciona o
processo CLASP e como seus componentes interagem. São introduzidas as
melhores práticas, a interação entre o CLASP e as políticas de segurança, alguns
conceitos de segurança e os componentes do processo.
A Visão baseada em Regras (II) introduz as responsabilidades básicas de
cada membro do projeto (gerente, arquiteto, especificador de requisitos, projetista,
implementador, analista de testes e auditor de segurança) relacionando-os com as
atividades propostas, assim como a especificação de quais são os requerimentos
básicos para que cada função.
83
A Visão de Avaliação de Atividades (III) descreve o propósito de cada
atividade, bem como o custo de implementação, a aplicabilidade, o impacto relativo,
os riscos em caso de não aplicar a atividade.
A Visão de Implementação (IV) descreve o conteúdo das 24 atividades de
segurança definidas pelo CLASP e identifica os responsáveis pela implementação,
bem como as atividades relacionadas.
A Visão de Vulnerabilidades (V) possui um catálogo que descreve 104 tipos
de vulnerabilidades no desenvolvimento de software, divididas em cinco categorias:
Erros de Tipo e Limites de Tamanho; Problemas do Ambiente; Erros de
Sincronização e Temporização; Erros de Protocolo e Erros Lógicos em Geral. Nessa
atividade também é realizada técnicas de mitigação e avaliação de risco. Assim
como período de A & M (Avoidance e Mitigation) por fase do SDLC.
Figura 15: Visões do CLASP. Adaptado de OWASP(2010).
84
Apêndice F – Mapa Conceitual:
Desenvolvimento do Software com
Código Seguro
Figura 16: Mapa conceitual do software com código seguro (SILVA, 2011)
85
Apêndice G – Código-fonte de Uma
Aplicação Web Sem Código Seguro
//Arquivo: pagAcesso.jsp
<%@page contentType="text/html" pageEncoding="ISO-8859-1"%>
<%@ page import="javax.servlet.http.HttpSession" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Página de acesso (1)</title>
<link rel="stylesheet" type="text/css" href="estiloufrj.css" />
</head>
<body>
<div align="center">
<form action="verificaSenha.jsp" method="post" name="login">
<table align="center" bgcolor="beige" border="0"
cellspacing="0" cellpadding="0" width="600">
<tr>
<td bgcolor="azure" align="center" colspan="2">
<%@ include file="/WEB-INF/jspf/Cabec.jsp" %>
<h3 class="marinho">Acesso ao Sistema</h3>
</td>
</tr>
<tr>
<td align="right"><br />Funcionário:  </td>
<td align="left"><br />
<input type="text" name="usuario" value="" size="15" maxlength="15">
</td>
</tr>
<tr>
<td align="right"><br />Senha:  </td>
<td align="left"><br />
<input type="password" name="senha"
value="" size="15" maxlength="15"></td>
</tr>
<tr>
<td colspan="2" align="center">
<br />
<input type="submit" value="Enviar" name="enviar" />  
<input type="reset" value="Limpar" name="limpa" />  
86
<input type="button" value="Voltar"
name="volta" onclick="javascript:history.back(-1)"/>
<br />
</td>
</tr>
</table>
</form>
</div>
</body>
</html>
---------------------------------------------//-----------------------------------------------//Arquivo: verificaSenha.jsp
<%@page contentType="text/html" pageEncoding="ISO-8859-1"%>
<%@page import="java.sql.*, sga.BeanFuncionario" %>
<%@ page import="javax.servlet.http.HttpSession" %>
<jsp:useBean id="login" scope="request" class="sga.BeanFuncionario" />
<jsp:setProperty name="login" property="usuario" param="usuario" />
<jsp:setProperty name="login" property="senha" param="senha" />
<% HttpSession ssga = request.getSession(false);
String usuario = (String) request.getParameter("usuario");
String senha = (String) request.getParameter("senha");
String nivelac = (String) request.getParameter("nivelac");
String logado = (String) request.getParameter("logado");
BeanFuncionario usu = new BeanFuncionario(usuario, nivelac, senha);
String logado1 = "";
//acesso padrão ALUNO
String nivelac1 = "";
//nível padrão 0 para ALUNO
String senha1 = "";
boolean entrada = false;
ResultSet rslogin = login.consultaFunLogin();
if ((usuario != null) && (senha != null)) {
while (rslogin.next()) {
logado1 = rslogin.getString("usuario");
nivelac1 = rslogin.getString("nivel");
senha1 = rslogin.getString("senha");
System.out.println("Usuario: " + logado1 );
System.out.println("Senha: " + senha1 );
System.out.println("Nível: " + nivelac1 );
System.out.println("Entrada antes: " + entrada);
if (usuario.equals(logado1)) {
if (senha.equals(senha1)) {
entrada = true;
System.out.println("Entrada depois: " + entrada);
nivelac = ssga.getAttribute("nivelac").toString();
logado = ssga.getAttribute("logado").toString();
}
}
break;
}
87
if (entrada) {
ssga.setAttribute("logado", logado1);
ssga.setAttribute("nivelac", nivelac1);
ssga.setAttribute("sessao", "autorizado");
}
}%>
<jsp:forward page="/pagAutorizado.jsp" />
---------------------------------------------//-----------------------------------------------//Arquivo: BeanFuncionario.java
public ResultSet consultaFunLogin() {
stmt2 = null; conecta2 = null; rs2 = null; int conta = 0;
try {
Class.forName(classe2);
System.out.println("Classe carregada com SUCESSO!");
} catch (ClassNotFoundException cnfe) {
permissao2 = false;
System.out.println("Classe nao foi carregada!");
}
try {
conecta2 = DriverManager.getConnection(url2, user2, password2);
System.out.println("Conexao feita com SUCESSO!");
} catch (SQLException sqlecon) {
permissao2 = false;
System.out.println("Erro ao conectar o Banco de dados '" + url2 + "' !");
}
try {
//consulta os registros cadastrados
tsql = "select * from funcionarios where usuario = '" + usuario + "'" +
" and senha = '" + senha + "'";
stmt2 = conecta2.createStatement();
rs2 = stmt2.executeQuery(tsql);
permissao2 = true;
System.out.println("Consulta bem sucedida!");
return rs2;
} catch (SQLException sqlex2) {
System.out.println("Consulta mal sucedida!" + "\n "+ usuario + "\n " + senha);
permissao2 = false;
}
return null;
}
Observação:
Este código sem segurança está aqui como exemplo. O mesmo já foi modificado no
sistema que está sendo desenvolvido na InfoTIC, após a equipe ficar sabendo das
diversas vulnerabilidades informadas pelos institutos de segurança.