il più grande vantaggio della sicurezza di non utilizzo di stored procedure è la chiarezza. Sai esattamente cosa può fare un account, vedendo quale accesso ha alle tabelle. Con le stored procedure, questo non è necessariamente il caso. Se un account ha la capacità di eseguire la procedura X, ciò limita l'account all'esecuzione di quello e non colpisce una tabella sottostante, ma X può fare qualsiasi cosa. Potrebbe far cadere tabelle, alterare dati, cancellare dati, ecc.
Per sapere cosa può fare un account con le stored procedure, è necessario esaminare la stored procedure. Ogni volta che uno sproc viene aggiornato, qualcuno dovrà vedere cosa fa per assicurarsi che qualcosa non venga inserito "accidentalmente" in esso. Il vero problema con la sicurezza in sprocs viene dall'interno dell'organizzazione, non da parte di aggressori malintenzionati.
Ecco un esempio:
Diciamo che si sta cercando di limitare l'accesso alla tabella dei dipendenti. Senza stored procedure, si nega semplicemente l'accesso al tavolo. Per ottenere l'accesso a qualcuno, in modo abbastanza esplicito, devi chiederti esplicitamente di concedere le autorizzazioni. Certo, potrebbero farti eseguire uno script per concedere l'accesso, ma la maggior parte delle persone cerca almeno di rivedere uno script che altera lo schema del database (supponendo che lo script non aggiorni uno sproc, di cui parlerò di seguito).
Esistono potenzialmente centinaia di stored procedure per un'applicazione. Nella mia esperienza, si aggiornano abbastanza frequentemente, aggiungono un campo qui, ne eliminano uno lì. Affinché qualcuno riesamini il numero di script della procedura di aggiornamento tutto il tempo diventi scoraggiante, e nella maggior parte delle organizzazioni il team del database inizia a esaminare solo rapidamente la procedura (o non guardare tutto) e a spostarla. È qui che entra in gioco il vero problema. Ora, in questo esempio, se qualcuno dello staff IT vuole consentire l'accesso a un tavolo, quella persona deve semplicemente inserire una riga di codice che concede l'accesso o fare qualcos'altro. In un mondo perfetto questo sarebbe catturato. Molti di noi non lavorano in un mondo perfetto.
Il vero problema con le procedure memorizzate è che aggiungono un livello di offuscamento al sistema. Con l'offuscamento arriva la complessità, e con la complessità arriva in definitiva più lavoro per capire e amministrare il sistema sottostante. La maggior parte delle persone nell'IT è oberata di lavoro e le cose scivolano via. In questo caso non si tenta di attaccare il sistema per accedere, si utilizza la persona responsabile del sistema per ottenere ciò che si desidera. Mitnick aveva ragione, nella sicurezza le persone sono il problema.
Gli attacchi di maggioranza contro un'organizzazione vengono dall'interno. Ogni volta che si introduce complessità in qualsiasi sistema, appaiono dei buchi, le cose possono essere trascurate. Non ci credo, pensa a dove lavori. Passare attraverso i passaggi su chi chiederebbe di accedere a un sistema. Presto ti renderai conto che puoi far sì che le persone trascurino le cose al momento giusto. La chiave per penetrare con successo in un sistema con le persone coinvolte è fare qualcosa che sembra innocuo, ma è davvero sovversivo.
Ricorda, se sto cercando di attaccare un sistema: non sono tuo amico; Non ho alcun interesse per i tuoi figli o hobby; Ti userò in qualsiasi modo necessario per ottenere ciò che voglio; Non mi interessa se ti tradisco. L'idea di "ma era mio amico ed è per questo che mi sono fidato che credesse che quello che stava facendo fosse corretto", non è di conforto dopo il fatto.
+1 per l'astrazione ("incapsulato/nascosto") –