Software Seguro

UNIVERSIDADE DO SUL DE SANTA CATARINA
ALEXANDRE PEREIRA PRAZERES
PRINCPIOS PARA O DESENVOLVIMENTO DE SOFTWARE SEGURO
Florianpolis
2015
1
Monografia apresentada ao Curso de

Especializao em Engenharia de Projetos de
Software da Universidade do Sul de Santa
Catarina, como requisito obteno do ttulo
de Especialista em Engenharia de Projetos de
Software.
Orientadora: Prof. Vera Rejane Niedersberg Schuhmacher, Dra.
Florianpolis
2015
2
Esta Monografia foi julgada adequada

obteno do Ttulo de Especialista em
Engenharia de Projetos de Software e aprovada
em sua forma final pelo Curso de
Especializao em Engenharia de Projeto de
Software da Universidade do Sul de Santa
Catarina.
Florianpolis, 14 de abril de 2015.
______________________________________________________
Professora e orientadora Vera Rejane Niedersberg Schuhmacher, Dra.
Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Aran Bey Tcholakian Morales, Dr.
Universidade do Sul de Santa Catarina
3
A Deus, minha famlia, meus amigos, minha

namorada, e a tudo de bom que a vida nos
permite ser e realizar.
4
AGRADECIMENTOS
A Deus, pois graas a Ele que tive sade para poder realizar este sonho.
Aos meus amados pais, Srgio e Telma, que me deram todo amor e dentre tantas
outras coisas, mais essa oportunidade maravilhosa na vida.
Ao meu irmo Rodolfo por estar sempre presente.
A toda minha famlia que, mesmo longe fisicamente sempre est no meu corao.
A minha namorada Gabriela, que faz as coisas ruins serem minsculas e as coisas
boas serem gigantes, me dando sempre muito amor e carinho.
Aos meus amigos por dividirem minhas felicidades e frustraes, sempre
estendendo a mo quando precisei.
A minha orientadora e coordenadora do curso, doutora Vera Schuhmacher, a qual
admiro imensamente desde a graduao e agradeo por todas as horas de ateno
dispensadas.
5
Tente mover o mundo o primeiro passo ser mover a si mesmo (Plato).

6
RESUMO
Este trabalho tem por objetivo apresentar tcnicas de segurana na codificao de softwares,
principalmente em aplicaes web. O estudo possui bases nas normas NBR ISO/IEC 27001 e
27002, e principalmente nas tcnicas gerais e praticas de dois desenvolvedores da Microsoft,
Howard e LeBlanc. O estudo tambm contribui para elucidar a importncia de eliminar, ou ao
menos atenuar, as vulnerabilidades web mais conhecidas, descrevendo seus impactos e at
solues especficas. Apresenta um sistema web desenvolvido em PHP, o qual teve diversas
tcnicas de segurana aplicadas e o resultado dos testes de segurana efetuados por meio do
software Acunetix Vulnerability Scanner perante o sistema implementado.
Palavras-chave: Cdigo Seguro. Normas e Tcnicas de Segurana. Vulnerabilidades Web.

7
ABSTRACT
This work aims to present security techniques in software coding, especially in web
applications. The study has bases in NBR ISO/IEC 27001 and 27002 , and especially in the
general techniques and practices of two Microsoft developers, Howard and LeBlanc. The
study also contributes to elucidate the importance of eliminating, or at least mitigate, the most
known web vulnerabilities, describing their impact and specific solutions. This work features
a web system developed in PHP, which had several security techniques applied, showing the
results of safety tests carried out by the Acunetix Vulnerability Scanner software in the
implemented system.
Keywords: Secure Code. Safety Standards and Techniques. Web Vulnerabilities.

8
LISTA DE QUADROS
Quadro 1 - Envolvidos na Segurana da Informao. .............................................................. 17

Quadro 2 - Ameaas Virtuais. .................................................................................................. 20
Quadro 3 - Ciclo PDCA, implementao de um SGSI............................................................. 24
Quadro 4 - Solues criptogrficas comuns contra ameaas. .................................................. 30
Quadro 5 - Relaes de troca ou compensao para proteger dados secretos. ......................... 31
Quadro 6 - Categorias de teste de ameaas. ............................................................................. 40
9
LISTA DE FIGURAS
Figura 1 - Etapas do ISMS. ...................................................................................................... 24

Figura 2 - Estouro de Buffer I ................................................................................................... 27
Figura 3 - Estouro de Buffer II. ................................................................................................ 27
Figura 4 - Confiana no buffer. ................................................................................................ 32
Figura 5 - Cdigo confivel para CopyData. ........................................................................... 33
Figura 6 - Funo CopyData mais segura. ............................................................................... 33
Figura 7 - SQL com parametrizao......................................................................................... 36
Figura 8 - Exemplo de utilizao da SQL parametrizada em PHP com PDO_MySQL. ......... 37
Figura 9 - Tecnologias Utilizadas............................................................................................. 43
Figura 10 - Tela inicial do sistema. .......................................................................................... 44
Figura 11 - Problema de autenticao no sistema. ................................................................... 45
Figura 12 - Tela inicial das notas. ............................................................................................ 46
Figura 13 - Tela inicial das notas em forma reduzida. ............................................................. 47
Figura 14 - Tela inicial das notas em forma reduzida com menu expandido. .......................... 48
Figura 15 - Reordenar notas. .................................................................................................... 49
Figura 16 - Reordenao das notas com sucesso...................................................................... 50
Figura 17 - Reordenao das notas com erro. .......................................................................... 51
Figura 18 - Tela de edio de uma nota especfica................................................................... 52
Figura 19 - Tela inicial de notas com mensagem de nota atualizada com sucesso. ................. 53
Figura 20 - Mensagem de nota no atualizada (erro). .............................................................. 53
Figura 21 - Confirmao antes de excluir nota......................................................................... 54
Figura 22 - Tela inicial com mensagem de sucesso aps excluso da nota. ............................ 55
Figura 23 - Mensagem de erro aps tentativa de excluso da nota (sem sucesso). .................. 55
Figura 24 - Tela de adio de notas. ......................................................................................... 56
Figura 25 - Adio de nota com sucesso. ................................................................................. 57
Figura 26 - Mensagem da tela de adio de nota com erro (nota no inserida). ...................... 57
Figura 27 - Tela de pesquisa de notas com resultados. ............................................................ 58
Figura 28 - Pesquisa de nota sem nenhum dado informado. .................................................... 58
Figura 29 - Tela de login aps o usurio clicar na opo Sair. ............................................. 59
Figura 30 - Permisses dadas ao banco de dados. .................................................................... 60
10
Figura 31 - Instrues contra a injeo de cdigo malicioso. .................................................. 61

Figura 32 - Codificao utilizada para as senhas do sistema. .................................................. 61
Figura 33 - Funes de validao de tipos e tamanhos. ........................................................... 63
Figura 34 - Trecho do cdigo da pgina de insero de notas. ................................................ 64
Figura 35 - Comandos de banco de dados para insero de notas. .......................................... 65
Figura 36 - Charset com UTF-8. .............................................................................................. 66
Figura 37 - Vulnerabilidade: formulrios HTML sem proteo contra CSRF. ....................... 68
Figura 38 - Vulnerabilidade: mensagens de erro na pgina. .................................................... 69
Figura 39 - Vulnerabilidade: listagem de arquivos do diretrio. .............................................. 70
Figura 40 - Vulnerabilidade: mod_negotiation do Apache. ..................................................... 71
Figura 41 - Vulnerabilidade: cookie de sesso sem flag de segurana configurada................. 72
Figura 42 - Vulnerabilidade: cookie de sesso sem a flag HttpOnly configurada.................... 73
Figura 43 - Corrigindo flag de HttpOnly e SSL dos cookies com HTACCESS. ..................... 73
Figura 44 - Vulnerabilidade: diretrios possivelmente sensveis. ............................................ 74
Figura 45 - Vulnerabilidade: clickjacking cabealho X-Frame-Options ausente. ................. 75
Figura 46 - Vulnerabilidade: campo de senha com recurso auto completar ativo. .................. 76
Figura 47 - Solucionando problema de cache com HTACCESS. ............................................ 76
Figura 48 - Vulnerabilidade: possvel divulgao do caminho do servidor (Unix) ................. 77
11
SUMRIO
1 INTRODUO.................................................................................................................... 12
1.1 PROBLEMTICA E JUSTIFICATIVA ............................................................................ 13
1.2 OBJETIVOS ....................................................................................................................... 14
1.2.1 Objetivo Geral .............................................................................................................................................. 14
1.2.2 Objetivos Especficos.................................................................................................................................... 15
1.3 ESTRUTURA DA MONOGRAFIA .................................................................................. 15
2 SEGURANA DA INFORMAO .................................................................................. 16
2.1 FALHAS DE SEGURANA ............................................................................................. 18
2.1.1 Causas ...........................................................................................................................................................18
2.1.2 Efeitos.............................................................. ............................................................................................. 21
3 PADRES DE SEGURANA ........................................................................................... 22
3.1 NBR ISO/IEC 27001 E NBR ISO/IEC 27002 ..................................................................... 22
3.2 ISO/IEC 15408 (COMMON CRITERIA) .................................................................................. 25
4 CODIFICAO SEGURA................................................................................................. 26
4.1 ESTOURO DE BUFFER .................................................................................................... 26
4.2 EXECUTAR COM O MNIMO DE PRIVILGIOS ......................................................... 28
4.3 CRIPTOGRAFIA ............................................................................................................... 28
4.4 PROTEGENDO DADOS CONFIDENCIAIS .................................................................... 30
4.5 ENTRADAS MAL-INTENCIONADAS ........................................................................... 32
4.6 REPRESENTAO CANNICA ..................................................................................... 34
4.7 ENTRADAS NA BASE DE DADOS ................................................................................. 35
4.8 ENTRADAS ESPECFICAS DA WEB .............................................................................. 37
4.9 INTERNACIONALIZAO............................................................................................. 38
5 FERRAMENTAS E TCNICAS DE AVALIAO DOS RISCOS .............................. 39
5.1 ACUNETIX VULNERABILITY SCANNER ..................................................................................... 39
5.2 TESTANDO VULNERABILIDADES COM A AJUDA DO STRIDE ................................................ 40
6 ESTUDO DE CASO ............................................................................................................ 42
6.1 TECNOLOGIAS UTILIZADAS ................................................................................................. 43
6.2 INTERFACES ......................................................................................................................... 43
6.3 TCNICAS E PADRES DE SEGURANA IMPLEMENTADOS ..................................................... 59
6.4 RESULTADOS E DISCUSSO ................................................................................................. 66
7 CONSIDERAES FINAIS .............................................................................................. 80
12
1 INTRODUO
O uso dos sistemas de informao e das tecnologias de informao mudou

drasticamente nas ltimas dcadas, expandindo e conectando todos os setores sociais. Esses
avanos trouxeram benefcios para os cidados, bem como para diversos setores, tais como o
financeiro, industrial, acadmico, de negcios e de servios. Em contrapartida, para que haja
uma operao confivel e segura dessa miscelnea de tecnologias, os sistemas de informao
e suas infraestruturas exigem grandes preocupaes com a segurana por parte do governo,
empresas, organizaes e usurios que desenvolvem, compram, oferecem, gerenciam ou
apenas utilizam esses sistemas de informao. (RAMSAROOP, 2003)
H cerca de 20 anos atrs, os computadores eram como ilhas isoladas e o mximo
que se podia fazer era se auto-atacar, ou seja, o usurio podia ser afetado mas isoladamente,
no disseminando uma ameaa para outros usurios. medida que a Internet cresceu, os
aplicativos passaram a estar cada vez mais interconectados e os tempos mudaram. Na era da
Internet praticamente todos os dispositivos possuem acesso Internet, possibilitando
oportunidades incrveis aos desenvolvedores de software mas tambm aumentam
exponencialmente as chances dos aplicativos serem atacados, j que no h limite de
conectividade. (HOWARD; LEBLANC, 2005)
Com este avano tecnolgico e o crescimento da rea de sistemas de informao,
o controle das vulnerabilidades nos softwares no acompanhou tamanha evoluo em to
pouco tempo. Por isso Khan e Zulkernine (2009) deixam claro que uma das fontes para os
problemas de segurana ausncia de planejamento e controle dos requisitos de segurana
durante o processo de desenvolvimento de software.
Segundo Gomes e Santos (2006), casos envolvendo vazamento de dados dos
usurios, segredos industriais e tantos outros dados privados das empresas no so mais to
incomuns, causando prejuzos financeiros e at danos marca e a imagem da empresa.
Portanto a adoo de prticas de segurana atua diretamente no corao das empresas,
trabalhando em paralelo com diversas atividades, muitas vezes de forma imperceptvel e se
tornando uma necessidade nas empresas modernas.
O problema para implantao de segurana nas empresas de desenvolvimento
que a segurana no vista como gerao de renda, levando gerncia a no investir em
treinamento para produo de cdigos seguros. O resultado que a empresa s investe quando
um ataque j foi bem-sucedido e a essa altura tarde demais, alm de muito mais caro, tanto
13
em termos financeiros quanto em termos de imagem da empresa. (HOWARD; LEBLANC,

2005)
A fim de auxiliar e compartilhar boas prticas com empresas que desenvolvem
sistemas, diversos modelos, padres e normas foram criados para atender essa demanda por
software seguros. Elas fornecem boas prticas porm no especificam de que forma devem
ser acopladas aos processos, deixando essa parte cargo de cada organizao (BRAZ, 2009).
Durante o desenvolvimento de um software necessrio atender os princpios de
integridade e confiabilidade, visto que o ndice de segurana deve aumentar enquanto que o
de falhas precisa diminuir. Por este motivo, alguns padres e normas foram estabelecidos
visando a produo de softwares seguros, dentre elas destaca-se a ISO/IEC 15.408 e a Norma
17799 (CRUZ, 2007). Essas e outras normas importantes sero abordadas no Captulo 3.
1.1 PROBLEMTICA E JUSTIFICATIVA
Segundo Howard e LeBlanc (2005), desde os primrdios a propriedade particular

protegida, at nosso mais antigo ancestral tinha leis que penalizavam pessoas que
invadissem, danificassem ou roubassem uma propriedade particular. No mundo digital no
diferente, sempre que h algum motivo para proteger bens e propriedades privadas, funo
dos desenvolvedores criar solues e aplicativos que protejam o patrimnio digital.
medida que a sociedade civil, principalmente nos pases industrializados, torna-
se cada vez mais dependente das tecnologias e sistemas de informao, a infraestrutura de
informao e os prprios sistemas se tornaram uma rea muito desejada por criminosos e
organizaes criminosas que aprenderam a tirar proveito do uso de sistemas de informao
com propsitos ilegais (crime virtual, ou Cybercrime) e para a violncia indiscriminada contra
civis e instituies civis (terrorismo virtual, ou Cyberterrorism) com o propsito de tumultuar
a sociedade destruindo a confiana da sociedade em seus lderes, polticas e instituies. Para
proteger a sociedade e as empresas dessas ameaas, a segurana da informao precisa ser
valorizada de modo que aes contra a populao ou ilegais sejam combatidas e
exterminadas. (RAMSAROOP, 2003)
No dia 22 de dezembro de 2014, conforme o New York Times (2014), a Coria
do Norte ficou sem internet por um dia. A causa da interrupo dos servios foi declarada
como um ataque ciberntico (atravs de computadores utilizando a internet) feita pelos
Estados Unidos ao pas asitico, impossibilitando os cerca de 1.024 IPs do pas de
conectarem-se com o mundo. Esta ocorrncia foi tratada como uma resposta aos milhes de
14
dados roubados de funcionrios da gigante americana dos eletrnicos, a Sony, por lanar o
filme chamado A entrevista, uma comdia que gira entorno da tentativa de assassinato do
ento lder supremo da Coria do Norte, Kim Jong-un. Conforme a matria, o lder
supremo no gostou do filme e ameaou a Sony e os Estados Unidos um dia antes da
ocorrncia do ataque Sony. Estes fatos deixam claro que se existem pases e grandes
empresas to vulnerveis a ataques de computador e Internet, o planeta Terra ainda est
engatinhando em termos de segurana da informao e precisa avanar muito (e rpido) para
que os dados trafegados por aplicativos e sistemas com acesso Internet sejam seguros.
Um software que alvo de especulaes ou notcias que afirmem que o mesmo
inseguro perceber que muitos potenciais clientes ou usurios, passam a fugir do produto ou
da empresa, ou pior, as pessoas com algum ressentimento do produto passam a aumentar
ainda mais o acumulo de publicidade negativa, provando outras pessoas que usar o produto
perigoso. Infelizmente as pessoas tendem a acompanhar somente as notcias ruins, o que
causa um dano irreparvel de tal modo que chegar o momento em que as pessoas procuraram
o produto do concorrente, afundando de vez o produto inseguro. (HOWARD; LEBLANC,
2005)
Conforme a Microsoft (2015), dados do FBI (Federal Bureau of Investigation)
revelam que em 2007, 70 bilhes de dlares foram roubados atravs de crimes virtuais e 90%
das vulnerabilidades dos sistemas so exploradas remotamente (via web).
Por isso, preciso garantir a segurana do software, porm, segundo Braz (2009),
apesar das normas de segurana serem bem claras, as mesmas no disponibilizam de uma
forma detalhada a forma de implantao nos processos, tornando difcil para as empresas
saber exatamente como atend-las em sua plenitude. Por este motivo, este estudo foi
desenvolvido e se experimentou na prtica a aplicao de algumas normas e prticas sugeridas
de segurana.
1.2 OBJETIVOS
Nas duas prximas sees tercirias, so descritos os objetivos deste trabalho

acadmico, tambm servindo como um escopo inicial do projeto.
1.2.1 Objetivo Geral

15
O presente trabalho tem por objetivo a aplicao de boas prticas de segurana no

desenvolvimento de um sistema para manuteno de notas pessoais.
1.2.2 Objetivos Especficos
So objetivos especficos do projeto:

conhecer as principais normas de segurana aplicveis ao desenvolvimento de
sistemas;
conhecer ferramentas que ajudem a verificar a segurana de um software;
desenvolver e implementar um sistema web em PHP que permita inserir, editar e
excluir notas pessoais em um banco de dados e que utilize algumas ou todas as
normas e boas prticas de segurana estudadas;
verificar a segurana do sistema desenvolvido atravs de testes com ferramentas
especializadas, validando os erros que as normas puderam evitar ou no.
1.3 ESTRUTURA DA MONOGRAFIA
No Captulo 1, dada uma breve introduo ao assunto, bem como os objetivos,

problemtica e justificativa do trabalho.
No Captulo 2, a Segurana da Informao o tema principal e os principais
conceitos a seu respeito bem como as principais falhas e seus efeitos so apresentados.
No Captulo 3, exibimos alguns padres de segurana reconhecidos
mundialmente para proteo do sistema, usurios e empresa desenvolvedora.
No Captulo 4, a codificao segura descrita na prtica em tpicos que revelam
o que pode ser feito para contornar os principais tipos de riscos encontrados nas aplicaes.
No Captulo 5, apresentamos softwares e metodologias que permitem testar se
um software seguro, ou que permitem ao menos afirmar que atende ou no ao mnimo
em segurana exigido de um sistema.
No Captulo 6, apresentamos um pequeno sistema que implementa normas e boas
prticas de segurana destacando os trechos em que os conhecimentos em segurana da
informao foram aplicados, bem como o resultado do teste de vulnerabilidades no mesmo.
16
2 SEGURANA DA INFORMAO
A informao , segundo a norma NBR ISO/IEC 27002 (ABNT, 2005), um ativo

importante para os negcios. Por atribuir valor empresa, a informao precisa receber a
proteo adequada. Para oferecer a proteo adequada, existe a segurana da informao, ou
seja, uma forma de proteger informaes de diversos tipos de ameaas. Essa proteo
influencia no campo estratgico das empresas, contribuindo para a continuidade dos negcios,
aumento das oportunidades, minimizao de riscos e maximizao do ROI (Retorno sobre os
investimentos).
Howard e LeBlanc (2005) alertam, um sistema desenvolvido sem preocupao
com a segurana da informao ser alvo fcil da mdia negativa, isto : o software tem sua
vulnerabilidade conhecida, ento divulgada pela imprensa e as pessoas simplesmente deixam
de compra-lo e passam a comprar do concorrente. Para evitar que isso ocorra, preciso
intensificar os cuidados com a codificao segura, visto que o principal produto de uma
empresa de software exatamente seus softwares.
Na definio de Campos (2007), a segurana da informao existe com o
propsito de garantir a confidencialidade, integridade e disponibilidade das informaes de
uma empresa. J para a norma ABNT NBR ISO/IEC 27002 (2005), adicionado o objetivo
de garantir a autenticidade. Os princpios bsicos da segurana da informao conforme a
norma so:
Autenticidade: este princpio prega a garantia da veracidade da fonte das

informaes. preciso garantir que a informao que trafegada tenha um
proprietrio e que este proprietrio no foi alterado;
Confidencialidade: ligado garantia de que a informao no acessada por
algum no autorizado, tanto internamente quanto externamente organizao. A
informao deve ser protegida contra cpias e distribuies no autorizadas,
garantindo que a informao confidencial e somente pessoas autorizadas
possuem acesso a ela;
Disponibilidade: tambm conhecido como continuidade do servio, a garantia
de que as informaes esto disponveis s pessoas autorizadas, sempre que elas
necessitarem;
17
Integridade: consiste na fidedignidade da informao. A informao trafegada

precisa ser original, no podendo ter nenhum dado alterado, acrescentado ou
removido sem a devida autorizao da pessoa responsvel por ela. Basicamente
a informao no pode sofrer nenhum tipo de violao.
O Tribunal de Contas da Unio (2007) define a segurana da informao sob os

mesmos pontos citados acima e acrescenta que a informao o principal ativo de uma
organizao, podendo ser considerada o recurso patrimonial mais crtico j que se no tiver a
ateno necessria da empresa, pode comprometer no s a imagem da instituio como at
mesmo sua continuidade.
J Lyra (2008), alm de citar os pontos j mencionados como disponibilidade,
autenticidade, integridade e confidencialidade da informao, divide os principais itens de
segurana conforme o quadro abaixo:
Quadro 1 - Envolvidos na Segurana da Informao.
Item Descrio
Ativo de Informao Um bem de grande valor para a organizao,
podendo ser a tecnologia, o meio que suporta
a informao, o ambiente em que est
inserida e as pessoas que a utilizam.
Ataque Um incidente de segurana causado por um
agente que deseja obter algum tipo de retorno
de algum ativo de informao.
Vulnerabilidade As fraquezas dos ativos de informao,
muitas vezes essas vulnerabilidades podem
existir mas nunca serem exploradas, porm
quando isso ocorre geralmente levam a
quebra de confidencialidade, integridade ou
indisponibilidade da informao, mesmo que
no intencionais por parte do ativo de
informao.
Ameaa Um ataque potencial a um ativo da
informao. Ocorre quando um agente
18
externo aproveita-se de alguma

vulnerabilidade encontrada e quebra um ou
mais princpios de segurana da informao.
Probabilidade A chance de uma falha de segurana ocorrer
ao somarmos o nmero de vulnerabilidades e
ameaas a algum ativo de informao.
Impacto a consequncia de um incidente de
segurana da informao, podendo ter
maiores ou menores magnitudes, j que
depende do ativo de informao envolvido.
Quanto maior o valor do ativo, maior o
impacto de um incidente de segurana.
Controle So todos os mecanismos utilizados para
diminuir as vulnerabilidades dos ativos de
informao, j que as ameaas provm de um
agente externo e no possvel agir
preventivamente sobre elas.
Fonte: Lyra, 2008.
Outros fatores que no so controlveis como greves, manifestaes, tempestades,

vulces, ausncia de energia eltrica e etc, tambm esto relacionadas segurana da
informao, j que podem afetar a integridade e disponibilidade das informaes. (LYRA,
2008)
2.1 FALHAS DE SEGURANA
As falhas de segurana so incidentes de segurana que ocorrem devido

existncia de um agente que busca algum retorno nas informaes da empresa, tambm
podendo se enquadrar no item de ataque descrito no livro de segurana da informao de
Lyra (2008). Nas sees tercirias so apresentadas as principais causas das falhas de
segurana e seus efeitos.
2.1.1 Causas
19
Segundo a Microsoft (2014), as causas que levam a uma falha de segurana so,
em sua maioria, devido :
Not a Security Bug (No uma falha de segurana): este primeiro item
autoexplicativo, simplesmente acredita-se que seja uma falha de segurana mas
no ;
Buffer Overflow / Underflow (Excesso ou falta de dados na memria virtual):
um tipo de violao de segurana de memria que ocorre quando no
verificado ou limitado o tamanho de memria que precisa ser alocada antes que as
informaes sejam manipuladas ou processadas por um software. No caso do
Overflow um programa ultrapassa os limites do buffer e sobrescreve a memria
adjacente, j o Underflow ocorre quando um buffer lido ou esvaziado antes de
ser reescrito ou preenchido;
Arithmetic Error (Erro aritmtico): quando o valor de algum dado excede
(overflow) ou no alcana (underflow) o limite em que foi especificado para ser
manipulado;
SQL / Script Injection (Injeo de cdigo): um tipo de falha que permite aos
usurios mal intencionados modificar o comportamento de alguma ao do
sistema, alterando o cdigo fonte do programa ou de uma instruo SQL
(Structured Query Language) ao banco de dados da aplicao;
Directory Traversal (Troca de diretrio): falha que permite aos usurios acessar
diretrios e executar comandos fora do local especificado;
Race Condition (Condio de corrida): vulnerabilidade de segurana causada
por problemas na sincronizao ou tempo de manipulao dos dados. Ocorre
quando um software comete erros de sincronia ou sequenciamento de aes;
Cross-Site Scripting (Injeo de script no servidor): tambm conhecida pela
sigla XSS, esta falha envolve sistemas web e sua causa alguma falha de
segurana que permite ao invasor acesso indevido a recursos ou informaes do
site, injetando cdigos maliciosos no sistema e que podem afetar todos os usurios
que estejam visualizando o site;
Cryptographic Weakness (Fraqueza criptogrfica): uso insuficiente ou
incorreto de criptografia na proteo aos dados;
20
Weak Authentication (Autenticao fraca): cdigos ou controles insuficientes

para determinar a autenticidade do usurio que j est logado no sistema;
Inappropriate Permission (Permisso incorreta): acesso a dados ou recursos
que exigiriam um login e senha, sem estar logado no sistema, acessando dados
confidenciais sem estar credenciado;
Ineffective Secret Hiding (Segredo mal escondido): falha causada pela
insuficiente ou incorreta proteo de chaves e senhas do sistema;
Unlimited Resource Consumption (Consumo ilimitado de recursos): tambm
conhecido por DoS, um erro causado pela no verificao ou limitao dos
recursos permitindo que um invasor esgote os recursos disponveis;
Incorrect / No Error Messages (Uso incorreto ou ausncia de mensagens de
erro): como o prprio nome j diz, falha causada pela ausncia ou incorreta
utilizao das mensagens de erro;
Incorrect / No Pathname Canonicalization (Caminho cannico incorreto ou
ausente): este um erro de caminho ou acesso a um arquivo ou recurso causado
pela passagem de um usurio mal intencionado pelas restries de localizao ou
de nomes;
Other (Outro): alguma falha de segurana no reportada acima.
As falhas citadas acima so bastante comuns e citadas em diversas literaturas a

respeito da segurana da informao. Os efeitos causados pelas falhas supracitadas pela
Microsoft (2014) so reportados na prxima seo.
Ainda nesse contexto, segundo Ramsaroop (2003) h quatro tipos comuns de
ameaas que podem ser causadas por criminosos virtuais que podem resultar em crime virtual,
sabotagem, terrorismo virtual ou guerra virtual:
Quadro 2 - Ameaas Virtuais.
Denominao Caractersticas
Hackers maliciosos So aquelas pessoas que invadem sistemas de
computadores sem autorizao. Estas pessoas
so especialmente preocupantes por no
serem conhecidos seus propsitos ou
identidade.
21
Cdigo malicioso So cdigos que, assim como os vrus,

causam srios danos e interrupes de alguns
aplicativos a redes inteiras, alm de
possurem um alto custo para reparao dos
danos.
Sabotagem de funcionrio ou espionagem Estes so funcionrios que trabalham
diretamente com os sistemas e podem causar
srios danos por terem informaes e
conhecimento detalhado dos sistemas, alm
de vulnerabilidades tcnicas.
Ameaas privacidade pessoal ou da So motivos de preocupao, pois os
empresa computadores / tecnologias, armazenam
diversas informaes sobre os empregados,
regras de negcio, fornecedores, dados
financeiros e outras informaes que podem
causar danos financeiros e imagem da
empresa.
Fonte: Ramsaroop, 2003.
Como apresentado no Quadro 2 (acima), Ramsaroop (2003) salienta o quanto os

computadores e a tecnologia que suportam os sistemas de informao, precisam receber os
cuidados necessrios em termos de segurana da informao para que no prejudiquem
moralmente ou financeiramente pessoas e instituies, por isso, ainda segundo ele, as
organizaes devem evoluir suas metodologias para suportar essas ameaas e prover garantia
de eficcia, consistncia e continuidade nas informaes.
2.1.2 Efeitos
A Microsoft (2014) faz uso da sigla STRIDE para classificar efeitos decorrentes
das falhas de segurana de uma aplicao. Neste acrnimo cada letra corresponde um efeito:
S Spoofing (Falsificao de identidade): se trata da falsificao de identidade

de um usurio;
22
T - Tampering (Adulterao de dados): quando ocorre modificao de

integridade da informao ou do sistema;
R - Repudiation (Repdio): a repudiao ou negao de execuo de ato
cometido previamente por um usurio;
I Information disclosure (Revelao de informaes): quando alguma
informao divulgada indevidamente;
D Denial of service (Negao de servio): a interrupo do servio devido ao
excesso de requisies ou informaes;
E Elevation of privilege (Elevao de privilgio): quando um usurio eleva
suas permisses ou privilgios indevidamente.
Os efeitos citados acima - conforme a Microsoft (2014) - podem produzir

impactos de baixo a alto valor, dependendo da aplicao e sistema operacional em que o
software estiver sendo executado. Levando desde a simples reinstalao de um software em
uma mquina de uso pessoal a incidentes que colocam a vida humana em perigo, como por
exemplo, a perda de gerao de energia eltrica em algum equipamento mdico-hospitalar.
Pelos efeitos observados, possvel perceber a importncia de um controle adequado desses
efeitos indesejados j que dependendo da aplicao as consequncias podem ser catastrficas.
3 PADRES DE SEGURANA
Conforme Ferreira e Arajo (2008), atualmente h diversas metodologias e

melhores prticas em segurana de informao. Esta necessidade surge devido s dificuldades
encontradas pelas empresas de tecnologia em atualizar seus modelos e estruturas de controle,
j que as tecnologias esto sempre mudando. Para auxiliar essas empresas, h padres
reconhecidos mundialmente como a NBR ISO/IEC 27001, NBR ISO/IEC 27002 e ISO/IEC
15408. Nas prximas sees secundrias so apresentados os padres mais conhecidos.
3.1 NBR ISO/IEC 27001 e NBR ISO/IEC 27002
As normas juntas so consideradas o mais completo padro de gerenciamento da

Segurana da Informao, pois permitem criar um sistema de gesto de segurana baseado em
controles definidos por normas e boas prticas internacionais. A norma j foi chamada BS
23
7799 (pois foi inicialmente criada pela British Standard Institute), ISO/IEC 17799 (adotada
pela ISO) e posteriormente adotada pelo Brasil em 2001 com o nome NBR ISO/IEC 17799
por meio da ABNT (Associao Brasileira de Normas Tcnicas), recebendo uma atualizao
em junho de 2005, recebendo novos captulos e chamando-se, finalmente, NBR ISO/IEC
27002, tambm conhecida como BS7799 parte 1, j a parte 2 recebe outro nome: NBR
ISO/IEC 27001 e abrange o ciclo PDCA (Plan-Do-Check-Act) (FERREIRA; ARAJO,
2008). Conforme a prpria norma, seu objetivo estabelecer diretrizes e princpios gerais
para iniciar, implementar, manter e melhorar a gesto da segurana da informao em uma
organizao (ABNT NBR ISO/IEC 27002, 2005).
Segundo o TCU (2008), a estrutura da norma NBR ISO/IEC 27002 est
distribuda da seguinte forma:
1 Escopo;
2 Termos e definies;
3 Estrutura da norma;
4 Avaliao e tratamento dos Riscos;
5 Poltica de Segurana da Informao;
6 Organizando a Segurana da Informao;
7 Gesto de Ativos;
8 Segurana em Recursos Humanos;
9 Segurana fsica e do ambiente;
10 Gesto das operaes e comunicaes;
11 Controle de acesso;
12 Desenvolvimento e manuteno de sistemas;
13 Gesto de incidentes;
14 Gesto da continuidade dos negcios;
15 Conformidade.
Conforme Ferreira e Arajo (2008), aplicando os conceitos de cada um dos

tpicos citados acima da norma em uma instituio, teremos como resultado um ISMS
(Information Security Management System). O ISMS ou SGSI (Sistema de Gesto em
Segurana da Informao) a aplicao planejada de objetivos, diretrizes, polticas,
procedimentos, modelos e outras medidas que em conjunto reduzem os riscos para Segurana
da Informao. Um ISMS pode ser construdo de acordo com o Ciclo PDCA, abordado na
segunda parte 2 da BS 7799 ou NBR ISO/IEC 27001, conforme a Figura 1:
24
Figura 1 - Etapas do ISMS.
Fonte: Adaptado de Ferreira e Arajo, 2008.
A Figura 1 acima representa as etapas do Ciclo PDCA, e que segundo Ferreira e

Arajo (2008) podem ser implementados conforme o quadro abaixo (Quadro 3):
Quadro 3 - Ciclo PDCA, implementao de um SGSI.
Fase I Plan Fase II Do Fase III Check Fase IV Act

Estruturao do Comit de Monitorao dos Implementao de
SGSI; Segurana da Controles de melhorias;
Plano Diretor de Informao; Segurana; Aes Corretivas
Segurana; Poltica de Gesto de e Preventivas;
Diagnstico de Segurana; Incidentes; Comunicao das
Segurana; Classificao da Reviso do nvel Aes e
Avaliao, Informao; de risco residual; Resultados para
Tratamento dos Plano de Auditoria Interna Alta
Riscos e Seleo Continuidade dos do SGSI. Administrao e
dos Controles de Negcios e de TI; Partes
Segurana; Treinamento e Interessadas;
Declarao de Conscientizao; Assegurar que as
Aplicabilidade Implementao Melhorias foram
(Statement of dos Controles Implementadas e
Applicability). Especificados na Atenderam as
Declarao de Expectativas.
25
Aplicabilidade.
Fonte: Ferreira e Arajo, 2008.
Portanto, com a aplicao dos itens do Quadro 3 (acima), Ferreira e Arajo (2008)
garantem, basicamente, que os ativos esto protegidos, que h um gerenciamento dos riscos e
os objetivos de controle esto implementados, formando assim, um SGSI. H tambm a
certificao nas normas, que podem ser conquistadas por empresas que buscam uma espcie
de atestado de que a empresa cumpre as boas prticas de Segurana da Informao.
Por fim, a norma NBR ISO/IEC 27001 traduzida em portugus custa R$ 113,00 e a NBR
ISO/IEC 27002 (tambm traduzida) custa R$ 209,00 conforme o site oficial para compra das
normas, o ABNT CATLOGO (2015). Esse valor irrelevante se considerarmos tamanhas
melhorias de Segurana de Informao que a aplicao das tcnicas pode proporcionar as
empresas, bastar saber se o valor gasto para aplicar a norma vivel e se ela a melhor opo
para determinado tipo de empresa.
3.2 ISO/IEC 15408 (Common Criteria)
A ISO/IEC 15408 uma norma criada a partir de um documento padro do

mercado, o Common Criteria for Information Technology Security Evaluation (Critrio
Comum para Avaliao de Segurana de Tecnologia da Informao), por isso tambm
conhecida como Common Criteria. Esta norma fornece um conjunto de critrios fixos que
permitem garantir a segurana da aplicao atravs de especificaes de segurana
caractersticas do ambiente da aplicao. (ALBUQUERQUE; RIBEIRO; 2002)
A ideia do Common Criteria (CC), segundo Albuquerque e Ribeiro (2002), de
que se desenvolva um sistema seguindo as normas, depois o teste em um laboratrio
credenciado e por fim um selo seja emitido garantindo que aquela aplicao atende os
requisitos de segurana. O CC especifica que para a aplicao ser considerada segura, os
requisitos de segurana, (chamado Security Target) precisam existir e serem alcanados.
Alm do Security Target, h tambm o Protection Profile (perfil de proteo) que se difere do
anterior por no estar restrito a uma aplicao especfica, podendo ser aplicado a toda uma
classe de sistemas.
O CC define sete nveis de garantia de segurana (os EAL Evaluation
Assurance Level), porm s os quatro primeiros nveis, EAL-1 ao EAL-4, so considerados
pela norma ISO/IEC 15408 j que os outros trs so to rgidos que so considerados
26
inviveis, sendo essa a nica diferena prtica entre os dois documentos (ALBUQUERQUE;
RIBEIRO; 2002). Conforme o site da prpria norma, o Common Criteria Portal (2015), os 7
nveis EAL so:
1 EAL 1: Funcionalmente testado;
2 EAL 2: Estruturalmente testado;
3 EAL 3: Metodicamente testado e verificado;
4 EAL 4: Metodicamente projetado, testado e verificado;
5 EAL 5: Semi-formalmente projetado e testado;
6 EAL 6: Semi-formalmente projetado, testado e verificado;
7 EAL 7: Formalmente projetado, testado e verificado.
data deste trabalho, o site da norma (Common Criteria Portal, 2015) declarava
que 1955 produtos de diversos setores diferentes j tinham sido certificados por esta norma,
dentre eles sistemas e aparelhos biomtricos, sistemas e dispositivos de controle de acesso,
bases de dados, sistemas operacionais, produtos para certificao digital, dispositivos
multifuncionais e etc. Isso mostra que apesar de ser uma norma rigorosa, aplicvel a
diferentes aplicaes, consolidando-se como um dos padres de segurana mais utilizados no
mercado.
4 CODIFICAO SEGURA
Este captulo dedicado apresentao de tcnicas que visam diminuir ou

eliminar falhas de segurana comuns em aplicaes web conforme Howard e LeBlanc (2005).
So 9 sees que abrangem diversos tipos de ameaas e que apresentam tcnicas que se
implementadas ajudam a garantir um software mais seguro. Todos os cdigos apresentados
esto na linguagem de programao C++.
4.1 ESTOURO DE BUFFER
Segundo Howard e LeBlanc (2005), o estouro de buffer um problema muito

comum causado por prticas ruins de codificao e que pode causar danos financeiros (e
morais) enormes. A primeira linha de defesa contra ele escrever um cdigo slido, ou seja,
bem pensado, bem codificado e bem testado, embora parea uma dica muito superficial,
impedir estouro de buffer uma questo de escrever um aplicativo seguro. Assim deve-se
27
validar as entradas de dados e todas as informaes que so passadas como parmetros para as
funes do sistema devem ser vistas como entradas hostis. Nada das funes alm das
entradas e sadas devem ser acessveis fora dela.
Um exemplo de cdigo que permite o estouro de buffer o da Figura 2 abaixo:
Figura 2 - Estouro de Buffer I
Fonte: Howard e LeBlanc, 2005.
No exemplo acima, percebe-se que o programador acredita conhecer o

comprimento do buffer, porm se algum outro programador menos cuidadoso fizer
modificaes na funo, possvel que haja um estouro, alm deste tipo de construo s
trazer problemas. Como sugesto, o cdigo abaixo seria indicado:
Figura 3 - Estouro de Buffer II.
No cdigo mencionado, se algum chamar a funo passando um argumento no

esperado para a funo, o cdigo ir falhar exibindo o local do erro rapidamente e facilitando
a correo do bug sem depender de uma cobertura completa de testes.
Outra prtica recomendada por Howard e LeBlanc (2005) o tratamento de
strings. Considerando que o estouro de buffer mais comum, uma reviso das funes
comumente utilizadas indicada, trocando sempre que possvel funes inseguras ou
depreciadas pelas mais recentes e seguras. Outras dicas mais especficas so:
Validar o tamanho das entradas de informao conferindo se o tamanho

especificado persiste mesmo depois do envio dos formulrios;
28
Cuidar com funes que retornam o tamanho da informao, pois fazendo uso
delas, permitir que um estouro de buffer ocorra devido a um tamanho
excessivamente grande dos dados;
Indicar erros o mais prximo possvel da origem, pois permite que a depurao
seja mais fcil, alm de evitar que um erro oculto transforme-se em uma
mensagem de erro em um local inesperado, fato que sempre que possvel deve ser
evitado.
4.2 EXECUTAR COM O MNIMO DE PRIVILGIOS
Conforme Howard e LeBlanc (2005) no campo da segurana, quanto menos

privilgios mais segurana. Toda ao deve ser executada com o mnimo de permisses
possveis, e se for dado acessos mais privilegiados que ele dure somente o tempo necessrio
correta execuo da funcionalidade, reduzindo a rea de explorao dos possveis invasores.
O vrus e o cavalo-de-Tria (programa que possui um cdigo malicioso oculto)
so dois viles que podem ser evitados em uma aplicao pelo simples fato de no executar
um programa como administrador. Vrus conhecidos como Back Orifice, SubSeven, FunLove
e ILoveYou s conseguem se proliferar ou alcanar seu risco mximo quando o usurio
executa os programas infectados com nvel de administrador. Abaixo vemos duas principais
dicas para esta seo importante da segurana:
Abra recursos com as permisses que so requeridas, nada mais exemplo: se for
necessrio ler um dado do registro do computador, solicite acesso de apenas
leitura;
No gravar dados do usurio em locais protegidos como, por exemplo, a pasta
C:\Arquivos de Programas ou C:\Windows, no caso do Sistema Operacional
Windows 8.1. Dados do usurio devem ser armazenados sempre que possvel
no diretrio de perfil do usurio como, por exemplo, C:\Users\NomeDoUsuario
(Windows 8.1).
4.3 CRIPTOGRAFIA
29
A criptografia, segundo Howard e LeBlanc (2005), algo muito importante para

garantir a privacidade e integridade dos dados bem como deixa mais forte a autenticao,
porm, ela por si s no diminuir os erros de programao que levam falhas de segurana.
Por isso, no basta utilizar criptografia, preciso saber escrever cdigos que permitam
criptografia alcanar seu grau mximo de segurana. Neste ltimo quesito, h diversas dicas
de desenvolvimento, dentre elas destacam-se:
Utilizar nmeros aleatrios ruins leva previsibilidade das chaves, por isso, a
regra para gerar bons nmeros gerar nmeros uniformemente distribudos,
imprevisveis e que possuam uma grande abrangncia de nmeros diferentes e que
permita incluir todos eles, o chamado ciclo longo e completo. A funo rand
(C++) no indicada para gerar nmeros aleatrios por possuir congruncia
linear, ou seja, um comportamento previsvel;
Criar funes prprias para criptografia no algo recomendvel. Isso pode criar
o risco de algum mais expert decifrar os cdigos e destruir a segurana do
sistema;
Bastante ateno ao gerenciamento das chaves, este o elo mais fraco de
aplicativos que utilizam criptografia, por exemplo, uma chave codificada em uma
imagem executvel fcil de quebrar, mesmo sem acesso ao cdigo fonte;
Utilize o nmero adequado de caracteres para chave criptogrfica. Quanto mais
curta mais fcil de atacar. importante lembrar que atacar chaves simtricas
como DES e RC4 exige que o invasor tente todas as chaves, no entanto chaves
RSA (cifra assimtrica) exige que o invasor tente valores aleatrios criados para
criar chaves pblicas e privadas o processo chamado de fatorao. A chave
simtrica no mais ou menos segura que a assimtrica, a diferena que elas so
atacadas de formas diferentes e o mais importante seu tamanho em bits (nmero
de caracteres), quanto maior, mais segura;
Outra dica importante, porm no relacionada codificao: nunca
recomendado dizer que a empresa ou o sistema possui segurana inquebrvel ou
criptografia de qualidade militar, isso pode ser um tiro no p caso venha a ter
algum problema de segurana, levando a empresa a adquirir uma m reputao.
30
Para identificar quais so as principais ameaas criptografia e como combat-la,

pode-se utilizar o Quadro 4 abaixo:
Quadro 4 - Solues criptogrficas comuns contra ameaas.
Ameaa Tcnica de atenuao Algoritmos de exemplo

Revelao de informaes Criptografia de dados utilizando RC2, RC4, DES, 3DES,
uma cifra simtrica. AES.
Adulterao Integridade de dados e de SHA-1, SHA-256, SHA-
mensagem utilizando funes de 384, SHA-512, MD4,
hash, MACs ou assinaturas MD5, HMAC,
digitais. assinaturas digitais RSA,
assinaturas digitais DSS,
XML DSig.
Spoofing Autenticar dados provenientes Certificados de chave
do remetente. pblica e assinaturas
digitais.
Fonte: Howard, LeBlanc, 2005.
No Quadro 4 acima, os algoritmos utilizados derivam da necessidade de

segurana de cada aplicao, podendo um algoritmo ser timo para evitar a revelao de
informaes mas fraco contra adulterao. Tudo depende da aplicao em que a criptografia
ser utilizada. Por isso preciso ter em mente quais objetivos de segurana precisam ser
alcanados para cada sistema (HOWARD; LEBLANC, 2005).
4.4 PROTEGENDO DADOS CONFIDENCIAIS
Segundo Howard e LeBlanc (2005), os dados secretos possuem um vilo

principal: as contas de administrador dos sistemas operacionais. Com esse privilgio as
ameaas confidencialidade (e a integridade) se tornam muito maiores. Para vencer essa
batalha, os mencionados desenvolvedores da Microsoft enumeram alguns pontos principais:
Muitas vezes um segredo no precisa ser algo codificvel e descodificvel. Senhas

de usurios no banco de dados, por exemplo, devem ser preferencialmente um
31
hash armazenado (md5, sha1, sha2 e etc.), isso permite que o sistema mesmo que
comprometido no permita recuperar os segredos, exceto por brute force
(chamado de fora bruta, consiste em testar milhes de vezes as senhas com
caracteres aleatrios at acert-lo);
Para criar cdigos hash mais aprimorados, pode-se utilizar o sal. O sal (tambm
chamado de salting, em portugus salgar) se trata de algum nmero aleatrio ou
caracteres adicionados aos dados do hash, criando segredos ainda mais difceis de
serem descobertos. Para linguagem C++ recomendada a CryptoAPI para criar
hashes com sal pois torna essa tarefa extremamente fcil;
Em Sistemas Operacionais Windows (2000 e posteriores), por meio da linguagem
de programao C++, possvel utilizar as funes CryptProtectData e
CryptUnprotectData da Data Protection API (DAPI). A mesma permite que
somente usurios com perfil de acesso administrador ou contas normais tenham
certos privilgios no sistema, por exemplo, de escrita, e alm disso adiciona
automaticamente um cdigo de verificao de integridade (MAC message
authentication code) aos dados criptografados, permitindo que a integridade dos
dados seja verificada. Ao utilizar CryptProtectData e CryptUnprotectData, pode-
se enviar uma senha adicional ao parmetro pOptionalEntropy, como o usurio e
senha do usurio do Windows, permitindo que apenas aquele usurio na
rede/computador faa determinadas aes no sistema;
H trs bases para construir aplicativos que armazenam segredos: a segurana
relativa, o esforo de desenvolvimento e a facilidade de instalao. Investir mais
em segurana durante o desenvolvimento diminui os custos de manuteno do
software. O Quadro 5 (abaixo) apresenta o esforo de desenvolvimento,
segurana relativa e a facilidade de instalao das opes de segurana dados
secretos.
Quadro 5 - Relaes de troca ou compensao para proteger dados secretos.
Opo Segurana Esforo de desenvolvimento Facilidade de

Relativa instalao
Arquivos de configurao Nenhuma. Baixo. Alta.
(nenhuma criptografia, somente
por comparao de informaes).
32
Segredos incorporados ao cdigo. Nenhuma. Baixo. Mdia.

DPAPI (mquina local). Alta. Mdio. Baixa.
DPAPI (dados de usurio). Alta. Mdio. Mdia.
Fonte: Adaptado de Howard, LeBlanc, 2005.
Como elucida o Quadro 5 (acima), quanto maior o esforo de desenvolvimento e

menor a facilidade de instalao, maior a segurana relativa de um sistema, portanto cabe a
cada sistema adequar-se a sua necessidade de proteo dados secretos, j que em alguns
casos tamanha segurana e esforo de desenvolvimento no faz jus necessidade do software.
4.5 ENTRADAS MAL-INTENCIONADAS
Toda entrada mal-intencionada at que se prove o contrrio, essas palavras de

Howard e LeBlanc (2005) deixam claro o quo importante validar todas entradas de dados
de uma aplicao, ou seja, todos os dados inseridos pelos usurios so dados no-confiveis.
Isso no significa dizer que sempre haver pessoas mal-intencionadas utilizando o aplicativo,
at mesmo usurios honestos podem incluir entradas que levam a uma exceo no sistema.
Para elucidar a importncia da validao dos dados, um exemplo de estouro de
buffer pode ser dado. O estouro de buffer ocorre por trs razes: dados inseridos de fonte no
confivel (possivelmente um invasor), confiana excessiva no formato em que os dados
deveriam ser inseridos (tamanho do buffer) e em decorrncia de um evento potencialmente
arriscado em que o buffer no confivel copiado para memria. Para exemplificar, pode-se
utilizar o cdigo C++ da Figura 4 abaixo:
Figura 4 - Confiana no buffer.
O cdigo acima est perfeito, tudo depende de como CopyData chamado e se

szData um dado confivel. Por exemplo, o seguinte cdigo seguro para funo acima, j
que um dado confivel (criado diretamente pelo sistema):
33
Figura 5 - Cdigo confivel para CopyData.
O cdigo acima seguro j que os nomes so declarados diretamente, no

excedendo o limite de 32 caracteres definidos na funo da Figura 4. Mas se o argumento da
funo CopyData, o szData, fosse criado por uma origem no confivel (o usurio, por
exemplo) ento CopyData copiaria os dados at alcanar um caractere nulo o que causaria
um estouro de buffer em cDest caso o tamanho excedesse 32 caracteres. Portanto, o cdigo
citado no seguro em meio no confivel. Para corrigi-lo seria necessrio seguir o cdigo
abaixo:
Figura 6 - Funo CopyData mais segura.
O cdigo apresentado acima muito mais seguro, pois limita a quantidade de

dados copiados a cDest impedindo que um estouro de buffer ocorra naquele ponto. Portanto a
lio fazer o cdigo mais seguro Figura 6 desde o incio, pois mais cedo ou mais tarde o
cdigo da Figura 4 precisaria ser corrigido, alm de evitar todo o transtorno causado pelo
estouro do buffer e a corrida desenfreada para encontrar o cdigo com problemas.
H diversos meios de combater as entradas mal intencionadas. Dentre as
principais formas pode-se mencionar:
Definir um limite de confiana ao aplicativo aps ultrapassar uma bateria de

validaes, pode-se considerar que os dados dentro deste limite so confiveis;
34
Criar um ponto de estrangulamento de entrada, ou seja, os dados que no

passaram nas validaes ficam fora da rea confivel;
Procurar sempre por dados vlidos, e no invlidos. H duas razes para isso:
pode haver mais de uma maneira vlida de representar os dados e um padro
invlido pode ser aceito. Exemplo: ao invs de procurar pelas extenses de
arquivo exe, bat ou cmd para determinar se um arquivo perigoso, procure se o
arquivo se enquadra dentro do necessrio, por exemplo, txt, gif e jpg;
Utilize expresses regulares para validar dados e literais mais complexos.
4.6 REPRESENTAO CANNICA
A representao cannica a maneira mais direta e menos ambgua de representar

algo. Segundo Howard e LeBlanc (2005), a canonicalizao o processo por meio do qual
vrias formas equivalentes de um nome so resolvidas em um nico nome-padro o nome
cannico. Isto , o arquivo teste.php pode estar sendo chamado em algum lugar do sistema
de ../temp/teste.php e em outro ../teste.php, porm todos fazem referncia ao mesmo
arquivo, o C:/temp/teste.php. Este ltimo a representao cannica do arquivo, enquanto
que os outros so as representaes no cannicas. Quando o sistema toma decises erradas
com base em uma representao no cannica os bugs de segurana relacionados acontecem.
Falhas de canonicalizao podem permitir acesso a arquivos no permitidos, a
chamada vulnerabilidade de revelao. Por exemplo, o Mac OS X da Apple em sua
primeira verso utilizava o sistema de arquivos HFS+ que no fazia distino entre nomes
maisculos e minsculos, porm o servidor Apache Web (instalado por padro) fazia
distino e protegia diretrios baseado no nome do arquivo. Resultado: um caminho
bloqueado pelo Apache chamado /scripts/ (em minsculo), ao ser digitado como
/SCRIPTS/ (em maisculo) via HFS+ o acesso ao diretrio era liberado.
Se tratando de um erro de codificao que pode ser grave, Howard e LeBlanc
(2005) citam as seguintes dicas de canonicalizao para no deixar a aplicao falhar por este
motivo:
Um aplicativo nunca deve tomar decises de segurana baseado no nome de um

arquivo;
35
Nunca utilizar palavras em sua representao normal de caracteres para

comparar com Strings indesejadas. Essas palavras podem ser escritas de outra
maneira e burlar a segurana. Por exemplo, comparar o valor remover para o
parmetro executar de uma URL (pagina1.php?executar=remover). Se um
usurio mal intencionado passar o valor %72emover para o parmetro
executar, onde %72 a representao hexadecimal da letra r, o servidor
web interpretaria como remover enquanto que a comparao de literais no
encontraria o valor remover para o parmetro executar, burlando a segurana
do sistema e liberando um acesso proibido. Esse escape em hexadecimal apenas
uma dentre vrias representaes de caracteres normais, s para citar outros
exemplos, h tambm a codificao de largura varivel no UTF-8, codificao
UCS-2 Unicode e a codificao dupla;
Ao invs de comparar literais problemticos, as expresses regulares devem ser
utilizadas para restringir o que permitido em um nome e rejeitar todas as outras
solicitaes;
No caso de aplicaes ISAPI (Internet Server Application Programming Interface)
e filtros ISAPI, provavelmente as tecnologias mais vulnerveis no quesito
canonicalizao, recomenda-se utilizar a varivel de servidor
SCRIPT_TRANSLATED no caso do servidor web IIS (Internet Information
Services), pois ela retorna nomes de arquivos corretamente canonicalizados
automaticamente;
Caminhos completos (absolutos) devem ser utilizados para localizar arquivos. Por
exemplo, ao invs de referenciar o arquivo teste.php com ../temp/teste.php,
tambm conhecido como caminho PATH, o correto referenci-lo como
C:/temp/teste.php que o caminho completo do arquivo.
4.7 ENTRADAS NA BASE DE DADOS
Dados provenientes de entradas no confiveis os usurios do sistema

costumam ser inseridos na base de dados para registrar informaes que agregam valor ao
usurio e ao sistema, no entanto, se no tomado os devidos cuidados, grandes problemas de
segurana podem ocorrer. Conforme Howard e LeBlanc (2005), scripts de Injeo SQL so os
36
mais comuns nesta seo de estudo e a SQL enviada ao banco de dados deve possuir
tratamento especial para evitar ou atenuar as ameaas aos bancos de dados.
Para evitar problemas com as entradas no banco de dados, deve-se seguir as dicas
abaixo:
Como j mencionado na seo 4.2, o perfil do usurio do banco de dados que faz
as consultas da aplicao deve possuir o mnimo de privilgios apenas o
necessrio correta execuo das instrues;
No reescrever os dados de acesso ao banco (usurio e senha) diretamente nos
scripts, pois aumentam as chances de um usurio malicioso roubar esses dados;
Utilizar funes que tratem informaes passadas SQL antes de execut-la,
sobrescrevendo caracteres ou combinao de caracteres perigosos, por exemplo,
as aspas simples (usadas comumente para fechar condies e acessar dados
proibidos);
Procedures (coleo de instrues SQL pr-compiladas) escondem a lgica do
aplicativo caso o cdigo seja comprometido, por isso, em aplicaes robustas e
que regras de negcio transitam pelas consultas, so geralmente bem
recomendadas.
A separao das dicas acima para esta proposital e visa dar maior destaque a
utilizao da dica mais importante: os comandos parametrizados, tambm chamados de
marcadores de lugar. Conforme Howard e LeBlanc (2005), esta uma das melhores tcnicas
(e de fcil utilizao) para garantir a segurana das entradas no banco de dados. Comandos
parametrizados podem receber os tratamentos indicados nas dicas acima e acrescentam um
fator importante: a prpria validao dos dados pela base de dados. Uma consulta
parametrizada simples pode ser feita da seguinte forma:
Figura 7 - SQL com parametrizao.
Como pode-se ver na Figura 7, a instruo retorna o nmero de registros da tabela

client que satisfazem a condio name=? e pwd=?. Os caracteres de interrogao so os
valores das entradas que sero passadas para a SQL posteriormente e que o banco de dados ir
37
interpretar. Elas so enviadas da seguinte maneira, em PHP com a API (Application

Programming Interface) PDO_MySQL:
Figura 8 - Exemplo de utilizao da SQL parametrizada em PHP com PDO_MySQL.
Fonte: Autor, 2015.
Como se conclui pela Figura 8, no complicado utilizar a parametrizao de

SQL para melhorar a segurana das consultas no banco, por isso, extremamente
recomendvel sua utilizao.
4.8 ENTRADAS ESPECFICAS DA WEB
Provavelmente o local mais perigoso de entradas de dados tambm o mais

utilizado atualmente, conforme Howard e LeBlanc (2005) o ambiente web apresenta riscos
maiores que os das aplicaes locais (desktop), porm, as dicas abaixo podem ajudar os
sistemas serem mais seguros neste ambiente hostil:
Nunca permita que valores passados pela URL (o caso do valor meuscript para
o argumento nome da URL www.meusite.com/dados?nome=meuscript)
faam alguma insero de informaes do contedo HTML da pgina;
Se possvel, evite cookies, eles so apenas um cabealho na solicitao HTTP,
portanto, invasores podem faz-los falsificar informaes e acessar dados que
somente o usurio conhece. Se utiliz-los, tente ao menos criptograf-los e exigir
autenticao aos dados via MAC (Message Authentication Code);
38
Coloque entre aspas duplas todas as propriedades das tags HTML. Muitos ataques
XSS partem da explorao de propriedades das tags que se inseridas envolvidas
por aspas duplas, podem no funcionar ou dificultar o ataque;
No utilize a funo eval() do JavaScript em entradas no confiveis. Ela permite
que praticamente qualquer cdigo possa ser executado, portanto, evite sua
utilizao ao mximo;
Por ltimo, no armazene dados sigilosos em cookies, campos ocultos ou
quaisquer outros dados que possam ser manipulados ou descobertos pelo usurio
via exibio do cdigo fonte da pgina, trfego dos dados no site e etc.
4.9 INTERNACIONALIZAO
Esta seo focada na internacionalizao, reconhecida pelos caracteres I18N (I de

internationalization, 18 caracteres e depois a letra N), no trata do assunto em termos gerais
restringindo-se a fornecer formas de melhorar a segurana ao utiliz-la.
Conforme Howard e LeBlanc (2005), importante que ao projetar softwares para
pblicos internacionais siga as seguintes regras:
Utilizar apenas o padro de caracteres Unicode. Dentre as trs principais

representaes binrias Unicode (UTF-8, UTF-16 e UTF-32), as duas mais
recomendadas so o UTF-8, para protocolos e sistemas web, e o UTF-16, para
aplicativos da plataforma Windows ( o padro de codificao utilizado pelo
sistema operacional). Utiliz-los deixar o cdigo menos exposto a problemas de
converso e segurana;
No criar um conversor prprio de caracteres, deixando esta tarefa para os padres
reconhecidos mundialmente uma boa prtica de segurana para os casos de
internacionalizao;
No converter caracteres Unicode em outros conjuntos de caracteres/pginas de
cdigo evita que falhas de segurana e outros bugs ocorram com o sistema.
Conforme o site oficial do padro internacional Unicode, o Unicode Consortium

(2015), o repositrio de caracteres do Unicode Common Locale Data Repository (CLDR),
permite a converso dos caracteres para cerca de 300 linguagens diferentes, ou seja, escrever
39
um caractere no padro Unicode, permite que ele seja traduzido para cerca de 300 linguagens
diferentes, o que o consolida como padro de caracteres tanto em termos de segurana como
em popularidade.
5 FERRAMENTAS E TCNICAS DE AVALIAO DOS RISCOS
Este captulo apresenta informaes sobre algumas das principais ferramentas do

mercado para testar softwares web, bem como tcnicas para identificao e teste dos riscos de
segurana de um sistema.
5.1 Acunetix Vulnerability Scanner
Acunetix o nome de uma empresa com sede em Malta e Reino Unido e ela a
desenvolvedora do Acunetix Vulnerability Scanner, seu software pago (possui verso de
avaliao por 14 dias) que promete verificar diversas vulnerabilidades em um sistema web.
Muito conhecido entre grandes empresas, presta servios para gigantes como a Sony, NASA,
Adidas, Adobe, Cisco, Samsung e a Coca-Cola. Segundo a Acunetix (2015), o software
pioneiro na rea de testes em aplicaes web e lder em anlise e deteco de
vulnerabilidades neste meio.
Conforme a Acunetix (2015), o software possui como principais pontos:
Encontrar ameaas de baixo risco atravs de um avanado scanner que combina

tcnicas de teste caixa preta (sem acesso ao cdigo fonte) com feedbacks
colocados dentro do cdigo fonte;
Analisador automatizado de JavaScript que encontra vulnerabilidades em cdigos
AJAX e aplicaes web 2.0;
Testes intensivos de SQL Injection e Cross-Site Scripting (XSS);
Testes em formulrios e reas protegidas;
Permite procurar falhas em milhares de pginas sem interrupo graas ao seu
processamento multitarefa;
O software compreende diversas tecnologias web complexas como REST, SOAP,
XML, AJAX e JSON.
40
Ainda segundo a Acunetix (2015), 70% dos sites possuem vulnerabilidades que
permitem acessar / roubar informaes sensveis como cartes de crdito e informaes dos
usurios j que hackers concentram seus esforos em sistemas baseados na web, como
carrinhos de compras, formulrios e contedos dinmicos. Com o software da empresa,
prometem encontrar essas falhas antes dos hackers, fazendo com que as informaes e
contedos vulnerveis sejam protegidos antes dos ataques.
O software em sua verso Entreprise custa U$ 4.995 (quatro mil e novecentos e
noventa e cinco dlares), ou aproximadamente R$ 13.150 (treze mil e cento e cinquenta reais)
em sua licena perptua, j sua licena anual custa U$ 3.195 (trs mil e cento e noventa e
cinco dlares, ou aproximadamente R$ 8.400 (oito mil e quatrocentos reais). Nas duas
verses, est incluso documentao, manuais de instruo dos diversos mdulos do sistema e
suporte via e-mail ou telefone (ACUNETIX, 2015). Este aplicativo em sua verso de
avaliao foi o escolhido para testar o sistema desenvolvido para este trabalho j que uma
aplicao web desenvolvida em PHP com JavaScript, alm de o software se mostrar de fcil
uso. No Captulo 6, exibido os documentos produzidos e o resultado dos testes feitos com o
Acunetix Vulnerability Scanner.
5.2 Testando vulnerabilidades com a ajuda do STRIDE
Esta tcnica descrita por Howard e LeBlanc (2005) e consiste em explorar com
simples testes as categorias de ameaa do STRIDE. Como j explicado na seo 2.1.2, o
STRIDE uma sigla que composta pelas classificaes das ameaas de segurana. Essas
classificaes ajudam a determinar os tipos de testes a serem realizados e o risco das ameaas,
priorizando cada tipo de teste. Abaixo segue o Quadro 6 com as tcnicas de testes sugeridos:
Quadro 6 - Categorias de teste de ameaas.
Tipo de Ameaa Tcnicas de teste

Falsificao de Identidade Tentativa de forar o aplicativo a no utilizar nenhuma
autenticao; h uma opo que permita isso, que um no
administrador possa configurar?
Tente forar um protocolo de autenticao a utilizar uma
verso legada menos segura?
Voc pode visualizar as credenciais de um usurio vlido
41
na rede ou no armazenamento persistente?

Tokens de segurana (por exemplo, um cookie) podem
ser reproduzidos para driblar uma etapa de autenticao?
Tente um ataque de fora bruta contra as credenciais de um
usurio; h alteraes sutis na mensagem de erro que o
ajudem a tentar esse ataque?
Adulterao de dados Tentativa de driblar a autorizao ou mecanismos de
controle de acesso;
possvel adulterar e depois refazer o hash dos dados?
Crie hashes, MACs e assinaturas digitais invlidos para ver
se esto verificados corretamente;
Determine se voc pode forar o aplicativo a rever (roll-
back) para um protocolo inseguro se o aplicativo utilizar
um protocolo resistente a adulterao como SSL/TLS ou
IPSec.
Repdio H condies que impedem o registro em log ou a
auditoria?
possvel criar solicitaes que criam dados incorretos em
um log de evento?
Aes sigilosas podem ser realizadas de tal maneira que
driblem as verificaes de segurana?
Revelao de informaes Tentem acessar dados que s podem ser acessados por
usurios mais privilegiados. Isso inclui dados persistentes
(dados baseados em arquivos, dados no registro, etc.) e
dados trafegados na rede. Os Sniffers, ou analisadores de
rede, so uma ferramenta til para encontrar esses dados;
Mate o processo e realize uma pesquisa no disco
procurando dados sigilosos que nele so gravados. Voc
talvez precise solicitar que os desenvolvedores marquem
seus dados como sigilosos com um padro comum em uma
distribuio de depurao para localizar os dados
facilmente;
Faa o aplicativo falhar de uma maneira que ele exponha
42
informaes teis a um invasor. Por exemplo, mensagens

de erro.
Negao de servio (DoS) Inunde um processo com um nmero to grande de dados
que ele pare de responder a solicitaes vlidas;
Dados malformados travam o processo? Isso
especialmente ruim nos servidores;
Influncias externas (como pouco espao em disco, presso
por memria e limitaes de recurso) podem forar o
aplicativo a falhar?
Elevao de privilgio Invista a maior parte do tempo em aplicativos que so
executados sob contas elevadas, como servios SYSTEM;
Voc pode executar dados como cdigo?
Um processo com privilgios elevados pode ser forado a
carregar um shell de comandos que, por sua vez, ser
executado com privilgios elevados?
O Quadro 6 (acima) no descreve como implementar o teste, apenas enumera

linhas gerais de testes para cada categoria do STRIDE. Muito til para orientar ou descobrir
quais so pontos de maior risco e que precisam ter cuidado dobrado em um sistema bem como
para avaliar de modo geral a segurana de uma aplicao. Alguns pontos desta tabela tambm
foram usados para testar o sistema deste trabalho garantindo sua presena nos resultados dos
testes no Captulo 6.
6 ESTUDO DE CASO
Neste trabalho apresentado o sistema web desenvolvido utilizando a linguagem

de programao PHP. O software um sistema de Notas que permite criar, editar e excluir
notas tanto pessoais quanto profissionais, exigindo um usurio e senha que seriam
previamente cadastrados (primeira tcnica de segurana). O sistema foi testado em um
servidor web online, efetuando testes de segurana com o uso de softwares ou tcnicas
descritas no Captulo 5.
43
6.1 Tecnologias Utilizadas
O sistema web foi desenvolvido em PHP 5.5 utilizando JavaScript, CSS 3, HTML
5 e os frameworks jQuery e Bootstrap. A plataforma em que o sistema est rodando um
servidor web Apache 2.2 em um Sistema Operacional Linux CentOS 6, conforme a Figura 9
abaixo:
Figura 9 - Tecnologias Utilizadas.
Fonte: Adaptado pelo Autor, 2015.
As tecnologias da imagem acima (Figura 9) foram usadas de forma livre, de

maneira que o mais importante no foi seguir diretrizes de uma tecnologia especfica, mas sim
uma metodologia criada a partir da juno das dicas de segurana com as normas de
segurana estudadas.
6.2 Interfaces
44
Nesta seo so apresentadas todas as telas do sistema, explicando qual ao o

usurio deve fazer em cada uma delas e qual comportamento ocorre de acordo com as
escolhas do usurio ou falhas no sistema.
O sistema de notas restrito, por isso, no h um local para cadastro de usurios,
eles so inseridos pelo administrador do sistema e os usurios ao digitar o endereo web do
mesmo, encontram diretamente a tela de login, conforme abaixo:
Figura 10 - Tela inicial do sistema.
Fonte: Autor, 2015.
Neste momento, o usurio deve digitar as informaes de Usurio e Senha, e caso

clique no boto Entrar sem preencher os dados, o sistema exibe uma popup explicando o
Voc precisa preencher o campo X, onde X o nome do campo que no foi preenchido.
Caso a combinao de login e senha seja invlida, disparada a seguinte mensagem de erro
de autenticao:
45
Figura 11 - Problema de autenticao no sistema.
Fonte: Autor, 2015.
Caso o usurio insira uma combinao correta de login e senha, o sistema

redirecionado para a tela inicial de notas:
46
Figura 12 - Tela inicial das notas.
Fonte: Autor, 2015.
Como apresentado na Figura 12 (acima), a tela inicial das notas lista as ltimas
notas adicionadas pelo usurio em questo, exibindo os dados armazenados para o campo
ttulo (fundo azul e cor branca na fonte) e texto (fundo transparente e cor cinza na fonte).
Esta tela tambm deflagra o comportamento padro do sistema, em que a pgina
em uso que possui navegao via menu, neste caso a opo Incio, recebe o efeito active do
CSS, ou seja, o bloco Incio fica com um tom de cinza mais escuro. Caso no exista
nenhuma nota cadastrada para o usurio, o quadro onde as notas esto posicionadas
substitudo pela mensagem No h notas cadastradas. Para cadastr-las, clique em
Adicionar.
No caso do sistema ser aberto em um dispositivo com menos resoluo de tela
disponvel, graas ao seu design flexvel com o Bootstrap, a tela inicial apresentada
conforme a imagem abaixo:
47
Figura 13 - Tela inicial das notas em forma reduzida.
Fonte: Autor, 2015.
Em sua forma reduzida de layout, Figura 13 acima, o sistema continua oferecendo

as mesmas opes, porm elas ficam acessveis somente aps clicar no cone do canto
superior direito da tela. Ao clicar neste boto o design da tela inicial fica da seguinte maneira:
48
Figura 14 - Tela inicial das notas em forma reduzida com menu expandido.
Fonte: Autor, 2015.
Este menu fixo e apresenta a mesma condio de flexibilidade em todas as pginas,

s alterando sua aparncia de acordo com qual funo foi ativada trocando a cor de fundo
do item selecionado para um tom de cinza mais escuro.
O sistema tambm possui a funo de reordenamento das notas, bastando o usurio
clicar e arrastar as notas para qual posio na listagem desejar. Ao fazer esta ao, o sistema
exibe um boto logo acima da primeira nota, solicitando ao usurio um clique para salvar a
nova ordem das notas:
49
Figura 15 - Reordenar notas.
Fonte: Autor, 2015.
Ao clicar no boto, o mesmo some e o sistema tenta salvar a nova ordenao no

banco de dados. Caso a ordenao tenha sucesso, uma mensagem exibindo o sucesso da
operao surge no topo da pgina e aps alguns segundos some:
50
Figura 16 - Reordenao das notas com sucesso.
Fonte: Autor, 2015.
Caso ocorra algum problema durante a execuo da atualizao dos dados no

banco, uma mensagem de erro exibida no topo da pgina:
51
Figura 17 - Reordenao das notas com erro.
Fonte: Autor, 2015.
Neste caso, a nova ordenao no salva no banco de dados e ao recarregar a

pgina as notas so apresentadas na ltima ordem vlida.
Ao lado do ttulo e texto da nota, h dois botes correspondentes a duas
funcionalidades distintas: o cone do lpis, correspondente funo de edio da nota, permite
que ao clicar o usurio seja redirecionado a pgina de edio da nota selecionada; e o cone de
uma lixeira, corresponde a funo de excluso da nota, que ao clicar, uma popup JavaScript
abre questionando se o usurio deseja realmente excluir a nota.
No caso do usurio clicar no cone do lpis (editar a nota) no primeiro registro,
por exemplo, ele ser redirecionado para a pgina de edio de notas, conforme imagem
abaixo:
52
Figura 18 - Tela de edio de uma nota especfica.
Fonte: Autor, 2015.
No caso da Figura 18 acima, antes de enviar o formulrio de edio, h a

validao dos campos (como em todos formulrios do sistema). Caso o usurio deixe algum
campo sem contedo uma mensagem em forma de popup aparece informando os campos que
o usurio deve preencher. Caso passe dessa validao e o sistema consiga atualizar esta nota,
o usurio redirecionado para tela inicial de notas e a seguinte mensagem aparece no topo da
pgina:
53
Figura 19 - Tela inicial de notas com mensagem de nota atualizada com sucesso.
Fonte: Autor, 2015.
Caso no seja possvel salvar as atualizaes da nota, a tela fica idntica da

Figura 19, com exceo da nota atualizada e da mensagem no topo da pgina, que ao invs de
ser de sucesso de erro:
Figura 20 - Mensagem de nota no atualizada (erro).
Fonte: Autor, 2015.
A outra funcionalidade disponvel na tela inicial a de excluso de uma nota

especfica. Nesse caso, ao clicar no cone da lixeira ao lado do ttulo/texto da nota, o sistema
exibe uma popup de confirmao exigindo que o usurio clique em OK para excluir a nota
(clicando em Cancelar, a janela popup fechada e nada alterado na tela de listagem):
54
Figura 21 - Confirmao antes de excluir nota.
Fonte: Autor, 2015.
Ao clicar no boto OK, o sistema envia uma requisio pgina note/del.php,

onde a nota validada e deletada caso passe para rea de segurana, local onde todas as
validaes j foram feitas e os dados podem prosseguir para excluso. Aps remover a nota
(em caso de sucesso), a nota excluda some da tela e a seguinte mensagem exibida e depois
escondida do usurio:
55
Figura 22 - Tela inicial com mensagem de sucesso aps excluso da nota.
Fonte: Autor, 2015.
No caso da Figura 22 acima, a nota some da listagem e excluda da tabela note

no banco de dados. Caso a excluso no obtivesse sucesso, o sistema exibiria a mensagem
abaixo:
Figura 23 - Mensagem de erro aps tentativa de excluso da nota (sem sucesso).
Fonte: Autor, 2015.
At o momento trabalhou-se com as aes em que o usurio j possui notas

cadastradas, porm, caso ele no tivesse, apenas no ficariam disponveis as funes de
reordenao, excluso e edio de notas. Caso o usurio queira incluir uma nota, o passo a ser
seguido acessar a opo Adicionar, na barra de menu superior. A tela exibida neste caso
a seguinte:
56
Figura 24 - Tela de adio de notas.
Fonte: Autor, 2015.
Aps preencher os dados e clicar no boto salvar, os campos so validados e, em

caso de sucesso, a nota inserida e o sistema continua na tela de adio de notas. Se o
usurio clicar no boto em cancelar, o sistema redirecionado para tela de incio das notas
sem nenhuma mensagem no topo. No primeiro caso, o sistema tenta inserir a nota no banco de
dados e em caso de sucesso o sistema recarrega a pgina de adio com uma mensagem de
sucesso conforme a tela abaixo:
57
Figura 25 - Adio de nota com sucesso.
Fonte: Autor, 2015.
Caso a tentativa de adio da nota no tenha xito na insero no banco de dados,

a mensagem abaixo apresentada no topo da pgina adicionar.php:
Figura 26 - Mensagem da tela de adio de nota com erro (nota no inserida).
Fonte: Autor, 2015.
A ltima funo do sistema a de procura de notas pelo ttulo ou texto cadastrado.

Aps clicar no campo de busca, localizado no centro do menu superior, digitar um ttulo ou
texto de uma nota que est procurando, o usurio enviado a pgina search.php,
apresentada conforme abaixo:
58
Figura 27 - Tela de pesquisa de notas com resultados.
Fonte: Autor, 2015.
Caso o usurio digite uma busca sem resultados, a mesma tela apresentada,
porm com a mensagem Nenhuma nota encontrada com o texto ou ttulo informado. No
caso acima, em que h resultados, o usurio pode executar as mesmas aes da tela inicial de
notas, exceto a reordenao de notas.
Vale lembrar que se o usurio apertar a tecla enter do teclado sem digitar nada no
campo de procura, a tela search.php aberta, porm na configurao da Figura 28 abaixo:
Figura 28 - Pesquisa de nota sem nenhum dado informado.
Fonte: Autor, 2015.
A ltima opo do menu superior, a opo Sair, como o prprio nome indica, ao
clicar nela, independente de onde o usurio estiver, o sistema remove os dados da sesso dele,
e o usurio redirecionado para a tela de login com a mensagem Deslogado com sucesso,
conforme a imagem abaixo:
59
Figura 29 - Tela de login aps o usurio clicar na opo Sair.
Fonte: Autor, 2015.
6.3 Tcnicas e padres de segurana implementados
Conforme a norma NBR ISO/IEC 27001 e 27002, especificar em que local a

aplicao ser utilizada e quais so seus usurios um dos primeiros passos de segurana. Por
este motivo, determinou-se que o sistema de notas funcionar em um servidor web dedicado e
que ser usado por funcionrios de uma empresa fictcia, no sendo acessvel ao pblico em
geral.
Para evitar tentativas de cadastro, perda de senha e procedimentos relativos ao
cadastro do usurio, os acessos dos usurios seriam cadastrados pelo gestor de informtica da
empresa, inserindo os novos usurios diretamente no banco de dados.
Para tratar a ameaa conhecida como SQL Injection, diretrizes de segurana do
Site oficial do PHP PHP.NET (2015) e que vo de encontro ao recomendado na seo 4.2
foram utilizadas. O usurio padro do banco de dados (MySQL) do sistema no teve
permisso de acesso total, possuindo apenas as permisses necessrias aplicao. Figura 30,
abaixo:
60
Figura 30 - Permisses dadas ao banco de dados.
Fonte: Autor, 2015.
Outra dica valiosa contra SQL Injection utilizada seguindo as dicas do PHP.NET
(2015) a utilizao das funes addslashes e is_numeric para validar consulta, insero,
atualizao e remoo de dados no banco de dados. Essas duas funes padro do PHP
auxiliam no tratamento a literais e inteiros, respectivamente, e no sistema em questo so
usadas antes de qualquer interao no banco de dados com inteiros ou literais (nicos tipos
utilizados para consulta pelo sistema) no confiveis, conforme a Figura 31 abaixo:
61
Figura 31 - Instrues contra a injeo de cdigo malicioso.
Fonte: Autor, 2015.
Para gerar as senhas dos usurios (e compar-las ao valor armazenado no banco

de dados), a seguinte codificao com MD5, SHA1 e sal foi utilizada:
Figura 32 - Codificao utilizada para as senhas do sistema.
Fonte: Autor, 2015.
O cdigo acima no foi encontrado para decodificao nos principais bancos de

dados de chaves conhecidas mesmo utilizando sal fixa em cada hash gerado. Dentre estes
bancos, destaca-se o site HashKiller (2015) em que, conforme o criador, 43.745 bilhes de
cdigos MD5 e SHA-1 foram catalogados, mas a simples senha a gerada a partir da funo
acima no pde ser decodificada. Para fins de estudo, a senha a codificada com MD5, SHA-
1 e sal conforme a Figura 32 possui o valor 27e93ad5767354dab29c9dd8f6f2f96d. Esta
62
prtica protege contra a adulterao dos dados, conforme a seo 4.3, e respeita as orientaes
de segurana de Howard e LeBlanc (2005) j que no foi criado nenhum cdigo de
criptografia novo.
Os mtodos de proteo de dados confidenciais da seo 4.4, com exceo do uso
de hashes e sal (como citado no pargrafo anterior), no foram aplicados j que os estudos da
mesma so voltados a sistemas em que o software uma aplicao desktop (aplicao
instalada na mquina do usurio) e que permite utilizar informaes do usurio conectado
rede local ou ao computador para proteger seus dados. No caso desta aplicao web esta
forma de proteo dos dados no foi desenvolvida, pois os usurios do sistema no utilizaro
o mesmo computador para acessar o sistema e conforme o Quadro 6 da referida seo, a
relao custo de desenvolvimento, facilidade de instalao e segurana relativa no
compensariam a aplicao destes mtodos.
As validaes das entradas dos dados feitas pelos usurios seguem as diretrizes
abaixo:
Valide se diferente de nulo;

Valide se o tamanho da informao menor ou igual ao definido no banco de
dados;
Valide se o tipo de informao (inteiro, literal, etc.) condiz com o esperado no
banco de dados.
Aps os dados inseridos passarem por estes aspectos, os dados no confiveis

entram no que Howard e LeBlanc (2005) chamam de rea segura, onde os principais danos
causados por entradas maliciosas por exemplo, o estouro de buffer tendem a no ocorrer
ou serem menores. A aplicao direta destes conceitos no sistema elucidada nas duas figuras
abaixo (Figura 33 e Figura 34):
63
Figura 33 - Funes de validao de tipos e tamanhos.
Fonte: Autor, 2015.
O cdigo da Figura 33 acima pertence ao arquivo functions.php, que includo

nos arquivos em que h interao com o banco de dados. Essas funes retornam o boolean
verdadeiro caso os dados estejam no formato e tamanho correto ou falso quando no
esto. A partir dessas validaes, os dados passam a rea segura, como no trecho da pgina
de insero de notas abaixo:
64
Figura 34 - Trecho do cdigo da pgina de insero de notas.
Fonte: Autor, 2015.
Na Figura 34 acima, os dados so validados quanto ao seu tipo e tamanho antes de

chegarem rea de segurana onde os dados esto prestes a serem inseridos no banco de
dados, porm antes de efetuar a requisio e conexo com o banco, para cada valor chamado
o tratamento especfico para validar se os valores no impactaro em algum aspecto de
segurana na SQL, principalmente quanto Injeo de SQL, e s ento, na linha 34, os dados
passam para etapa de insero no banco de dados.
Seguindo os conceitos de segurana abordados por Howard e LeBlanc (2005), foi
utilizada a API PDO_MySql, mantendo-se como regra a parametrizao dos argumentos para
SQL. Esta API foi escolhida baseada nas comparaes feitas pelo PHP.NET (2015), onde a
API PDO_MySQL relacionada como a mais recente introduzida no PHP 5.1 ,
recomendada para criao de novos projetos e com status de desenvolvimento ativo, o que
significa que devem surgir melhorias nas prximas verses do PHP, alm de ser a nica a
suportar SQLs parametrizadas tanto no lado do servidor quanto no lado do cliente. A Figura
35 abaixo demonstra como feita a parametrizao e insero dos dados na pgina de adio
de notas, e corresponde continuao da Figura 34 acima:
65
Figura 35 - Comandos de banco de dados para insero de notas.
Fonte: Autor, 2015.
Na Figura 35 acima, linha 38, o banco de dados instanciado e estende a API

PDO_MySQL, em seguida preparada a SQL para insero dos dados, registra-se os
parmetros com o mtodo bindValue e em seguida executada a query (consulta).
Conforme a seo 4.7 deste trabalho, a adoo desta parametrizao diminui o risco de
Injeo de SQL, j que o prprio banco de dados far tambm a validao desses dados.
Os cookies no foram utilizados em nenhuma parte do sistema (em PHP o
$_COOKIE), pois conforme a seo 4.8, um recurso interessante porm abre mais uma
brecha de segurana, portanto, ao invs de cookies o sistema utilizou session (em PHP o
$_SESSION), trabalhando apenas com dados no lado do servidor e para armazenar dados
inerentes ao usurio: nome, id e id de privilgio.
O sistema no suporta internacionalizao, ou seja, o uso por diversas linguagens
diferentes, no entanto, por ser considerado o padro mais seguro de converso de caracteres,
todas as pginas do sistema possuem o charset (padro de caracteres) definido para UTF-8
(padro recomendado para aplicaes web conforme a seo 4.9). O uso do charset
demonstrado no cabealho da pgina de procura de notas, a search.php:
66
Figura 36 - Charset com UTF-8.
Fonte: Autor, 2015.
Outros procedimentos mais simples de segurana tambm foram seguidos ao

codificar o sistema, tais como:
Utilizao de aspas duplas em todas as propriedades de tags HTML (conforme a

seo 4.8);
No utilizao da funo eval() do JavaScript (conforme a seo 4.8);
Utilizao de caminhos absolutos ao invs de relativos (conforme a seo 4.7);
Validao de literais com expresso regular e somente para os retornos esperados,
no os inesperados ou proibidos (seo 4.6);
Indicao de erros sempre prxima origem, facilitando a manuteno e
descoberta de falhas do cdigo (seo 4.1);
Pastas de dentro do sistema sempre possuem um arquivo index.php para no
permitir a visualizao dos arquivos do diretrio;
Essas foram as principais tcnicas de segurana utilizadas no sistema. Nem todas

foram listadas, pois no caberiam neste documento. Mesmo se tratando de um sistema
simples, quase todas as linhas de cdigo podem receber ou incrementar tcnicas de segurana
apresentadas neste estudo, por isso, escrever todas as tcnicas seria invivel, restringindo esta
seo apenas as mais importantes.
6.4 Resultados e Discusso
Nesta seo apresentado o resultado dos testes de segurana efetuados com o

software Acunetix Vulnerability Scanner, que varreu o sistema em busca de vulnerabilidades
e encontrou 10 alertas de segurana que so categorizados, explicados e discutidos nos
prximos pargrafos.
Para efetuar o teste, o software mencionado foi instalado e configurado para testar
o sistema online, em uma hospedagem e domnio paga na internet (UOL Host). A verificao
67
aplicada com o software demorou 2 horas e 30 minutos, enviou cerca de 30.000 requisies
para o site e apontou 10 alertas. Este nmero total de alertas, separado em 4 nveis de alerta:
o nvel 3 (vulnerabilidade muito perigosa), nvel 2 (vulnerabilidade de mdia periculosidade),
nvel 1 (vulnerabilidade de pequena periculosidade) e nvel 0 (apenas informacional), sendo
apresentado os resultados nessa sequencia. Como o software da Acunetix foi utilizado em sua
verso de avaliao gratuita, os alertas no ofereceram o local exato da falha, apenas
indicaram as vulnerabilidades encontradas, cabendo ao desenvolvedor encontrar o local das
falhas e descobrir como corrigi-la. Alm disso, nessa verso os testes so do tipo caixa
preta, ou seja, sem acesso ao cdigo fonte da aplicao.
Durante a exibio das vulnerabilidades, a correo das mesmas tambm
apresentada, sugerindo tcnicas ou apresentando o cdigo que precisa ser implementado. Por
se tratar de uma rea prtica de baixo referencial terico, grande parte das referncias sobre a
correo dos erros proveniente da experincia prtica de usurios disponibilizadas na
Internet.
A primeira categoria, o nvel alto ou nvel 3, em que as vulnerabilidades so as
mais graves encontradas pelo aplicativo, ficou sem nenhum alerta. Portanto, o sistema
desenvolvido, conforme o software, no possui alguma vulnerabilidade grave, podendo isso
estar atrelado tambm as configuraes de segurana do servidor da UOL que hospedou o
site.
No segundo nvel de vulnerabilidades, as de mdia periculosidade (nvel 2 ou
nvel mdio), foram encontrados trs alertas de segurana.
A primeira vulnerabilidade encontrada neste nvel foi a HTML form without
CSRF protection, em traduo livre Formulrios HTML sem proteo contra CSRF, onde
CSRF a sigla para Cross-Site Request Forgery. A descrio do alerta est na Figura 37
abaixo:
68
Figura 37 - Vulnerabilidade: formulrios HTML sem proteo contra CSRF.
Fonte: Acunetix, 2015.
Segundo Ristic (2005), o CSRF consiste em uma explorao maliciosa pelo qual
comandos no autorizados so transmitidos ao sistema web, a partir da confiana em que o
sistema tem na identidade de um usurio. Esta falha de segurana abordada em praticamente
todas as sees secundrias do Captulo 4, porm de forma superficial, no explicando
exatamente como combater esta ameaa especfica. Conforme a Acunetix (2015), quando
explorada, esta ameaa pode comprometer os dados do usurio no sistema se tratando de um
usurio normal, no caso de um administrador do sistema, pode comprometer a aplicao
inteira.
Para evita-la, conforme o site da fundao Open Web Application Security
Project, a OWASP (2015), deve-se utilizar tokens nos formulrios. Usando tokens, os valores
dos formulrios so codificados e no apresentam o valor digitado pelo usurio. Essa
codificao pode ser feita com hashes de 256 bits do BASE64 encode e, segundo a fundao,
atualmente um dos melhores mtodos para evitar este tipo de ataque.
A segunda vulnerabilidade do nvel 2, foi a Error message on page, em
traduo livre Mensagens de erro na pgina. A descrio do alerta est na Figura 38 abaixo:
69
Figura 38 - Vulnerabilidade: mensagens de erro na pgina.
Conforme a Acunetix (2015), esta falha causada por mensagens de erro no

sistema que podem exibir informaes sensveis, como por exemplo, o local da falha.
Informaes como essa podem ser usadas para iniciar outros ataques portanto devem ser
evitadas.
Para eliminar esta ameaa, a sugesto revisar o cdigo da aplicao,
encontrando locais em que erros podem ocorrer e verificar as mensagens que so exibidas,
modificando-as para que informaes sensveis no sejam exibidas (Acunetix, 2015).
Outra vulnerabilidade encontrada no nvel de segurana mdio, foi o Directory
listing, ou em traduo livre listagem de diretrio. O alerta apresentado pode ser conferido
na integra na Figura 39 abaixo:
70
Figura 39 - Vulnerabilidade: listagem de arquivos do diretrio.
Com esta falha de segurana, usurios maliciosos podem listar todos os arquivos
de um diretrio, podendo acessar ou visualizar informaes confidenciais do sistema ou de
outros usurios (Acunetix, 2015).
No caso do sistema de notas pessoais, o problema tinha sido tratado criando
arquivos index.php dentro de todas as pastas do sistema, mas como pde-se perceber, no foi
a melhor soluo.
Conforme o HTML Staff (2015), este problema pode ser resolvido atravs da
configurao do HTACCESS (Hypertext access) da pgina. O HTACCESS um arquivo do
tipo .htaccess, sem nome, localizado na raiz do sistema, executado no servidor web e que
permite a configurao de diversos aspectos como autenticao, bloqueio de IPs,
configuraes da listagem de diretrios e etc. A simples instruo IndexIgnore * dentro
deste tipo de arquivo, impossibilita que arquivos possam ser listados dos diretrios do
sistema, atenuando ou inibindo esta ameaa.
J no nvel baixo, em que a vulnerabilidade possui baixo grau de periculosidade
(nvel 1), encontrou-se a vulnerabilidade Apache mod_negotiation filename bruteforcing. O
alerta exibido pelo Acunetix foi:
71
Figura 40 - Vulnerabilidade: mod_negotiation do Apache.
Conforme o software, essa falha trata-se de um mdulo do Web Service Apache, o

mod_negotiation, responsvel por selecionar documentos correspondentes as requisies web,
em que, ao usurio ou o sistema enviar um cabealho invlido (header) para uma pgina, ele
emite uma mensagem de erro que lista diretrios, permitindo que usurios mal intencionados
possam conhecer mais informaes sobre o sistema como, por exemplo, uma listagem de
extenses interessantes ou arquivos de backup.
Para solucionar esta falha, conforme um dos relatrios do HackerOne (2015),
deve-se desabilitar a diretiva MultiViews das configuraes do Apache. Utilizando
HTACCESS isso possvel adicionando a instruo Options MultiViews.
Outra vulnerabilidade de nvel 1 encontrada foi a Session Cookie without Secure
flag set, em traduo livre Cookie de sesso sem a flag de segurana configurada. A Figura
41 abaixo exibe o alerta do Acunetix:
72
Figura 41 - Vulnerabilidade: cookie de sesso sem flag de segurana configurada.
Conforme o relatrio, algum cookie de sesso no possui a flag de segurana

configurada para ser acessada somente com SSL (sesso segura, com certificados de
segurana). Essa flag muito importante para a proteo dos cookies de sesso, por isso
quando os cookies de sesso esto atrelados ao acesso restrito dos usurios, ela deve ser
configurada.
Esta falha similar com a prxima vulnerabilidade, por isso sua soluo
apresentada em conjunto com a prxima.
A quinta vulnerabilidade apontada, terceira do nvel 1, trata-se da Session Cookie
without HttpOnly flag set, em traduo livre Cookie de sesso sem a flag HttpOnly
configurada. A Figura 42, abaixo, exibe as informaes desta vulnerabilidade conforme o
software da Acunetix:
73
Figura 42 - Vulnerabilidade: cookie de sesso sem a flag HttpOnly configurada.
Como mencionado, esta vulnerabilidade muito prxima a sua antecessora,

justamente por tambm estar ligada com a segurana da sesso do usurio. Nesse caso, o
relatrio aponta que no h uma flag que defina que os cookies de sesso devam ser acessados
somente pelo lado do servidor, permitindo com essa vulnerabilidade que o lado do cliente
tambm possa acessar as informaes da sesso. Esta vulnerabilidade permite que
informaes dos usurios sejam acessadas ou modificadas, trazendo possveis danos aos
dados do usurio ou do sistema como um todo.
Para corrigir esta falha, bem como a sua antecessora, um tpico do Stack
Overflow (2015), uma espcie de frum dos programadores, descreve que aps adicionar as
duas linhas da imagem abaixo no arquivo HTACCESS, as duas flags so devidamente
configuradas e corrigem os dois erros:
Figura 43 - Corrigindo flag de HttpOnly e SSL dos cookies com HTACCESS.
Fonte: Stack Overflow, 2015.
Com o uso das duas linhas acima, as sesses dos usurios ficam muito mais
seguras, podendo ser acessadas somente pelo lado do servidor e exigindo que o trfego dos
dados da sesso seja feito com HTTPS.
74
A prxima vulnerabilidade da lista, com nvel de segurana baixa (nvel 1),

chamada de Possible sensitive directories, ou em traduo livre Diretrios possivelmente
sensveis. Pelo relatrio da Acunetix, suas informaes foram descritas conforme a imagem
abaixo:
Figura 44 - Vulnerabilidade: diretrios possivelmente sensveis.
Conforme o software, algum diretrio sensvel pde ser encontrado, mesmo sem
ele ser referenciado por algum link ou arquivo dentro do sistema. As informaes contidas
nesses diretrios podem ajudar os invasores a ter informaes sobre o alvo.
Esta falha, corrigida automaticamente aps solucionar a vulnerabilidade de nvel
mdio, a Directory Listing, j que ela instrui o uso de configuraes no HTACCESS para
bloquear a listagem de diretrios do sistema (veja a Figura 39).
Outra vulnerabilidade apontada no relatrio foi a Clickjacking: X-Frame-Options
header missing, em traduo livre Clickjacking: cabealho X-Frame-Options ausente. O
relatrio apresentou as seguintes informaes:
75
Figura 45 - Vulnerabilidade: clickjacking cabealho X-Frame-Options ausente.
O Clickjacking trata-se de uma tcnica maliciosa que consiste em enganar o

usurio de um site ou sistema web, fazendo-o clicar em lugares que paream seguros, porm,
sem perceber, o usurio est permitindo ao invasor acessar informaes confidenciais ou
efetuar operaes maliciosas. Esta vulnerabilidade ocorre pela falta de configurao do
cabealho X-Frame-Options. Sem essa configurao, sites legtimos podem ser includos em
sites maliciosos atravs da tag <frame> ou <iframe> do HTML, levando o usurio a acreditar
que est no site original (ACUNETIX, 2015).
Segundo o site Stop Malvertising (2015), para configurar o cabealho X-Frame-
Options de forma a combater o clickjacking, deve-se inserir a instruo Header set X-Frame-
Options DENY no arquivo HTACCESS. Ainda segundo o site, esta prtica tambm defende
o sistema do CSRF.
No quarto e ltimo nvel, as vulnerabilidades menos perigosas e de caracterstica
apenas informativa (nvel 1), encontrou-se ameaas interessantes como a da Figura 46 abaixo:
76
Figura 46 - Vulnerabilidade: campo de senha com recurso auto completar ativo.
Como descreve o software, esta falha trata-se do recurso auto completar salvo em
cache, permitindo que algum invasor obtenha os dados a partir do cache do navegador. Esse
acesso ao cache permite que ele descubra informaes sensveis sem a permisso do usurio.
Conforme Lucas Peperaio (2015), para solucionar esta falha, a maneira mais
simples utilizar HTACCESS. Segundo ele, o cdigo abaixo inserido em um arquivo
HTACCESS corrige esta vulnerabilidade:
Figura 47 - Solucionando problema de cache com HTACCESS.
Fonte: Autor, 2015.
Salienta-se que esta uma instruo que pode ajudar a combater a falha, mas no
uma garantia de sucesso, visto que atualmente os navegadores esto combatendo falhas
prprias de segurana todos os dias.
A ltima vulnerabilidade encontrada pelo software, foi Possible server path
disclosure (Unix), ou em traduo livre Possvel divulgao do caminho do servidor
(Unix). O software exibiu o seguinte alerta para esta vulnerabilidade:
77
Figura 48 - Vulnerabilidade: possvel divulgao do caminho do servidor (Unix)
Esta vulnerabilidade permite que o invasor conhea o caminho completo do

servidor, informao que pode revelar dados confidenciais como o nome do dono do site,
servidor utilizado ou outras informaes sensveis (Acunetix, 2015).
Conforme o site Security Tweaks (2015), este erro j ocorreu em alguns mdulos
do Wordpress, famoso Content Management System (CMS), ou Sistema de Gerenciamento de
Contedo desenvolvido em PHP, e para corrigir esta vulnerabilidade, basta no permitir a
exibio de erros, j que atravs deles que os invasores conhecem as informaes do
servidor. Para conseguir este efeito, segundo o site, basta adicionar a seguinte linha ao arquivo
HTACCESS: php_flag display_errors off. A instruo configura o PHP para no exibir
erros impossibilitando a exibio do caminho do servidor.
Percebe-se que, apesar de aplicar diversos conceitos e tcnicas para proteger o
pequeno sistema, os resultados da verificao provam que no foi o suficiente para proteger o
sistema de todas as vulnerabilidades. Vale salientar que o software Acunetix possui
catalogadas 528 vulnerabilidades data do trabalho, o que com certeza no representa o total
de vulnerabilidades nas prximas semanas.
Tambm se percebe que a maioria dos erros apontados podem ser corrigidos
atravs de um arquivo HTACCESS, que por sua vez, altera configuraes padro do servidor
ou do PHP instalado no servidor web. Demonstrando que desenvolver um cdigo bem feito e
focado na segurana, pode no ser o suficiente se o servidor web no for bem configurado.
Para finalizar, importante lembrar que se no fosse um sistema bem pequeno,
aplicar tantas tcnicas de segurana teria sido muito trabalhoso, e se houvesse um prazo muito
curto para conclu-lo (fato recorrente em empresas de desenvolvimento de software) seria
78
praticamente impossvel garantir o mnimo de segurana do sistema. Tambm vale salientar

que os softwares so feitos por pessoas, e assim sendo, cometem erros que em alguns casos
nem os prprios conseguem explicar, deixando de fazer correes ou validaes que
normalmente fariam.
79
7 CONSIDERAES FINAIS
O presente trabalho mostrou que aplicar as tcnicas de codificao segura no

uma tarefa fcil, j que para cada aplicao especfica, exige-se que o usurio tenha
permisses e acessos especficos. No caso da pequena aplicao desenvolvida, as
especificidades foram poucas pois foram definidas restrio para apenas quatro funes:
inserir, editar, excluir e pesquisar notas pessoais, tambm no permitindo a insero de novos
usurios.
Testar o sistema com um dos softwares mais recomendados, o Acunetix, foi muito
importante j que grandes empresas o utilizam, no entanto, todo o poder de verificao do
mesmo no pode ser utilizado j que sua verso gratuita no permite testes com acesso ao
cdigo fonte, limitando-se aos testes de caixa preta, o que certamente diminuiu o nmero de
ameaas encontradas.
O trabalho mostrou-se muito interessante em termos de aplicabilidade nas
empresas. Conforme Albuquerque e Ribeiro (2002), as tcnicas de segurana no
desenvolvimento de software precisam ser difundidas por diversos aspectos, entre eles,
devido ao seu impacto positivo na mitigao de riscos para as empresas, sua cooperao com
as polticas de segurana interna nas empresas, fornecem softwares melhores e mais seguros e
contribuem para a urgente necessidade de segurana digital.
Como trabalhos futuros, pretende-se:
a aquisio do software Acunetix, para que seja possvel testar o sistema em todos
seus aspectos, corrigindo todas as ameaas de forma ainda mais simples, j que o
software apresentaria a correo indicada e local da vulnerabilidade;
inserir as funes de gerenciamento de usurios, gerenciamento de permisses e o
uso de tokens com SSL na rea de acesso com senha;
e expandir o sistema de maneira que permita o gerenciamento da vida pessoal do
usurio, adicionado, por exemplo, um mdulo financeiro que permitisse controlar
as finanas pessoais dos usurios.
Entende-se que a apresentao de exemplos, abordagens e aplicao prtica das

tcnicas estudadas tenha contribudo para a difuso de conhecimentos na rea de segurana de
sistemas, principalmente no meio web.
80
REFERNCIAS
ABNT Associao Brasileira de Normas Tcnicas. ABNT NBR ISO/IEC 27002

Tecnologia da informao Tcnicas de segurana Cdigo de prtica para a gesto de
segurana da informao. ABNT, 2005.
ABNT CATLOGO Associao Brasileira de Normas Tcnicas. Site Oficial Para

Compra de Normas. Endereo: <http://www.abntcatalogo.com.br>. Acesso em: 17/01/2015.
ACUNETIX VULNERABILITY SCANNER. Site oficial. Endereo:

<http://www.acunetix.com>. Acesso em 02/01/2015.
ALBUQUERQUE, RICARDO; RIBEIRO, BRUNO. Segurana no desenvolvimento de

software: como garantir a segurana do sistema para seu cliente usando a ISO/IEC.
Rio de Janeiro: Editora Campus, 2002.
BRASIL - TRIBUNAL DE CONTAS DA UNIO. Boas prticas em segurana da

informao. Secretaria de Fiscalizao de Tecnologia da Informao 3. Ed. Braslia:
TCU, 2008.
BRAZ, F. Instrumentao da anlise e projeto de software seguro baseada em ameaas e

padres. Tese (Doutorado em Engenharia Eltrica) - Faculdade de tecnologia, Braslia -
Brasil. 2009.
CAMPOS, A. Sistema de segurana da informao: controlando os riscos. 2.ed.

Florianpolis : Visual Books, 2007.
COMMON CRITERIA PORTAL. Publications: New CC Portal. Disponvel em

<http://www.commoncriteriaportal.org/cc>. Acesso em 02/01/2015.
CRUZ, E. F.; et al. TSDD - Teste de segurana durante o

Desenvolvimento. Unio Educacional Minas Gerais Uniminas Uberlndia, MG
Brasil Artigo para Especializao em Segurana da Informao, 2007.
FERREIRA, FERNANDO NICOLAU FREITAS; ARAJO, MRCIO TADEU DE.
Poltica de Segurana da Informao Guia Prtico para Elaborao e
Implementao. 2. Ed. Revisada Rio de Janeiro: Editora Cincia Moderna Ltda, 2008.
GOMES, K. DA SILVA; SANTOS, NEWTON. Segurana no Desenvolvimento de

Aplicaes Web, Universidade da Amaznia UNAMA Centro de Cincias Exatas e
Tecnolgicas CCET Trabalho de Concluso de Curso do Curso de Bacharel em Cincia
da Computao, 2006.
HACKERONE. #25382 Apache mod_negotiation filename bruteforcing. Disponvel

em: <https://hackerone.com/reports/25382>. Acesso em: 10/01/2015.
HASH KILLER. MD5 Decrypter. Disponvel em: <http://www.hashkiller.co.uk/md5-

decrypter.aspx>. Acesso em: 05/01/2015.
81
HTML STAFF. Htaccess rapidinho: Impedir listagem do diretrio. Disponvel em:

<http://www.htmlstaff.org/ver.php?id=1463>. Acesso em: 20/01/2015.
KHAN, M. U. A.; ZULKERNINE, M. Activity and Artifact Views of a Secure Software

Development Process. International Conference on Computational Science and Engineering.
Vancouver - Canad. IEEE, 2009. Disponvel em:
<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5283250&url=http%3A%2F
%2Fieeexplore.ieee.org%2Fiel5%2F5282954%2F5282955%2F05283250.pdf%3Farnumber%
3D5283250>. Acesso em 02/01/2015.
MICROSOFT. Appendix B: Security Definitions for Vulnerability Work Item

Tracking. Disponvel em: <http://msdn.microsoft.com/library/cc307392.aspx>. Acesso em:
20/11/2014.
MICROSOFT. Appendix B: Security Definitions for Vulnerability Work Item

Tracking. Disponvel em: <http://www.microsoft.com/security/sdl/default.aspx>. Acesso
em: 02/01/2015.
OWASP. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. Disponvel em:
<https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>. Acesso em 20/01/2015.
PEPERAIO, LUCAS. Cache de navegador com .htaccess. Disponvel em:

<http://www.lucaspeperaio.com.br/blog/cache-de-navegador-com-htaccess>. Acesso em:
09/01/2015.
PHP.NET. PHP: Injeo de SQL - Manual. Disponvel em:

<http://php.net/manual/pt_BR/security.database.sql-injection.php> Acesso em: 12/01/2015.
HOWARD, MICHAEL; LEBLANC, DAVID. Escrevendo cdigo seguro: estratgias,

tcnicas prticas para codificao segura de aplicativos em um mundo em rede. 2.ed.
Porto Alegre: Bookman, 2005.
LYRA, MAURCIO ROCHA. Segurana e auditoria em Sistemas de Informao. Rio

de Janeiro: Editora Cincia Moderna Ltda., 2008.
RAMSAROOP, PETER. Cybercrime, Cyberterrorism, and Cyberwarfare: Critical Issues in

Data Protection for Health Services Information Systems. Washington / Estados Unidos da
Amrica : Editora PAHO, 2003.
RISTIC, IVAN. Apache Security. ORelly Media, 2005.
SECURITY TWEAKS. Security Tweak's: HOW TO FIX WORDPRESS FULL PATH

DISCLOSURE ERROR. Disponvel em <http://www.securitytweaks.com/2013/12/how-to-
fix-wordpress-full-path.html>. Acesso em 17/01/2015.
STACK OVERFLOW. php Session cookies http & secure flag - how do you set these?.
Disponvel em <http://stackoverflow.com/questions/22221807/session-cookies-http-secure-
flag-how-do-you-set-these>. Acesso em: 15/01/2015.
82
STOP MALVERTISING. .htaccess HTTP Headers | Securing your website with

.htaccess | Security. Disponvel em < http://stopmalvertising.com/security/securing-your-
website-with-.htaccess/.htaccess-http-headers.html >. Acesso em: 16/01/2015.
THE NEW YORK TIMES - PERLROTH, NICOLE; SANGER, DAVID E. North Korea
Loses Its Link to the Internet. Disponvel em:
<http://www.nytimes.com/2014/12/23/world/asia/attack-is-suspected-as-north-korean-
internet-collapses.html?_r=0>. Acesso em 30/12/2014.
UNICODE CONSORTIUM. Acclaim for Unicode. Disponvel em

<http://www.unicode.org/announcements/quotations.html>. Acesso em: 11/01/2015.

Software Seguro

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Software Seguro

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO SUL DE SANTA CATARINA

ALEXANDRE PEREIRA PRAZERES

PRINCPIOS PARA O DESENVOLVIMENTO DE SOFTWARE SEGURO

ALEXANDRE PEREIRA PRAZERES

PRINCPIOS PARA O DESENVOLVIMENTO DE SOFTWARE SEGURO

Monografia apresentada ao Curso de

Orientadora: Prof. Vera Rejane Niedersberg Schuhmacher, Dra.

ALEXANDRE PEREIRA PRAZERES

PRINCPIOS PARA O DESENVOLVIMENTO DE SOFTWARE SEGURO

Esta Monografia foi julgada adequada

Florianpolis, 14 de abril de 2015.

A Deus, minha famlia, meus amigos, minha

Tente mover o mundo o primeiro passo ser mover a si mesmo (Plato).

Palavras-chave: Cdigo Seguro. Normas e Tcnicas de Segurana. Vulnerabilidades Web.

Keywords: Secure Code. Safety Standards and Techniques. Web Vulnerabilities.

Quadro 1 - Envolvidos na Segurana da Informao. .............................................................. 17

Figura 1 - Etapas do ISMS. ...................................................................................................... 24

Figura 31 - Instrues contra a injeo de cdigo malicioso. .................................................. 61

O uso dos sistemas de informao e das tecnologias de informao mudou

em termos financeiros quanto em termos de imagem da empresa. (HOWARD; LEBLANC,

1.1 PROBLEMTICA E JUSTIFICATIVA

Segundo Howard e LeBlanc (2005), desde os primrdios a propriedade particular

Nas duas prximas sees tercirias, so descritos os objetivos deste trabalho

1.2.1 Objetivo Geral

O presente trabalho tem por objetivo a aplicao de boas prticas de segurana no

1.2.2 Objetivos Especficos

So objetivos especficos do projeto:

1.3 ESTRUTURA DA MONOGRAFIA

No Captulo 1, dada uma breve introduo ao assunto, bem como os objetivos,

A informao , segundo a norma NBR ISO/IEC 27002 (ABNT, 2005), um ativo

Autenticidade: este princpio prega a garantia da veracidade da fonte das

Integridade: consiste na fidedignidade da informao. A informao trafegada

O Tribunal de Contas da Unio (2007) define a segurana da informao sob os

Quadro 1 - Envolvidos na Segurana da Informao.

externo aproveita-se de alguma

Outros fatores que no so controlveis como greves, manifestaes, tempestades,

2.1 FALHAS DE SEGURANA

As falhas de segurana so incidentes de segurana que ocorrem devido

Weak Authentication (Autenticao fraca): cdigos ou controles insuficientes

As falhas citadas acima so bastante comuns e citadas em diversas literaturas a

Quadro 2 - Ameaas Virtuais.

Cdigo malicioso So cdigos que, assim como os vrus,

Como apresentado no Quadro 2 (acima), Ramsaroop (2003) salienta o quanto os

S Spoofing (Falsificao de identidade): se trata da falsificao de identidade

T - Tampering (Adulterao de dados): quando ocorre modificao de

Os efeitos citados acima - conforme a Microsoft (2014) - podem produzir

Conforme Ferreira e Arajo (2008), atualmente h diversas metodologias e

3.1 NBR ISO/IEC 27001 e NBR ISO/IEC 27002

As normas juntas so consideradas o mais completo padro de gerenciamento da

Conforme Ferreira e Arajo (2008), aplicando os conceitos de cada um dos

Figura 1 - Etapas do ISMS.

Fonte: Adaptado de Ferreira e Arajo, 2008.

A Figura 1 acima representa as etapas do Ciclo PDCA, e que segundo Ferreira e

Quadro 3 - Ciclo PDCA, implementao de um SGSI.

Fase I Plan Fase II Do Fase III Check Fase IV Act

3.2 ISO/IEC 15408 (Common Criteria)

A ISO/IEC 15408 uma norma criada a partir de um documento padro do

Este captulo dedicado apresentao de tcnicas que visam diminuir ou

4.1 ESTOURO DE BUFFER

Segundo Howard e LeBlanc (2005), o estouro de buffer um problema muito

Figura 2 - Estouro de Buffer I

Fonte: Howard e LeBlanc, 2005.

No exemplo acima, percebe-se que o programador acredita conhecer o

Figura 3 - Estouro de Buffer II.