La dipendenza da query parametrizzate è l'unico modo per proteggersi dall'iniezione SQL?

I proc memorizzati non proteggono automaticamente dall'iniezione. Che dire di questo

CREATE PROC proc
  @id VARCHAR(5)
AS
BEGIN
  EXEC("SELECT * FROM Client WHERE ClientId = " + @id);
END

L'utilizzo di query parametrizzate ti proteggerà dall'iniezione, indipendentemente dal fatto che siano in proc o meno.

So is a set of (enforced) rules such as this an appropriate alternative to stored procedures in preventing SQL injection attacks? If not, why not?

No, perché infliggono piuttosto una pesante penalità agli sviluppatori. Una ripartizione per articolo:

1. No client/application had direct access to the database tables.

Utilizza i ruoli. I client dovrebbero essere in grado di accedere al DB solo attraverso un ruolo limitato che ha solo accesso SELECT, INSERT, UPDATE e DELETE a quelle tabelle (e righe, ove possibile) a cui è necessario accedere. Se vuoi assicurarti che nessun cliente possa inviare spam o eliminare tutte le voci, utilizza un'API per la modifica dei dati.

2. All accesses to all tables were through views.

Potrebbe essere qualsiasi cosa, da trascurabile a un enorme costo di prestazioni, a seconda dell'efficienza delle visualizzazioni. È una complessità inutile che rallenta lo sviluppo. Utilizza i ruoli.

3. All data items had a domain specified.

Potrebbe essere molto lavoro da mantenere, e probabilmente dovrebbe essere normalizzato in una tabella separata.

4. No data item was permitted to be nullable - this had implications that had the DBAs grinding their teeth on occasion; but was enforced.

È semplicemente sbagliato. Se gli sviluppatori non sono in grado di gestire NULL s hai grossi problemi.

Can a database be secured against such attacks by database (only) specific measures?

non hai bisogno di stored procedure, usa solo query parametrizzate con una funzione che sfugge agli argomenti, come pg_query_params . Naturalmente, se il tuo database è scrivibile in tutto il mondo o se il ruolo del cliente ha pieno accesso a tutto, sei comunque fregato. Qualcuno deve solo venire e capire cosa sta facendo il cliente, e poi cucinare un client in cinque minuti che distrugge (o peggio, avvelena) il tuo DB.

Non sono sicuro che le tue regole ti proteggano completamente.

Il primo problema è che dichiari che sono applicati ma, oltre ad avere un sovraccarico significativo, non ho mai visto un'applicazione perfetta.

In secondo luogo, la mia lettura di questi è che regole come queste potrebbero rendere le cose più difficili da sfruttare ma non le impediscono. Ad esempio, non avere accesso diretto alle tabelle in realtà non cambia molto se le viste consentono di accedere agli stessi dati. Se il cliente ha bisogno di fare qualcosa, una vista deve facilitarla e, se una vista lo facilita, le stesse funzionalità / dati possono essere utilizzate da un utente malintenzionato.

Ricorda anche che non si tratta solo di aggiornare o cancellare dati. Parte della vulnerabilità con SQL injection è la raccolta di informazioni e per questo non ti importa se i dati sono stati passati indietro attraverso la vista vCustomers o tabella Clienti sottostante. potresti esserti protetto da alcuni punti deboli ma non tutti. Allo stesso modo se gli aggiornamenti possono essere fatti dal client, anche se attraverso i trigger, allora SQL può essere scritto per attivare i trigger e fare aggiornamenti.

(In termini di tutti gli aggiornamenti fatti tramite i trigger, ho intenzione di dire due cose: (1) quando ho letto questo ho fatto un po 'di malessere in bocca e (b) non ti piace Stored Procedure perché sono "meno manutenibili, meno testabili, altamente accoppiati e bloccano un sistema in un unico fornitore", ma si usano trigger su cui si possono sostanzialmente dire le stesse cose.)

Tutto ciò di cui hai bisogno è un buco che permetta l'esecuzione di istruzioni SQL (e non vedo nessuna di queste regole che lo impedisca) e l'autore dell'attacco è dentro. Potrebbero trovarsi dietro un database molto poco intuitivo, ma se sono determinato che li rallenterà piuttosto che fermarli).

L'altra cosa qui è che stai aggiungendo anche la complessità e (oltre al sovraccarico che crea), la complessità tende a creare buchi che possono essere sfruttati.

Non sto dicendo che un tale insieme di regole non possa essere creato - più perché ti daresti fastidio? Sembrano più ingombranti e meno affidabili dei semplici metodi di prevenzione di questo tipo di attacco.