Perché utilizzare SQL injection per estrarre password o hash delle password da un database di accesso (che non dovrebbe mai rivelarli legittimamente) è possibile?

C'è un grande divario tra "non richiede" e "implementato dal miglior offerente".

why do we even use full-power database software and SQL queries

Perché se stai già eseguendo un database SQL per i tuoi dati transazionali, l'implementazione di un secondo stack tecnologico con uno staff di supporto e sviluppo adeguatamente addestrato per una funzione molto specifica è molto costoso.

Dato che non riescono a ottenere una pila di domande giusta, come faranno a far fronte a due?

Certamente il problema dell'iniezione SQL deriva da API che non separano il codice (SQL) dai dati (parametri) mentre ci sono altri sistemi di database (e API SQL) che fanno rispettare questa separazione. Ma i database relazionali e i database SQL in particolare forniscono una grande quantità di funzionalità che semplicemente non sono disponibili negli altri tipi di database. Sarebbe molto difficile scrivere un carrello degli acquisti che utilizza LDAP per la persistenza.

IMHO le persone responsabili dello sviluppo di questo sistema sono altrettanto colpevoli quanto l'hacker.

Un altro angolo per la risposta di symbbean.

L'intera situazione sembra piuttosto semplificata. Chi dovrebbe prendersi cura di ciò che può essere interrogato e cosa no? Il sottosistema DB (utilizzando tabelle speciali per l'archiviazione utente), il back-end del server di applicazioni Web o anche un WAF? Per quanto riguarda le query incluse le istruzioni LIKE (ad esempio PasswordHash come 'a%', puoi vedere dove sta andando)? Se andiamo oltre, SQL injection non si limita a rubare le credenziali di accesso. Potrebbero esserci molte informazioni più sensibili che possono essere estratte. Ancora peggio, può portare a RCE sul server DB. E così avanti e avanti.

Sembra più semplice implementare solo misure per prevenire l'iniezione SQL (di questo ovviamente parlo non solo di parametrizzare le istruzioni SQL, ma dell'intero approccio alla difesa per prevenire l'iniezione SQL).

So why do we even use full-power database software and SQL queries to handle the pretty limited needs of username & password authentication at all?. Why aren't there limited-purpose database applications specifically aimed at just doing what a password database needs to do, vs. using general-purpose applications that leave lots of room for SQL injection to occur? What am I missing?

Quello che ti manca è che i database sono strumenti generali progettati per casi di utilizzo diffuso. Quello che stai descrivendo è uno strumento molto specifico, progettato per un caso d'uso molto specifico.

La domanda si riduce a uno di manutenzione e costi. In genere è più economico e più semplice utilizzare strumenti comuni piuttosto che affidarsi a qualcosa di più specifico come si sta descrivendo.

Utilizzato correttamente, un database è perfettamente adatto per memorizzare i dati e interrogarli direttamente dal programma. Non conosco personalmente soluzioni come quelle che descrivi in modo diffuso. Ciò non significa che non esistano, ma implicherebbe che non siano terribilmente comuni.

Inoltre, si tratta di progettazione della sicurezza. Quello che stai descrivendo è un design sicuro. Se il sito web in questione non è stato progettato pensando alla sicurezza, non includerà funzionalità protette come quelle che descrivi.

Essendo il punto, la sicurezza non (generalmente) viene appena fuori dalla scatola. L'impostazione predefinita è normalmente nessuna sicurezza. Se non è progettato e pensato attivamente, non lo otterrai. Questo è uno dei più grandi problemi che dobbiamo affrontare e la sicurezza deve essere pensata sin dall'inizio, non come un ripensamento.

L'aggiunta di più elementi tecnologici allo stack non è un modo economicamente efficace per gestirli e, in generale, la memorizzazione dei dati di autenticazione nel database non è un problema. È più come lo si memorizza e come è possibile accedervi.

Questo ci porta alla tua altra domanda sulle iniezioni SQL. Sono facili da prevenire e mi permetto che la maggior parte dei siti che non sono il risultato di una programmazione pigra e / o di una progettazione di database lenta (non memorizzare le password in testo normale!). Non intendo che sia un suono insultante per chiunque, ma in realtà si riduce al linguaggio o al metodo utilizzato per accedere al database e al modo in cui è implementato.

Ad esempio, PHP aveva i comandi mysql, che poi diventavano mysqli e ora è incoraggiato a usare PDO per le situazioni per risolvere questo problema. La ragione per cui si è verificata la progressione è garantire che qualsiasi input fornito al server sia presentato in un formato valido.

Un'altra cosa che ha attirato la mia attenzione qui è che hai menzionato che i database hanno lo scopo di restituire informazioni leggibili dall'utente. Questo è uno dei molti usi, ma non è esclusivo dello scopo di un database. Il problema non è il database, è come ci si arriva. Ci sono molti casi in cui desideri / devi essere in grado di inviare comandi a un database per motivi molto validi.

Le iniezioni SQL funzionano sull'input e indipendentemente dal fatto che quell'input sia convalidato prima di richiedere informazioni dal server. Quindi, il problema non è il database, è il processo di richiesta di informazioni da esso. Puoi, ovviamente, memorizzare le credenziali in altri formati e alcuni lo fanno, ma questi tendono ad avere una flessibilità limitata.

Inoltre, tieni presente che un'iniezione SQL è solo uno dei tanti vettori di attacco a cui pensare. Ottiene solo un sacco di stampa perché è il modo più semplice per entrare in un sistema configurato in modo improprio.

Un database non è uno strumento di autenticazione. Se hai già utilizzato uno strumento di autenticazione (le credenziali di accesso al sito Web con accesso a computer o applicazione altrove, ad esempio una versione web della tua app finanziaria aziendale), utilizza in ogni caso Active Directory, PAM o RADIUS o qualsiasi altra cosa.

Esecuzione di un secondo database isolato, solo per l'accesso utente della tua app Web accanto all'enorme database che contiene il resto dei loro dettagli, oltre a mantenere l'intermediario di autenticazione, crea più problemi, e alla fine quel database esiste ancora e potrebbe essere violato molti altri modi. Se hanno commesso un errore per consentire l'iniezione SQL, probabilmente farebbero altri errori che potrebbero esporre il database "speciale" direttamente o tramite il loro processore di autenticazione homebrew.