Backdoor dopo l'iniezione SQL?

Come dice @Adnan, il peggio è "Pieno compromesso e esistenza di una backdoor". Perché? Mentre giocare con SQL alon non può portare ad alcun compromesso del sistema stesso (basta ricaricare il datatabase da un backup e si dovrebbe essere impostato), i programmi che usano SQL e interagiscono con il sistema hanno capacità molto più elevate.

Ad esempio, è possibile che tu abbia una tabella contenente snippet di modello PHP. Un utente malintenzionato può modificarlo e aggiungere codice dannoso. Se qualcosa dalle tabelle SQL viene eseguito (o anche scaricato su un file - se il file può essere scaricato nella cartella Web, allora un utente malintenzionato potrebbe usarlo per iniettare ed eseguire il proprio PHP), quindi potresti avere un problema .

Quindi scopri dove vengono utilizzati tutti i dati nelle tabelle. Se, in qualsiasi momento, viene salvato o eseguito, vedere se questo è sfruttabile (nel caso del primo, dipende se l'utente malintenzionato può inserire del testo arbitrario nella cartella Web che lo utilizza. Nel caso di quest'ultimo, è quasi sempre un problema). In tal caso, è possibile che il sistema sia stato compromesso e potresti voler eseguire un'installazione pulita.

In caso contrario, cerca i problemi nelle tabelle e correggili se presenti. Assicurati di cambiare nome utente / password (e controlla gli account non autorizzati)

Una cosa interessante da notare è che in SQLite, il comando ATTACH DATABASE può essere usato per introdurre direttamente le vulnerabilità .

Analogamente, il comando SPOOL in SQL * Plus può essere usato se l'iniezione consente l'esecuzione di più comandi.

Se utilizzi uno dei due precedenti, un'installazione pulita sarebbe buona indipendentemente dal modo in cui vengono utilizzati i dati.

Un'iniezione SQL da sola PU CAN portare a un completo compromesso del sistema. Esistono molti modi dai database per accedere al file system locale tramite operazioni di lettura e scrittura. Consideriamo il database in esecuzione come 'root', quindi sarebbe banale leggere il file / etc / shadow. Inoltre, si assume che sia possibile leggere la tabella degli utenti locali del database (selezionare l'utente, passare da mysql.users per esempio) e dopo aver crackato hash banali si maggio essere in grado di SSH nell'host utilizzando il stesse credenziali (abuso del riutilizzo della password). Inoltre, e probabilmente più comunemente, è possibile eseguire comandi del sistema operativo dal database stesso. Xp_cmdshell può essere utilizzato su SQL Server, le funzioni definite dall'utente possono essere create su MySQL e ci sono un sacco di modi per farlo su Oracle - la creazione di funzioni Java è solo una!

Se il tuo database è stato compromesso e non hai intrapreso alcuna procedura per bloccarlo o indurirlo, puoi supporre che sia il peggiore, ovvero che l'autore dell'attacco abbia privilegi trasferiti sul sistema operativo stesso.