Ho una buona conoscenza di come funzionano le iniezioni di SQL. Vedo che Googling inurl upload.php indicherà uno dei percorsi di caricamento in un sito web. La mia domanda è che se una persona trova un percorso attraverso il quale può caricare solo le immagini, può comunque ottenere iniezioni SQL? Per favore guida.
In realtà possono essere dannosi. Una delle sfide del CTF di 29C3 era in realtà di caricare un'immagine ed eseguire SQLi con esso.
Come funzionava? Bene le immagini hanno i metadati, dopo aver caricato l'immagine, i metadati sono stati estratti e inseriti nel database. Quindi il trucco per ottenere il flag era includere SQL nei metadati. (l'input non è stato correttamente sterilizzato).
Sì e no.
Le immagini sono solo dati e in quanto tali non si differenziano dai campi modulo, dai parametri GET o da qualsiasi altro tipo di dati forniti dall'utente. Non c'è davvero nulla di speciale su di loro, tranne che la maggior parte degli altri dati che riceverai è testuale e che in genere non contengono nulla che "potrebbe somigliare a SQL". Quest'ultima è una falsa ipotesi, dato che la maggior parte dei formati di file di immagini soddisfano i metadati, il che rende estremamente facile incorporarli in SQL e, anche se non lo fanno, creare un file immagine che contiene SQL come parte del flusso di dati binari non dovrebbe essere troppo difficile.
Per farla breve: se hai la parametrizzazione della tua query in ordine (cosa che dovresti comunque), allora hai esattamente tanto da temere come con qualsiasi altro dato fornito dall'utente: finché passi il blob dell'immagine come parametro e le chiamate di parametrizzazione dell'API del database non sono vulnerabili, sei bravo. Se, tuttavia, decidi di concatenare elementi nella tua query che sono stati estratti da un file caricato, hai un problema esattamente identico a quello che avresti se avessi una vulnerabilità SQLi attraverso un campo modulo.
Un'altra cosa che devi cercare con i file caricati è l'esecuzione di codice in modalità remota . Se non stai attento, un utente malintenzionato può caricare un file PHP, mascherato come un'immagine, e ingannare lo script per salvarlo in una posizione dove può essere raggiunto ed eseguito tramite apache (o, peggio, in una posizione dove viene rilevato da un processo locale del sistema, nel peggiore dei casi, uno che viene eseguito come root). Qui la difesa deve verificare e autorizzare il tipo MIME di un file, assicurarsi che la sua estensione corrisponda al tipo MIME, disinfettare (o semplicemente sostituire completamente) il nome del file e memorizzarlo da qualche parte al di fuori della docroot.
I caricamenti di immagini non sono direttamente vulnerabili a SQL injection, a patto che tu stia verificando che l'immagine sia effettivamente un'immagine. Con questo, voglio dire non basandomi semplicemente sul nome del file. Potrebbe essere possibile per qualcuno caricare una "immagine" che non è affatto un'immagine e contiene script di iniezione SQL. Se l'immagine contiene comandi SQL, il caricamento dell'immagine può mettere a rischio l'iniezione SQL indirettamente .
Ci sono tutta una serie di altri potenziali problemi relativi ai caricamenti di immagini, tra cui la possibilità di impedire agli utenti di caricare immagini infette (diversi tipi di immagine possono essere infettati da malware) e, se il sito Web non è creato correttamente, potrebbero essere in grado di usa l'immagine ricavata dal caricamento delle immagini per capire come eseguire un attacco di Directory Traversal. Ma questi sono molto diversi da SQL Injection.
Vedi: (Attacchi correlati)
e infine, quello sotto menziona i passaggi per garantire che l'elemento da caricare sia effettivamente un'immagine.
Il file immagine di per sé non eseguirà l'iniezione SQL, ma il file immagine non viene da solo; include un file nome . Le iniezioni SQL riguardano il codice server, incurante delle stringhe di caratteri all'interno di una richiesta a un database SQL, in cui la stringa inclusa proviene dall'utente remoto potenzialmente ostile. Il nome del file è una stringa che è stata scelta dall'utente remoto. Quindi ...
"Another thing you need to look out for with file uploads is remote code execution. If you don't watch out, an attacker can upload a PHP file, disguised as an image, and trick your script into saving it in a location where it can be reached and executed through apache"
Sì, questo è molto comune. Molti "provider" di shell in realtà lo consiglieranno come metodo di caricamento preferito / predefinito nella descrizione della shell.
Cambiando il nome del file è meglio puntare qui (+1) e alcuni content / file manager lo faranno immediatamente (cioè K2 per Jommla).
Leggi altre domande sui tag sql-injection