Difesa generica contro l'iniezione SQL

L'unico approccio generico alla prevenzione dell'iniezione SQL è l'utilizzo di query parametrizzate, note anche come istruzioni preparate. Questi essenzialmente separano i dati dal linguaggio di query a livello di protocollo, quindi il software DBMS non tenterà di analizzare alcun linguaggio di query dai parametri.

Il meccanismo che hai descritto sembra che stia filtrando le richieste con schemi di blacklist, che non è necessariamente una cosa negativa (la difesa in profondità è buona!) ma sembra ridondante se le query vengono gestite correttamente e non possono mai sostituire la vera sicurezza solida pratiche.

Firewall di applicazioni Web come Modsecurity è solo una misura di sicurezza operativa per proteggere l'applicazione Web da input dannosi. WAF è solo un filtro del livello dell'applicazione in grado di confrontare ogni richiesta e risposta con la firma dannosa fornita dal set di regole WAF. Modsecurity Core Rule fornisce una serie di regole generiche complete contro diverse varianti di attacchi. La qualità del WAF dipende dalla qualità delle firme che utilizza e non funzionerà a meno che l'amministratore di sistema non le sintonizzi sulle sue esigenze e scartini le regole che causano falsi positivi. Ma sfortunatamente ciò richiede uno sforzo serio e una profonda conoscenza. Vorrei suddividere la sicurezza in tre fasi

1. Fase di sviluppo (seguire le pratiche di programmazione sicura)
2. Fase di implementazione (Application Hardening tramite Selinux, apparmor)
3. Fase operativa (sicurezza operativa tramite WAF come Modsecurity)

Continuare dal mio sfogo in risposta al polinomio;) ....

La corretta escaping dei parametri dei parametri è una misura preventiva molto semplice - e l'uso del binding di parametri è un modo per ottenerlo.

Un altro approccio (complementare) alla protezione dei dati consiste nel non consentire l'interazione diretta con i dati sottostanti alla sessione dal livello logico - non consentire all'account del server web di SELEZIONARE / AGGIORNARE / ELIMINARE / INSERIRE ... ecc. tabelle di dati - consentono invece di eseguire funzioni e procedure (che hanno autorità delegata). Ma ciò richiede un livello aggiuntivo da implementare su database che non supportano le lingue procedurali / le autorizzazioni trasferite.

Come dice Ali Ahmad, devi configurare gli strumenti a tua disposizione per lavorare bene insieme. Non ci sono circostanze one-config-fits-all.

La mia preferenza per ambienti ad alta sicurezza è quella di richiedere una traduzione linguistica, vale a dire se la mia app è scritta in PHP, quindi passo i parametri della query a un'app non PHP per fare la query; questo aggiunge un po 'di latenza e sovraccarico computazionale. Se stai proteggendo Cose che contano (tm), questo è facilmente valevole - se stai proteggendo lolz forse no.

Nel caso in cui non sia chiaro - piuttosto che prendere parametri da un utente, disinfettandoli e inviandoli a un DB SQL prendo i parametri dall'utente, li disinfettiamo, quindi li passo a un servizio di query che disimballa, disinfetta, riconfeziona e invia a un DB per l'elaborazione. In questo modo, le vulnerabilità in una lingua o API o classe di query ecc. Non sono sufficienti per consentire un compromesso. La sicurezza è fatta meglio nei livelli poiché è difficile essere perfetti su qualsiasi cosa.