Alcune pagine del mio sito Web erano vulnerabili all'iniezione SQL. L'iniezione ha funzionato solo quando l'utente ha effettuato l'accesso. Ora ho risolto questo problema e ora voglio assicurarmi che non rimangano problemi simili. Ho provato a scansionare con sqlninja e sqlmap ma nessuno dei due programmi ha una disposizione per fornire i dettagli di accesso al sito web. Esistono strumenti in grado di eseguire la scansione delle vulnerabilità di iniezione con una sessione di accesso?
Lascia che ti offra un'alternativa più semplice.
È il tuo sito web. Hai accesso al codice sorgente. Guardare attraverso di esso e verificare che tutte le query del database siano parametrizzate. Questo è molto più efficiente della scansione del tuo sito web nella speranza che lo strumento che usi provi l'iniezione giusta nel posto giusto.
Non si "risolvono" i problemi di SQL injection. Bene, le persone lo fanno, ma è sbagliato. Quello che devi fare è non permettere che succedano in primo luogo. Lo strumento principale è, come sottolinea @TerryChia, istruzioni SQL parametrizzate . Le istruzioni SQL parametrizzate sono molto efficaci nella prevenzione degli attacchi SQL injection, essendo una soluzione generica e completa; questo è molto migliore, incomparabilmente migliore di qualsiasi altro tipo di "sanificazione dei dati di input".
Gli attacchi di SQL injection si verificano perché il sito Web sta tentando di interpretare i dati forniti dall'utente (contenuto del campo) come codice (in fondo SQL è un linguaggio di programmazione, dopotutto). Questa strategia di implementazione è condannata. Non può essere veramente "riparato"; vedi questa risposta per alcune discussioni concettuali su questo argomento .
"Quando l'unico strumento che possiedi è un martello, allora tutti i problemi dovrebbero essere unghie, perché li colpisci ripetutamente sulla testa". Tenere presente che le istruzioni SQL parametrizzate, sebbene siano ampiamente applicabili e efficienti (più delle tradizionali istruzioni SQL "dinamiche"), non possono fare tutto ; ci sono contesti molto rari e specifici in cui la creazione dinamica di istruzioni SQL è l'unica soluzione. Ma questa non è la tua situazione - lo sapresti già, e anche tutto ciò che scrivo in questa risposta.
Gli "strumenti di test" dell'iniezione SQL non sono soddisfacenti in alcun modo: non sono pensati per garantire la sicurezza, ma per attaccare il "frutto a basso impatto". Perderanno la stragrande maggioranza delle possibili iniezioni SQL. Il loro scopo è quello di permettere ad un attaccante non tecnico di credere comunque che sia una specie di hacker di alto livello; o per automatizzare i tentativi di attacco su migliaia di siti distinti. Ciò che questi strumenti ti diranno è a senso unico: se riesci a entrare nel tuo sito, allora sai che il sito è estremamente vulnerabile; tuttavia, se non riescono , non sai nulla.
Tuttavia , se vuoi ottenere uno strumento oltre un sistema di "sessione di accesso" (nonostante tutto ciò che ho spiegato sopra), allora dipende da come viene gestito l'accesso. La maggior parte dei siti Web utilizza una "pagina di accesso" che risulta nell'impostazione di un valore del cookie nel client; quel cookie rappresenta lo stato "loggato" ed è sufficiente inviarlo al server per essere considerato parte della "sessione". Gli strumenti di test di iniezione SQL consentono di includere valori di cookie arbitrari nella richiesta, che è ciò che si richiede. Vedi, ad esempio, la documentazione sqlninja (cerca la seconda occorrenza della parola "cookie" in quella pagina) .
Puoi usare webslayer. link .
Webslayer è un'applicazione brute force / applicazione Fuzz. Per verificare l'iniezione dopo l'accesso, attenersi alla seguente procedura.
Avrai bisogno del seguente, un browser e un proxy di intercettazione come webscarab (o l'aggiunta di dati di manomissione di firefox lo farà).
I passaggi 3 - 7 sono il funzionamento standard di webslayer, su cui puoi ottenere un tutorial. Ci sono molti video per questo in Youtube come ( link )
Ciò consentirà di testare eventuali vulnerabilità di iniezione in una sessione connessa.
La maggior parte delle applicazioni web ben scritte ha una logica di login o di convalida della sessione centrale. Quello che faccio in questi casi è semplicemente commentare quella parte del codice nel server di sviluppo . Ora tutti i miei strumenti hanno accesso a tutte le funzionalità.
Le istruzioni SQL parametrizzate sono l'unica risposta affidabile al tuo problema. Forse sqlmap o havij non riescono a identificare il parametro vulnerabile, ma un hacker determinato e abile potrebbe. Quindi, per essere sicuri, disinfettare tutte le query del database.
Leggi altre domande sui tag sql-injection tools mysql