Non dedicare molto tempo a soluzioni alternative o mezze correzioni. Ogni minuto che spendi cercando di implementare qualsiasi cosa suggerita qui è un minuto che avresti potuto spendere per implementare dichiarazioni preparate. Questa è l'unica vera soluzione.

Se hai una vulnerabilità SQLi, l'attaccante probabilmente vincerà alla fine, qualunque cosa tu faccia per cercare di rallentarlo. Quindi tieni presente che mentre puoi apportare miglioramenti, alla fine stai giocando una partita persa a meno che non risolva la causa principale del problema.

Per quanto riguarda quello che hai provato finora: nascondere i messaggi di errore è un buon inizio. Ti consiglio di applicare autorizzazioni ancora più rigorose (vedi sotto). È discutibile se cambiare i nomi delle tabelle aiuta, ma probabilmente non farà male.

Ok, che dire di quei permessi? Limita quanto più possibile ciò che l'utente del database può fare, fino al livello di tabella o persino di colonna. Puoi persino creare più utenti del database per bloccare le cose ancora di più. Ad esempio, utilizza solo un utente del database con il permesso di scrivere quando stai effettivamente scrivendo. Connettiti solo con un utente che ha il diritto di leggere la colonna della password quando hai effettivamente bisogno di leggere la colonna della password. In questo modo, se hai una vulnerabilità di injection in qualche altra query, non può essere sfruttata per far trapelare le password.

Un'altra opzione è usare un firewall per applicazioni web (WAF), come mod_security per Apache. Puoi configurarlo per bloccare le richieste che sembrano sospette. Tuttavia, nessun WAF è perfetto. E ci vogliono tempo ed energia per configurarlo. Probabilmente faresti meglio a usare quel tempo per implementare le dichiarazioni preparate.

Ancora una volta, non lasciare che nulla di tutto ciò ti attiri in un falso senso di sicurezza. Non è possibile sostituire la causa principale del problema.

L'unico modo corretto è utilizzare istruzioni preparate.

1. Se nascondi i messaggi di errore, è un po 'più difficile, ma non fermerà gli aggressori.
2. Puoi limitare i diritti, ma tutti i diritti concessi all'utente potrebbero essere acquisiti dall'aggressore. In alcuni casi è anche possibile eseguire comandi di shell da una SQL-injection.
3. Rinominare le tabelle non ti aiuterà. Lo strumento sqlmap forza bruta i nomi delle tabelle per te carattere per carattere. Questo non richiede molto tempo.

Potresti anche limitare il numero di chiamate, per rendere le cose più difficili per gli aggressori o fare avvisi su chiamate sospette e fermare questo manuale, ma l'unico modo corretto per affrontare questo problema è usare istruzioni preparate. Basta eseguire il grep del codice sorgente e dare un'occhiata alle istruzioni SQL con contenuti dinamici e sostituirli.

Lo sappiamo, ma non abbiamo abbastanza sviluppatori / tester per renderlo sicuro al 100%.

Questo è il vero problema . Finché non assumi più persone o riassegni le priorità, non sei al sicuro. Fermare il 99,9% degli aggressori significa che i tuoi dati sono stati compromessi. Le soluzioni cerotto sono una cosa cattiva e non funzionano. Non perdere tempo a refactoring del tuo modello di accesso SQL mentre potresti risolvere problemi reali.

Per quanto riguarda la soluzione del codice, utilizzare istruzioni preparate, come molte persone qui suggeriscono, è il modo più semplice per usare SQL in sicurezza.

È molto più facile che provare a usare php per ripulire gli argomenti da solo e costa molto meno tempo. Basta grep tutta la tua base di codice per tutto ciò che riguarda SQL e risolverlo.

Elimina definitivamente tutto l'SQL dal codice

La migliore soluzione a questo problema è eliminare tutto il codice SQL come stringhe letterali dal codice e non introdurlo mai più. Utilizza invece il software ORM come Hibernate o Entity Framework. Questo software è comunque molto più piacevole da usare rispetto all'SQL grezzo e parametrizza automaticamente l'SQL quando finisce nel database. Se è possibile per te, segui questa politica.

Se non hai il tempo di apprendere e implementare questi pacchetti, o non puoi usarli per qualche altro motivo, la risposta di trietend è la prossima cosa migliore, usando dichiarazioni preparate. Ciò ti consentirà di essere al sicuro dall'iniezione SQL. Cioè, finché non eserciti alcuna pressione sui tuoi sviluppatori per fornire soluzioni rapide, momento in cui potrebbero dimenticare ancora una volta di parametrizzare una singola variabile, lasciandoti al punto di partenza.

Lo sappiamo, ma non abbiamo abbastanza sviluppatori / tester per renderlo sicuro al 100%.

Non è del tutto chiaro cosa intendi con questa affermazione, come preparata le dichiarazioni sono banali in ogni linguaggio web popolare (PHP, Python, Java, node.js, ecc.) e sono più o meno una misura efficace al 100% contro l'iniezione SQL.

Vuoi dire che subappalti sviluppo e non puoi permetterti di controllare il codice che scrivono per te su contratto? Non puoi permetterti di non farlo: qui sei ancora la parte responsabile.

Vuoi dire che i tuoi sviluppatori sono troppo occupati nell'implementare le funzionalità per impiegare qualche ora per aggiornare la base di codice? Tutto tranne le dichiarazioni preparate richiederà più tempo e costerà di più (ad esempio ORM, obsfucation, autorizzazioni granulari, ecc.).

Vuoi dire che i tuoi sviluppatori non sono abbastanza competenti per eseguire questo semplice compito? Questo è un problema mooolto più grande (o per essere più precisi, SQL injection non dovrebbe essere la tua più grande preoccupazione a quel punto).

Vuoi dire che la tua base di codice è un tale pasticcio di logica spaghetti formattato a fucile code> include che anche sviluppatori competenti impiegheranno un'eternità per eseguire quello che altrimenti sarebbe un semplice compito di poche ore? Allo stesso modo, problema più grande.

Qualunque sia, la soluzione è usare dichiarazioni preparate, circa ieri.

Una volta implementato il consiglio iniziale di "istruzione preparata", consiglierei alcune letture sull'iniezione di SQL. Chiedere "come posso impedire l'iniezione di SQL" è una domanda piuttosto ampia! La sicurezza è un argomento che tu (piuttosto, il tuo intero team di sviluppo) devi conoscere molto per ridurre il rischio di compromissione. Un buco mina tutti gli altri tuoi sforzi.

Visita l'Open Web Application Security Project (OWASP) qui: https://www.owasp.org/index.php/SQL_Injection

In particolare il materiale aggiuntivo:

• Foglio informativo sulla prevenzione di SQL Injection
• Foglio informativo sulla parametrizzazione delle query
• Articolo guida su come evitare le vulnerabilità di SQL injection

E anche

• Come esaminare il codice per le vulnerabilità di SQL injection .

Una misura provvisoria potrebbe essere quella di esaminare un firewall per applicazioni web (WAF): ci sono alcune aziende là fuori che lo forniscono come servizio e alcuni fornitori di cloud che hanno anche offerte. CloudFlare sembra offrirne uno, ho avuto un client che utilizza Incapsula e so che l'offerta AWS WAF ha alcuni set di regole gestiti per SQL injection.

Il modo in cui funziona è che tutto il traffico viene inviato a / attraverso il WAF (includendolo sui server o impostando il DNS in modo che punti al WAF come faresti per un CDN), e cerca cose che sembrano tentativi di SQL injection nei parametri. Non rileva tutti gli attacchi e potrebbe bloccare il traffico legittimo, ma è una soluzione disponibile per i cerotti.

Con "non ho abbastanza sviluppatori" presumo tu intenda che alcune persone influenti nella tua organizzazione pensano che ci siano priorità più alte, quindi qualsiasi risorsa tu abbia è dedicata a queste cose. Quindi risolvere il tuo problema di sicurezza significa perdere altri punti in un'analisi costi-benefici.

Il tuo compito qui è cambiare idea, tanto quanto implementare la correzione. Quantificare la posta in gioco: quale sarebbe il danno, sia in termini economici che di reputazione, di un'altra violazione? Potrebbero esserci leggi nella tua giurisdizione che richiedono di segnalare le violazioni dei dati dei tuoi utenti. Sarebbe imbarazzante? Potrebbero esserci rapporti dei media sulle cattive pratiche della tua organizzazione?

Pensa all'investimento per fissare la sicurezza come un'assicurazione. In retrospettiva, dopo aver saputo che il tuo edificio non è stato bruciato per un periodo di dieci anni, potresti sostenere che i tuoi premi sono stati uno spreco. Ma tu e la tua organizzazione pagate l'assicurazione, perché dovete affrontare un futuro incerto. È la gestione del rischio.

Il rischio ha due fattori: probabilità e impatto. La probabilità di un'altra violazione è alta: sai che può essere eseguita almeno una volta. Se anche le potenziali conseguenze sono negative, dovresti aumentare la priorità di correggere le tue vulnerabilità di sicurezza.

Come tutti hanno già detto, correggi il codice sul sito.

Puoi fare qualsiasi patch desideri su un muro, ma fino a quando il muro non sarà costruito correttamente, qualsiasi patch sarà un problema di sanguinamento ..

Qualsiasi altro suggerimento per pulire il codice è ciò che Linus Torvalds chiamerebbe masterbation.

• Correggi il tuo codice (dai punti di iniezione più ovvi all'ultimo IE Get params) e utilizzare istruzioni preparate. come posso impedire l'iniezione sql in php

  • Puoi provare un WAF (IE ModSecurity ) temporaneamente finché non sarai in grado di sistemare le cose.

  • Prova Forse una sorta di divieto di PI su "persone che testano il sito" o blocca le query non sicure.

  • Se hai la possibilità di creare una schermata di accesso temporanea (sicura) di fronte fino a quando questo non viene risolto.

  • Prova un servizio di terze parti finché non viene risolto qualcosa come cloudflare o qualsiasi altra cosa sia fuori lì.

I PDO sono disponibili dal rilascio di PHP 5.1 nel 24 novembre 2005 ... Gli sviluppatori devono capire che sono conseguenze per le loro cattive abitudini di codifica e personalmente penso che dovrebbe esserci responsabilità per la qualità del lavoro fornito.

In ogni caso i PDO sono una cosa facile da implementare. Se i tuoi sviluppatori non sono in grado di fornire una qualità migliore, allora suggerirei di eliminarli ...

La regola più importante è:

Utilizza librerie, strumenti e API che rendono l'opzione sicura l'opzione più semplice.

Nacht dice "basta usare un ORM "che è un sottoinsieme di questa regola.

Le istruzioni preparate violano questa regola, poiché sono ingombranti da usare, provocano un eccesso di codice, inoltre possono essere spesso più lente delle istruzioni non preparate a seconda Banca dati. Sono una soluzione valida, non criticherò chi li usa, ma non sono necessariamente la soluzione migliore e più conveniente.

E .. vogliamo che l'opzione sicura sia facile e conveniente, quindi il programmatore lo usa per interesse personale e pigrizia. Vogliamo che il programmatore debba effettivamente fare di tutto e investire un po 'di impegno per utilizzare l'opzione non sicura! ...

Una soluzione molto migliore è un'API come Python dbapi. Ho scritto un equivalente in php anni fa, che era come:

  db_query ("SELECT * FROM mytable WHERE id =% s", $ id)  

Questo è più conveniente delle dichiarazioni preparate. Solo una riga per digitare. Inoltre restituisce il risultato in una forma utilizzabile da foreach (), quindi è molto più facile da usare rispetto a fetch () e altre cose. Ancora più importante, il codice nascosto dietro questa API gestirà correttamente l'escape. Ciò rende irrilevanti le SQL injection. Questo gestisce circa il 99% delle query se non si utilizza un ORM. Le query dinamiche (di solito la ricerca) richiedono una gestione speciale, ma è comunque facile.

Se tieni a mente questa regola, a un certo punto ti chiederai perché devi usare htmlspecialchars (), e perché la lingua non ha una caratteristica che renderebbe l'impostazione sicura (cioè, nessun vuln XSS) la più facile da usare? Perchè oh perchè? Ed è allora che rilascia PHP.

Oltre a tutte le ottime risposte finora, se vuoi affrontare il problema specifico dell'estrazione delle credenziali utente, puoi effettuare il refactoring del tuo database per avere le password in una tabella separata con diritti di accesso rigorosi , simile al modo in cui i sistemi Unix le inseriscono in /etc/shadow.

Per verificare le credenziali, è necessaria una procedura memorizzata che prenda la password (o hash) inserita come parametro e restituisca un valore booleano. In altre parole, scarichi il lavoro di verifica delle credenziali sul database e l'hash effettivo non lascia mai il database.

Ciò richiede un refactoring minimo e risolve il tuo problema immediato alla radice, invece di una specifica SQL injection mentre lasciandoti vulnerabile al prossimo.