sql injection testing tutorial example
Esempi di SQL Injection e modi per prevenire attacchi SQL Injection su applicazioni Web
Durante il test di un sito Web o di un sistema, l'obiettivo del tester è garantire che il prodotto testato sia il più protetto possibile.
Il test di sicurezza viene solitamente eseguito a questo scopo. Per eseguire questo tipo di test, inizialmente, dobbiamo considerare quali attacchi hanno maggiori probabilità di verificarsi. SQL Injection è uno di questi attacchi.
SQL Injection è considerato uno degli attacchi più comuni in quanto può portare conseguenze gravi e dannose al tuo sistema e ai dati sensibili.
Cosa imparerai:
- Cos'è SQL injection?
- Rischi di SQL Injection
- L'essenza di questo attacco
- Strumento consigliato
- Test di sicurezza delle applicazioni Web contro SQL Injection
- Parti vulnerabili di questo attacco
- Automatizzazione dei test di SQL injection
- Confronto con altri attacchi
- Conclusione
- Lettura consigliata
Cos'è SQL injection?
Alcuni degli input dell'utente potrebbero essere utilizzati nell'inquadratura Dichiarazioni SQL che vengono poi eseguiti dall'applicazione sul database. È possibile che un'applicazione NON gestisca correttamente gli input forniti dall'utente.
Se questo è il caso, un utente malintenzionato potrebbe fornire input imprevisti all'applicazione che vengono quindi utilizzati per inquadrare ed eseguire istruzioni SQL sul database. Questo si chiama SQL Injection. Le conseguenze di una simile azione potrebbero essere allarmanti.
Come suggerisce il nome stesso, lo scopo dell'attacco SQL Injection è iniettare il codice SQL dannoso.
Ogni campo di un sito web è come un cancello per il database. Nel form di login l'utente inserisce i dati di login, nel campo di ricerca l'utente inserisce un testo di ricerca, nel form di salvataggio dati l'utente inserisce i dati da salvare. Tutti questi dati indicati vanno al database.
Invece di dati corretti, se viene inserito un codice dannoso, è possibile che si verifichino seri danni al database e all'intero sistema.
SQL Injection viene eseguita con il linguaggio di programmazione SQL. SQL (Structured Query Language) viene utilizzato per la gestione dei dati contenuti nel database. Pertanto durante questo attacco, questo codice del linguaggio di programmazione viene utilizzato come un'iniezione dannosa.
Questo è uno degli attacchi più diffusi, poiché i database vengono utilizzati per quasi tutte le tecnologie.
Molte applicazioni utilizzano alcuni tipi di database. Un'applicazione sotto test potrebbe avere un'interfaccia utente che accetta l'input dell'utente che viene utilizzato per eseguire le seguenti attività:
# 1) Mostra all'utente i dati memorizzati rilevanti, ad es. l'applicazione verifica le credenziali dell'utente utilizzando le informazioni di accesso inserite dall'utente ed espone all'utente solo le funzionalità ei dati pertinenti
#Due) Salvare i dati inseriti dall'utente nel database es. una volta che l'utente compila un form e lo invia, l'applicazione procede al salvataggio dei dati nel database; questi dati vengono poi messi a disposizione dell'utente nella stessa sessione così come nelle sessioni successive
Rischi di SQL Injection
Al giorno d'oggi, un database viene utilizzato per quasi tutti i sistemi e siti Web, poiché i dati dovrebbero essere archiviati da qualche parte.
Poiché i dati sensibili vengono archiviati nel database, la sicurezza del sistema comporta maggiori rischi. Se i dati di un sito web o di un blog personali vengono rubati, non ci saranno molti danni rispetto ai dati che verrebbero rubati dal sistema bancario.
Lo scopo principale di questo attacco è hackerare il database del sistema, quindi le conseguenze di questo attacco possono essere davvero dannose.
Le seguenti cose potrebbero derivare da SQL Injection
- Violazione dell'account di un'altra persona.
- Rubare e copiare i dati sensibili del sito web o del sistema.
- Modifica dei dati sensibili del sistema.
- Eliminazione dei dati sensibili del sistema.
- L'utente può accedere all'applicazione come un altro utente, anche come amministratore.
- L'utente potrebbe visualizzare informazioni private appartenenti ad altri utenti, ad es. dettagli dei profili di altri utenti, dettagli delle transazioni, ecc.
- L'utente può modificare le informazioni di configurazione dell'applicazione e i dati degli altri utenti.
- L'utente può modificare la struttura del database; anche eliminare le tabelle nel database dell'applicazione.
- L'utente può assumere il controllo del server del database ed eseguire comandi su di esso a piacimento.
I rischi sopra elencati possono davvero essere considerati gravi, poiché il ripristino di un database o dei suoi dati può costare molto. Può costare alla tua azienda una reputazione e denaro per ripristinare i dati e il sistema persi. Pertanto si consiglia vivamente di proteggere il sistema da questo tipo di attacco e di considerare i test di sicurezza come un buon investimento per la reputazione del prodotto e della società.
Come tester, vorrei commentare, che testare contro possibili attacchi è una buona pratica anche se Test di sicurezza non è stato pianificato. In questo modo è possibile proteggere e testare il prodotto da casi imprevisti e utenti malintenzionati.
L'essenza di questo attacco
Come accennato in precedenza, l'essenza di questo attacco è hackerare il database con scopi dannosi.
Per eseguire questo test di sicurezza, inizialmente, è necessario trovare le parti di sistema vulnerabili e quindi inviare codice SQL dannoso al database. Se questo attacco è possibile per un sistema, verrà inviato un codice SQL dannoso appropriato e potrebbero essere eseguite azioni dannose nel database.
Ogni campo di un sito web è come un cancello per il database. Qualsiasi dato o input che di solito inseriamo in qualsiasi campo del sistema o del sito Web va alla query del database. Pertanto, invece di correggere i dati, se si digita un codice dannoso, potrebbe essere eseguito nella query del database e portare conseguenze dannose.
Strumento consigliato
# 1) Kiuwan
Trova e correggi facilmente vulnerabilità come SQL injection nel codice in ogni fase dell'SDLC. Kiuwan è conforme ai più severi standard di sicurezza tra cui OWASP, CWE, SANS 25, HIPPA e altri.
Integra Kiuwan nel tuo IDE per un feedback immediato durante lo sviluppo. Kiuwan supporta tutti i principali linguaggi di programmazione e si integra con i principali strumenti DevOps.
=> Scansiona il tuo codice gratuitamente
Per eseguire questo attacco, dobbiamo modificare l'azione e lo scopo di una query di database appropriata. Uno dei metodi possibili per eseguirlo è rendere la query sempre vera e successivamente inserire il codice dannoso. La modifica della query del database in sempre true può essere eseguita con un codice semplice come 'o 1 = 1; -.
I tester dovrebbero tenere presente che mentre si controlla se la modifica della query su sempre true può essere eseguita o meno, è necessario provare virgolette diverse: singole e doppie. Pertanto, se abbiamo provato codice come 'o 1 = 1; -, dovremmo provare anche il codice con virgolette doppie' o 1 = 1; -.
Per esempio, consideriamo che abbiamo una query, che sta cercando la parola inserita nella tabella del database:
seleziona * dalle note nt dove nt.subject = 'search_word';
Pertanto, invece della parola di ricerca, se inseriamo una query SQL Injection 'o 1 = 1; -, la query diventerà sempre vera.
seleziona * dalle note nt dove nt.subject = ‘’ o 1 = 1; -
In questo caso, il parametro 'oggetto' viene chiuso con la virgoletta e quindi abbiamo il codice o 1 = 1, il che rende la query sempre vera. Con il segno “-“ commentiamo il resto del codice della query, che non verrà eseguito. È uno dei modi più popolari e più semplici per iniziare a controllare la query.
Pochi altri codici possono essere utilizzati anche per rendere la query sempre vera, come:
- 'O' abc '=' abc '; -
- 'O' '=' '; -
La parte più importante qui è che dopo il segno di virgola possiamo inserire qualsiasi codice dannoso, che vorremmo essere eseguito.
Per esempio, può essere 'o 1 = 1; rilasciare note sul tavolo; -
Se questa iniezione è possibile, è possibile che venga scritto qualsiasi altro codice dannoso. In questo caso, dipenderà solo dalla conoscenza e dall'intenzione dell'utente malintenzionato. Come controllare SQL Injection?
Il controllo di questa vulnerabilità può essere eseguito molto facilmente. A volte è sufficiente digitare 'o' accedi nei campi testati. Se restituisce un messaggio inaspettato o straordinario, possiamo essere sicuri che SQL Injection è possibile per quel campo.
Per esempio , se ricevi un messaggio di errore come 'Errore interno del server' come risultato della ricerca, possiamo essere certi che questo attacco è possibile in quella parte del sistema.
Altri risultati che possono notificare un possibile attacco includono:
- Pagina vuota caricata.
- Nessun messaggio di errore o di successo - la funzionalità e la pagina non reagiscono all'input.
- Messaggio di successo per codice dannoso.
Diamo un'occhiata in giro a come funziona in pratica.
Per esempio, Esaminiamo se una finestra di accesso appropriata è vulnerabile per SQL Injection. A tale scopo, nel campo dell'indirizzo e-mail o della password, è sufficiente digitare il segno come mostrato di seguito.
Se tale input restituisce un risultato come il messaggio di errore 'Errore interno del server' o qualsiasi altro risultato inappropriato elencato, allora possiamo essere quasi sicuri che questo attacco è possibile per quel campo.
Molto complicato Codice SQL Injection può anche essere provato. Vorrei ricordare che nella mia carriera non ho riscontrato nessun caso in cui ci fosse un messaggio di 'Errore interno del server' come risultato del segno, ma a volte i campi non hanno reagito per codice SQL più complicato.
Pertanto il controllo di SQL Injection con una singola virgoletta 'è un modo abbastanza affidabile per verificare se questo attacco è possibile o meno.
Se la virgoletta singola non restituisce alcun risultato inappropriato, possiamo provare a inserire virgolette doppie e controllare i risultati.
Inoltre, il codice SQL per modificare la query in sempre true può essere considerato come un modo per verificare se questo attacco è possibile o meno. Chiude il parametro e cambia la query in 'true'. Pertanto, se non convalidato, tale input può anche restituire un risultato imprevisto e informare lo stesso che questo attacco è possibile in questo caso.
Il controllo di possibili attacchi SQL può essere eseguito anche dal collegamento del sito web. Supponiamo di avere il link di un sito web come http://www.testing.com/books=1 . In questo caso 'libri' è un parametro e '1' è il suo valore. Se nel collegamento fornito dovessimo scrivere 'segno invece di 1, verificheremo la possibile iniezione.
Quindi link http://www.testing.com/books= sarà come un test se l'attacco SQL è possibile per il sito web http://www.testing.com o no.
In questo caso, if link http://www.testing.com/books= restituisce un messaggio di errore come 'Errore interno del server' o una pagina vuota o qualsiasi altro messaggio di errore imprevisto, quindi possiamo anche essere sicuri che SQL Injection è possibile per quel sito web. Successivamente, possiamo provare a inviare codice SQL più complicato tramite il link del sito web.
Per verificare se questo attacco è possibile tramite il collegamento del sito Web o meno, è possibile inviare anche codice come 'o 1 = 1; -.
In qualità di tester di software esperto, vorrei ricordare che non solo il messaggio di errore imprevisto può essere considerato una vulnerabilità di SQL Injection. Molti tester verificano la presenza di possibili attacchi solo in base ai messaggi di errore.
Tuttavia, va ricordato che nessun messaggio di errore di convalida o messaggio di successo per codice dannoso può anche essere un segno che questo attacco è possibile.
Test di sicurezza delle applicazioni Web contro SQL Injection
Test di sicurezza delle applicazioni web spiegato con semplici esempi:
Poiché le conseguenze di consentire questa tecnica di vulnerabilità potrebbero essere gravi, ne consegue che questo attacco deve essere testato durante il test di sicurezza di un'applicazione. Ora con una panoramica di questa tecnica, comprendiamo alcuni esempi pratici di SQL injection.
Importante: questo test SQL Injection deve essere testato solo nell'ambiente di test.
Se l'applicazione dispone di una pagina di accesso, è possibile che l'applicazione utilizzi l'SQL dinamico come l'istruzione seguente. Questa istruzione dovrebbe restituire almeno una singola riga con i dettagli dell'utente dalla tabella Users come set di risultati quando è presente una riga con il nome utente e la password immessi nell'istruzione SQL.
SELEZIONA * FROM Users WHERE User_Name = ‘' & strUserName & '‘ AND Password = ’' & strPassword & '’; '
Se il tester inserisse John come strUserName (nella casella di testo per il nome utente) e Smith come strPassword (nella casella di testo per la password), l'istruzione SQL sopra sarebbe:
SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;
Se il tester inserisse John'– come strUserName e nessuna strPassword, l'istruzione SQL diventerebbe:
SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;
Notare che la parte dell'istruzione SQL dopo John viene trasformata in un commento. Se nella tabella Utenti fosse presente un utente con il nome utente John, l'applicazione potrebbe consentire al tester di accedere come utente John. Il tester può ora visualizzare le informazioni private dell'utente John.
Cosa succede se il tester non conosce il nome di alcun utente esistente dell'applicazione? In tal caso, il tester potrebbe provare nomi utente comuni come admin, administrator e sysadmin. Se nessuno di questi utenti esiste nel database, il tester potrebbe inserire John 'o' x '=' x come strUserName e Smith 'o' x '=' x come strPassword. Ciò farà sì che l'istruzione SQL diventi come quella seguente.
SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;
Poiché la condizione 'x' = 'x' è sempre vera, il set di risultati sarebbe composto da tutte le righe nella tabella Users. L'applicazione potrebbe consentire al tester di accedere come primo utente nella tabella Utenti.
Importante: il tester dovrebbe richiedere all'amministratore del database o allo sviluppatore di copiare la tabella in questione prima di tentare i seguenti attacchi.
Se il tester inserisse John '; DROP table users_details; ’- come strUserName e qualsiasi cosa come strPassword, l'istruzione SQL diventerebbe come quella sotto.
SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';
Questa istruzione potrebbe causare la cancellazione permanente della tabella 'users_details' dal database.
Sebbene gli esempi precedenti trattino dell'utilizzo della tecnica SQL injection solo nella pagina di accesso, il tester dovrebbe testare questa tecnica su tutte le pagine dell'applicazione che accettano l'input dell'utente in formato testuale, ad es. pagine di ricerca, pagine di feedback, ecc.
L'iniezione SQL potrebbe essere possibile nelle applicazioni che utilizzano SSL. Anche un firewall potrebbe non essere in grado di proteggere l'applicazione da questa tecnica.
Ho cercato di spiegare questa tecnica di attacco in una forma semplice. Vorrei ripetere che questo attacco dovrebbe essere testato solo in un ambiente di test e non nell'ambiente di sviluppo, ambiente di produzione o qualsiasi altro ambiente.
come creare un piano di test per il test del software
Invece di testare manualmente se l'applicazione è vulnerabile o meno agli attacchi SQL, è possibile utilizzare un file Web Vulnerability Scanner che verifica questa vulnerabilità.
Lettura correlata: Test di sicurezza dell'applicazione Web . Controlla questo per maggiori dettagli sulle diverse vulnerabilità web.
Parti vulnerabili di questo attacco
Prima di iniziare il processo di test, ogni tester sincero dovrebbe più o meno sapere quali parti sarebbero più vulnerabili a un possibile attacco.
È anche una buona pratica pianificare esattamente quale campo del sistema deve essere testato e in quale ordine. Nella mia carriera di test, ho imparato che non è una buona idea testare i campi contro gli attacchi SQL in modo casuale poiché alcuni campi possono essere persi.
Poiché questo attacco viene eseguito nel database, tutte le parti del sistema di immissione dei dati, i campi di input e i collegamenti ai siti Web sono vulnerabili.
Le parti vulnerabili includono:
- Campi di accesso
- Campi di ricerca
- Campi commento
- Qualsiasi altro inserimento dati e campi di salvataggio
- Link del sito web
È importante notare che durante il test contro questo attacco non è sufficiente controllare solo uno o pochi campi. È abbastanza comune che un campo possa essere protetto da SQL Injection, ma un altro no. Pertanto è importante non dimenticare di testare tutti i campi del sito web.
Automatizzazione dei test di SQL injection
Poiché alcuni sistemi o siti Web testati possono essere piuttosto complicati e contenere dati sensibili, il test manuale può essere davvero difficile e richiede anche molto tempo. Pertanto testare contro questo attacco con strumenti speciali a volte può essere davvero utile.
Uno di questi strumenti di SQL Injection è SOAP UI . Se disponiamo di test di regressione automatizzati a livello di API, possiamo anche cambiare il controllo rispetto a questo attacco utilizzando questo strumento. Nello strumento SOAP UI sono già presenti modelli di codice preparati per il controllo contro questo attacco. Questi modelli possono anche essere integrati dal tuo codice scritto.
È uno strumento abbastanza affidabile.
Tuttavia, un test dovrebbe già essere automatizzato a livello di API, il che non è così facile. Un altro modo possibile per eseguire il test automaticamente è utilizzare vari plug-in del browser.
Va detto che, anche se gli strumenti automatizzati fanno risparmiare tempo, non sono sempre considerati molto affidabili. Se stiamo testando un sistema bancario o qualsiasi sito web con dati molto sensibili, si consiglia vivamente di testarlo manualmente. Dove puoi vedere i risultati esatti e analizzarli. Inoltre, in questo caso, possiamo essere certi che non è stato saltato nulla.
Confronto con altri attacchi
SQL Injection può essere considerato uno degli attacchi più gravi, poiché influenza il database e può arrecare gravi danni ai tuoi dati e all'intero sistema.
Di sicuro può avere conseguenze più gravi di un'iniezione Javascript o HTML, poiché entrambe vengono eseguite sul lato client. Per confronto, con questo attacco, puoi avere accesso all'intero database.
Va detto che per testare contro questo attacco, dovresti avere una conoscenza abbastanza buona del linguaggio di programmazione SQL e, in generale, dovresti sapere come funzionano le query sui database. Inoltre, mentre esegui questo attacco injection dovresti essere più attento e attento, poiché qualsiasi imprecisione può essere lasciata come vulnerabilità SQL.
Conclusione
Spero che tu abbia un'idea chiara di cosa sia una SQL injection e di come dovremmo prevenire questi attacchi.
Tuttavia, si consiglia vivamente di eseguire un test contro questo tipo di attacco ogni volta che viene testato un sistema o un sito Web con un database. Qualsiasi vulnerabilità del database o del sistema rimanente può costare la reputazione di un'azienda e molte risorse per ripristinare l'intero sistema.
Poiché il test contro questa iniezione aiuta a trovare il massimo importanti vulnerabilità di sicurezza , si consiglia inoltre di investire nelle proprie conoscenze e strumenti di test.
Se è pianificato il test di sicurezza, il test con SQL Injection dovrebbe essere pianificato come una delle prime parti di test.
Hai incontrato qualche tipica iniezione SQL? Sentiti libero di condividere le tue esperienze nella sezione commenti qui sotto.
Lettura consigliata
- Tutorial sull'iniezione di HTML: tipi e prevenzione con esempi
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Tutorial approfonditi su Eclipse per principianti
- Tutorial sui test distruttivi e non distruttivi
- Download dell'eBook Testing Primer
- Test funzionale vs test non funzionale
- Esercitazione sul test SOA: metodologia di test per un modello di architettura SOA
- Tutorial sul test pairwise o sul test per tutte le coppie con strumenti ed esempi