Become a partner   | Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Che cos'è una SQL Injection (SQLi) e come prevenirla

18/11/21 CoreTech Blog

SQL Injection (SQLi) è un tipo di attacco di iniezione che consente di eseguire istruzioni SQL dannose. Queste istruzioni controllano un server di database dietro un'applicazione web. Gli aggressori possono utilizzare le vulnerabilità di SQL injection per aggirare le misure di sicurezza delle applicazioni. Possono aggirare l'autenticazione e l'autorizzazione di una pagina Web o di un'applicazione Web e recuperare il contenuto dell'intero database SQL. Possono anche utilizzare SQL Injection per aggiungere, modificare ed eliminare record nel database.

Una vulnerabilità SQL Injection può interessare qualsiasi sito Web o applicazione Web che utilizza un database SQL come MySQL, Oracle, SQL Server o altri. I criminali possono utilizzarlo per ottenere l'accesso non autorizzato ai tuoi dati sensibili: informazioni sui clienti, dati personali, segreti commerciali, proprietà intellettuale e altro. Gli attacchi SQL Injection sono una delle vulnerabilità delle applicazioni Web più antiche, diffuse e pericolose. L'organizzazione OWASP (Open Web Application Security Project) elenca le iniezioni nel documento OWASP Top 10 2017 come la minaccia numero uno alla sicurezza delle applicazioni web.

Banner

Come e perché viene eseguito un attacco SQL injection

Per effettuare un attacco SQL Injection, un utente malintenzionato deve prima trovare input di utenti vulnerabili all'interno della pagina Web o dell'applicazione Web. Una pagina Web o un'applicazione Web che presenta una vulnerabilità SQL Injection utilizza tale input dell'utente direttamente in una query SQL. L'attaccante può creare contenuti di input. Tale contenuto è spesso chiamato payload dannoso ed è la parte fondamentale dell'attacco. Dopo che l'autore dell'attacco ha inviato questo contenuto, nel database vengono eseguiti comandi SQL dannosi.

SQL è un linguaggio di query progettato per gestire i dati archiviati in database relazionali. Puoi usarlo per accedere, modificare ed eliminare i dati. Molte applicazioni web e siti web archiviano tutti i dati in database SQL. In alcuni casi, puoi anche utilizzare i comandi SQL per eseguire i comandi del sistema operativo. Pertanto, un attacco SQL Injection riuscito può avere conseguenze molto gravi.

  • Gli aggressori possono utilizzare SQL Injection per trovare le credenziali di altri utenti nel database. Possono quindi impersonare questi utenti. L'utente rappresentato può essere un amministratore di database con tutti i privilegi di database.
  • SQL consente di selezionare e restituire i dati dal database. Una vulnerabilità SQL Injection potrebbe consentire all'aggressore di ottenere l'accesso completo a tutti i dati in un server di database.
  • SQL consente inoltre di modificare i dati in un database e aggiungere nuovi dati. Ad esempio, in un'applicazione finanziaria, un utente malintenzionato potrebbe utilizzare SQL Injection per alterare i saldi, annullare le transazioni o trasferire denaro sul proprio conto.
  • Puoi utilizzare SQL per eliminare i record da un database, anche per eliminare le tabelle. Anche se l'amministratore esegue backup del database, l'eliminazione dei dati potrebbe influire sulla disponibilità dell'applicazione fino al ripristino del database. Inoltre, i backup potrebbero non coprire i dati più recenti.
  • In alcuni server di database è possibile accedere al sistema operativo utilizzando il server di database. Questo può essere intenzionale o accidentale. In tal caso, un utente malintenzionato potrebbe utilizzare un'iniezione SQL come vettore iniziale e quindi attaccare la rete interna dietro un firewall.

Esistono diversi tipi di attacchi SQL Injection: SQLi in banda (utilizzando errori di database o comandi UNION), SQLi cieco e SQLi fuori banda.

Come prevenire un'iniezione SQL

L'unico modo sicuro per prevenire gli attacchi SQL Injection è la convalida dell'input e le query parametrizzate, incluse le istruzioni preparate. Il codice dell'applicazione non deve mai utilizzare direttamente l'input. Lo sviluppatore deve disinfettare tutti gli input, non solo gli input dei moduli Web come i moduli di accesso. Devono rimuovere potenziali elementi di codice dannoso come le virgolette singole. È anche una buona idea disattivare la visibilità degli errori del database sui siti di produzione. Gli errori del database possono essere utilizzati con SQL Injection per ottenere informazioni sul database.

Se scopri una vulnerabilità di SQL Injection, ad esempio utilizzando una scansione Acunetix, potresti non essere in grado di risolverla immediatamente. Ad esempio, la vulnerabilità potrebbe essere nel codice open source. In questi casi, puoi utilizzare un firewall per applicazioni Web per disinfettare temporaneamente l'input.

6 passaggi per prevenire un’iniezione SQL

Prevenire le vulnerabilità di SQL Injection non è facile. Le tecniche di prevenzione specifiche dipendono dal sottotipo di vulnerabilità SQLi, dal motore del database SQL e dal linguaggio di programmazione. Tuttavia, ci sono alcuni principi strategici generali che dovresti seguire per mantenere sicura la tua applicazione web.

Passaggio 1: allenare e mantenere la consapevolezza

Per mantenere sicura la tua applicazione web, tutti coloro che sono coinvolti nella creazione dell'applicazione web devono essere consapevoli dei rischi associati alle vulnerabilità CSRF. Dovresti fornire una formazione sulla sicurezza adeguata a tutti i tuoi sviluppatori, personale addetto al controllo qualità, DevOps e SysAdmins.

Passaggio 2: non fidarsi di alcun input dell'utente

Considera tutto l'input dell'utente come non attendibile. Qualsiasi input dell'utente utilizzato in una query SQL introduce il rischio di un'iniezione SQL. Tratta l'input da utenti autenticati e/o interni allo stesso modo in cui tratti l'input pubblico.

Passaggio 3: utilizzare le whitelist, non le blacklist

Non filtrare l'input dell'utente in base alle blacklist. Un aggressore intelligente troverà quasi sempre un modo per aggirare la tua lista nera. Se possibile, verifica e filtra l'input dell'utente utilizzando solo whitelist rigorose.

Passaggio 4: adotta le ultime tecnologie

Le vecchie tecnologie di sviluppo web non hanno la protezione SQLi. Utilizzare l'ultima versione dell'ambiente e del linguaggio di sviluppo e le ultime tecnologie associate a quell'ambiente/linguaggio. Ad esempio, in PHP usa PDO invece di MySQLi.

Passaggio 5: utilizzare meccanismi verificati

Non provare a creare una protezione SQLi da zero. La maggior parte delle moderne tecnologie di sviluppo può offrire meccanismi per proteggersi da SQLi. Usa questi meccanismi invece di provare a reinventare la ruota. Ad esempio, utilizzare query con parametri o stored procedure.

Passaggio 6: scansiona regolarmente

Le SQL Injection possono essere introdotte dai tuoi sviluppatori o tramite librerie/moduli/software esterni.


Articoli su Sicurezza

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23