⏰ Início: 6 de agosto às 14h (horário de Brasília)
🏁 Término: 7 de agosto às 19h (horário de Brasília)
🚨 Register ASAP: https://lnkd.in/gTKNsyCR
🤯 That’s 30 hours of play in 60+ challenges
🥇 Winners get custom swag!
Vídeo handson explicando como usar o Caido
https://youtu.be/HjZxwcBJl7Y
Quem tá lendo o canal ta pelo menos 2 meses a frente de alguns assuntos LoL 😂
As vezes é meio doido isso de ter um bloco de anotações que guarda um histórico longo.
-> Vi novamente esse post no linkedin.
-> Abri o link pro youtube.
-> Vim pra cá pra divulgar o vídeo.
-> Pensei de colocar na minha lista de vídeos para ver depois.
Like a Psycho. Como se já não tivesse feito esse mesmo fluxo antes.
-> Vi novamente esse post no linkedin.
-> Abri o link pro youtube.
-> Vim pra cá pra divulgar o vídeo.
-> Pensei de colocar na minha lista de vídeos para ver depois.
Like a Psycho. Como se já não tivesse feito esse mesmo fluxo antes.
http://xss.is/ (Errata: my bad, achei que era um site estilo 14.rs kkk. Im too whitehat for those things)
https://ssd-disclosure.com/an-introduction-to-chrome-exploitation-webassembly-edition/?twclid=21y8n917umeet1ee2uzglwbxcy
Ele tem um medium:
https://bxmbn.medium.com/
Github query
lang:php /\$(col|column|field|sort|order_by|sort_by)\w*\s*=\s*\$_(GET|REQUEST)/ /->prepare\s*\(\s*["']SELECT\s+.*\`\$\w+/Então, o que fica de aprendizado nisso é que o prepared statement, mesmo na emulação do PDO, faz sim o papel de evitar que o atacante "saia das aspas" da concatenação.
Contudo, como pode ser visto nesse cenário, essa proteção falha quando temos um código que mistura a construção dinâmica de uma parte da query (como o nome da coluna) com o uso de parâmetros seguros, e o atacante usa um null byte para enganar o próprio analisador (parser) do PDO, convencendo-o a mover o ponto seguro da injeção para um local totalmente vulnerável.
Contudo, como pode ser visto nesse cenário, essa proteção falha quando temos um código que mistura a construção dinâmica de uma parte da query (como o nome da coluna) com o uso de parâmetros seguros, e o atacante usa um null byte para enganar o próprio analisador (parser) do PDO, convencendo-o a mover o ponto seguro da injeção para um local totalmente vulnerável.
Deu um trabalho criar todos esses passos (sim usei IA pra ajudar na explicação mas mesmo assim ela não entendia muitos pontos) hahaha, dá uma reação aí se curtiu
tmj
tmj
Passo 4 (e último): O Backend (MySQL)
Como o PDO encontrou apenas um marcador, ele pega o único valor do
O MySQL recebe a consulta final, já montada e reestruturada:
Como o PDO encontrou apenas um marcador, ele pega o único valor do
execute() (o payload de name) e o insere ali.O MySQL recebe a consulta final, já montada e reestruturada:
SELECTO MySQL executa a primeira parte (\'x' FROM (SELECT table_name AS `\'xfrom information_schema.tables)y;#'#\0` FROM fruit WHERE name = ?
SELECT ... FROM ...;) e, por causa do ponto e vírgula, encerra a instrução. O resto da string é ignorado, e a lista de tabelas é retornada ao atacante.Passo 3: O Parser do PDO (A Confusão)
Agora, vamos analisar com calma como o PDO interpreta essa query que ele mesmo montou.
O Gatilho da Confusão: O parser do PDO encontra a crase de abertura
que encontrar aqui dentro."
A Quebra: No entanto, dentro dessas crases, ele encontra o payload do atacante. O null byte (
A Reinterpretação: Nessa reavaliação, ele vê o
A "Cegueira" do Parser: Imediatamente após, o parser vê o caractere
O resultado é que o PDO conclui que a consulta tem apenas um marcador (
Agora, vamos analisar com calma como o PDO interpreta essa query que ele mesmo montou.
O Gatilho da Confusão: O parser do PDO encontra a crase de abertura
(`\) que estava no código original e pensa: "Ok, estou lendo um nome de coluna. Vou ignorar qualquer ?`
que encontrar aqui dentro."
A Quebra: No entanto, dentro dessas crases, ele encontra o payload do atacante. O null byte (
\0) no final age como um terminador inesperado e quebra a leitura do nome da coluna. O parser fica confuso e reavalia o que acabou de ler.A Reinterpretação: Nessa reavaliação, ele vê o
? não mais como parte de um nome de coluna, mas como um marcador de parâmetro válido.A "Cegueira" do Parser: Imediatamente após, o parser vê o caractere
#. Ele o reconhece como o início de um comentário do MySQL e para de analisar a query ali. Por isso, ele ignora completamente a parte " FROM fruit WHERE name = ?", pois acredita que tudo aquilo é um comentário.O resultado é que o PDO conclui que a consulta tem apenas um marcador (
?) para substituir: aquele que o atacante injetou.