Accesso al sito Web utilizzando le credenziali del database

Modifica: ho fatto molte supposizioni in questa risposta che non erano necessariamente vere. Ho appena scoperto che il DB in questione è Postgres. La mia risposta è più adatta a SQL Server, che fino alla versione 2016 non disponeva di sicurezza a livello di riga. Lascerò qui la mia risposta a scopo informativo.

Ciò che stai suggerendo non è certamente la migliore pratica, per molte ragioni. Ciò non significa che non puoi farlo, ma devi essere disposto a concedere tutti questi punti se non lo fai:

Con il tuo modello, qualsiasi utente può accedere direttamente al database senza utilizzare il sito web. (Modifica: si presume che ci si trovi in una intranet locale e gli utenti possano accedere al DB direttamente utilizzando un altro strumento al di fuori del sito Web).

Per questo motivo:

1. Ogni utente può aggiungere / modificare / visualizzare / eliminare informazioni per tutti gli utenti, non solo le proprie informazioni. (Nota: questo non è necessariamente vero se il tuo DB supporta la sicurezza a livello di riga e se lo usi.)
2. Se le credenziali di un solo utente sono compromesse, tutti i dati sono potenzialmente a rischio. (Nota: questo non è necessariamente vero se il tuo DB supporta la sicurezza a livello di riga e se lo usi.)
3. Un utente che accede direttamente al DB potrebbe incidentalmente eseguire query che fanno qualcosa che non intendevano. Possono anche inconsapevolmente bloccare il DB e renderlo inutilizzabile per gli altri.

Ci sono altri motivi per non farlo, ma parliamo invece della "norma". Generalmente gestisci i tuoi utenti dal sito web e poi dai al sito l'accesso al DB con un singolo utente che ha il set minimo di autorizzazioni necessarie. Se si sospetta che la password del DB sia stata compromessa, è sufficiente modificare quella sola password e quindi comunicare al sito Web la nuova password (di solito in un file crittografato di qualche tipo che non è accessibile dal Web). Ciò rende inoltre più semplice fornire diversi livelli di autorizzazioni a diversi utenti, semplicemente controllandone l'accesso nel codice del sito web. Puoi anche diventare molto più granulare, ad esempio potresti consentire ad alcuni utenti di aggiornare solo una particolare colonna di una determinata tabella, se lo desideri.

Fortunatamente, ci sono molte soluzioni gratuite pronte all'uso che gestiscono utenti e ruoli praticamente su ogni piattaforma web popolare. Non riesco davvero a pensare a una buona ragione per sfuggire alla norma per la connessione a un database tramite un sito Web.

Modifica: anche se è possibile che le migliori pratiche di Postgres differiscano dai miei suggerimenti in questa risposta, non sono ancora convinto che fornire un accesso diretto al DB sia migliore del mio suggerimenti. Senza sapere di più su Postgres, preferirei comunque questo modello. Ma potrebbe essere semplicemente perché questo è quello a cui sono abituato.

Ci sono in realtà due domande qui: come autenticare un utente contro un server web e quale utente usare per connettersi al db as.

La vera domanda è, se la sicurezza del database è all'altezza del DBA o del programmatore web?

I server di database sono di lunga durata e sono spesso condivisi da più applicazioni.

Idealmente, autenticherai i tuoi utenti webapp (LAN) contro un server LDAP (aka ActiveDirectory), tramite Kerberos + SPNEGO. Ciò ti offre un'autenticazione centralizzata e single sign-on su molte app.

Potresti anche autenticare gli utenti webapp direttamente dagli utenti db, ad esempio qui . Se è lì che sono presenti tutte le informazioni authn dell'utente e non si utilizza LDAP / Kerberos, potrebbe anche usarlo.

La prossima domanda è quale utente db usare quando ci si connette dal server web:

1. Connetti come utente esperto e aggiungi informazioni "reali" userid alle tue istruzioni SQL (utilizzando i parametri, ovviamente!)
2. Connetti come vero utente db (elimina il pool di connessioni)
3. Connetti come utente limitato e impersonare l'utente reale utilizzando set role

ONE è il più comune, non perché sia una buona idea, ma perché le persone volevano utilizzare il pool di connessioni in passato e non capivano la rappresentazione. Questo calcia il principio del privilegio minimo direttamente nel cavallo.

Ci sono delle vulnerabilità incredibilmente comuni, a fine carriera, rese più probabili dall'opzione 1: SQL Injection e Riferimenti agli oggetti non sicuri :

Il server Web si connette a db come powerUser , Malice accede al sito Web come malice e trova un'iniezione SQL e rilascia la tabella payments , poiché powerUser ha quell'autorità.

Gli sviluppatori web aggiungono l'ID utente allo sql per l'URL /bank-accounts , ma sono stupidi e dimenticano di aggiungere l'ID utente per gli URL di singoli conti bancari (come /bank-accounts/999 ). Malice accede come malice e visualizza bobs saldo bancario.

Questi rischi possono essere ridotti al minimo utilizzando la rappresentazione e la sicurezza delle righe del database (che in sostanza richiede la rappresentazione). PG 9.5 supporta la sicurezza delle righe. Puoi imitarlo nelle versioni precedenti con security_barrier check option visualizzazioni e trigger.

Rende anche più semplice il controllo dei dati, dato che hai il vero nome utente nel tuo db come current_user

Direi che un database come Postgres ha una sicurezza migliore rispetto alla maggior parte dei framework di sicurezza web, così come Row Security, Column Security e ha un buon sistema di ruoli gerarchici.

Ho visto framework di sicurezza web che selezionano tutte le righe per una determinata query, quindi eliminano tutto ciò che non appartiene all'utente X. Ciò stravolge completamente l'impaginazione ed è terribile per le prestazioni. Non ne ho mai visto uno che faccia correttamente la sicurezza Column / Field.