Escolar Documentos
Profissional Documentos
Cultura Documentos
Brasília
2011
Marcos Pontes da Silva
Brasília
2011
Marcos Pontes da Silva
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.
Figura 7: Códigos que fazem muita coisa sem proteção (GUERRA, 2008) .............. 33
Figura 10: Código com dados sem proteção (GUERRA, 2008) ................................ 36
Figura 16: Mapa conceitual do software com código seguro (SILVA, 2011) ............. 84
Lista de Tabelas
Errata ......................................................................................................................... 3
Dedicatória ................................................................................................................. 5
Agradecimentos ......................................................................................................... 6
Sumário ................................................................................................................... 10
Resumo ................................................................................................................... 14
Abstract.................................................................................................................... 15
3 Metodologia .......................................................................................................... 42
4 Resultados ............................................................................................................ 46
5 Discussão ............................................................................................................. 51
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
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.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.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.
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 “software-
como-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.
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).
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.
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).
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).
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.
3 Metodologia
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”).
4 Resultados
4
IDE – Integrated Development Enviroment (ambiente integrado para desenvolvimento de software).
5
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.
Tabela 1 – Plano de Coleta de Dados.
Técnica 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é 16h
Documentação. Entrevista. 31/10/2011
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) 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?
10) As informações dos Institutos de segurança sobre vulnerabilidades são utilizadas nas aplicações que desenvolve?
SEGUIR PADRÕES,
TRATAR STRINGS DE
LOGIN E SENHA CONSULTA DE CRIPTOGRAFIA, CRIPTOGRAFIA,
LOGIN E SENHA COM LOGIN, REGISTRO DE
2 LOGIN E SENHA COM PERFIL DE BANCO DE DADOS, GERENCIA DE GERENCIA DE
CRIPTOGRAFIA MD5 LOG
ACESSO CUIDADO COM A PERMISSÕES, LOGIN PERMISSÕES, LOGIN
SAÍDA DOS DADOS
PARA EVITAR O XSS
NOTA 2 1 1 1 1 1 1 1
DIVERSOS, ALGUNS
LOCALIZADOS NA TODA A TODA A
PARA TODA A TODA A
3 UNIDADE, OUTROS REITORIA NÃO SABE UNIVERSIDADE E UNIVERSIDADE E
UNIVERSIDADE UNIVERSIDADE
ABRANGEM TODA A PÚBLICO EXERNO PÚBLICO EXERNO
UNIVERSIDADE
NOTA 3 1 1 1 1 0 1 1
DESDE
CONFORME A ACESSO A ÚLTIMAS ACESSO A ÚLTIMAS
DEPARTAMENTOS INTRANET OU
4 FINALIDADE DE CADA SIGA , SAM NÃO SABE NOTÍCIAS, ACESSO NOTÍCIAS, ACESSO
ATÉ TODA A INTERNET
UM OUTROS SISTEMAS OUTROS SISTEMAS
UNIVERSIDADE
NOTA 4 1 1 1 1 0 0 0
SIM, CASO NÃO SEJA
SIM, INDEPENDENTE UTILIZADA ALGUMA SIM, SIM,
5 SIM SIM SIM
DA LINGUAGEM TÉCNICA DE CONSTANTEMENTE CONSTANTEMENTE
SEGURANÇA
NOTA 5 1 1 1 1 1 1 1
ACESSO AS DoS, SNIFFING,
DoS, SNIFFING,
INJEÇÃO DE SQL, TABELAS DO BANCO INVASÃO AO FALHAS NÃO
ATAQUES DOS XSS, SQL INJECTION, FALHAS NÃO
6 CROSS-SITE DE DADOS, ACESSO SERVIDOR DE REVISADAS PELOO
HACKERS BRUTE FORCE, DDOS REVISADAS PELOO
SCRIPTING (XSS) DE UMA PÁGINA VIA APLICAÇÃO DESENVOLVEDOR,
DESENVOLVEDOR
GET XSS
NOTA 6 1 1 1 1 1 1 1
USO DE USO DE
COMPONENETES COMPONENETES
ESPECÍFICOS QUE ESPECÍFICOS QUE
VALIDAR TODOS OS
UTILIZAR PREPARED UTILIZAR VALIDAR O GERENCIAM A GERENCIAM A
DADOS RECEBIDOS FUNÇÕES NATIVAS
7 STATEMENT OU INTERROGAÇÃO NO CONTEÚDO DOS CONEXAO COM O CONEXAO COM O
PELO APLICATIVO VIA DO BANCO DE DADOS
NAMED PARAMETERS SQL CAMPOS "INPUT" BANCO DE DADOS, BANCO DE DADOS,
GET OU POST
EVITAR EVITAR
CONCATENAÇÃO DE CONCATENAÇÃO DE
STRINGS STRINGS
NOTA 7 1 1 1 1 0 0 0
O MESMO ANTERIOR NÃO OUVIU FALAR UTILIZA O CONTENT USA A FUNÇÃO
8 COM A ATIVAÇÃO DO NESSE TIPO DE SEGURITY POLICY NÃO SABE HTMLENTITIES DO NÃO SABE NÃO SABE
ESCAPE ATAQUE DO GOOGLE PHP
NOTA 8 1 0 0 0 0 0 0
SEGUIR PADRÕES E
DESENVOLVIMENTO RECOMENDAÇÕES DESENVOLVIMENTO DESENVOLVIMENTO
DESENVOLVIMENTO
PADRÃO MAIS DE SEGURANÇA E OBJETIVO, EVITAR OBJETIVO, EVITAR
BASEADO NUMA
CUIDADOS MINIMIZAR TODAS AS CONHECER BEM OS CONEXÕES ABERTAS, CONEXÕES ABERTAS,
9 METODOLOGIA NÃO SABE
INFORMADOS PELOS VULNERABILIDADES RECURSOS DA SERVIDOR COM BOA SERVIDOR COM BOA
SEGURA COMO O
INSTITUTOS DE LINGUAGEM DE INFRAESTRUTURA DE INFRAESTRUTURA DE
OWASP
SEGURANÇA PROGRAMÇÃO QUE SEGURANÇA SEGURANÇA
UTILIZA
NOTA 9 1 1 1 0 1 1 1
MANTER AS
AINDA NÃO, MAS
BIBLIOTECAS
10 PRETENDEMOS APENAS ALGUNS AINDA NÃO NÃO NÃO SABE NÃO SABE
UTILIZADAS SEMPRE
UTILIZAR
ATUALIZADAS
NOTA 10 0 1 0 0 1 0 0
NOTA TOTAL 9 9 8 6 5 5 5
6
Os nomes dos funcionários nas Tabelas 2 e 3 foram trocados por motivo de segurança da
informação.
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.
7
Os nomes dos funcionários nas Tabelas 2 e 3 foram trocados por motivo de segurança da
informação.
50
5 Discussão
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.
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
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.
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.
PASSOS, Antonio. Java Security - Como Usar JAAS Com Tomcat 6. Disponível em:
<http://pt.scribd.com/doc/7571690/Java-Security-Como-Usar-JAAS-Com-
Tomcat-6>. Acessado em: maio 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.
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 integrado para
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.
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
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.
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.
<security-role>
<role-name>admin</role-name>
</security-role>
<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>
@EJB
private BusinessSessionLocal businessSessionBean;
@EJB
private AuthenticationLocal authenticationBean;
public SecurityFacadeBean({
policy = new AccessControlPolicy();
}
@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
}
Apêndice E – Processo de
Desenvolvimento Seguro CLASP
Figura 16: Mapa conceitual do software com código seguro (SILVA, 2011)
85
//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.