Quindi, se alcune parti del codice sono inclini all'iniezione SQL, almeno l'utente non può scrivere nulla nel database se si trova ad usare il front-end che non ha accesso universale in scrittura a tutto?È buona norma per la sicurezza separare gli utenti di lettura e scrittura per un database?
Sì, direi che è buona norma che gli utenti si connettano utilizzando account che consentono solo i privilegi minimi di cui hanno bisogno per utilizzare il sito. Se i tuoi utenti web dovessero leggere solo i dati dal database, creerei sicuramente un account che avesse solo accesso in lettura e che li colpisse attraverso il DB.
La cosa più importante sarebbe proteggere la tua applicazione web. Puoi comunque essere vittima di un devastante attacco SQL Injection anche se un utente non scrive nel tuo database (pensa a numeri di carta di credito o password rubati).
Buon punto a proposito anche l'accesso è abbastanza pericoloso. – Yasser1984
L'approccio è generalmente quello di avere ruoli diversi, non proprio gli utenti di per sé. Per quanto riguarda gli attacchi SQL injection, mi concentrerei sul risolvere il problema a titolo definitivo invece di mitigarlo attraverso questo approccio che proponi.
Sì, tuttavia ci sono molte tecniche di progettazione che possono aiutare a controllare l'interfaccia del database e l'area della superficie.
Si deve assumere che il codice utilizzerà generalmente lo stesso accesso per tutte le sue operazioni in una determinata sessione (letture e scritture). Tuttavia, se un utente non è un utente scrivente, il login utilizzato per la sua sessione non dovrebbe certamente avere alcun diritto di scrittura.
Un buon modo per ridurre l'area di superficie esposta all'iniezione SQL non consiste nell'avere quell'account in grado di aggiornare direttamente le tabelle in primo luogo.
Con accesso in scrittura tramite stored proc, ad esempio, l'unica iniezione che può accadere è eseguire tali procedure con parametri appropriati.
Quindi le procedure dovranno essere eseguite con un utente diverso con autorizzazioni di scrittura e potranno essere eseguite solo dall'utente "di sola lettura". anche questa è una buona idea, sono sicuro che mysql lo supporta, probabilmente anche il resto lo fa. – Yasser1984
@ user893730 Le procedure verranno eseguite per il ruolo utente dell'applicazione. In genere ciò che mi piace vedere è il ruolo utente dell'applicazione con i privilegi minimi: selezionare sulle viste, eseguire sulle procedure, nient'altro. http://dev.mysql.com/doc/refman/5.6/en/grant.html Puoi avere EXECUTE su una routine ma non avere diritti sugli oggetti sottostanti. –
Il più delle volte questo è eccessivo, ma la maggior parte delle volte è necessario utilizzare query parametrizzate che non sono comunque soggette all'iniezione SQL.
Considerare l'utilizzo di stored procedure e un account utente che può solo chiamare procedure, non eseguire direttamente le query.
Se è necessario utilizzare le query dirette e non è possibile utilizzare i parametri per qualche motivo, allora sì, si dovrebbe avere un account utente che può essere letto dal database solo quando ciò è possibile.
Difesa in profondità, piano in caso di fallimento. Le vulnerabilità hanno trovato nelle librerie di query parametrizzate. – rook
Sì. Oltre alle buone risposte di Abe e Cade Roux, può aiutare i revisori della sicurezza a stabilire le priorità e rendere più facile la ricerca forense dopo un attacco.
Esso consente di concentrare gli audit di sicurezza sul codice che utilizza più privilegi - si può spendere più codice di revisione tempo che ha bisogno di privilegi di scrittura di codice che deve privilegi di lettura, e ancora più tempo sul codice che richiede privilegi Drop Table.
Un'altra proprietà piacevole della separazione dei ruoli è che rende più semplice la ricerca forense. Se si dispone di una separazione dei ruoli e si può identificare l'attacco nei registri del database, è possibile restringere il codice che potrebbe essere stato sfruttato, solo il codice che utilizza il ruolo associato all'attacco nei registri.
Sembra che la tua idea di iniezioni SQL provenga da quel buffo fumetto di Bobby Tables.
Ma in realtà, solo una lettura dal database può essere più disastrosa della scrittura.
Inoltre, ho la netta sensazione che NESSUNO dei bravi ragazzi che ha detto "è una buona pratica" lo ha usato nella vita reale. Dì, un frontend (nella vita reale, non immaginaria) deve avere anche l'accesso in scrittura.
Stai abbaiando albero sbagliato.
Se si dispone di alcune parti del codice incline all'iniezione sql: CORREGGERE QUESTE PARTI. Questa è l'unica soluzione sensata.
Un po 'duro ma amato lo http://bobby-tables.com/ lool – Yasser1984
Non ci dovrebbero essere parti del codice soggette all'iniezione SQL. Se pensi che alcuni siano poi cambiati. Limitare i privilegi di lettura/scrittura non sarà sufficiente. – Ben
È un buon punto, ma in questo caso sto lavorando ad un sito web arcaico di asp che fondamentalmente non ha alcuna sanificazione o qualcosa del genere, quindi prima di iniziare a correggere gli script antichi pensavo che questo potesse essere un buon inizio – Yasser1984