Postgres protection from SQL Injection

2

Postgres consente l'esecuzione dinamica del codice, che potrebbe renderlo vulnerabile all'iniezione SQL.

Quali misure protettive ha contro questo?

    
posta LINUX G33NYUS 06.03.2017 - 23:26
fonte

2 risposte

4

Come qualsiasi altro database che usa SQL, usa quanto segue (tratto dal foglio cheat OWASP)

  • Opzione n. 1: uso di istruzioni preparate (query parametrizzate)
  • Opzione n. 2: uso di stored procedure
  • Opzione n. 3: escaping di tutti gli input forniti dall'utente
  • Applica anche: privilegio minimo
  • Esegui anche: Convalida inserimento lista bianca
risposta data 07.03.2017 - 14:14
fonte
2

L'iniezione SQL è una minaccia dell'applicazione, non una minaccia del database. Alla fine, tutti i database relazionali eseguono l'SQL che viene passato a loro come una stringa. Ed è responsabilità dello sviluppatore dell'applicazione assicurarsi che la stringa SQL non sia dannosa.

L'iniezione SQL è un modo per far sì che un'applicazione possa inviare stringhe SQL al database che sono dannose e farlo in un modo che potrebbe non essere ovvio nella prima vista allo sviluppatore dell'applicazione. Per esempio. se l'applicazione contiene codice come

string sql_stmt = "select a from t where k = '" + textfield.text + "'"

dove textfield.text sarebbe un testo inserito dall'utente nell'applicazione e tu invii sql al database, quindi un utente intelligente potrebbe inserire

';drop table t; --

nel campo di testo, che risulterebbe nella stringa

select a from t where k = '';drop table t; --'

viene inviato al database e la tabella t verrebbe eliminata.

Ma questo è un errore dello sviluppatore dell'applicazione, non del database. Il database esegue solo qualsiasi cosa sia stata inviata a SQL. E alla fine deve avere la possibilità di rilasciare tabelle.

Come già affermato da @RoryAlsop nella sua risposta, Postgres - come molti altri database - offre un certo supporto agli sviluppatori di applicazioni per facilitare lo sviluppo di codice sicuro (autorizzazioni, istruzioni preparate, ecc.), ma alla fine è responsabilità del sviluppatore di applicazioni per utilizzare questi o altri metodi per proteggere l'applicazione contro l'iniezione SQL, poiché è lì che si può verificare. I database non sono il livello in cui si tratta di una minaccia, ma solo dove si verifica l'effetto dell'errore.

    
risposta data 10.03.2017 - 20:00
fonte

Leggi altre domande sui tag