O documento discute os métodos GET e POST no HTTP, explicando que GET envia variáveis na URL enquanto POST envia no corpo da requisição. Também aborda limitações de cada método e ferramentas como Burp Suite e Wireshark para analisar requisições.

1. O GET envia suas variáveis no URL dos navegadores da Web de seus visitantes o que
facilita a visualização do que foi enviado. No entanto, também é muito fácil para os visitantes
alterarem o que foi enviado e, além disso, geralmente há um limite baixo no número de
caracteres que podem ser enviados em um URL - geralmente menos de 250. Como resultado,
se você envia variáveis longas usando GET, é provável que você perca grandes quantidades
delas.
O HTTP GET envia dados no URL de uma maneira muito óbvia:
Observe que a string de consulta (os pares nome / valor) são enviados na URL de uma
solicitação GET:
/teste/demonstracao_form.php?name1=value1&name2=value2
Algumas outras notas sobre solicitações GETi
:
➢ Solicitações GET podem ser armazenadas em cache
➢ As solicitações GET permanecem no histórico do navegador
➢ Solicitações GET podem ser marcadas
➢ As solicitações GET nunca devem ser usadas ao lidar com dados confidenciais
➢ Solicitações GET têm restrições de tamanho
➢ Pedidos GET são usados apenas para solicitar dados (não modificar)
As solicitações GET datam das primeiras versões do HTTP. Portando, GET não tem um
corpo e, até a versão 1.1, não era necessário ter cabeçalhos. (HTTP / 1.1 requer que o
cabeçalho do Host esteja presente em todas as solicitações, para suportar hospedagem
virtual).
Na prática você pode usar o BurpSuite, OWASP ZAP ou qual interceptador para verificar
como os cabeçalhos são analizados. Compartilhe aqui nos comentários qual é o melhor
programa para analisar GET and POST e logo, manipula-los se for o caso do seu
“experimento”.
Na solicitação que é enviada por um navegador HTTP / 1.1 você preenche um formulário
HTML simples para solicitar seu cadastro. Quando inserimos um valor no formulário, o
navegador constrói uma URL composta do campo de ação a partir do formulário seguida
de uma string de consulta contendo todos os parâmetros de entrada do formulário e os
valores fornecidos para eles.
A string de consulta é separada do restante da URL por um ponto de interrogação.
Assim, se o usuário digitar "poupanca", o navegador criará a URL

2. http://finance.uol.com/q?s=poupanca e a solicitação enviada será a seguinte (alguns
cabeçalhos opcionais são omitidos para simplificar):
GET / q? S = poupanca HTTP / 1.1
Host: finance.uol.com
User-Agent: Mozilla / 5.0 (Windows; U; Windows 10; pt-BR; rv: 1.8.0.11)
A resposta que volta do servidor é algo como isto:
HTTP / 1.1 200 OK
Data: Ter, 08 Abr 2018 15:16:46 GMT
Conexão: close
Tipo de Conteúdo: text / html
Relembre que a manipulação de url pelo método GET não é tão comum e fácil devido a
padronizações de segurança. Mas ainda é possível quando usamos burp or owasp
interceptando os valores e verificando se os valores serão aceitos pelo servidor em
questão.
MÉTODO POST
A diferença fundamental entre as solicitações GET e POST é que as solicitações POST
possuem um corpo: conteúdo que segue o bloco de cabeçalhos, com uma linha em
branco separando os cabeçalhos do corpo. Observe que o navegador agora coloca
parâmetros do formulário no corpo da mensagem, em vez de anexá-los ao URL como
parte da string de consulta:
POST / q HTTP / 1.1
Host: finance.uol.com
User-Agent: Mozilla / 4.75 [en] (WinNT; U)
Tipo de Conteúdo: application / x-www-form-urlencoded
Content-Length: 6

3. s = poupanca
A resposta que chega de finance.uol.com é a mesma de quando se usa o método GET,
mas somente porque os criadores do aplicativo de servidor decidiram suportar os dois
métodos de solicitação da mesma maneira:
HTTP / 1.1 200 OK
Data: Ter, 08 Abr 2008 15:33:04 GMT
Conexão: close
Tipo de Conteúdo: text / html
Observe que para entender em uma perspectiva ampla, removi a maioria dos cabeçalhos
opcionais nas solicitações GET e POST e as respostas do servidor para nos
concentrarmos nos parâmetros de comunicação mais essenciais.
Caso você use wireshark para analisar os dados e eu indico o uso para entender como o
excesso de dados pode desencorjar a busca por dados importantes. Portando use o
comando
http.request.method == GET or http.request.method == POST
e você terá uma boa visão das maneiras diferentes que os pacotes são enviados
e recebidos.
➢ HTTP / 1.1 indica o protocolo / versão usada.
➢ 304 é o código de status para "Não modificado". Você pode encontrar todos
os códigos de status HTTP na página w3.org.
➢ Data indica o tempo durante o qual a resposta foi gerada.
Considerações sobre POST

4. O POST envia suas variáveis para no plano de fundo, o que significa que é muito mais difícil
de manipular, e tem um limite muito maior (normalmente vários megabytes) na quantidade
de dados que podem ser enviados. A desvantagem de usar o POST é que os navegadores
não reenviarão automaticamente os dados do post se o usuário clicar no botão Voltar, o que
levará a mensagens como "Os dados nesta página precisam ser reenviados", o que costuma
confundir os usuários. Isso não acontece com o GET, porque os navegadores consideram os
URLs GET iguais a qualquer outro URL e reenviam os dados com prazer, conforme
necessário.
Dica para PHP
Você pode definir quantos dados o PHP deve aceitar editando a entrada post_max_size no
seu arquivo php.ini - normalmente é configurado para 8M por padrão, permitindo que seus
usuários transfiram até 8 megabytes.
--
POST para enviar dados para o formulario.php:
<form action = " formulario.php" method = "post">
<input type = "submit" />
</ form>
Portando, você usa solicitações GET para páginas que apenas lêem dados do servidor. Você
geralmente usa solicitações POST quando o usuário precisa enviar informações por meio de
um formulário.
Algumas outras notas sobre solicitações POST:
➢ As solicitações POST nunca são armazenadas em cache
➢ As solicitações POST não permanecem no histórico do navegador
➢ Pedidos POST não podem ser marcados
➢ Solicitações POST não têm restrições quanto ao tamanho dos dados
Teoria sobre os métodos
Os servidores HTTP / 1.1 não são obrigados a implementar todos os métodos de
solicitação. No mínimo, qualquer servidor de propósito geral deve suportar os métodos

5. GET e HEAD. Todos os outros métodos são opcionais, embora seja difícil encontrar um
servidor com uso comum hoje que não ofereça suporte a solicitações POST. A maioria
dos servidores mais recentes também suporta os métodos PUT e DELETE.
Os servidores podem implementar métodos personalizados e definir restrições e
comportamento de processamento para eles. Essa abordagem só faz sentido para
ambientes fechados e raramente é usada.
ATAQUES
Passagem de diretório
Vamos começar com um simples ataque por diretório. O ataque traversal de diretórios
é uma fraqueza realmente básica, mas pode revelar informações interessantes - às vezes
sensíveis - sobre um sistema da Web. Esse ataque envolve a navegação em um site e a
busca de pistas sobre a estrutura de diretórios do servidor e arquivos confidenciais que
podem ter sido salvos/carregados/expostos intencionalmente ou não.
Crawlers
Um programa spider, como o HTTrack Website, pode rastrear seu site para procurar
todos os arquivos publicamente acessíveis. Para usar o HTTrack, basta carregá-lo, dar
um nome ao seu projeto, dizer ao HTTrack quais sites devem ser espelhados e, depois
de alguns minutos (dependendo do tamanho e da complexidade do site), você terá tudo
o que é publicamente acessível no site armazenado em sua unidade local.
E a análise do website fica a seu critério.
Usando Maltego, também é possível mapear um website e testar alguns vulnerabilidades.
OWASP ZAP
Basta escolhar a pasta e iniciar o método intrusivo em cada diretório.
Bibliografia
Nájera-Gutiérrez, G., & Ansari, J. A. (2018). Web Penetration Testing with Kali Linux - Third
Edition: Explore the methods and tools of ethical hacking with Kali Linux, 3rd Edition.
Birmingham: Packt Publishing.
Sabih, Z. (2018). Learn ethical hacking from scratch: Your stepping stone to penetration testing.
https://www.diffen.com/difference/GET-vs-POST-HTTP-Requests
Web Application Architecture: Principles, Protocols and Practices, 2nd Edition By: Leon Shklar;
Rich Rosen

6. Publisher: John Wiley & Sons Pub. Date: May 18, 2009 Hacking For Dummies® 3rd Edition
By: Kevin Beaver Publisher: For Dummies Pub. Date: January 12, 2010
http://www.httrack.com/
Fortify WebInspect https://software.microfocus.com/en-us/products/webinspect-dynamic-
analysis-dast/overview
Firefox Web Developer (http://chrispederick.com/work/web-developer) for analyzing script code
and performing other manual checks.
SWFScan(https://h30406.www3.hp.com/campaigns/2009/wwcampaign/1-
5TUVE/index.php?key=swf) for analyzing Shockwave Flash (.swf) files.
WSDigger(www.foundstone.com/us/resources/proddesc/wsdigger.htm) for analyzing Web
services.
WSFuzzer(www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project) for analyzing
Web services.
i
https://www.w3schools.com/tags/ref_httpmethods.asp