Molti servizi offerti su Internet come email, sftp e giochi online possono eseguire autenticazione su database relazionali. Il modulo PAM per Postgres è un esempio in quanto ha avuto una vulnerabilità di SQL injection .
Anche se non è normale eseguire logging in un database, questo può essere utile in alcune situazioni. L'appender del database del framework di registrazione Java log4j non ha fatto alcun tentativo di escape nelle prime versioni di log4j.
Questi due casi sopra sono piuttosto facilmente individuabili in una verifica. Il caso più interessante, tuttavia, dal mio punto di vista è il seguente:
Dato un'applicazione per dipendenti che è in uso da decenni. Quando il software è stato sviluppato molto tempo fa, la sicurezza non era un problema (ad esempio perché i dipendenti potevano fare danni molto maggiori immettendo numeri errati o perché era fatto usando permessi stretti a livello di database).
Conosci quelle brutte vecchie applicazioni nessuno sa come funzionano e nessuno vuole toccare. Se il rischio che i dipendenti facciano cose cattive è accettato, questo funziona bene.
Avanti veloce: Internet è cool. I clienti devono inserire i propri dati in un'applicazione Web autonomamente. L'applicazione internet è stata correttamente verificata. Potrebbe persino utilizzare un database shadow.
Ma alla fine i dati inseriti da persone non fidate vengono ora elaborati usando la vecchia applicazione. Se tali dati vengono salvati nel database o utilizzati nella query, le istruzioni SQL iniettate vengono eseguite con le autorizzazioni del database del dipendente. (Mi spiace, nessun riferimento, ma ho visto che potrebbe accadere troppo spesso nel mondo reale. A volte questo non viene scoperto finché un cliente non ha un nome che include un ').
