Perché non solo fare in modo che le query non parametrizzate restituiscano un errore?

L'iniezione di SQL è un problema di sicurezza molto grave, in gran parte perché è così facile sbagliare: il modo ovvio e intuitivo per creare una query che incorpora l'input dell'utente ti rende vulnerabile e il modo giusto per mitigarlo richiede di conoscere i parametri query e iniezione SQL prima.

Mi sembra che il modo ovvio per risolvere questo sarebbe chiudere l'opzione ovvia (ma sbagliata): correggere il motore di database in modo che qualsiasi query ricevuta che utilizza valori hardcoded nella sua clausola WHERE invece di parametri restituisca un bel descrittivo messaggio di errore che indica di utilizzare invece i parametri. Ciò dovrebbe ovviamente avere un'opzione di opt-out in modo che roba come le query ad hoc dagli strumenti di amministrazione continueranno a funzionare facilmente, ma dovrebbe essere abilitata per impostazione predefinita.

Avere questo chiuderebbe l'iniezione di SQL a freddo, quasi da un giorno all'altro, ma per quanto ne so, nessun RDBMS lo fa davvero. C'è qualche buona ragione perché no?

Ci sono troppi casi in cui l'uso di un valore letterale è l'approccio giusto.

Dal punto di vista delle prestazioni, ci sono volte in cui desideri letterali nelle tue query. Immagina di avere un bug tracker in cui una volta che diventa abbastanza grande da preoccuparsi delle prestazioni, mi aspetto che il 70% dei bug nel sistema sarà "chiuso", il 20% sarà "aperto", il 5% sarà "attivo" e 5 % sarà in qualche altro stato. Potrei ragionevolmente voler avere la query che restituisce tutti i bug attivi

SELECT *
  FROM bug
 WHERE status = 'active'

anziché passare la statusvariabile as come bind. Voglio un piano di query diverso a seconda del valore trasmesso per status- Vorrei fare una scansione della tabella per restituire i bug chiusi e una scansione dell'indice sulstatuscolonna per restituire i prestiti attivi. Ora, database diversi e versioni diverse hanno approcci diversi per (più o meno correttamente) consentire alla stessa query di utilizzare un piano di query diverso a seconda del valore della variabile bind. Ma ciò tende a introdurre una discreta quantità di complessità che deve essere gestita per bilanciare la decisione se preoccuparsi di ri-analizzare una query o se riutilizzare un piano esistente per un nuovo valore variabile di bind. Per uno sviluppatore, può avere senso affrontare questa complessità. Oppure può avere senso forzare un percorso diverso quando ho più informazioni su come saranno i miei dati rispetto all'ottimizzatore.

Dal punto di vista della complessità del codice, ci sono anche molte volte in cui ha perfettamente senso avere letterali nelle istruzioni SQL. Ad esempio, se hai una zip_codecolonna che ha un codice postale di 5 caratteri e talvolta ha altre 4 cifre, ha perfettamente senso fare qualcosa come

SELECT substr( zip_code, 1, 5 ) zip,
       substr( zip_code, 7, 4 ) plus_four

anziché passare in 4 parametri separati per i valori numerici. Queste non sono cose che cambieranno mai, quindi renderle variabili di legame serve solo a rendere il codice potenzialmente più difficile da leggere e creare il potenziale che qualcuno legherà i parametri nell'ordine sbagliato e finirà con un bug.

L'iniezione SQL si verifica quando viene creata una query concatenando il testo da un'origine non attendibile e non convalidata con altre parti di una query. Mentre una cosa del genere si verificherebbe più spesso con i letterali di stringa, non sarebbe l'unico modo in cui potrebbe accadere. Una query per valori numerici potrebbe richiedere una stringa immessa dall'utente (che dovrebbe contenere solo cifre) e concatenarsi con altro materiale per formare una query senza le virgolette normalmente associate ai valori letterali delle stringhe; il codice che si fida eccessivamente della convalida lato client potrebbe avere elementi come i nomi dei campi provenienti da una stringa di query HTML. Non è possibile che il codice guardando una stringa di query SQL possa vedere come è stata assemblata.

L'importante non è se un'istruzione SQL contenga valori letterali di stringa, ma piuttosto se una stringa contenga sequenze di caratteri da fonti non attendibili e la migliore convalida di ciò dovrebbe essere gestita nella libreria che crea query. In genere in C # non è possibile scrivere codice che consenta una stringa letterale ma che non permetta altri tipi di espressione di stringa, ma si potrebbe avere una regola di pratiche di codifica che richiede che le query vengano costruite usando una classe di creazione di query piuttosto che concatenazione di stringhe e chiunque passi una stringa non letterale al generatore di query deve giustificare tale azione.

SELECT count(ID)
FROM posts
WHERE deleted = false

Se vuoi mettere i risultati di questi nel piè di pagina del tuo forum, devi aggiungere un parametro fittizio solo per dire falso ogni volta. Oppure l'ingenuo programmatore web cerca come disabilitare quell'avviso e poi continua.

Ora puoi dire che aggiungerai un'eccezione per gli enum ma che apre di nuovo il buco (anche se più piccolo). Per non parlare delle persone che devono prima essere istruite per non usarle varchars.

Il vero problema dell'iniezione è la costruzione programmatica della stringa di query. La soluzione è un meccanismo di procedura memorizzata che ne impone l'utilizzo o una whitelist di query consentite.

TL; DR : dovresti limitare tutti i letterali, non solo quelli nelle WHEREclausole. Per motivi che non lo fanno, consente al database di rimanere disaccoppiato da altri sistemi.

Innanzitutto, la tua premessa è difettosa. Vuoi limitare solo le WHEREclausole, ma non è l'unico posto in cui l'input dell'utente può andare. Per esempio,

SELECT
    COUNT(CASE WHEN item_type = 'blender' THEN 1 END) as type1_count,
    COUNT(CASE WHEN item_type = 'television' THEN 1 END) AS type2_count)
FROM item

Questo è ugualmente vulnerabile all'iniezione SQL:

SELECT
    COUNT(CASE WHEN item_type = 'blender' THEN 1 END) FROM item; DROP TABLE user_info; SELECT CASE(WHEN item_type = 'blender' THEN 1 END) as type1_count,
    COUNT(CASE WHEN item_type = 'television' THEN 1 END) AS type2_count)
FROM item

Quindi non puoi semplicemente limitare i letterali nella WHEREclausola. Devi limitare tutti i letterali.

Ora ci rimane la domanda "Perché consentire letteralmente?" Tenetelo a mente: mentre i database relazionali sono usati sotto un'applicazione scritta in un'altra lingua una grande percentuale del tempo, non v'è alcun requisito che è necessario utilizzare il codice di applicazione per utilizzare il database. E qui abbiamo una risposta: hai bisogno di letterali per scrivere codice. L'unica altra alternativa sarebbe richiedere che tutto il codice sia scritto in una lingua indipendente dal database. Quindi averli ti dà la possibilità di scrivere "codice" (SQL) direttamente nel database. Questo è un prezioso disaccoppiamento e sarebbe impossibile senza i letterali. (Prova a scrivere nella tua lingua preferita qualche volta senza letterali. Sono sicuro che puoi immaginare quanto sarebbe difficile.)

Come esempio comune, i letterali vengono spesso utilizzati nella popolazione di tabelle di elenchi di valori / di ricerca:

CREATE TABLE user_roles (role_id INTEGER, role_name VARCHAR(50));
INSERT INTO user_roles (1, 'normal');
INSERT INTO user_roles (2, 'admin');
INSERT INTO user_roles (3, 'banned');

Senza di essi, dovresti scrivere il codice in un altro linguaggio di programmazione solo per popolare questa tabella. La capacità di farlo direttamente in SQL è preziosa .

Ci resta quindi un'altra domanda: perché le librerie client del linguaggio di programmazione non lo fanno? E qui abbiamo una risposta molto semplice: avrebbero implementato nuovamente il parser dell'intero database per ogni versione supportata del database . Perché? Perché non c'è altro modo per garantire che hai trovato ogni letterale. Le espressioni regolari non sono sufficienti. Ad esempio: contiene 4 letterali separati in PostgreSQL:

SELECT $lit1$I'm a literal$lit1$||$lit2$I'm another literal $$ with nested string delimiters$$ $lit2$||'I''m ANOTHER literal'||$$I'm the last literal$$;

Provare a farlo sarebbe un incubo per la manutenzione, soprattutto perché una sintassi valida spesso cambia tra le principali versioni dei database.