SQL Injection se la struttura della tabella / struttura db non è nota

Oltre a ciò che ha detto Philipp, tieni presente che gli attacchi di SQL injection spesso vengono eseguiti senza conoscere la struttura del DB, ma una volta esposta una vulnerabilità, può essere utilizzata per determinare la struttura.

Ad esempio, una delle prime stringhe di input SQL che una volta veniva insegnata era ';shutdown--

Ciò presuppone che l'utente dati fornito sia stato inserito tra virgolette in una query SQL, quindi la prima citazione nella stringa lo chiude e il seguente punto e virgola termina l'istruzione, il che potrebbe causare un errore. Tuttavia, la seguente dichiarazione sarebbe ancora eseguita, che sarebbe shutdown . -- indica che il resto sono commenti. Quindi, questa stringa potrebbe arrestare immediatamente un server se l'input non è stato disinfettato.

Facendo lo stesso passo in avanti in molti sistemi DB, come SQL server, l'elenco delle tabelle di sistema è ben noto e se l'account che stava eseguendo la query aveva privilegi, poteva essere usato per elencare utenti, tabelle, stored procs, visualizzazioni e altre configurazioni SQL. Una volta elencato, possono essere eliminati, esportati e anche la struttura delle tabelle o delle viste potrebbe essere elencata.

Allo stesso modo, le query possono essere costruite per bypassare l'autenticazione, ad esempio con una stringa come ' or '1'='1' --

Una stringa come quella precedente verrebbe inserita in una clausola WHERE e indipendentemente dal nome utente o password forniti, ciò comporterebbe una vera valutazione, consentendo all'utente di autenticarsi senza fornire alcuna credenziale. per esempio:.

SELECT * FROM USERS WHERE UserName = '' or '1'='1' --

In breve, una volta che un attacco di SQL injection ha avuto successo, l'utente malintenzionato ha la possibilità di eseguire codice sul server che dovrebbe essere considerato come se fosse seduto sul server stesso in termini di modellazione delle minacce.

Per evitare gli attacchi, la maggior parte dei framework e dei sistemi DB fornisce un meccanismo per le query parametrizzate. Anche se dovresti controllare la tua piattaforma, le query parametrizzate sono di solito il modo più sicuro. Se devi compilare query SQL tu stesso (ad esempio per passare ad alcune API esterne che lo richiedono), considera di codificarlo correttamente anche se tenterei di evitarlo.

Dipende.

1. In alcune applicazioni Web, le istruzioni SQL sintatticamente errate generano un messaggio di errore che potrebbe essere inoltrato all'output HTML visualizzato dal visitatore. Ciò potrebbe fornire all'atterizzatore alcune informazioni su come appare la query. ("Hai un errore nella tua query SQL vicino a" myapp_tbl_users "."). Per evitare ciò, configurare il server Web in modo che non visualizzi messaggi di errore dettagliati.
2. Ci sono casi in cui gli attacchi con iniezione SQL portano alla stampa del contenuto del database sul frontend. Quando hanno scoperto un simile attacco, possono anche usarlo per produrre meta-informazioni sul database, come le tabelle in esso contenute.
3. Non assumere mai che tutti gli aggressori siano esterni. Un sistema sicuro dovrebbe anche essere sicuro contro gli attaccanti interni che sanno come funziona l'applicazione.
4. Potrebbe esserci una vulnerabilità non correlata nella tua applicazione web che rivela codice sorgente. Di solito non sono così importanti, ma quando c'è anche un'iniezione SQL nella tua app, potrebbe aiutare l'aggressore a ottenere informazioni sulla struttura del tuo database.
5. L'attaccante può solo indovinare. L'ipotesi può essere automatizzata (esegui uno script che bruta-forza i nomi possibili della tabella).

Ma il modo migliore per evitare uno di questi problemi è semplicemente evitare iniezioni SQL in primo luogo. Esistono molti modi migliori per comunicare con il tuo database SQL piuttosto che concatenare le stringhe. Usa stored procedure, istruzioni preparate o un wrapper ORM.

Sì - possono scoprire la struttura del tuo database usando INFORMATION_SCHEMA .

Molti tutorial online, come questo ti parlano attraverso il processo, da un semplice exploit all'estrazione di tutti i dati.

Dal punto di vista dei difensori, potresti negare l'accesso alle tabelle INFORMATION_SCHEMA - dubito che la tua applicazione legittima le abbia mai utilizzate. Tuttavia, in tal caso, un utente malintenzionato potrebbe eseguire la bruta tabella di forza e nomi di colonne, come suggerisce Philipp. Non ho mai visto un'app Web che neghi l'accesso: è meglio spendere il tuo sforzo per prevenire l'iniezione SQL in primo luogo.