universidade da amazÔnia – unama centro de ...universidade da amazÔnia – unama centro de...
TRANSCRIPT
UNIVERSIDADE DA AMAZÔNIA – UNAMA
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICA – CCET
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
Kleiton da Silva Gomes
Newton Santos
SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
Belém-Pará
2006
UNIVERSIDADE DA AMAZÔNIA – UNAMA
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICA – CCET
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
Kleiton da Silva Gomes
Newton Santos
SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
Trabalho de Conclusão de Curso
apresentado à Universidade da Amazônia,
como condição parcial para obtenção de
Grau de Bacharel em Ciência da
Computação, sob a orientação do Prof.
Msc. Cláudio Roberto de Lima Martins.
Belém-Pará
2006
UNIVERSIDADE DA AMAZÔNIA – UNAMA
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICA – CCET
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
Kleiton da Silva Gomes
Newton Santos
SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
Trabalho de Conclusão de curso
apresentada à Universidade da Amazônia,
como condição parcial para obtenção de
Grau de Bacharel em Ciência da
Computação, sob a orientação do Prof.
Msc. Cláudio Roberto de Lima Martins.
Data da defesa: ___ / ___ / _____
Nota: ______
Banca Examinadora:
_____________________________________
_____________________________________
_____________________________________
Cláudio Roberto de Lima Martins
Dedicamos este trabalho aos nossos queridos pais e entes familiares, que sempre acreditaram no nosso futuro e por nunca deixarem faltar nada em nossas vidas.
AGRADECIMENTOS
“Agradeço primeiramente a Deus por ter me guiado a escolher sempre as portas certas e por me ajudar a superar as dificuldades que a vida nos coloca.
A minha mãe, Maria Ivoneide da Silva Gomes, por ter me educado e ajudado, tanto financeiramente como moralmente a chegar onde estou e principalmente pelo seu esforço em prol desta realização.
A toda família Assunção e Silva, por ter me dado apoio tanto moral como financeiro. Gostaria de agradecer em especial a Delcineide Assunção e Silva pela dedicação, paciência e esforço que sempre teve na realização e concretização deste sonho, sendo uma peça de fundamental importância. Sou muito grato por tudo que você fez.
Ao meu irmão Fernando da Silva Gomes, por ter me dado apoio moral e principalmente por me ajudar a vencer as dificuldades que a vida nos coloca.
A toda família Braga, por ter me ajudado direta e indiretamente. Gostaria de agradecer em especial à Arivaldo Gomes Braga e Iolene das Chagas Braga por terem me acolhido em um momento difícil dando todo o apoio necessário na conclusão deste trabalho e principalmente por me ajudar nas dificuldades que a vida nos coloca.
A todos os amigos e companheiros que, direta ou indiretamente, possibilitaram a realização deste trabalho. E ao meu amigo e orientador Cláudio Martins que me possibilitou atingir este objetivo principalmente pela construção e conclusão deste trabalho.”
Kleiton da Silva Gomes
"Há homens que lutam um dia e são bons. Há outros que lutam um ano e são melhores. Há os que lutam muitos anos e são muito bons. Porém, há os que lutam toda a vida. Esses são os imprescindíveis." Bertolt Brecht.
RESUMO
A construção de sistemas de software, em especial aqueles que usam a
Web como ambiente, é uma das áreas mais afetadas pelos aspectos da segurança.
Grande parte das vulnerabilidades de aplicações web é provocada por erros de
projeto e arquitetura, bem como em falhas de programação. Existe uma grande
pressão nas equipes de desenvolvimento de sistema no sentido de desenvolver
sistemas seguros e dos usuários em obter garantia da segurança de um sistema.
Dada a importância em tratar questões de segurança no desenvolvimento de
software, alguns padrões e normas foram propostos, como é o caso da ISO/IEC
15.408, que traz as diretrizes e princípios gerais para auxiliar o desenvolvimento de
sistemas, visando um produto de qualidade.
O objetivo deste trabalho consiste em apresentar os principais aspectos de
segurança, identificar políticas e planos de segurança, levantar e analisar riscos,
ameaças e os principais meios para que se desenvolvam sistemas mais seguros.
Para dar ênfase ao trabalho foi realizado um estudo das principais vulnerabilidades
presentes no ambiente de aprendizado on-line da UNAMA, o Aprendiz, onde foi
possível detectar algumas falhas e propor possíveis correções.
PALAVRAS CHAVES: Segurança, Vulnerabilidades, Normas, informação,
Aplicações WEB.
ABSTRACT
The construction of systems of software, in special those that use the Web as
surrounding, is one of the areas more affected by the aspects of the security. Great
part of the vulnerabilities of applications web is provoked by errors of project and
architecture, as well as in programming imperfections. A great pressure in the teams
of development of system in the direction to develop safe systems and of the users in
getting guarantee of the security of a system exists. Given the importance in dealing
with questions security in the software development, some standards and norms had
been considered, as it is the case of ISO/IEC 15,408, that it brings the general lines
of direction and principles to assist the development of systems, aiming at a quality
product.
The objective of this work consists of presenting the main aspects of security,
identifying to politics and plans of security, uprising and to analyze risks, threats and
the main ways so that safer systems are developed. To give emphasis to the work
on-line of the UNAMA was carried through a study of the main vulnerabilities gifts in
the environment of learning, the Apprentice, where it was possible to detect some
imperfections and to consider possible corrections.
WORDS KEYS: Security, Vulnerabilities, Norms, information, Applications WEB.
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................13 1.1 OBJETIVO.............................................................................................................13 1.2 JUSTIFICATIVA DO TEMA ...................................................................................14 1.3 RELEVÂNCIA DO TEMA.......................................................................................14 1.4 ORGANIZAÇÃO DO TRABALHO..........................................................................15 2 ASPECTOS DE SEGURANÇA DA INFORMAÇÃO.............. ................................16 2.1 NORMAS E FERRAMENTAS PARA A SEGURANÇA DA INFORMAÇÃO............17 2.1.1 Orange Book .........................................................................................................18 2.1.2 Common Criteria ...................................................................................................19 2.1.3 CobiT.....................................................................................................................20 2.1.4 Legislação Brasileira .............................................................................................20 2.2 COMO USAR A ISO/IEC 15.408 ...........................................................................21 2.3 GARANTIA DE SEGURANÇA DA APLICAÇÃO....................................................22 2.3.1 Boas Praticas de Programação .............................................................................23 2.3.2 Testes Funcionais de Segurança ..........................................................................25 3 AVALIAÇÃO DO AMBIENTE E ESTRATÉGIAS DE SEGURANÇA . ...................26 3.1 LEVANTAMENTO DA POLÍTICA DE SEGURANÇA .............................................27 3.2 DETECTANDO AMEAÇAS....................................................................................27 3.2.1 Os Agentes............................................................................................................28 3.2.2 Os mecanismos.....................................................................................................30 3.2.3 Os ativos ...............................................................................................................31 3.3 OBJETIVO DA SEGURANÇA ...............................................................................32 4 REQUISITOS FUNCIONAIS DE SEGURANÇA............... .....................................33 4.1 AUDITORIA...........................................................................................................34 4.2 NÃO REPÚDIO .....................................................................................................37 4.3 CRIPTOGRAFIA....................................................................................................38 4.4 PROTEÇÃO DE DADOS DO USUÁRIO................................................................39 4.4.1 Controle de Acesso ...............................................................................................40 4.4.2 Importação e exportação de dados........................................................................42 4.5 GERENCIAMENTO DE SEGURANÇA..................................................................43 4.6 PRIVACIDADE ......................................................................................................44 4.7 AUTOPROTEÇÃO ................................................................................................44 4.8 CONTROLE DE SESSÕES...................................................................................46 4.9 AUTENTICAÇÃO ..................................................................................................47 4.9.1 Processo de Autenticação e Identificação .............................................................48 4.9.2 Mecanismo de Autenticação..................................................................................48 4.9.3 Conformidade com a ISO/IEC 15408.....................................................................50 5 ANALISANDO RISCOS................................ ........................................................52 5.1 ANALISE DE VULNERABILIDADES .....................................................................52 5.2 SEGURANÇA DE APLICAÇÕES WEB .................................................................55 5.2.1 Aspectos gerais de segurança para desenvolver sistemas para Web ...................55 5.2.2 SQL Injections .......................................................................................................56 5.2.3 Cross-site Scripting ...............................................................................................60 5.2.4 Controle de Acesso Falho .....................................................................................61 5.2.5 Falha no Tratamento de Erros ...............................................................................62 5.2.6 Command Injections/ Parâmetros Inválidos...........................................................64 5.2.7 Uso de URLs “mágicas” e campos de formulário ocultos.......................................65 5.2.8 Buffer Overflows ....................................................................................................66
10
6 ESTUDO DE CASO ..............................................................................................68 6.1 DESCRIÇÃO DO SISTEMA ..................................................................................68 6.2 VULNERABILIDADES VERIFICADAS NO APRENDIZ .........................................69 6.2.1 Vazamento de Informações...................................................................................69 6.2.2 Tratamento de Falhas de Autenticação .................................................................71 6.2.3 Definição de atributos do Usuário para Autenticação ............................................71 6.2.4 Métricas mínimas das Senhas...............................................................................72 6.2.5 Limitação do número de Seções Simultâneas .......................................................72 6.2.6 Cross-site scripting ................................................................................................73 6.2.7 SQL Injetions.........................................................................................................73 6.2.8 Controle de Acesso Falho .....................................................................................74 6.2.9 Controle de Sessão ...............................................................................................74 6.3 CONSIDERAÇÕES FINAIS...................................................................................75 7 CONSIDERAÇÕES FINAIS E CONTRIBUIÇÃO.............. .....................................80 7.1 Perspectivas futuras ..............................................................................................80 BIBLIOGRAFIA....................................... ............................................................................82
LISTA DE ILUSTAÇÕES
FIGURA 1 – FAMÍLIA FAU_GEN .........................................................................................35 FIGURA 2 – FAMÍLIA FAU_SEL ..........................................................................................36 FIGURA 3 – FAMÍLIA FAU_SAR .........................................................................................36 FIGURA 4 – NÃO REPÚDIO DE ORIGEM ..........................................................................37 FIGURA 5 – NÃO REPÚDIO DE DESTINO .........................................................................37 FIGURA 6 – FAMÍLIA FCS_COP .........................................................................................39 FIGURA 7 – FAMÍLIA FCS_CKM.........................................................................................39 FIGURA 8 – FAMÍLIA FIA_UID ............................................................................................50 FIGURA 9 – FAMÍLIA FIA_UAU...........................................................................................51 FIGURA 10 – EXEMPLO DE SQL INJECT (QUEBRA DA AUTENTICAÇÃO) .....................59 FIGURA 11 – EXEMPLO DE CROSS-SITE SCRIPTING.....................................................60 FIGURA 12 – EXEMPLO DE FALHA NO TRATAMENTO DE ERROS ................................63 FIGURAS 13 – EXEMPLO DE BUFFER OVERFLOW.........................................................66 FIGURA 14 – VISÕES DE USO DO SISTEMA APRENDIZ .................................................69 FIGURA 15 – MENSAGEM DE ERRO.................................................................................70 FIGURA 16 – MENSAGEM DE ERRO.................................................................................70 FIGURA 17 - TAMANHO MÍNIMO DAS SENHAS NÃO IMPLEMENTADO..........................72 FIGURA 18 – EXEMPLO DE CSS .......................................................................................73
LISTA DE TABELAS
TABELA 1 – LISTA DE ACESSO AO SISTEMA. .................................................................29 TABELA 2 - CONHECIMENTO DO SISTEMA .....................................................................29 TABELA 3 - MOTIVAÇÃO DO AGENTE ..............................................................................29 TABELA 4 - MOTIVAÇÃO DO AGENTE ..............................................................................30 TABELA 5 - MECANISMOS DE ATAQUE .........................................................................30 TABELA 6 - ATIVOS COM VALOR......................................................................................31 TABELA 7 - CARACTERES MAIS UTILIZADOS .................................................................58 TABELA 8 - RESUMO DAS VULNERABILIDADES E POSSÍVEIS SOLUÇÕES .................76
13
1 INTRODUÇÃO
A informação é algo de vital importância para uma organização e
fundamental para o sucesso dos negócios. Para isso, é importante que seja
adequadamente protegida, pois, com o crescimento da interconectividade entre
ambientes de trabalho, a informação fica exposta a uma grande variedade de
ameaças. Daí cresce a importância com a necessidade da segurança da informação,
que é a proteção da informação contra os vários tipos de agentes ameaçadores,
minimizando riscos ao negócio, garantindo que a informação se mantenha íntegra,
maximizando o retorno sobre os investimentos.
Para obter a segurança da informação, faz-se necessário um conjunto de
controles adequados com intuito de garantir que os objetivos do negócio e da
segurança da organização sejam atendidos. Esses controles vêm mudando e se
aperfeiçoando com o passar do tempo, permitindo às organizações cuidarem e se
prevenirem contra eventuais riscos causados pela ausência de segurança.
A norma ISO/IEC 15.408 (Commom Criteria) traz as diretrizes e princípios
gerais para auxiliar no desenvolvimento de software, permite desenvolver, melhorar
e avaliar os aspectos de segurança da aplicação em desenvolvimento ou a ser
desenvolvida, bem como do ambiente de desenvolvimento em si.
Segundo Albuquerque (2002), o desenvolvimento de sistemas é uma das
áreas mais afetadas pelos aspectos da segurança. Muitos dos problemas de
segurança existentes hoje não são nem físicos, nem de procedimento, mas sim
devidos a erros de programação ou a arquiteturas falhas.
1.1 OBJETIVO
Este trabalho tem como objetivo fornecer conceitos tecnológicos voltados à
segurança da informação; apresentar os principais requisitos funcionais de
segurança dispostos na norma ISO/IEC15.408 (Commom Criteria for Information
tecnology Security Evolution); apresentar as principais ameaças à segurança da
informação, como os principais meios para que se desenvolvam sistemas menos
vulneráveis.
14
Para dar ênfase ao trabalho serão analisadas as principais vulnerabilidades
presentes no sistema de aprendizado on-line da UNAMA, o Aprendiz. Em seguida,
serão propostas soluções para a diminuição dos riscos decorrentes das falhas
detectadas.
1.2 JUSTIFICATIVA DO TEMA
Ao iniciar as atividades na área de Segurança da Informação, percebe-se ao
longo do tempo o quanto que as organizações sofrem para manter a sua base de
informação segura, pois vários são os obstáculos existentes. A segurança no
ambiente WEB sempre foi um assunto importante no desenvolvimento de sistemas e
com o avanço da Internet, que possibilitou a interconexão entre computadores de
todos os portes, deve-se ter preocupação redobrada com a segurança da
informação, pois esse tipo de aplicação exige atenção especial quando comparada
às aplicações desktop, porque à medida que a aplicação está no ambiente WEB ela
se torna de domínio publico, facilitando o acesso de usuários não autorizados
(hacker). Logo, não tardou para a aparição de ameaça à confidencialidade,
integridade e disponibilidade da informação que neste momento tornou-se um ativo
valioso e estratégico.
É notório que a difusão da Internet facilitou a exploração remota de brechas
de segurança, muitas vezes consideradas inofensivas durante o desenvolvimento da
aplicação.
1.3 RELEVÂNCIA DO TEMA
Por que se deve preocupar com a segurança da informação? É importante,
pois esse tema e a informática como um todo está presente na sociedade
contemporânea. Hoje as organizações guardam nos computadores os segredos de
seus negócios e indivíduos trocam correspondências eletrônicas de caráter pessoal,
enfim, todos têm o legítimo direito de esperar que os dados confiados às máquinas
sejam mantidos intactos e confidenciais, acessíveis apenas às pessoas autorizadas.
15
Apesar de todas as ferramentas de hardware e software disponíveis no
mercado há sempre uma possibilidade de falhas na segurança. Alguns especialistas
defendem a idéia de que é praticamente impossível se ter um ambiente tecnológico
totalmente seguro. Diante do crescimento de aplicações voltadas para a Internet
surge a preocupação de termos ambientes seguros, nos quais todos possam dispor
de informações verdadeiras e confiáveis.
Esta pesquisa contribui na área de segurança em aplicações voltadas para a
Internet, especialmente aos que irão desenvolver aplicações para o ambiente web,
que devem estar atentos aos aspectos de segurança de acesso, confidencialidade e
privacidade das informações.
1.4 ORGANIZAÇÃO DO TRABALHO
O trabalho está organizado da seguinte forma:
No capitulo 2, foram identificados na literatura às técnicas e procedimentos
considerados fundamentais para a segurança da informação. Por elas, é possível
estabelecer um conjunto mínimo de requisitos de segurança que, se não eliminam,
visam diminuir as vulnerabilidades e melhorar a qualidade do produto (software).
No capítulo 3, é apresentada uma visão sobre segurança da informação,
avaliação de ambiente e definição de estratégias de segurança.
O capitulo 4, apresenta uma relação de requisitos funcionais de segurança a
serem considerados durante o desenvolvimento de software.
O capitulo 5, faz uma abordagem da necessidade de se analisar os riscos
que uma aplicação está sujeita e relaciona as principais vulnerabilidades presentes
em ambiente web.
O capitulo 6, apresenta um estudo de caso em uma aplicação web real, no
caso o ambiente de educação a distância da UNAMA, o Aprendiz, onde é
identificado algumas vulnerabilidades e proposto algumas possíveis soluções.
16
2 ASPECTOS DE SEGURANÇA DA INFORMAÇÃO
Segundo Albuquerque (2002), segurança é um termo tão genérico que é
melhor pensarmos em aspectos de segurança da informação. Existem vários
aspectos de segurança, sendo que os três considerados centrais ou principais são:
confidencialidade, integridade e disponibilidade. Além desses, existem outros
aspectos tais como: autenticação, não repúdio, legalidade, privacidade e auditoria.
Vale ressaltar que, embora Albuquerque considere a confidencialidade,
integridade e a disponibilidade como requisitos principais, não exclui que os demais
aspectos não sejam importantes, visto que essa escolha deve levar em
consideração a natureza da aplicação. A seguir, é apresenta uma definição para
cada aspecto citado.
a) Confidencialidade : capacidade de um sistema de impedir que usuários
não-autorizados vejam determinada informação que foi delegada a
somente usuários autorizados a vê-la.
b) Integridade : atributo de segurança que indica se uma informação pode
ser alterada somente de forma autorizada.
c) Disponibilidade : indica a quantidade de vezes que o sistema cumpriu
uma tarefa solicitada sem falhas internas, para um número de vezes em
que foi solicitado a fazer a tarefa.
d) Autenticação : capacidade de garantir que um usuário, sistema ou
informação é mesmo quem alega ser.
e) Não repúdio : capacidade do sistema provar que um usuário executou
determina ação no sistema.
f) Legalidade : aderência de um sistema à legislação.
g) Privacidade : Capacidade de manter incógnito um usuário,
impossibilitando a ligação direta da identidade do usuário com as ações
por este realizadas.
h) Auditoria : capacidade do sistema de auditar tudo o que foi realizado
pelos usuários, detectando fraudes ou tentativas de ataque.
17
Segundo Dias (2000), segurança é a proteção de informações, sistemas,
recursos e serviços contra desastres, erros e manipulação não autorizada, de forma
a reduzir a probabilidade e o impacto de incidentes de segurança. Um problema de
segurança é a perda de qualquer aspecto da segurança importante para o sistema.
Apesar de todos os objetivos de segurança serem importantes para um
sistema, dependendo da organização, ou da utilidade do software, alguns são mais
importantes do que outros.
De acordo com a ISO/IEC 15.408 (Commom Criteria), o termo ameaça
indica uma tríade: Agente, Vulnerabilidade (ou mecanismo) e Ativo com alto valor, o
que permite um ataque.
Durante a fase de desenvolvimento do software deverá ser dada atenção
especial à segurança do ambiente de desenvolvimento e da aplicação desenvolvida.
2.1 NORMAS E FERRAMENTAS PARA A SEGURANÇA DA INFORMAÇÃO
Na área de segurança da informação existem vários documentos e normas
que tratam diretamente ou indiretamente da segurança da informação, as quais têm
por objetivo maior, apresentar orientações e sugestões quanto às boas práticas da
política de segurança.
A segurança das informações, em função de sua grande importância para a
sociedade moderna, deu origem a diversos grupos de pesquisa, cujos trabalhos,
muitas das vezes, são traduzidos em padrões de segurança, ou mesmo projetos
legislativos (DIAS, 2000).
Essas ferramentas têm uma importância muito grande na implantação de
segurança, são variados os objetivos de cada uma, tais como: autenticação,
controles de acesso físico e lógico, registro de logs, monitoração e etc. A maior parte
das brechas na segurança de uma aplicação é oriunda da falta de boas praticas de
engenharia de software, e por isso é necessário tomar extremo cuidado durante o
desenvolvimento dos sistemas.
A seguir, é apresentado um histórico e uma série de normas que auxiliam
na manutenção da segurança de sistemas de informação.
18
2.1.1 Orange Book 1
O “Orange book” do NCSC tem como objetivo a classificação baseada nas
características de segurança definidas no projeto dos sistemas computacionais
(DIAS, 2000). Essas categorias são dispostas de tal forma que cada nível superior
de segurança deve implementar todos os requisitos específicos para os níveis
inferiores.
O "The Orange Book" foi inicio de tudo; dele nasceram vários padrões de
segurança, cada qual com a sua filosofia e métodos proprietários, contudo visando
uma padronização mundial. Houve um esforço para a construção de uma nova
norma, mais atual e que não se detivesse somente na questão da segurança de
computadores, mas sim na segurança de toda e qualquer forma de informação. Este
esforço foi liderado pela ISO (International Organization for Standardization).
Em meados de 1977, o Departamento de Defesa dos Estados Unidos
formulou um plano sistemático para tratar do problema clássico de segurança, o qual
deu origem ao "DoD Computer Security Initiative", que, por sua vez, desenvolveria
um centro para avaliar o quão seguro eram as soluções disponibilizadas. Para essa
avaliação, fez-se necessário a criação de diversas regras para a utilização durante o
processo. Mais tarde, este conjunto de regras ficaria conhecido informalmente como
"The Orange Book", devido a cor da capa deste manual de segurança. Mesmo que o
"Orange Book", atualmente, seja considerado um documento "ultrapassado", é
considerado como o marco inicial de um processo mundial e contínuo de busca de
um conjunto de medidas que permitam, a um ambiente computadorizado, ser
qualificado como seguro. Esta norma de segurança permitiu e continua permitindo a
classificação, por exemplo, do nível de segurança fornecido pelos sistemas
operacionais atualmente utilizados. Outro ponto importante a ser lembrado é que o
"Orange Book", dentro de seu conteúdo, permite, de uma maneira simples,
especificar o que deve ser implementado e fornecido por um software, para que ele
seja classificado em um dos níveis de segurança pré-estipulados, permitindo assim
que este também seja utilizado como fonte de referência para o desenvolvimento de
1 Orange Book. Disponível em: http://www.dynamoo.com/orange/summary.htm. Acesso em: 05/09/2006
19
novas aplicações e para o processo de atualização ou refinamento de aplicações já
existentes e em uso.
2.1.2 Common Criteria
O objetivo da Commom Criteria (Commom Criteria for Information Tecnology
Security Evolution) é fornecer um conjunto de critérios fixos que permitem especificar
a segurança de uma aplicação de forma não ambígua a partir de características do
ambiente da aplicação, e definir formas de garantir a segurança da aplicação para o
cliente final.
O Common Criteria (CC 1999) é uma norma ou padrão de indústria criado a
partir de diversos padrões anteriores com o objetivo de gerar uma norma
internacional no assunto. A primeira versão do Common Criteria foi lançada em
janeiro de 1996. Em maio de 1998 foi liberada uma grande revisão, denominada
Common Criteria 2.0. Finalmente, em dezembro de 1999 a versão 2.1 do Common
Criteria foi homologada como a norma internacional ISO/IEC 15.408.
O Common Criteria estabelece que qualquer sistema para ser considerado
seguro, precisa ter seu Security Target (objetivo ou alvo de segurança) elaborado. O
Security Target é a especificação de segurança, ou seja, indica quais aspectos de
segurança foram considerados importantes e porque o foram para aquele sistema
em particular.
O CC (Common Criteria) define também sete níveis de garantia de
segurança. A cada nível, temos um maior numero de testes e, portanto, maior
garantia de que o sistema atende aos requisitos de segurança. Esses níveis são
denominados EAL (Evalution Assurance Level, ou nível de garantia da avaliação), e
podem ser EAL-1 a EAL-7. Assim, apenas os níveis EAL-1 a EAL-4 são
reconhecidos pela ISO, pois os níveis EAL-5 a EAL-7 são considerados muito
rígidos.
O CC define como TOE (Targent Of Evalution, ou alvo de segurança) para
diferenciar o sistema que estamos avaliando de outros sistemas.
O Common Criteria pode ser usado para desenvolver um sistema seguro ou
avaliar a segurança de um já desenvolvido. A exigência de avaliação por
20
laboratórios internacionais e o grande número de detalhes na implantação, como
determina o processo estabelecido na norma, torna o processo caro.
A idéia do Common Criteria é que ao aplicá-lo no desenvolvimento de um
sistema, é possível testá-lo em um laboratório credenciado e obter um selo de
certificação. Contudo, não é preciso aplicar a norma em sua totalidade para
desenvolver um sistema seguro ou avaliar a segurança de um já existente.
2.1.3 CobiT 2
Trata-se de uma estrutura para o gerenciamento dos processos de negócios
alinhada a um modelo de governança em TI, que permite o entendimento e o
gerenciamento dos riscos. O Cobit parte do princípio de que a organização requer
informação para atingir seus objetivos, e que essa informação deve ter atributos
como integridade, oportunidade e confiabilidade. Considerando que a informação
será gerada, processada e mantida por meio de recursos tecnológicos, o Cobit
define quatro domínios para a estrutura de controles da área de TI – planejamento e
organização, aquisição e implementação, delivery e suporte e monitoramento –que
se subdividem em 34 processos e mais de 300 objetivos detalhados de controle.
2.1.4 Legislação Brasileira
A Legislação brasileira, com relação à segurança da informação, não se
encontra bem estrutura como a legislação americana, porém já existem alguns
dispositivos legais, ou projetos de lei sobre assuntos relativos à segurança da
informação, conforme pode ser observado a seguir:
a) Projeto de lei nº 84, de 1999 – dispõe sobre os crimes cometidos na área
de informática e suas penalidades;
b) Projeto de Lei do senado nº 234, de 1996 – dispõe sobre crime contra a
inviolabilidade de comunicação de dados de computador;
2 Cobit. Disponível em: http://www.efagundes.com/Artigos/COBIT.htm. Acesso em: 10/09/2006
21
c) Decreto nº 79.099, de 06 de janeiro de 1977 – aprova o regulamento
para salvaguarda de assuntos sigilosos.
d) ABNT NBR ISO/IEC 17.799 – dispõe sobre normais gerais sobre
segurança da informação, onde seu objetivo fundamental é assegurar a
continuidade e minimizar o dano empresarial, prevenindo e minimizando
o impacto de incidentes de segurança.
Com referência a padrões e normas técnicas, o Brasil conta com a ABNT
(Associação Brasileira de Normas Técnicas), a qual é encarregada de ditar os
padrões a serem seguidos por serviços e produtos de varias áreas, inclusive
segurança de informação. Trata de algoritmos de criptografia, técnicas criptográficas,
gerência de senhas, controle de acesso para segurança física de instalações de
processamento de dados, critérios de segurança física relativos ao armazenamento
de dados, a microcomputadores e terminais.
2.2 COMO USAR A ISO/IEC 15.408
Não é preciso aplicar a norma em sua totalidade para conseguir os objetivos
de se desenvolver uma aplicação segura e garantir sua segurança. Utilizando a idéia
central da norma, temos um método simples que, mesmo que não tenha o mesmo
nível de garantia de uma certificação ISO/IEC 15.408, apresenta resultados
satisfatórios.
Podemos avaliar a segurança de uma aplicação usando a ISO/IEC 15.408
como base nas aplicações em fase de projetos ou em aplicações já desenvolvidas.
Como lembra Albuquerque (2002), para utilizarmos a norma ISO/IEC 15.408
em aplicações em fase de desenvolvimento devemos seguir os critérios:
1º - Especifique a segurança da aplicação na fase de análise, gerando um
documento de especificação de segurança usando a ISO/IEC 15.408, como um
guia. Isso significa usar os mesmos requisitos descritos na norma, a mesma
estrutura de análise de ambiente, mas não necessariamente seguir o padrão do
Security Target (Objetivo ou alvo de segurança).
2º - Manter um ambiente de desenvolvimento e testes suficientes seguros e
capazes de atender os níveis de garantia da ISO/IEC 15.408, seguindo as
22
recomendações do EAL-3 (Evalution Assurance Level, ou nível de garantia da
avaliação ), pois é um excelente começo para a maior parte das aplicações.
3º - Desenvolva utilizando boas práticas de programação e seguindo os
requisitos de segurança, ou seja, crie um processo de desenvolvimento bem definido
e planeje adequadamente a implementação de requisitos especificados.
4º - Escolha um dos sete níveis de garantia de segurança e teste seus
sistemas internamente, gerando as evidências para verificação da aderência à
especificação. Se o projeto demandar alto nível de segurança, utilize um dos
laboratórios credenciados para a homologação final dentro da norma.
Para aplicações já desenvolvidas pode se utilizar outra receita, conforme
descrevemos a seguir:
1º - Levante a especificação de segurança para aplicação usando o CC
como base.
2º - Levante quais requisitos de segurança a aplicação desenvolvida possui
e quais estão presentes em seu ambiente de desenvolvimento.
3º - Verifique se os requisitos implementados atendem à necessidade de
segurança verificada na especificação inicial.
4º - Escolha um nível de garantia de segurança até o nível EAL-3 (Evalution
Assurance Level, ou nível de garantia da avaliação), não é possível fazer
verificações mais detalhadas em aplicações prontas, ou seja, os níveis 4 a 7 exigem
testes e procedimentos durante a implementação) e faça os testes para garantir a
segurança da aplicação.
2.3 GARANTIA DE SEGURANÇA DA APLICAÇÃO
Segundo Dias (2000) precisamos de segurança nos sistemas para atender
legislações ou políticas de segurança interna que é preciso obedecer, e com a
evolução tecnológica podem existir ameaças à aplicação que necessitarão ser
eliminadas ou ao menos diminuir a sua gravidade em nível de aplicação. Uma vez
levantadas todas as ameaças e legislações, consolidamos nossos objetivos de
segurança. Esses objetivos são requisitos básicos de segurança que precisarão ser
atendidos pelo sistema para que tanto a legislação quanto as ameaças sejam
23
corretamente tratadas. Boa parte dos objetivos de segurança será atendida por
premissas externas de uso ou de ambiente.
A Especificação de Segurança da Aplicação é um documento que visa
identificar os objetivos de segurança da aplicação e, a partir das melhores práticas
de mercado, estabelecer os requisitos mínimos que devem ser atendidos pela
aplicação. Toda esta análise pode ser feita com base na ISO/IEC 15.408, e cada
requisito é acompanhado de uma sugestão de implementação e dos testes
necessários para verificar o atendimento do requisito.
Alguns cuidados precisam ser levados em consideração para garantir a
segurança de um sistema, como pode ser visto a seguir.
2.3.1 Boas Praticas de Programação
Segundo Albuquerque (2002), as boas práticas de programação devem ser
levadas em consideração quando do desenvolvimento de software, mesmo que não
estejamos preocupados com a segurança em si, pois elas permitem a criação de
códigos mais robustos, confiável e, evidentemente, seguro.
Por mais que o código seguro implique em certa perda de desempenho,
devida a maior carga de controles, é mais vantajoso para o sistema, pois garante
melhor segurança e legibilidade.
Albuquerque (2002) faz referência às recomendações citadas a seguir,
concluindo que elas são importantes para que se possam desenvolver códigos com
melhor qualidade.
a) Criar funções intrinsecamente seguras – Na aplicação, devem existir
funções que verifiquem os dados de entrada para impedir perda de
controle do sistema, falhas gerais de proteção ou outros tipos de falhas,
como o buffer overflow.
b) Usar funções intrinsecamente seguras – Exemplo de uma função
intrinsecamente insegura é a strcpy (C e C++, copia uma string). Essa
função recebe dois ponteiros como parâmetros e copia todo o conteúdo,
de uma para o outro, até encontrar 0. Se a função for chamada passando
parâmetro inválido, pode gerar resultados imprevisíveis, podendo até
sobrescrever áreas importantes da memória. Uma possível solução para
este problema seria usar a função strncpy, que permite limitar o tamanho
24
máximo a ser copiado. Em algumas linguagens de programação tipadas,
como Visual Basic e Delphi, por exemplo, minimizam problemas como
esse.
c) Testar o retorno de funções – Sempre que se chamar uma função, seu
retorno precisa ser verificado. É preciso atentar para a falha segura, isto
é, encontrar a alternativa com menor impacto, que traga menos risco.
d) Documentar funções corretamente – A boa documentação da função
evita mal-entendido a respeito da interpretação da mesma.
e) Tratar as entradas de dados – Tratar adequadamente os dados, seja
pelo usuário ou outro sistema, mesmo que se acredite que todas as
funções são intrinsecamente seguras. Tendo sempre cuidado em
identificar caracteres maliciosos na aplicação.
f) Ter uma política de versão consistente – Utilizar uma política de
versão consistente, no que diz respeito a versões liberadas, não importa
se é por uma gerência de configuração ou simplesmente backup,
facilitando assim a identificação de problemas e, por conseqüência, uma
melhoria contínua do produto.
g) Usar componentes e bibliotecas confiáveis – Toda segurança e
cuidado incluído no código pode ser comprometida com o uso de
bibliotecas ou sistemas auxiliares não-confiáveis. Deve-se assegurar que
bibliotecas não comprometem a segurança do sistema.
h) Evitar informações sensíveis em arquivos temporário s – Assim,
deve-se evitar que informações sigilosas tornem-se vulneráveis
restringindo seu uso em arquivos dessa natureza.
i) Não armazenar senhas e chaves criptográficas no cód igo – Senhas e
chaves criptográficas em códigos podem ser reveladas através de
engenharia reversa. O armazenamento de chaves criptográficas deve ser
alvo de análise criteriosa, assim como os algoritmos empregados.
j) Operar com o privilégio necessário – As aplicações deveriam rodar
com o privilégio requerido para desempenhar suas tarefas.
A ISO/IEC 15.408 (Commom Criteria) aborda a segurança como uma
questão de avaliação (ou investigação) da aplicação ou sistema. O Commom Criteria
propõe, além da verificação dos meios tradicionais de avaliação, que a avaliação
25
seja realizada com um incremento progressivo a ênfase dada ao escopo, à
profundidade e ao rigor.
2.3.2 Testes Funcionais de Segurança
O Commom Criteria possui quatro famílias para tratamento de testes:
ATE_COV (cobertura), ATE_DPT (profundidade), ATE_IND (teste funcionais
realizados por terceiros) e ATE_FUN (testes funcionais). Os testes têm a finalidade
de garantir que as aplicações estão atendendo os seus requisitos funcionais de
segurança.
A cobertura dos testes está relacionada ao tipo de verificação, quanto à
amplitude que será realizada no sistema durante a fase de teste.
A evidência de cobertura e a análise de cobertura são testes semelhantes,
em que fica comprovado que as funcionalidades de segurança foram testados em
relação ao que estava definido na especificação funcional. Sendo que na análise de
cobertura a correspondência entre os testes, na documentação de testes, e das
funções, na especificação funcional precisam ser sistemática e completa.
Na profundidade dos testes, os componentes dessa família, tratam com um
nível maior de detalhe em relação às funcionalidades das informações utilizadas na
análise. Todavia, os testes de alto nível tem o objetivo de demonstrar a presença de
qualquer falhas, fornecendo a garantia de que aqueles subsistemas foram
corretamente implementados.
Os testes funcionais, executados pelos desenvolvedores da aplicação,
garantem que suas funcionalidades de segurança exibam as propriedades
necessárias para satisfazer os requisitos funcionais da aplicação.
26
3 AVALIAÇÃO DO AMBIENTE E ESTRATÉGIAS DE SEGURANÇA
O primeiro ponto a ser tratado na especificação de segurança é levantar e
avaliar o ambiente no qual essa aplicação será implantada. É importante, além de
levar em conta as premissas já existentes no ambiente, fazer uma análise das
principais ameaças, dos pontos críticos, dos ativos valiosos e da legislação aplicada,
se for o caso.
Albuquerque (2002) relembra que não adianta implantarmos várias defesas,
mecanismos de proteção e auditoria se não temos em mente aquilo contra o qual
estamos nos defendendo, quais são as ameaças. É difícil desenvolver uma
aplicação segura em um ambiente não-seguro. Conforme a análise do ambiente da
aplicação – a especificação e o nível de garantia – podem ser necessários mais ou
menos controles. Não pode ser esquecido que existem diversas considerações a
respeito do uso do sistema, por parte dos usuários, fato que pode influenciar
fortemente os aspectos de segurança.
O mesmo autor relembra que várias pessoas (desenvolvedores) têm
utilizado com muito sucesso a abordagem da ISO/IEC 15.408 para o levantamento
dos requisitos de segurança. Baseia-se em cada um dos quatros aspectos a serem
considerados:
a) Política de segurança: diretrizes, normas e legislação pertinente.
b) Ameaças: ativos, mecanismos de ataque e agentes.
c) Objetivos de segurança: necessidades do usuário formalizadas.
d) Premissas: considerações sobre o uso do sistema e sobre seu ambiente.
Note que é importante considerarmos a ordem neste caso, pois levantamos
primeiramente a política de segurança e as ameaças para então fornecermos
subsídios à definição dos objetivos da segurança. Somente após a definição dos
objetivos de segurança, levantamos o que já é atendido pelo ambiente.
27
3.1 LEVANTAMENTO DA POLÍTICA DE SEGURANÇA
Segundo Dias (2000) a política de segurança é um mecanismo preventivo de
proteção dos dados e processos importantes de uma organização que define um
padrão de segurança a ser seguido pelo corpo técnico, gerencial e pelos usuários,
internos e externos. A política de segurança deve especificar quais os princípios
institucionais de como a organização irá proteger, controlar e monitorar seus
recursos computacionais. É importante que a política estabeleça responsabilidades
das funções relacionadas com a segurança e discrimine as principais ameaças e
riscos que estão presentes.
Política de segurança engloba quaisquer diretrizes, normas, legislação,
manual da qualidade ou qualquer outro documento que imponha ao sistema
determinadas características de segurança.
Em varias outras situações existem legislação ou normas da empresa
relativas a privacidade, confidencialidade e diversos outros aspectos da segurança.
Assim, temos de levantar essas necessidades antes de tudo, já que representam
requisitos do sistema, os quais não podemos alterar. O trabalho de levantamento
dos requisitos pode ser facilitado, bastando que o cliente já tenha uma política de
segurança definida.
Normalmente a política funciona como uma pirâmide formada por: diretrizes,
normas e procedimentos. As diretrizes são poucas e breves, mas indicam a direção
geral da segurança na empresa. As normas são mais detalhadas e podem ser gerais
ou especificas. Procedimentos e instruções de trabalho são detalhamentos de
operações importantes do ponto de vista de segurança.
3.2 DETECTANDO AMEAÇAS
Albuquerque (2002) afirma, também, que ameaça é qualquer situação que
ponha em risco o sistema. É impossível levantar todas as ameaças a que um
sistema está submetido, visto que elas são frutos da evolução da tecnologia ou de
futuras alterações na aplicação.
Dentre as inúmeras ameaças existentes, será dado um foco em um grupo de
ameaças bem definido e garantir que as ameaças serão tratadas pelo sistema. Seria
28
impossível tentarmos agir contra todas, pois levaria a sistemas falhos ou a sistemas
caros e pesados demais. Ainda que tenhamos uma aplicação que consiga se
proteger contra um número grande de ameaças, muito provavelmente estará
dificultando uma série de outras ameaças não consideradas, pois várias delas
utilizam o mesmo mecanismo, partem do mesmo agente ou visam ao mesmo ativo.
A garantia de segurança é uma das preocupações centrais da ISO/IEC
15.408. Não se pode garantir a um sistema proteção contra todas as ameaças, mas
pode-se testá-lo e avaliá-lo, garantindo que um número tão grande quanto se queira
seja inócuo ao sistema.
É importante ressaltar que se deve buscar ameaças práticas e bem
definidas, do tipo: “usuário altera notas quando podia somente consultá-las”, e não
itens genéricos como “invasão do sistema”.
Para Albuquerque (2000) as ameaças, em sua maioria, têm certas
características: um ativo com valor, um mecanismo de ataque e um agente com
conhecimento necessário para atingir o ativo. Assim, as ameaças são em geral
tríades: Agente x Mecanismo x Ativo.
Para que possamos detectar as ameaças que estão sujeitos um sistema, é
fundamental o levantamento dos agentes, mecanismos e ativos.
3.2.1 Os Agentes
No levantamento dos requisitos da política de segurança, uma tarefa
importante é a definição dos agentes, contra quem estamos nos defendendo, ou
queremos nos precaver.
O agente de uma ameaça é sempre alguém que vai ganhar algo com sua
eventual exploração. Existem diversos tipos de retorno ou compensação, como
danos a outra pessoa e roubo de dados, entretanto, o mais esperado é o retorno
financeiro.
Segundo Albuquerque (2002) a classificação do agente pode se dar de
acordo com as categorias:
29
Acesso ao sistema
Esse tipo de agente está relacionado ao tipo de acesso disponibilizado ao
sistema. Quanto maior o acesso, mais fácil para o agente realizar o ataque. A última
categoria, “acesso não-autorizado”, indica que o agente não deveria ter acesso ao
sistema. Se ele está realizando um ataque, certamente precisou criar algum tipo de
acesso. A tabela 1 apresenta a lista de algumas categorias de acesso ao sistema.
Tabela 1 – Lista de acesso ao sistema.
Categoria Descrição 1 Programador Acesso, eventualmente total acesso, ao código do sistema. 2 Administrador Total acesso à operação e administração do sistema. 3 Usuário Acesso a algumas funções do sistema 4 Acesso não-autorizado Pessoas, em principio, sem acesso ao sistema.
Conhecimento do sistema
Para ter sucesso no ataque, é necessário que se tenha um bom
conhecimento do funcionamento do sistema. Assim, quanto mais conhecimento o
atacante tiver, mais fácil será para ele realizá-lo. Um exemplo pode ser visto na
Tabela 2.
Tabela 2 - Conhecimento do sistema
Categoria Descrição 1 Grande conhecimento Usuários poderosos, administradores ou ex-administradores. 2 Algum conhecimento Usuários ou ex-usuários do sistema. 3 Acesso a manuais Embora sem conhecimento do sistema, tem acesso a manuais. 4Nenhum conhecimento Nenhum conhecimento do sistema.
Capacidade do agente
Mesmo um usuário comum pode ser perigoso se tiver amplo acesso e
conhecimento em relação ao sistema. Assim, deve-se distinguir um usuário leigo de
um hacker experiente. Um exemplo pode ser visto na Tabela 3.
Tabela 3 - Motivação do agente
Categoria Descrição 1 Especialista Grande experiência em ataques. Uso de ferramentas
sofisticadas. 2 Conhecedor Alguma experiência em ataques. Ferramentas mais simples. 3 Curioso Ferramentas básicas de ataque. 4 Leigo Nenhum conhecimento de ferramentas de ataque.
30
A motivação não precisa ser considerada diretamente na especificação de
segurança, até porque geralmente um agente pode ter múltiplas motivações. Um
exemplo pode ser visto na Tabela 4.
Tabela 4 - Motivação do agente
Categoria Descrição
1 Financeira Interesse em retorno financeiro. 2 Imagem Interesse em destacar suas habilidades. 3 Dano Busca por vingança ou prejuízo de empresa para a qual já
trabalhou ou empresa concorrente. 4 Aprendizado Estudo de ferramentas de ataque.
E importante classificar o agente porque ao longo da especificação de
segurança do sistema iremos utilizar essas informações para traçar as estratégias
adequadas a cada ameaça.
3.2.2 Os mecanismos
Inúmeros são os mecanismos conhecidos para se explorar as
vulnerabilidades de um sistema, todavia deve-se lembrar que pode haver outros
ainda por definir. De fato, para a concretização de uma ameaça, pode ser necessário
a utilização de um conjunto de mecanismos.
Temos de ressaltar que existem mecanismos tanto em baixo nível, como em
nível mais alto; por exemplo, “apoderar-se de uma conta de usuário” é um
mecanismo de alto nível; indica a quebra da autenticidade do usuário. Aqui,
buscaremos dar ênfase as ameaças de alto nível.
Na Tabela 5 destacamos alguns dos mecanismos mais comuns.
Tabela 5 - Mecanismos de ataque
Mecanismo Descrição
Cross-site Scripting Ataque que usa uma aplicação web para atingir um outro
visitante/usuário.
By-pass de controle de
acesso
Agente com acesso ao sistema utiliza funções externas a este
visando burlar o controle de acesso.
31
Força bruta Usada para quebrar senhas e criptografia. Tentativa e erro.
Estouro de buffer Muito comum e incrivelmente destrutível.
Quebra de autenticidade Apoderar-se da conta de um usuário ou do administrador,
através de ferramentas de sniffer ou de engenharia social.
Command/SQL Inject Informações enviadas para a construção de queries (consultas
SQL) e interações com o banco de dados não são devidamente
validadas e checadas.
3.2.3 Os ativos
Os ativos variam de acordo com a aplicação, ao contrario dos agentes e
mecanismos que às vezes até ocorrem com certa freqüência. Ativos são as
informações importantes de um sistema, aquilo que pode ser de interesse do agente
em termos de leitura, alteração ou até destruição.
A Tabela 6 apresenta um conjunto de exemplos de ativos, com seu
respectivo valor para os agentes.
Tabela 6 - Ativos com valor
Ativo Agente Valor
Disponibilidade do sistema. Corrente, ex-funcionário. Dano à empresa.
Integridade da tabelas de
usuários.
Hacker. Passo intermediário para outro
ataque.
Integridade da tabela notas de
alunos.
Hacker iniciante, usuário,
administrador.
Alteração de notas.
Existem diversos aspectos da segurança que podem ser de interesse em um
ativo, a saber:
a) Confidencialidade: se o agente da ameaça conseguir simplesmente ler a
informação, já obteve um ganho. A informação que resulta em lucro para
o agente da ameaça quase sempre representa uma perda para os
clientes do negócio.
b) Integridade: o agente, para aferir valor, precisa alterar ou remover um
dado no sistema.
c) Disponibilidade: basta que o sistema fique “fora do ar” por algum tempo
para que isso seja percebido.
32
d) Autenticação: não é preciso sequer alterar um dado, mas simplesmente
questionar sua veracidade para que tenhamos um problema de
autenticação.
3.3 OBJETIVO DA SEGURANÇA
Para Davis (1993) a definição do objetivo da segurança inicia no
levantamento das necessidades básicas de segurança, na forma de ameaças e
necessidades legais. Entretanto, há de consideramos que existem objetivos que são
de exclusiva escolha do cliente.
É importante fazer uma lista de objetivos de segurança a qual servirá de
base, previamente acertada com o cliente, dos requisitos que deverão ser
abordados no momento da avaliação do ambiente.
33
4 REQUISITOS FUNCIONAIS DE SEGURANÇA
Relembra Thayler (1990) que os requisitos funcionais de segurança são
declarações que descrevem os controles necessários para atenuar o risco. O termo
funcional é significativo: os controles devem ser expressos conforme as funções
desejadas, em oposição às tecnologias estabelecidas. Soluções técnicas
alternativas também são possíveis e qualquer decisão é aceitável, desde que atenda
aos requisitos funcionais de segurança. A equipe de gerenciamento de riscos de
segurança é responsável pela definição dos requisitos funcionais.
É necessário definir os requisitos funcionais para cada risco discutido no
processo de suporte às decisões. O produto resultante poderia ser chamado de
definições do requisito funcional. A definição e a propriedade do requisito funcional
são muito importantes no processo de análise de relação de custo/benefício. O
documento definiria o que é necessário para reduzir o risco identificado, mas não
especificaria como deveria ser reduzido, nem definiria os controles específicos. Essa
distinção concede à equipe de gerenciamento de riscos de segurança
responsabilidade na sua área de experiência, ao mesmo tempo em que permite ao
proprietário da atenuação, responsável pela implementação da solução de
atenuação, a propriedade das decisões relacionadas à operação e ao suporte aos
negócios.
Assim, organiza-se um documento de especificação da segurança pelos
objetos, apontando a estratégia e os atributos utilizados. Em algumas situações os
atributos estarão presentes em mais de um objetivo de segurança. Em função disso,
pode-se optar por, ao final da lista de estratégias, montar uma lista com os atributos
e os motivos de seu uso. A ISO/IEC 15.408 (Commom Criteria) emprega um modelo
diferente que lista objetivos e atributos e descreve o porquê de um ser usado com o
outro.
Do ponto de vista de Albuquerque (2002), a forma usada pelo Common
Criteria dificulta o entendimento da estratégia de segurança usada. Ele prefere
agrupar as estratégias de forma global e, se for oportuno, acrescentar a tabela de
relacionamento ao final.
34
Algumas estratégias de segurança aparecem de forma muito comum, como
verdadeiros padrões de segurança da aplicação. Cada caso deve ser avaliado
particularmente, mas alguns requisitos são descritos a seguir para, pelo menos,
orientar a especificação da segurança do sistema.
4.1 AUDITORIA
Auditoria em software incide basicamente na gravação, armazenamento e
análise de informações importantes que determinem quais ações relevantes à
segurança ocorreram e quem as cometeu. Aparentemente, simples rotinas de
auditoria devem considerar uma série de fatores que elevam sua complexidade. É
necessário registrar as ações importantes do sistema, como tratar a privacidade,
como analisar as trilhas, armazená-las e compatibilizá-las com as trilhas de
auditorias.
Segundo Dias (2000), deve ser dada atenção especial ao volume de dados a
ser armazenado e o volume de ações registradas. É preciso definir quais ações são
relevantes para serem gravadas – registrar pouco pode não ser elucidativo para
desvendar um problema, e registrar a mais pode comprometer o sistema e/ou gerar
trilhas em volume superior à capacidade de análise. A gravação das trilhas deve
considerar a finitude do espaço nas mídias adotadas, assim como o tratamento a ser
dado aos dados quando o espaço se exaurir. É necessário destacar as seguintes
preocupações:
a) saber se os dados mais antigos serão apagados à medida que os novos
são inseridos (permitindo que um atacante gere ações lícitas
repetidamente após um ataque, de forma a eliminar qualquer registro das
trilhas);
b) se o melhor é parar de registrar (admitindo que o atacante aja
incognitamente); ou,
c) se travar o sistema até a intervenção do administrador para liberar
espaço é atitude mais apropriada.
O armazenamento da trilha de auditoria deve ser feito de forma que sua
integridade, mesmo em caso de ataque ou falha do sistema, seja garantida.
35
Outro aspecto importante é o que trata da privacidade. Alguns sistemas são
altamente comprometidos com a privacidade de seus usuários. A auditoria pode
violar a privacidade. Nesse caso, será necessário escolher entre privilegiar a
auditoria ou a privacidade.
O registro e a visualização da trilha de auditoria é coberta no Commom
Criteria por três atributos de segurança: FAU_GEN (geração de dados para
auditoria), FAU_SEL (seleção de dados para auditoria) e FAU_SAR (revisão de
dados da auditoria).
Figura 1 – Família FAU_GEN
A geração de dados para a auditoria é tratada na ISO/IEC 15.408 pelo
atributo FAU_GEN, o qual possui dois níveis, FAU_GEN.1 (geração de dados de
auditoria) e FAU_GEN.2 (associação do usuário ao evento de auditoria), conforme é
visto na figura 1. Este atributo recomenda que sejam armazenados os registros de
cada um dos seguintes eventos:
a) Inicialização e finalização das funções de auditoria;
b) Todos os eventos auditáveis para o nível [seleção: mínimo, básico,
detalhado ou não especificado];
c) designação: outros eventos de auditoria;
d) Para cada evento auditado deve-se registrar ao menos as seguintes
informações:
e) Data e hora do evento, tipo de evento, identidade do sujeito (usuário ou
sistema) e resultado final (sucesso ou falha);
f) Para cada tipo de evento, baseado na definição do evento na
especificação de segurança, incluir [designação: outras informações
necessárias.
A seleção de dados para a auditoria é tratada no Commom Criteria pelo
atributo FAU_SEL, o qual possui apenas um nível, conforme é mostrado na figura 2.
36
Figura 2 – Família FAU_SEL
Considerando que os eventos auditáveis ao passar do tempo podem deixar
de serem importantes, a ISO/IEC 15.408 sugere que se permita mudanças nos
eventos auditáveis e que o sistema registre na trilha de auditoria, no nível mínimo,
todas as alterações na configuração da auditoria, com base nos seguintes critérios:
a) Identidade do objeto e usuário
b) Hora do dia
A revisão de dados da auditoria é tratada no Commom Criteria pelo atributo
FAU_SAR (revisão de dados de auditoria), o qual possui três níveis, conforme é
visto na figura 3: FAU_SAR.1 (revisão de auditoria), FAU_SAR.2 (revisão restrita de
auditoria) e FAU_SAR.3 (revisão selecionável de auditoria).
Figura 3 – Família FAU_SAR
De acordo com Albuquerque (2002), a análise de trilha de auditoria
manualmente é tediosa e seus resultados estão passivos a erros. Na maioria das
vezes, os eventos não representam grandes problemas de segurança. Muitas vezes
o verdadeiro potencial da auditoria não é aproveitado até que os dados sejam
transformados em informações úteis.
Dias (2000) relembra que é importante a criação de um mecanismo
automático para detecção de problemas. Alarmes e respostas automáticas à
tentativa de invasão permitem que, detectada uma situação suspeita, o sistema
envie um e-mail, apresente uma mensagem no console do administrador, registre na
tabela de suspeita de invasão, ou mesmo, tome alguma medida de auto-proteção.
37
4.2 NÃO REPÚDIO
Relembra Albuquerque (2002) que repúdio é uma forma de ataque. O
agente do ataque executa uma função no sistema e posteriormente nega tê-la
efetuado; por exemplo, alguém faz uma compra em uma loja eletrônica e, no
momento de pagar, alega que não a fez.
A ISO 15.408 (Common Criteria) define dois atributos de segurança para a
especificação dos mecanismos de não-repúdio utilizados, conforme figura 4 e 5.
Figura 4 – Não repúdio de origem
Figura 5 – Não repúdio de destino
Para garantir a identificação do emissor da informação, utilizamos o atributo
FCO_NRO (repúdio de origem), o qual pode ser especificado em dois níveis,
FCO_NRO.1 (prova de origem seletiva) e FCO_NRO.2 (prova de origem
assegurada), e para assegurar a identificação do destinatário, utiliza o atributo
FCO_NRR (prova de recebimento), o qual também pode ser dividido em dois níveis,
o FCO_NRR.1 (prova de recebimento seletiva) e o FCO_NRR.2 (prova de
recebimento assegurada). Para evitar o não-repúdio é necessário autenticar as
partes envolvidas e garantir a integridade da mensagem, para que o conteúdo não
seja alterado.
As assinaturas eletrônicas são eficazes para garantir o não-repúdio de
origem. Entretanto, insuficiente para garantir o de recebimento. É preciso algum tipo
de protocolo em que o destinatário ou uma terceira parte confiável envie ao
emitente, ou armazene em base confiável, uma mensagem comprobatória do
recebimento. A mensagem de resposta (prova do recebimento) deve ser também
assinada eletronicamente.
Uma terceira parte confiável arbitrando as trocas de mensagens é
importante também para evitar que a prova de recebimento chegue ao emissor da
38
mensagem original. Nesse caso, o emissor (A) enviaria uma mensagem, o
destinatário (D) acusaria seu recebimento enviando outra em resposta, porém essa
prova de recebimento não chega a A.
Há a hipótese de se configurar, na visão de A, que o negócio não foi fechado
e D, sim. Uma terceira parte confiável permitiria ambas as partes consultar um
árbitro para saber se o protocolo foi concluído com sucesso. Outra alternativa seria o
emissor repetir a mensagem, notificando em caso de uma cópia, a intervalos
regulares até a confirmação de recebimento.
4.3 CRIPTOGRAFIA
Soares (1995) comenta que a criptografia surgiu da necessidade de se
enviar informações sensíveis através de meios de comunicação não confiáveis, ou
seja, em meios onde não é possível garantir que um intruso não irá interceptar o
fluxo de dados para leitura (intruso passivo) ou para modificá-lo (intruso ativo). A
forma de contornar esse problema é utilizar um método que modifique o texto
original da mensagem a ser transmitida (texto normal), gerando texto criptografado
na origem, através de um processo de codificação definido por um método de
criptografia. O texto (ou a mensagem) criptografado é então transmitido e, no
destino, o processo inverso ocorre, isto é, o método de criptografia é aplicado agora
para decodificar o texto criptografado, transformando-o no texto normal original.
Há dois tipos de criptografia: a simétrica e a assimétrica (ALBUQUERQUE,
2002). A simétrica utiliza uma chave para criptografar os dados e a mesma chave
serve para decriptografá-los. Na criptografia assimétrica, as chaves são sempre
produzidas em par.
Para Rufino (2002), um problema da criptografia assimetria está no fato de
ser dificultoso entregar a chave de forma segura a quem vai decifrar a mensagem.
Existem diversos algoritmos conhecidos de criptografia simétrica, como DES, IDEA,
TRIPLE-DES e BlowFish .
Segundo Albuquerque (2002), a garantia da confidencialidade na criptografia
deve ser baseada na segurança da chave; o ideal é usar algoritmo público
conhecido. O segredo tem que estar na chave, não no algoritmo. Os algoritmos
públicos mais conhecidos são desenvolvidos para evitar criptoanálise e decifração
39
do texto. Algoritmos feitos de forma amadorística são, geralmente, bastantes
suscetíveis a criptoanálise. Criptoanálise é uma especialidade que busca identificar a
chave ou o texto original. É preciso atentar que alguns algoritmos são protegidos por
direitos autorais em alguns países do mundo.
O Commom Criteria define dois atributos de segurança para a especificação
do uso de criptografia: o FCS_COP (operação de criptografia) e o FCS_CKM
(gerenciamento de chaves de criptografia).
O atributo de segurança FCS_COP (operação de criptografia) apresenta
apenas um nível, de mesmo nome, conforme visto na figura 6.
Figura 6 – Família FCS_COP
O atributo de segurança FCS_CKM é dividido em quatro níveis, conforme
visto na figura 7: FCS_CKM.1 ( geração de chaves de criptografia), FCS_CKM.2
(distribuição de chaves de criptografia), FCS_CKM.3 (acesso a chave de
criptografia) e FCS_CKM.4 (destruição de chaves de criptografia).
Figura 7 – Família FCS_CKM
4.4 PROTEÇÃO DE DADOS DO USUÁRIO
A proteção de dados dos usuários é regida pelo Common Criteria por
funções de segurança e políticas para proteção dos dados. Esses requisitos são
divididos em quatro grupos:
40
a) Políticas de funções de segurança para proteção dos dados do usuário:
b) Política de controle de acesso;
c) Política de controle de fluxo de informações.
d) Formas de proteção dos dados do usuário:
e) Funções de controle de acesso;
f) Funções de controle de fluxo de informações;
g) Transferências internas;
h) Proteção de informação residual;
i) Retorno;
j) Integridade de dados armazenados.
k) Armazenamento off-line, importação e exportação:
l) Autenticação de dados;
m) Exportação de dados para fora do controle do sistema;
n) Importação de dados de fora do controle do sistema.
o) Comunicação interna:
p) Proteção de confidencialidade de dados do usuário;
q) Integridade na transferência de dados.
4.4.1 Controle de Acesso
Albuquerque (2002) comenta que proteção de dados do usuário é
basicamente realizado por controle de acesso. A função de controle de acesso do
sistema é utilizada para definir se o usuário tem direito a acessar ou alterar
determinada informação e para garantir que apenas o usuário com esse direito pode
ter acesso a essa informação.
Conforme o Commom Criteria (1999), o controle de acesso, é atendido por
dois níveis de atributos: FDP_ACF (funções de controle de acesso) e FDP_ACC
(política de controle de acesso). O atributo FDP_ACC apresenta dois níveis,
FDP_ACC.1 (controle de acesso por subconjuntos) e FDP_ACC.2 (controle de
acesso completo).
As funções de controle de acesso da aplicação devem considerar que
diferentes usuários possuem direitos de acesso distintos. Usuários podem realizar
diversos tipos de operações sobre os dados (ler, alterar, remover ou criar
41
informações). Atenção especial deve ser dada ao controle de acesso tendo em vista
que é responsável por monitorar o acesso aos diversos usuários, assim, tem por
principal função não deixar que usuários burlem o controle de acesso e assim
tenham acesso a informações diretamente sem passar por mecanismo de
autenticação/validação.
Há vários tipos de controle de acesso que podem ser utilizados. Todavia, os
mais comuns são:
a) controle de acesso por níveis universais, o qual classifica as informações
com níveis, como secreta, confidencial, restrita e pública;
b) controle de acesso por proprietário e grupo de proprietário, esse muito
popular em sistemas operacionais do tipo UNIX, no qual é definido o
acesso amplo ao dono da informação.
Um segundo nível mais restrito a um grupo de pessoas que pode precisar de
informações e, em seguida, o direito de acesso a todos. Alguns, porém, indicam
alguns usuários, negando-lhes explicitamente determinada operação.
Comenta Albuquerque (2002) que o controle de acesso por contexto pode
ser exemplificado como o objeto 'Projeto' pode ser lido e alterado pelo perfil
'Financeiro' e pelo perfil 'Equipe do Projeto'.
Note que o perfil 'Equipe do Projeto' varia de projeto; não é um grupo fixo de
pessoas. Isso é uma característica geralmente necessária em sistemas de controle
de acesso e que gera mais custo para implementação.
Ainda que o aplicativo, o sistema operacional e o firewall3 tenham a política
de acesso obedecida, outros fluxos ilícitos precisam ser controlados. Entre eles,
existem computadores ligados a modem, roubo de HD (disco rígido) e outras
ocorrências de furto. De todas as alternativas, difíceis de serem levantadas e
implementadas na totalidade, a maneira mais segura de se evitar acessos ilícitos é
através do uso de criptografia das informações.
3 Firewall é um nome dado a um dispositivo de rede que tem por função regular o trafego de rede entre redes distintas e impedir a transmissão de dados nocivos ou não autorizados de uma rede a outra (SOARES, 1995).
42
4.4.2 Importação e exportação de dados
A exportação ou importação de dados precisa respeitar as regras
estabelecidas na política de controle de acesso e fluxo de informações.
Segundo o CC (1999), essa premissa de segurança é tratada pelo atributo
FDP_ITC, a qual possui os níveis FDP_ITC.1 e FDP_ITC.2. Embora óbvio, um
usuário não autorizado a criar determinada informação, não deve ter oportunidade
de criá-la também por importação ou exportação. As comunicações entre sistemas
também devem ter os níveis necessários de segurança à proteção das informações.
A política de segurança deve tratar das questões pertinentes a relatórios (saída de
dado sem segurança), alertando os usuários das suas responsabilidades sobre a
confidencialidade dos dados, que não será mais tarefa do sistema.
Na norma ISO/IEC 15.408, importação, exportação, autenticidade e proteção
da confidencialidade e da integridade são atributos separados. Isso faz sentido já
que, teoricamente, é possível usar um desses atributos e não o outro. Porém
segundo Albuquerque (2002), geralmente usamos apenas os atributos de
importação e exportação, sem atributo de segurança, ou usamos o pacote completo,
com todos os atributos especificados.
As transferências internas – aplicações em locais físicos diferentes como em
um ambiente cliente-servidor – necessitam, muitas vezes, de controles especiais que
envolvem a criptografia ou a autenticação dos dados em virtude da possibilidade de
interceptação da informação.
As informações residuais, como as armazenadas em cookies4, que
permanecem armazenadas mesmo depois de excluídas, precisam ser tratadas de
forma adequada para que pessoas não autorizadas não possam recuperá-las. A
solução mais simples é escrever zeros sobre os dados apagados. Se a informação
for muito importante, pode-se escrever zero, depois um, depois zero novamente, em
seguida dois e repetir o processo 128 vezes para assegurar que uma análise
magnética da superfície não permita detectar a informação.
A garantia de integridade dos dados armazenados requer medidas
preventivas quanto a problemas de hardware e atomicidade de transações. Pouco
se pode fazer quanto a problemas físicos, como interferência magnética, no
4 Cookies é um grupo de dados trocados entre o navegador e o servidor de páginas, colocando num arquivo de texto criado no computador do usuário(TORRES,2003).
43
desenvolvimento de software, mas pode-se remediar a deficiência com alertas após
detectado problemas que caracterizem falhas no hardware. Albuquerque (2002)
define transação como o conjunto de operações realizadas na base de dados do
sistema que só faz sentido quando realizadas todas as operações em conjunto. O
exemplo clássico é o de transferência entre contas, a operação só tem importância
se tanto o crédito quanto o débito tenham sido feitos com segurança. Se apenas um
deles for feito, a operação deve ser desfeita. Geralmente a atomicidade de
transações fica sob a responsabilidade do sistema de banco de dados, nas ocasiões
que são empregados.
4.5 GERENCIAMENTO DE SEGURANÇA
O Common Criteria (CC 1999) define uma classe para gerenciamento de
segurança que envolve atributos, informações e funções de segurança. Todo
gerenciamento de segurança passa por pontos importantes como:
a) Definição e gerência de papéis de segurança, que significa determinar
quem possui acesso a determinadas funções ou informações de
segurança.
b) Capacidade de revogação e expiração de atributos de segurança, que é
a capacidade do sistema revogar um direito imediatamente ou
estabelecer um prazo para tal.
c) Depois desses pontos, outros três tipos de funções compõem o
gerenciamento:
d) Gerenciamento das funções de segurança, que descreve o acesso e os
atributos das funções de segurança.
e) Gerenciamento dos atributos de segurança, que descreve o acesso aos
atributos de segurança de outros objetos do sistema, como quem define
o proprietário de um arquivo.
f) Gerenciamento de dados de segurança, o qual, ao contrário dos
atributos, não se liga a um objeto particular.
44
4.6 PRIVACIDADE
Segundo Albuquerque (2002) privacidade é a capacidade de um usuário
realizar ações em um sistema sem que seja identificado. É completamente diferente
de confidencialidade, que define que apenas usuários autorizados podem ter acesso
à determinada informação.
O Commom Criteria define quatro atributos para a privacidade:
FPR_ANO (anonimato), garante que um usuário possa usar um recurso ou
serviço sem ter sua identidade revelada;
FPR_PSE (pseudônimo) – garante que processos ou operações realizadas
por um usuário devem identificar somente o seu pseudônimo para os usuários;
FPR_UNL (não-rastreamento) - garante que um usuário possa fazer uso de
vários recursos e serviços sem que outros possam ligá-lo a esses usos; e,
FPR_UNO (invisibilidade) – garante que um usuário possa usar um recurso
ou serviço sem que outros, principalmente terceiros, possam saber que o recurso ou
serviços está sendo usado.
O não-rastreamento e a invisibilidade são tratadas no Commom Criteria
pelos atributos FPR_UNL e FPR_UNO, respectivamente.
4.7 AUTOPROTEÇÃO
Segundo Albuquerque (2002), é importante notar que existe uma distinção
entre atributos, funções e informações do sistema, para seu funcionamento
específico, e atributos, funções e informações de segurança do sistema. O primeiro
grupo foca na proteção dos dados do usuário, aqueles destinados à atividade fim do
sistema, enquanto o segundo na proteção dos dados da segurança do sistema.
Existem três pontos que podem ser destacados nas funções de segurança
do sistema:
a) Camada subjacente, que é a plataforma (sistema operacional ou
hardware) sob a qual o sistema opera. Uma plataforma comprometida
representa um risco para o sistema.
45
b) Implementação das funções de segurança, que se for possível interferir
alterando-se as funções de segurança, também será atingido
indiretamente os dados confidenciais sistema.
c) Dados e atributos de segurança, que corresponde ao banco de dados
administrativo que orienta a proteção do sistema, bem como define a
política de controle de acesso.
Os itens citados anteriormente devem ser implementados conjuntamente,
visto que são complementares; a implementação de um e não de outro, representa
um alto risco e pode comprometer a segurança como um todo.
O Common Criteria define um grupo de famílias importantes para proteção
da Segurança:
a) Teste de camada subjacente
b) Falha Segura
c) Disponibilidade de dados exportados pelo sistema
d) Confidencialidade dos dados exportados pelo sistema
e) Integridade dos dados exportados pelo sistema
f) Transferência interna de dados
g) Proteção física do sistema
h) Recuperação segura
i) Detecção de repetição
j) Monitor de referência
k) Separação de domínios
l) Protocolo de sincronização de estado
m) Registros de tempo (time stamp)
n) Consistência de dados entre funções de segurança
o) Consistência de dados replicados
p) Autoteste
Sistemas que não implementam proteção nas funções de segurança
comprometem a segurança dos dados do usuário, pois controles de proteção
tornam-se vulneráveis e, dessa forma, comprometem a segurança como um todo.
Albuquerque (2002) considera essencial a existência dos seguintes
mecanismos:
46
a) Controle de acesso a dados de segurança
b) Autoteste
c) Proteção física
d) Teste da camada subjacente
e) Falha segura
Os dados de segurança devem ser protegidos de forma análoga aos dados
do usuário. Isto é, as medidas (controle de acesso, integridade, disponibilidade,
informação residual e outros) que protegem os dados do usuário devem também
proteger os dados de segurança.
4.8 CONTROLE DE SESSÕES
Segundo ALBUQUERQUE (2002), o controle de sessões envolve desde
questões como notificar o usuário sobre quais foram seus últimos acessos até o
cancelamento da sessão após um período de inatividade do sistema. As notificações
a respeito dos últimos acessos podem englobar informações dos acessos não só
bem-sucedidos como também dos malsucedidos. As sessões também podem ser
restringidas a determinados horários e dias, como o horário comercial. Se uma
sessão ficar sem uso durante muito tempo, regras, como o seu cancelamento
automático, podem ser estabelecidas.
O acesso ao sistema envolve uma série de aspectos que podem ser usados
para ajudar na estratégia de segurança:
a) Limitação do acesso ao sistema – conforme o tipo de acesso (local, via
rede, via Internet) e a hora do acesso (hora de trabalho normal, fora do
expediente), o usuário pode ser impedido de executar o sistema.
b) Limitação do escopo do sistema – conforme o tipo de acesso (local, via
rede, via Internet) e a hora do acesso (hora de trabalho normal, fora do
expediente), o usuário pode ser limitado a algumas funções do sistema.
c) Limitação do número de acessos – restringir o número máximo de
sessões de um usuário.
d) Mensagem de acesso – solicitar que o usuário confirme a leitura de uma
mensagem antes de liberar o acesso ao sistema.
47
e) Histórico de acesso – informar ao usuário quando foi o último acesso
com sucesso e eventuais falhas na autenticação ou no estabelecimento
da sessão.
f) Travamento de sessão – meios de o usuário bloquear o console sem
encerrar a sessão.
Após um travamento, intencional ou não, a forma de se voltar a ter acesso à
sessão deve ser por meio de uma nova autenticação do usuário.
4.9 AUTENTICAÇÃO
Segundo Albuquerque (2002), a autenticação visa possibilitar identificar que
o usuário que está acessando o sistema é de fato quem ele diz ser. É notória a
importância da autenticação dos usuários para a segurança dos sistemas
computacionais. Não basta apenas dispormos de mecanismos fortes de controle de
acesso se um usuário pode se fazer passar por outro. Logo, ficaria difícil de
responsabilizar um usuário através da auditoria, pois não temos a garantia da
identificação.
Segundo Albuquerque (2002) há três formas de identificar um usuário, quais
sejam:
a) Perguntar algo que só aquele usuário saberia responder corretamente.
b) Solicitar a apresentação de algo que só aquele usuário teria.
c) Identificar o usuário por características pessoais.
Dessas maneiras listadas, a primeira alternativa é a mais comum. A
informação que o usuário sabe é, geralmente, uma senha individual de acesso. A
segunda alternativa é geralmente utilizada no sistema bancário, com os cartões
magnéticos. Basta apenas apresentar o cartão e digitar a senha e este é autenticado
como o usuário. A última alternativa é o sistema biométrico que visa identificar a
existência de características pessoais. No momento, os métodos mais utilizados são
através do reconhecimento da íris e impressões digitais. Ocorre que o uso desses
dispositivos ainda é muito caro e está sujeito a erros. Além do que a impressão
48
digital, ou qualquer outro aspecto morfológico, é armazenado na forma de uma
quantidade muito grande de dados (cerca de 2 Kbytes).
4.9.1 Processo de Autenticação e Identificação
É importante ressaltar que existe diferença entre a identificação e
autenticação do usuário. A identificação procura saber quem está operando o
sistema. Enquanto que a autenticação trata de garantir que o usuário é quem ele diz
ser. Até podemos identificar um usuário sem autenticá-lo, todavia a autenticação
pressupõe sempre uma identificação. Existem sistemas em que apenas uma senha
é solicitada e a identificação é realizada com base nos dados da autenticação,
todavia isso é uma grave falha de segurança.
Durante a fase de autenticação do usuário geralmente os sistemas realizam
verificação das senhas informadas com a armazenada anteriormente no banco de
dados. Uma senha é armazenada em um banco de dados na forma de um hash. A
técnica hash é uma forma de criptografia, a qual atua em um só sentido
(ALBUQUERQUE, 2002). Não existe qualquer forma de se obter a senha em claro a
partir do hash, mas apenas o hash a partir da senha em claro.
4.9.2 Mecanismo de Autenticação
Segundo Albuquerque (2002), independentemente da forma da autenticação,
seja ela por senha, cartão, biométrica ou o que quer seja, existem diversos aspectos
da autenticação que precisam ser observado:
a) Momento da autenticação: a situação ideal é que o usuário só consiga
fazer qualquer coisa no sistema após ter sido autenticado. Se houver a
possibilidade de um usuário realizar alguma operação sem se autenticar,
isso precisa ser bem limitado e definido.
b) Impossibilidade de fraude do sistema: a aplicação deve impedir que
qualquer outro usuário consiga usar o hash ou outra informação
disponível de um outro usuário especifico para forjar a autenticação.
Essa é uma preocupação adicional, já que o administrador do sistema
49
tem normalmente acesso ao hash da senha. Se ele consegue interceptar
o processo de autenticação e enviar diretamente o hash (em vez da
senha), ele conseguirá efetuar o login como aquele usuário. Uma outra
possibilidade é o replay, ou seja, um usuário gravar todas as informações
que são enviadas para autenticar outro usuário e enviá-las novamente.
c) Múltiplos mecanismos de autenticação: caso o sistema permita mais de
um mecanismo de autenticação, por exemplo, senha ou biometria, faz-se
necessária que haja uma política bem definida sobre a interação entre os
mecanismos.
d) Reautenticação: muito embora a autenticação seja uma das operações
inicias do sistema, é importante lembrar que o usuário pode ter deixado a
máquina com a sessão aberta (desbloqueada), e um usuário mal
intencionado pode se aproveitar deste fato e realizar alguma operação
critica. Assim, é importante haver uma nova autenticação sempre que
uma operação critica é solicitada ao sistema.
e) Mensagens de erro de autenticação: eventuais mensagens de erro de
autenticação podem dar pistas a um eventual agente que esteja
buscando atacar o sistema. Sejam nas mensagens de login inválido ou
senha inválida. Assim, é importante usarmos apenas um número
reduzido de mensagens de erro na autenticação.
O emprego de flag para bloqueio de conta, estipulação de prazo de validade
em contas e necessidade de troca de senha ou de certificado, são atributos que
contribuem para aumentar a segurança do processo de autenticação. Informações
para autenticação comumente usadas pelos sistemas:
a) Identificação do usuário
b) Dados para autenticação
c) Prazo de validade dos dados para autenticação
d) Prazo a partir do qual deve-se alertar o usuário para renovar seus
dados de autenticação
e) Indicador de conta bloqueada (flag)
f) Data e hora para liberação do bloqueio
50
As senhas, quando empregadas, devem atender critérios que determinem o
número mínimo de caracteres, se são compostos por letras, números, sinais e se as
letras são sensíveis à caixa (alta e baixa).
Segundo Albuquerque (2002), a autenticação é recomendada sempre que o
sistema exigir controle de acesso. Utilizamos a autenticação quando devemos
responsabilizar usuários por seus atos e quando necessitamos manter a
confiabilidade das informações, permitindo apenas seu acesso por parte do próprio
usuário e do administrador.
4.9.3 Conformidade com a ISO/IEC 15408
A autenticação do usuário é tratada no Commom Criteria por três atributos:
identificação do usuário (FIA_UID), autenticação do usuário (FIA_UAU) e tratamento
de falhas de autenticação (FIA_AFL).
A figura 8 ilustra o atributo FIA_UID.
Figura 8 – Família FIA_UID
A identificação do usuário pode ser definida em dois níveis:
a) FIA_UID.1, ações anteriores à identificação do usuário, que permitem ao
usuário algumas ações especificas antes da identificação; e,
b) FIA_UID.2, identificação do usuário antes de qualquer ação, na qual a
identificação do usuário deve ser feita antes de qualquer outra coisa no
sistema.
Os atributos FIA_UID.1 ou FIA_UID.2 são síncronos com os atributos
FIA_UAU.1 e FIA.UAU.2, tendo em vista que a autenticação deve acontecer no
mesmo momento da identificação.
O Commom Criteria sugere que sejam consideradas possíveis funções de
gerenciamento de segurança a gerência de identidade de usuários e, para o nível
FIA_UID.1, o número e os tipos de ações permitidas antes da identificação.
51
Autenticação do Usuário (FIA_UAU)
Figura 9 – Família FIA_UAU
A autenticação do usuário é definida no Commom Criteria em dois níveis:
FIA_UAU.1, ações anteriores a autenticação e FIA_UAU.2, autenticação do usuário
antes de qualquer ação. Além desses dois níveis, outros cinco aspectos são
definidos nesse atributo: FIA_UAU.3, autenticação a prova de fraude; FIA_UAU.4,
autenticação de utilização única; FIA_UAU.5, múltiplos mecanismos de autenticação;
FIA_UAU.6, reautenticação; e FIA_UAU.7, resposta restrita de autenticação,
conforme visto na figura 9.
52
5 ANALISANDO RISCOS
Dias (2000) relembra que muitas vezes o termo risco é utilizado como
sinônimo de ameaça ou da probabilidade de uma ameaça ocorrer. Na verdade, risco
é uma combinação de componentes, tais como ameaças, vulnerabilidades e
impactos. Vale ressaltar que o risco é inerente a qualquer atividade, podendo seu
impacto ser apenas reduzido, visto que a quebra de segurança sempre irá ocorrer,
sendo apenas uma questão de tempo, recursos técnicos ou econômicos.
Para Rufino (2002), o comportamento anormal de um sistema deve ser
examinado para que, ao final de uma análise, possa ser ou não considerado um
incidente de segurança. Essas práticas de testes visam testar à resistência dos
sistemas as ameaças existentes no ambiente. A avaliação de vulnerabilidades pode
ser realizada pelos próprios desenvolvedores, ou por uma equipe independente com
conhecimento elevado.
Nas seções seguintes, serão discutidas e apresentadas análise de
vulnerabilidades em sistemas desenvolvidos para o ambiente web, bem como
sugeridas dicas para melhoria na segurança para desenvolver sistemas neste
ambiente.
5.1 ANALISE DE VULNERABILIDADES
É recomendado por Dias (2000) que antes de decidir como proteger um
sistema, atenção especial deve ser dada em saber contra quem ele será protegido.
A segurança poderá ser então definida em termos de combate às ameaças
identificadas. Para que se tenha sucesso na avaliação e sucesso na análise de
vulnerabilidades devemos seguir as recomendações:
Verificar os ambientes em que a aplicação será implementada, ou seja,
analisar uma amostragem dos ambientes mais fracos;
Analisar o nível de conhecimento dos principais agentes de ataque, o que
pode também ser obtido da avaliação do ambiente; e,
53
Levantar toda a documentação disponível, inclusive as premissas de
ambiente já levantadas.
Depois de realizados esses levantamentos, o processo de análise resume-
se a seguir passos descritos de forma detalhada, pois qualquer detalhe não
observado pode ser considerado uma falha de segurança. O analista de testes tem
que assumir o papel de “chato”, registrando cada detalhe mínimo, pois o agente
(atacante) terá muito mais tempo do que a equipe de testes em descobrir falhas.
Segundo Dias (2000), qualidade de software é algo que todos cobiçam. Os
gerentes sabem que eles precisam ter alta qualidade em seus trabalhos;
desenvolvedores sabem que desejam produzir um produto de alta qualidade; os
usuários, por sua vez, insistem que o seu trabalho através do uso do software deve
ser confiável e consistente.
Albuquerque (2002) recomenda que sejam tomadas as providencias a seguir
para a realização dos testes.
a) Montagem do Ambiente : o analista de testes deve criar o ambiente de
acordo com as especificações enviadas ao cliente. O ideal é levantar o
ambiente sem consultar a equipe de desenvolvimento. Também é
necessário realizar instalações fora dos padrões especificados para
testar a resistência do sistema a alguns tipos de erros e ataques.
b) Execução de testes : o analista de testes deve realizar os ataques mais
comuns para os agentes e ambientes selecionados.
c) Estouro de campos de entrada : utilizar um número muito grande de
caracteres, maior do que o esperado. Esse tipo de falha é muito comum
em ambientes web.
d) Execução do sistema em modo de depuração : através da marcação
de pontos sensíveis no sistema, pode-se obter chaves de criptografia e
outras informações sensíveis. Apenas o fato do sistema operar em modo
de depuração já indica uma vulnerabilidade
e) Teste de caracteres estranhos : deve-se verificar se a aplicação aceita a
entrada de caracteres estranhos. Em ambientes web ou interfaces de
banco de dados, deve-se, por exemplo, verificar a entrada de caracteres
como aspas simples ou dupla, pois o não tratamento de eventuais erros
pode fornecer informações nocivas aos possíveis agentes.
54
f) Alteração no modo de chamada do programa ou parâmet ros
inválidos : Este tipo de ataque é muito utilizado em ambientes web, pois
se pode forjar com muita facilidade parâmetros passados pela URL
buscando um comportamento anormal do sistema.
g) Exploração de arquivos temporários e chaves no regi stro do
sistema operacional : utilizando alguns tipos de aplicações que
monitoram o registro e o sistema de arquivos, podemos verificar todas as
chaves e arquivos acessados pelo sistema e tentar obter informações
através destes.
h) Exploração de portas do servidor : em casos de ambiente
cliente/servidor ou em n-camadas, usar um sistema de verificação de
segurança em portas.
i) Comportamento de comunicação : tentar quebrar a integridade da trilha
de auditoria.
j) Interceptação de comunicação : verificar, com um sniffer5 ou analisador
de trafego, se é possível ler a comunicação entre cliente e servidor. Ou
tentar assumir o papel do servidor para verificar se o cliente aceita
servidores falsos.
A análise e avaliação de vulnerabilidades são tratadas no Commom Criteria
(ISO 15.408) pela atributo AVA, a qual contempla a existência de ameaças passiveis
de exploração, a possibilidade de um mau uso da aplicação ou de sua configuração
incorreta, a possibilidade dos mecanismos de segurança falharem quando expostos
à força e a exploração de quaisquer vulnerabilidades que possam ser introduzidas
durante o desenvolvimento ou a operação do sistema.
Comenta Albuquerque (2002) que a análise de vulnerabilidades é um tipo de
avaliação que objetiva determinar se as vulnerabilidades identificadas durante
qualquer período do ciclo de vida do sistema ou outra avaliação podem ser
exploradas pelos usuários para violar políticas organizacionais de segurança.
Esse tipo de análise trata da ameaça do usuário descobrir falhas no sistema,
acessando recursos de maneira não-autorizada, alterando configurações de
segurança ou prejudicando outros usuários.
5 Um sniffer é um software capaz de monitorar toda a atividade da rede do computador e capturar dados e informações sobre o uso da rede (DIAS, 2000).
55
5.2 SEGURANÇA DE APLICAÇÕES WEB
Aplicação Web é o termo utilizado para designar, de forma geral, sistemas
de informática projetados para utilização através de um navegador, na internet ou
em redes privadas (SCAMBRAY, 2002).
Os softwares desenvolvidos na arquitetura cliente-servidor em ambientes
web utilizam o protocolo http (HyperText Transfer Protocol), e utilizam um navegador
como cliente. Essas aplicações estão divididas, normalmente, em duas camadas de
aplicação: a de apresentação e a de dados e armazenamento.
Segundo Torres (2003), a arquitetura web é considerada diferente das
demais arquiteturas conhecidas, porque difere justamente no controle de segurança.
Assim, uma aplicação web construída de forma tradicional pode até fazer funcionar,
porém para o contexto da Web, isso pode não ser o suficiente. Um desenvolvedor
web não especializado, que não adota boas práticas de engenharia web, pode
construir uma aplicação sem considerar a escalabilidade, sacrificando servidores,
além de não considerar aspectos de segurança, propiciando “brechas” no código,
acarretando invasões, por exemplo.
A seguir, algumas sugestões para melhorar questões de vulnerabilidade em
sistemas desenvolvidos para a Web.
5.2.1 Aspectos gerais de segurança para desenvolver sistemas para Web
As dicas aqui apresentadas é uma compilação dos autores DIAS(2000),
ALBUQUERQUE (2002), SHEMA(2003) e TORRES(2003).
Sempre critique os parâmetros de uma requisição GET ou POST, mesmo
que eles já tenham sido criticados por código JavaScript no navegador, ou seja
“impossível” ao usuário digitar um valor errado (um elemento <select>, por exemplo);
Estabeleça tamanhos máximos para todos os dados recebidos. Garanta que
qualquer arquivo de dados utilizado por uma página esteja fora da árvore de
documentos acessível ao navegador;
Toda informação textual deve ser quotada antes de ser concatenada ou
armazenada em outro meio, para garantir que nenhum símbolo seja interpretado
56
como tendo significado especial pela linguagem de script, banco de dados ou pelo
navegador do usuário;
Sempre imponha limites obrigatórios ao uso de recursos (memória,
processador, espaço em disco, largura de banda) para todas as páginas.
Garanta que páginas capazes de modificar informações só possam ser
acessadas por meio de requisições POST;
Nunca deixe informações de autenticação no navegador, seja em cookies ou
em campos escondidos; utilize um tipo de identificador de sessão (a session id) não
reutilizável e não seqüencial para indexar esta informação dentro do servidor web;
Não dependa do controle de acesso a páginas (URLs) pelo servidor web
para autorizar o acesso a informações por uma página;
Nunca confie que o identificador (chave) recebido em uma requisição
represente um registro autorizado ao usuário; refaça este tipo de verificação em
todas as páginas;
Não utilize a mesma senha de acesso à aplicação para outras conexões de
rede, por exemplo, a um banco de dados;
Utilize os privilégios mínimos em todas as operações, em especial não rode
aplicações e servidores com logins de sistema ou administrador, e não acesse um
banco com papel de administrador de banco de dados.
Não reinvente a roda – uma biblioteca de larga utilização tem mais chances
de ter falhas (bugs) identificados e corrigidos do que o código criado internamente
em sua empresa.
Nas sub-seções que se seguem, várias ocorrências de vulnerabilidades são
discutidas.
5.2.2 SQL Injections
SQL (Structured Query Language) é uma linguagem criada para
manipulação de banco de dados permitindo a execução de consultas, obtenção de
dados, inserção de novos, remoção e exclusão de registros de dados. Apesar de ser
uma linguagem padronizada, ainda assim vários comandos específicos são
introduzidos para atender uma tecnologia de banco de dados. Alguns gerenciadores
57
também possibilitam a interação com o sistema operacional, permitindo a execução
de programas utilizando somente SQL.
Segundo Torres (2003), SQL Inject é nome que se dá à alteração da
instrução SQL utilizada por uma aplicação através da inserção de caracteres
indevidos na entrada de dados da aplicação.
Hoje em dia é uma prática comum os sites pedirem um cadastro do visitante,
e criar-lhe um login, dando acesso a áreas restritas e especiais do site. Cadastro
esse que na maioria das vezes é gratuito, com a intenção apenas de fidelizar o
usuário e, claro, ter mais um e-mail para uma possível divulgação, que neste caso
não se caracteriza spam6, pois o devido usuário previamente aceitou informações
vindas daquele site. Em sites onde o cadastro é pago, aí a coisa muda de figura. O
site imagina estar vendendo alguma informação ao visitante, e por isso, pode pedir
alguns dados sigilosos do usuário e guardá-los seguramente no seu banco de
dados. Em ambos os casos a aplicação pode estar vulnerável a uma das falhas de
segurança muito utilizada hoje em dia, o SQL Inject.
Um ataque baseado em injeção em SQL (SQL injection attack) é uma
técnica que se aproveita da falta de filtragem das informações de entrada em
sistemas que geram comandos SQL para manipular conjuntos de dados.
Tipicamente, estas informações de entrada são oriundas dos próprios usuários finais
do sistema. Usuários maliciosos podem então se aproveitar da falta de tratamento
de entradas e inserir strings que geram, por sua vez, comandos SQL de caráter
nocivo à camada de dados da aplicação.
A falha provocada por SQL inject pode ocorrer através de diversos pontos de
entrada: caixas comuns de entrada de dados, transmissões de dados via GET e
distorções da origem de dados. Essas informações são enviadas para construção de
queries e interações com o banco de dados e não são devidamente validadas e
checadas quando recebidas e tratadas pela aplicação/site ou pelo banco de dados.
SQL INJECTIONS NA PRÁTICA
Para ilustrar o funcionamento de um SQL injection, será mostrado um
exemplo de mecanismo de autenticação baseado em formulários que utiliza SQL
6 Spam é uma mensagem eletrônica não-solicitada enviada em massa (DIAS,2000).
58
para a verificação das credenciais. Após a entrada de dados do usuário, a aplicação,
que neste exemplo é escrita em JSP (Java Servet Pages), efetua a operação de
acordo com a instrução abaixo:
String sql = "SELECT * FROM usuarios WHERE login = ’" + formusr +
"’ AND password = ’" + formpwd + "’";
Esta operação, junto com os dados passados pelo usuário, resulta no
seguinte comando SQL.
SELECT * FROM usuarios WHERE login = ’foobar’ AND password = ’foobar123’;
Caso o sistema de banco de dados retorne uma tupla (linha), a aplicação
entende que a autenticação ocorreu com sucesso, caso contrário, um erro de
registro não encontrado é retornado a aplicação, e esta rejeita o acesso.
Em um sistema projetado e implementado visando a segurança, deveriam
ser validadas as entradas de usuário e senha, permitindo somente caracteres
válidos. Estes caracteres válidos são os que podem estar contidos nas respectivas
strings.
A Tabela 7 ilustra os caracteres mais utilizados para realizar injeções.
Tabela 7 - Caracteres mais utilizados
59
Esta preocupação se deve ao fato que usuários mal intencionados podem
preparar as strings de login e password de tal forma que operações ilícitas sejam
efetuadas, utilizando recursos da própria linguagem SQL.
Ou seja, o usuário através do que digitou nas caixas de entrada de dados,
conforme figura 10, conseguiu alterar o significado da instrução SQL da aplicação.
No exemplo mostrado, o usuário informou ‘ OR ’1’=’ 1 nas duas caixas, de login e
senha. Veja como ficaria o resultado da concatenação:
SELECT *FROM login where login=’ OR ‘1’=’1’ and senha=’OR’1’=1
Neste exemplo o significado da instrução SQL foi totalmente alterado.
Estará sendo feito a busca de login e senha vazios ou ‘1’=’1’. Como sempre 1 é igual
a 1, todos os registros serão retornado e o algoritmo da aplicação se verá a frente de
uma situação totalmente inesperada, permitindo o acesso ao usuário.
Figura 10 – Exemplo de SQL Inject (Quebra da autenticação)
60
5.2.3 Cross-site Scripting
O cross-site scripting é comumente chamado de XSS ou CSS. Consiste na
reprodução de informações de um cliente quando a origem desses dados pode ser
uma fonte mal intencionada. Um usuário mal intencionado pode enviar determinadas
informações para sites web com páginas dinâmicas, que quando forem acessadas
por uma aplicação cliente, como o navegador Web, este executa operações ilícitas.
Segundo Torres (2003), esse tipo de invasão, também causado por falha de
programação, não é tão prejudicial ao site como o SQL INJECTION, mas pode
causar prejuízos indiretos, como danos a imagem de um site.
Esta invasão consiste na possibilidade de o usuário digitar, nos campos de
entrada de dados normais da página, scripts HTML e/ou Java Script sem validá-los.
Um exemplo típico deste problema seria a inserção de imagens ou texto
depreciativos em sites de organizações governamentais e oficiais, acarretando
sérios danos a imagem do site.
Outro exemplo seria no envio de um formulário de e-mail, em que no campo
comentário, o usuário ao invés de digitar sua mensagem, introduz códigos em script,
o qual levaria o usuário a um outro destino, conforme é visto na Figura 11,
modificando o fluxo normal da navegação.
Figura 11 – Exemplo de Cross-site Scripting
61
As conseqüências podem ir muito além de simplesmente disparar uma janela
pop-up7. Com a ajuda do XSS é possível seqüestrar uma sessão Web de um
usuário já autenticado em um web site. O invasor pode injetar um código em um
Web site que quando for acessado, ele envia informações sobre o cookies de
determinada sessão para o e-mail do invasor ou submete-as via CGI (Common
Gateway Interface)8. Depois de conseguir as informações do cookies, o invasor
pode montar manualmente o seu conteúdo e driblar o mecanismo de autenticação.
A idéia inicial para correção para vulnerabilidade do XSS seria impedir que
determinados símbolos que devam marcar instruções de scripting, tal como os sinais
de maior e menor e as aspas, sejam digitadas pelo usuário. Porém, estes símbolos
podem ser digitados pelo usuário não apenas quando ele estiver tentando invadir o
site, mas eventualmente em um texto comum. Se isso acontecer, será desagradável
se sua validação estiver impendido a entrada do texto que o usuário precisa digitar.
Desta forma a validação não deve ser feita na entrada dos dados, mas sim na saída,
passando por um tratamento de segurança.
As vulnerabilidades de XSS podem ser difíceis para identificar e remover de
uma aplicação web. A melhor maneira é realizar revisões de segurança no código e
procurar por todos os lugares onde a entrada de uma requisição HTTP pode seguir
possivelmente para uma saída HTML.
5.2.4 Controle de Acesso Falho
Nessa vulnerabilidade, restrições sobre o que usuários autenticados podem
ou não realizar não são propriamente definidas. Isto possibilita aos atacantes
(agentes) explorar ou acessar contas de outros usuários, visualizar arquivos, ou
mesmo se utilizar de funções não autorizadas previamente ao seu perfil.
Para encontrar esse tipo de vulnerabilidade durante a revisão de código,
pode-se procurar por funções que realizam operações de entrada e saída nos
arquivos para verificar a confiabilidade, não colisão de nomes, localização em que o
7 O pop-up é uma janela normalmente indesejada, na maioria das vezes usado na web como meio de exibir uma propaganda em uma janela diferente com o propósito de chamar a atenção do usuário (DIAS,2000). 8 CGI (Common Gateway Interface) é uma tecnologia que permite gerar páginas dinâmicas permitindo a um navegador passar parâmetros para um programa alojado num servidor web(TORRES,2003).
62
arquivo será criado no sistema de arquivos e se existe uma maneira do nome do
arquivo ser manipulado por indivíduos maliciosos de forma a apontar para um
arquivo que o intruso não deveria acessar.
Para evitar esse problema, todos os arquivos de uma determinada aplicação
devem ser mantidos em locais seguros, sem acessos e permissões de escrita,
leitura e execução desnecessários por quem não é de direito.
A seguir apresentamos alguns exemplos de controle de acesso falho:
a) http://www.site.com.br/admin/modulox (?);
b) http://www.site.com.br/admin/moduloy/action.asp (?);
c) http://www.site.com.br/adm/pegar_arquivo.cfm?arquivo=../../../winnt/syste
m32/certmgr.reg ;
d) http://www.site.com.br/adm/upload_arquivo.cfm?arquivo=iislog_safado.dll
&destino=../../../winnt/system32/inetserv/isslog.dll.
Além disso, deve-se restringir quais nomes de arquivos serão aceitos como
válidos, não aceitar que um nome de arquivo, por padrão, represente um arquivo
válido e considerar o armazenamento de arquivos temporários em um diretório
temporário pertencente a um usuário, fazendo com que seja mais fácil executar a
aplicação no privilégio mínimo.
5.2.5 Falha no Tratamento de Erros
Esse tipo de falha trata de condições de erro que ocorrem durante a operação
normal e que não são tratadas apropriadamente. Se um atacante (agente) puder
causar erros os quais a aplicação não saiba tratar, é possível obter informações
detalhadas do sistema, indisponibilizar serviços, causar falhas em mecanismos de
segurança ou tornar o servidor inoperante.
O tratamento de condições de erro em um programa deve ser
cuidadosamente pensado e implementado, já que a falha em lidar com qualquer erro
pode fazer com que o programa termine em uma condição insegura. E quando
ocorrer um erro, este deve estar previsto e a mensagem de erro deve ser controlada
63
pela aplicação. Esta vulnerabilidade pode se apresentar de várias maneiras, dentre
as quais:
a) Disponibilização de informação em demasia;
b) Ignorar erros;
c) Má interpretação dos erros;
d) Utilização de valores de erros inúteis;
e) Tratamento das exceções erradas.
Figura 12 – Exemplo de falha no tratamento de erros
Outro exemplo desse tipo erro é mostrado na figura 12, em que o excesso de
informações (ou o não tratamento do erro) poderá ser utilizado para uma possível
invasão.
64
5.2.6 Command Injections/ Parâmetros Inválidos
A vulnerabilidade de command injection ou injeção de comando consiste da
não verificação dos valores de entrada nos programas, gerando, assim, situações
inesperadas como execução de programas indevidos, roubo de sessão, dentre
outras. A entrada de dados em um programa pode ser realizada de inúmeras
maneiras. Dentre elas, por parâmetros de execução do programa, leitura de teclado,
leitura de arquivos, através de comunicação interprocessos e via sockets9. Para
cada entrada deve haver uma validação específica, o que se costuma chamar de
input validation ou validação de entrada.
Comandos do sistema operacional também podem ser executados através
das aplicações dependendo da forma como elas foram construídas. Estes comandos
podem ser injetados através dos campos visíveis ou ocultos de um formulário junto
com os valores de entrada.
Como um dos objetivos de um invasor é obter acesso ao sistema
operacional da aplicação atacada, este artifício é comumente utilizado. Este
problema acontece tipicamente em aplicações CGI escritas de maneira insegura.
Para se evitar o Command Injection pode se tomar as seguintes
precauções/ verificações:
a) Deve-se realizar validação de entrada em todas as entradas antes de
passá-las para o interpretador de comandos;
b) É necessário que as falhas sejam tratadas de forma segura, bem como
sejam tratados os erros de checagem de validação de entradas;
c) Não se deve, de forma alguma, permitir que dados não validados sejam
passados como entrada para um interpretador de comandos.
A seguir, alguns exemplos desse tipo de vulnerabilidade, em que usuários
maliciosos podem alterar os parâmetros passados para a aplicação, refletindo na
integridade dos dados e na autenticidade do usuário, visto que no primeiro exemplo
o usuário pode manipular o atributo “valor”, e no segundo caso, o usuário burla o
mecanismo de autenticação, não alegando quem ele possa de fato ser.
9 Sockets é a combinação de um endereço IP, um protocolo e uma porta.
65
Ex1:
• http://www.site.com.br/cesta/fecha_pedido.php?IDproduto=12&valor=776
Ex2:
• Cookie: lang=pt-br; ADMIN=no; y=1; time=10:30GMT Cookie: lang=pt-br;
ADMIN=yes; y=1 ; time=12:30GMT
5.2.7 Uso de URLs “mágicas” e campos de formulário oc ultos
As denominadas URLs “mágicas” tratam-se de URLs que contêm
informações sensíveis incluídas, como por exemplo, senhas de acesso codificadas
com algoritmos inadequados. Se a URL em questão é utilizada para autenticar
usuários, o risco de algum incidente de segurança ocorrer é alto.
Já os campos de formulário ocultos são definidos por um campo, no qual
dados potencialmente importantes são passados ao cliente em um formulário que se
espera que o cliente não o veja, nem o manipule.
Entretanto, usuários maliciosos podem subverter o sistema, visualizando o
código fonte da página apresentada e enviando a versão modificada.
Portanto, devemos seguir algumas recomendações que ajudam no
tratamento desse tipo de falha.
a) Deve-se testar todas as entradas e formulários via web com entradas
maliciosas;
b) Não se deve armazenar dados confidenciais em qualquer construção
HTML ou HTTP, tais como URL, cookie ou formulário, se o canal não for
criptografado (SSL, TLS, IPSec) ou não utilizar criptografia no nível da
aplicação;
c) Não se deve confiar em dados provenientes de um formulário web, dado
que indivíduos maliciosos podem modificá-los facilmente, mesmo com o
uso de SSL;
d) Não se deve assumir que a utilização de criptografia torna o sistema
seguro, pois existem outras formas de se atacar um sistema.
66
5.2.8 Buffer Overflows
Buffer overflow ou extravazamento de buffer é a vulnerabilidade mais
comum presente nos programas. Ela, geralmente, ocorre quando um número de
dados maior do que o suportado é escrito em um buffer10. Esta vulnerabilidade
pode ocorrer devida a falta de cuidados com os índices dos buffers em loops. Um
buffer overflow também pode ocorrer quando o caracter ’\0’ não estiver presente no
buffer ou quando ocorrer algum erro de aritmética de ponteiros ou índices dos
buffers.
Os buffers podem ser estáticos ou dinâmicos. Os estáticos são alocados
quando o programa é carregado, loadtime, já os dinâmicos são alocados em tempo
de execução.
Figura 13 – Exemplo de Buffer overflow
10 Um buffer é uma área de memória contiguamente alocada que suporta inúmeras instâncias de um
mesmo tipo de dado, como as cadeias de caracteres.
67
Esta vulnerabilidade ocorre quando dados são lidos e/ou armazenados fora
dos limites alocados para o buffer, conforme figura 13. Além disso, em algumas
linguagens como C e C++ não existem checagens automáticas de limites de um
buffer, o que significa que existe a possibilidade de que um buffer seja extravazado.
Segundo Dias (2000) buffer overflow depende do servidor de aplicação e
continua sendo a principal vulnerabilidade explorada em um software. Essa
fragilidade pode ser evitada ou minimizada com o auxilio de filtragem de dados
inseridos pelo formulário.
68
6 ESTUDO DE CASO
Neste capitulo mostraremos as vulnerabilidades encontradas no Ambiente
de Ensino a Distância da UNAMA, o Aprendiz. Segundo Portilho, Marcelo e Silva,
Marco Antonio (2005), o Aprendiz é uma aplicação WEB desenvolvida na linguagem
de programação JAVA, utilizando várias soluções de software livre, como o
framework STRUTS, o banco de dados MYSQL, e o conteiner web TOMCAT. Ao
final, apresentaremos algumas sugestões para as correções das falhas detectadas,
que possibilitarão minimizar os riscos de ameaças futuras.
6.1 DESCRIÇÃO DO SISTEMA
A aplicação que será usada como exemplo é uma demonstração de um
típico sistema web. Na Figura 1, é ilustrada a estrutura do sistema Aprendiz, em
forma de um diagrama de contexto do sistema, enfatizando as visões e as
dependências de uso entre os atores que dele participam. A modelagem de atores
ilustra a classificação de generalização e especialização de atores do sistema e a
dependência do sistema Aprendiz com um ator, caracterizado por um sistema
externo ao contexto, chamado “SistemaAcadêmicoUnama”. O Sistema Acadêmico
fornece informações ao Aprendiz como cadastro de aluno, disciplinas dos cursos,
entre outras. Uma das tarefas comuns às visões e uso do sistema pelo atores, está
relacionada a identificação, via login e senha, para acesso ao Aprendiz. A
autenticação de acesso para os usuários determina a visão que cada um deve ter,
considerando o perfil do usuário.
69
Figura 14 – Visões de uso do sistema Aprendiz
6.2 VULNERABILIDADES VERIFICADAS NO APRENDIZ
O estudo constatou a existência de algumas vulnerabilidades no sistema de
aprendizado on-line da UNAMA, o Aprendiz, as quais, serão discutidas e
apresentadas possíveis soluções nas sub-seções que se seguem.
6.2.1 Vazamento de Informações
O sistema apresenta vazamento de informações, quando do acesso da
função “Conheça o Aprendiz”, tendo em vista que está sendo apresentada
informações detalhadas do ambiente em que a aplicação está rodando, banco dados
utilizado (MySQL) e informações do servidor web. Essas informações permitem que
um possível agente (atacante), de posse delas, procure coletar tantas informações
quanto possível sobre o seu alvo, ganhando em seguida facilidades na busca de
exploit ou procurar por vulnerabilidades existentes no ambiente em que a aplicação
está disponível.
70
Há vazamento de informações também quando a aplicação disponibiliza
mensagens de erro do tipo: “senha inválida!” ou “Usuário (MATRÍCULA) inexistente
no sistema (solicite cadastramento)!”, conforme figuras 15 e 16, respectivamente,
durante uma tentativa de acesso a aplicação.
Figura 15 – Mensagem de erro
Figura 16 – Mensagem de erro
O Commom Criteria (ISO/IEC 15.408) recomenda a aplicação da família
FIA_UAU (autenticação do usuário), nível FIA_UAU.7 (resposta restrita da
autenticação), para o tratamento das mensagens de retorno da aplicação. Onde
sugere que para a segurança da aplicação devem fornecer apenas mensagens do
tipo:
a) Usuário ou senha inválidas.
b) Falha interna do mecanismo de autenticação.
A restrição a apenas essas mensagens evita que o eventual atacante do
sistema saiba, por exemplo, que determinado usuário é válido, e apenas a senha
71
está errada, ou, ainda, que a retirada de uma ou mais formas de comunicação com
servidores impede ou dificulta a autenticação.
6.2.2 Tratamento de Falhas de Autenticação
As funções de segurança da aplicação não possuem mecanismos que
predeterminam o número máximo de tentativas de acesso ao sistema sem sucesso,
para fins de bloqueio da conta do usuário. Simplesmente, a aplicação permite que o
usuário tente acessar o sistema realizando o método da força bruta.
O Commom Criteria (ISO/IEC 15.408) recomenda a aplicação do atributo
FIA_AFL.1 (tratamento de falhas de autenticação), que define a política de
tratamento para tentativas falhas de autenticação sucessivas. Ressalta, essa norma,
que um mecanismo simples de quebra de autenticação é através de tentativa e erro.
A norma sugere que se tenha um gerenciamento do número máximo de tentativas
falhas e o gerenciamento da ação a ser tomada quando o número de tentativas
exceder o máximo.
6.2.3 Definição de atributos do Usuário para Autent icação
No processo de autenticação, as funções de segurança da aplicação
mantém armazenados somente os atributos: identificação do usuário, tipo de usuário
e os dados para autenticação.
O Commom Criteria (ISO/IEC 15408) recomenda a aplicação do atributo
FIA_ATD.1 (definição de atributos de autenticação) para deixar claro na
especificação do sistema as informações que precisam ser mantidas. A norma
recomenda que alem dos atributos acima, sejam armazenados também os seguintes
atributos: prazo de validade dos dados para autenticação; prazo a partir do qual se
deve alertar o usuário sobre a necessidade de renovação dos dados de
autenticação; indicação de conta bloqueada, e data e hora para liberação de conta
bloqueada.
72
6.2.4 Métricas mínimas das Senhas
Quanto à métrica mínima das senhas, as funções de segurança da aplicação
Aprendiz não possuem mecanismo que predefinam tamanho mínimo das senhas
válidas, conforme é mostrado no código da Figura 17. A aplicação aceita senhas de
até no máximo 20 (vinte) caracteres, não há especificação quanto a necessidade de
mesclagem entre caracteres alfabéticos e numéricos para composição da senha.
O Commom Criteria (ISO/IEC 15.408) recomenda a aplicação do atributo
FIA_SOS.1 (métrica mínima das senhas) o qual define a métrica mínima de senhas.
Figura 17 - Tamanho mínimo das senhas não implementado
6.2.5 Limitação do número de Seções Simultâneas
Quanto o número de acessos simultâneos por um mesmo usuário, as
funções de segurança da aplicação não possuem mecanismos que permitam
gerenciar o número máximo de conexões concorrentes. Está sendo permitido o
acesso concorrente de um mesmo usuário. O Commom Criteria (ISO/IEC 15408)
recomenda a aplicação do atributo FTA_MCS.1 (limitação básica do número de
seções) e o FTA_MCS.2 (limitação básica do número de sessões por usuário) para o
gerenciamento do número máximo de conexões simultâneas e das regras que
definem o número máximo de conexões simultâneas para um usuário.
73
6.2.6 Cross-site scripting
O sistema apresenta vulnerabilidade nos módulos do “FÓRUM“ e no
“CORREIO ELETRÔNICO”. No correio eletrônico e no fórum está sendo possível
encaminhar mensagens de scripts, os quais são exibidos ao destinatário através de
simples janelas de pop-up, conforme figura 18. Todavia, a preocupação deve ser
maior, pois um usuário malicioso, com maiores conhecimento da área, pode até
mesmo realizar um seqüestro de sessão de um determinado usuário autenticado.
Figura 18 – Exemplo de CSS
Uma possível solução seria realizar a validação dos dados de entrada no
momento da saída, tendo em vista que seu tratamento na entrada poderá inibir o
usuário de utilizar os caracteres de sinais maior e menor e aspas, caracteres
essenciais para a criação das tags.
6.2.7 SQL Injetions
No sistema Aprendiz foi possível detectar duas vulnerabilidades a injeção de
comandos SQL. Uma no módulo de “Autenticação”, onde estava sendo possível
burlar o mecanismo de autenticação, permitindo o acesso não autorizado ao
sistema, bem como, permitir a interação dos comandos SQL diretamente com o
74
banco de dados, sendo passivo de alteração na integridade da informação. Devido a
gravidade do assunto, esta falha já foi corrigida tempestivamente.
A outra está presente no módulo de “ALTERAÇÃO DE SENHA”, onde é
possível a injeção de comandos SQL arbitrários.
A correção da falha existente poderá ser efetuada através do tratamento dos
dados de entrada por parte da aplicação permitindo somente a entrada de
caracteres válidos. Também, tratando o tamanho dos campos de entrada, com vista
a não permanecerem longos, em relação aos dados a serem recebidos de fato pela
aplicação, pois caso ocorra, facilitam a construção de querys complexas.
6.2.8 Controle de Acesso Falho
O sistema apresenta controle de acesso falho, pois possibilita que usuários
não autenticados visualizem informações que não são disponibilizadas a seu perfil,
fragilizando a confidencialidade da informação. O sistema possibilita que usuários
visualizem arquivos disponibilizados pelos professores para downloads, mesmo sem
estarem autenticados na aplicação, basta que o aluno copie a URL referente ao
material e depois acesse o conteúdo.
Outra falha detectada, mas já corrigida, era referente a listagem de diretórios
da aplicação, possibilitando que o usuário tivesse acesso irrestrito a todo conteúdo
disponibilizado pelo sistema. A correção foi realizada em nível de rede e
configurando o servidor web (Tomcat, no caso).
Esta vulnerabilidade pode ser corrigida mantendo os arquivos da aplicação
em locais seguros, sem acessos e permissões de escrita, leitura e execução por
quem não é de direito.
6.2.9 Controle de Sessão
Verificamos que o controle de sessão não se encontra desenvolvido em
todos os seus níveis. Não há controle de sessão no módulo “PRINCIPAL”, existindo
somente no sub-módulo “DISCIPLINA”, cujo sistema de segurança deste sub-
módulo encerra totalmente a aplicação, após um período de inatividade,
redirecionando o usuário para uma nova chamada ao sistema.
75
O Commom Criteria (ISO/IEC 15408) define o travamento de sessão através
de três itens independentes: FTA_SSL.1 (travamento automático da sessão) que
indica os mecanismos nos quais o próprio sistema provoca o travamento da sessão
devido a um grande período de inatividade; FTA_SSL.2 (travamento por requisição
do usuário) que indica formas para o usuário solicitar o travamento e, finalmente, o
FTA_SSL.3 (encerramento automático da sessão) que indica que o sistema deve
encerrar a sessão interativa após um período de inatividade.
Diante da norma, sugerimos que após o período de inatividade o sistema
redirecione o usuário para se reautenticar e permanecer no mesmo local onde houve
o estouro da sessão, bem como, sugerimos também que sejam desenvolvidos os
outros métodos propostos pela Commom Criteria.
6.3 CONSIDERAÇÕES FINAIS
Na tabela 8, apresentamos a síntese das vulnerabilidades detectadas no
ambiente de aprendizado on-line da UNAMA, o Aprendiz, sua relação com a
ISO/IEC 15.408 e as possíveis soluções para correção das falhas detectadas.
76
Tabela 8 - Resumo das vulnerabilidades e possíveis soluções
Vulnerabilidade Funcionalidade
verificada
Atributo de
acordo com a
ISO/IEC 15.408
Comentário em relação a ISO/IEC 15.408 Solução prop osta
Vazamento de
informações
Conheço o
Aprendiz
/autenticação
FIA_UAU.7 - A norma recomenda que seja realizado o
tratamento das mensagens de retorno
- Apresentar mensagens
do tipo: “usuário ou senha
invalida” ou “falha interna
no mecanismo de
autenticação”.
Tratamento de falha de
autenticação
Autenticação FIA_AFL.1 - A norma recomenda que se tenha um
gerenciamento do número máximo de
tentativas falhas e o gerenciamento da ação
a ser tomada quando o número de
tentativas exceder o máximo.
- Aplicação da norma
Definição de atributos
do usuário para
autenticação
Autenticação FIA_ATD.1 - A norma recomenda que sejam
armazenados os atributos: identificação do
usuário, tipo de usuário, dados para a
autenticação, prazo de validade dos dados,
prazo para alterar a renovação dos dados
para autenticação, indicação de conta
bloqueada e data e hora de liberação da
conta bloqueada.
- Complementar os dados,
pois a aplicação somente
retêm informações da
identificação do usuário,
tipo de usuário, dados
para autenticação.
76
77
Vulnerabilidade Funcionalidade
verificada
Atributo de
acordo com a
ISO/IEC 15.408
Comentário em relação a ISO/IEC 15.408 Solução prop osta
Métricas mínimas das
senhas
Redefinir senha FIA_SOS.1 - A norma recomenda que seja estipulado
um tamanho mínimo de caracteres para
composição da senha.
- Aplicação da norma, pois
o sistema não possui
mecanismo que
predefinam o tamanho
mínimo das senhas
válidas.
Limitação do número de
sessões simultâneas
Aplicação FTA_MCS.1 e
FTA_MCS.2
- A norma recomenda que seja realizado o
gerenciamento do número máximo de
conexões simultâneas e do número máximo
de conexões simultâneas para um mesmo
usuário.
- Aplicação da norma
Cross-site scripting Fórum e correio
eletrônico
- - - realizar validação dos
dados de entrada no
momento da saída, pois
seu tratamento na entrada
poderá inibir o usuário de
utilizar os caracteres de
sinais maior e menor e
aspas.
SQL Injections Autenticação/Alte
ração de senha
- - - a correção da falha
poderá ser efetuada
77
78
Vulnerabilidade Funcionalidade
verificada
Atributo de
acordo com a
ISO/IEC 15.408
Comentário em relação a ISO/IEC 15.408 Solução prop osta
através do tratamento dos
dados por parte da
aplicação, permitindo
somente a entrada de
caracteres válidos.
Controle de acesso
falho
Aplicação/downlo
ads de arquivos
- - - a vulnerabilidade pode
ser corrigida mantendo os
arquivos em locais
seguros, sem acesso e
permissões de escrita,
leitura e execução por
quem não é de direito.
Controle de sessão Principal/
Disciplina
FTA_SSL.1
FTA_SSL.2
FTA_SSL.3
- a norma recomenda o travamento
automático da sessão; o travamento por
requisição do usuário e o encerramento
automático da sessão.
- Sugerimos que após o
período de inatividade o
sistema redirecione o
usuário para se
reautenticar e permaneça
no mesmo local onde
houve o estouro da
sessão;
- sejam desenvolvidos os
78
79
Vulnerabilidade Funcionalidade
verificada
Atributo de
acordo com a
ISO/IEC 15.408
Comentário em relação a ISO/IEC 15.408 Solução prop osta
outros métodos pela
norma.
79
80
7 CONSIDERAÇÕES FINAIS E CONTRIBUIÇÃO
Este trabalho apresentou os principais aspectos de segurança, identificou
políticas e planos de segurança, levantou e analisou riscos, ameaças e os principais
meios para que se desenvolvam sistemas mais seguros.
Durante o estudo de caso foi verificado algumas vulnerabilidades no ambiente
de aprendizado on-line da UNAMA, o Aprendiz, em que alguns requisitos estão em
desacordo com as normas sugeridas pela ISO/IEC 15.408 ou com as boas praticas de
programação. Logo, propomos ao fim de cada sub-sessão possíveis correções das
vulnerabilidades encontradas.
Este trabalho contribui com os seguintes pontos;
a) Define aspectos gerais de segurança;
b) Ratifica a importância da segurança no desenvolvimento de aplicações;
c) Apresenta fatores importantes para construção de aplicações seguras;
d) Discorre sobre normas e padrões dirigidas à segurança da informação, em
especial à ISO/IEC 15.408;
e) Identifica algumas vulnerabilidades (e propões soluções) em uma aplicação
web real, no caso o ambiente de educação a distância da UNAMA, o
Aprendiz;
7.1 Perspectivas futuras
Como perspectiva mais imediata, a abordagem deste trabalho pretende apoiar
aqueles que desejam aperfeiçoar processos de desenvolvimento de produtos com
maior segurança.
Diversos trabalhos podem ser definidos e desenvolvidos com o propósito de
melhorar e estender a proposta apresentada, por exemplo:
a) Formulação de padrões de desenvolvimento que suportem, se não todos,
alguns dos requisitos de segurança citados;
81
b) Criação de documentos para gerência de desenvolvimento de softwares
aderentes à norma ISO/IEC 15.408;
c) Elaboração de conteúdo pedagógico para capacitação de recursos humanos
(desenvolvedores e engenheiros de software) em segurança da informação;
Outros trabalhos também podem ser realizados para apoiar as atividades que
sucintamente foram mencionadas e outras que não foram abordadas nesse trabalho,
por exemplo:
a) Fatores econômicos, como meios de viabilizar a integração da engenharia de
software e segurança da informação;
b) Avaliação de impactos (positivos e negativos) na adoção da norma ISO/IEC
15.408 em um processo de desenvolvimento de sistemas para a web;
c) Contribuições de outros padrões, como COBIT, podem oferecer ao
desenvolvimento de aplicações.
82
BIBLIOGRAFIA
ALBUQUERQUE, R; RIBEIRO, B. Segurança no Desenvolvimento de Software, Editora
Campus, 2002.
DIAS, CLAÚDIA. Segurança e Auditória da Tecnologia da Informação, Editora Axcel
Books do Brasil,2000.
TORRES, DENNIS. Segurança Máxima de Software: como desenvolver soluções
seguras / DENNES TORRES. – Rio de Janeiro: Brasport, 2003
DAVIS, A. Softwtare Architecture: Objects, Functions and States, Prentice-Hall, 1993.
RUFINO, N. M. O. Segurança Nacional - Técnicas e Ferramentas de Ataque e Defesa
de Redes de Computadores, Novatec Editora, 2002.
SOARES, L. F. G.; LEMOS, G.; COLCHER, S. Redes de Computadores - Das Lans,
Mans e Wans às Redes ATM, Editora Campus, 1995.
THAYLER, R.; DORFMAN, M. System and Software Requirements Engineering, IEEE
Computer Society Press, 1990.
Portilho, Marcelo Silva e Balieiro, Marco Antonio da Silva. Técnicas de modelagem,
Frameworks e padrões de projeto em Sistemas de educação à distância, Trabalho de
Conclusão de Curso (Grauduação) - Bacharelado em Ciência da Computaçao,
Unviersidade da Amazônia - UNAMA, 2005.
ISO JTC 1/SC 27 Commitee ISO/IEC 15408-1:1999 Information Technology – Security
Techniques - Evaluation Criteria for IT Security - Part 3: Security Assurance
Requirements, ISO Online Catalogue, 1999.
83
G. Hoglund end G. MacGraw, exploiting software: How to break code. Addison Wesley,
2004.
Shema, Mike . Hack Notes - Segurança Na Web, Editora Campus, 2003.
SCAMBRAY, JOEL Hackers Expostos - Segredos e Soluções para Segurança de
Redes, Editora Makron Books, 2002.