Vale la pena, dal punto di vista della sicurezza, limitare l'utente del server database per il sito Web ASP.NET al solo ESEGUI sulle stored procedure?

Ci sono due ragioni principali (di sicurezza) per fare ciò, al di sopra e al di là dell'utilizzo di query parametriche:

• Applicazione del tipo di parametro
• Minimo privilegio.

Il principio del privilegio minimo richiede che qualsiasi entità (utente o applicazione) acceda solo a qualunque cosa sia necessaria per eseguire l'attività definita. Se non si limita la webapp solo agli SP, l'applicazione potrebbe potenzialmente eseguire query arbitrarie.
Si noti che ciò è rilevante in due situazioni: impedire a un utente malintenzionato, che è riuscito a trovare una vulnerabilità nella propria applicazione (o SQL injection, o qualsiasi altro vuln che potrebbe consentirgli di eseguire codice), dall'esecuzione di query SQL dannose; e, molto meno rischi, gli sviluppatori alla ricerca di scorciatoie non protette e non approvate (o anche di sviluppatori malintenzionati).
Concedere i privilegi di solo EXECUTE sugli SP richiesti, impedirà all'applicazione di eseguire query che non sono state predefinite.

I tipi di parametri di forzatura wrt, mentre è possibile implementarlo in altri modi, questo porta l'applicazione di tipo al database, ma prima che colpisca il server db. Cioè utilizzando i tipi effettivamente definiti nel database e senza saltare saltuariamente un parametro.

Si noti che per fare ciò correttamente ed evitare alcuni errori comuni, si desidera:

1. definisce un account utente specifico per l'applicazione ASP.NET
2. assegna l'account a un ruolo personalizzato DB
3. rimuovi l'account da tutti gli altri ruoli, ad esempio dbo .
4. concedere i privilegi EXECUTE al ruolo DB personalizzato creato
5. rimuove tutti gli altri privilegi su SP, tabelle e altri oggetti DB. Ciò include i ruoli predefiniti "pubblici" e così via.
6. assicurati che il ruolo DB personalizzato non abbia altri privilegi.

Assolutamente.

Tuttavia, è necessario fare attenzione alle stored procedure. Se uno può consentire che vengano passate query arbitrarie, allora sei ancora bloccato nella stessa posizione.

Il principio dei privilegi minimi mi viene in mente qui, ora per essere un po 'aneddotico. In PostgreSQL (sì, mi rendo conto che questa è una domanda di SQL Server, ma potrebbe essere qualcosa a cui prestare attenzione) è possibile per un utente non privilegiato scrivere una funzione che sovraccarica (stessa funzione nome + parametri) che può essere un malintenzionato query. Quando un utente privilegiato esegue questa query, potrebbe pensare che stia utilizzando la funzione di aggiunta predefinita quando in realtà sta utilizzando quella dannosa. Come sviluppatore so che stai creando un incubo di manutenzione, perché ci sarà sempre una query "una tantum" che deve essere scritta. Quindi ecco una domanda, quando crei un nuovo account utente se questa è una query predefinita, non ti sei concesso alcuna protezione aggiuntiva. Si potrebbe obiettare che in effetti si è reso peggio dato che ora si consente a un utente malintenzionato di monitorare il proprio sistema indefinitamente, a meno che non si monitorino costantemente i file di registro per i nuovi utenti. Inoltre, i dati cambiano così l'istruzione UPDATE è il tuo nuovo peggior nemico in quanto consente a qualcuno di inserire javascript direttamente in un record che viene restituito, perché e sto parlando per esperienza, tutti confidano che i dati nel database siano già protetti.

Qui c'è un brutto lato negativo: una volta avevamo questo tipo di regole, ma non tutte le richieste del database si adattano perfettamente alle stored procedure. Quindi, quello che è successo è stato che molti sviluppatori stavano costruendo SQL manualmente all'interno delle procedure memorizzate ed eseguendole lì. Ciò ha portato a un sacco di brutti codici e cattivi potenziali buchi in quanto sp_executsql , almeno in quel momento, sarebbe stato eseguito con autorizzazioni di livello sa una volta all'interno di un processo memorizzato e l'input di sanitizzazione all'interno delle procedure SQL è molto più brutto dell'input di sanitizzazione in un linguaggio di applicazione moderno.

Abbiamo iniziato a utilizzare le operazioni CRUD sulle tabelle e ad applicare la parametrizzazione nel livello applicazione dopo che questo è venuto alla luce.