I riferimenti diretti insicuri e l'iniezione SQL potrebbero essere risolti utilizzando la sicurezza a livello di riga e le stringhe di connessione per utente?

Question

I riferimenti diretti insicuri e l'iniezione SQL potrebbero essere risolti utilizzando la sicurezza a livello di riga e le stringhe di connessione per utente?

#1 da (3 voti)
#2 da (1 voti)

1

Riguardo alle seguenti vulnerabilità OWASP:

Riferimenti agli oggetti diretti non sicuri . Con ciò intendo lasciare che qualcuno veda /account/123/not-theirs (questo potrebbe essere il riferimento sbagliato che sto usando sopra).
SQL Injection .

Possono essere risolti utilizzando un database che supporti la sicurezza a livello di riga e creando account utente reali nel database per ciascun utente e facendoli accedere al database come se stessi (tramite il server Web)?

Qualche problema in questo approccio di essere a conoscenza di (oltre a uccidere il pool di connessioni)?

Modifica

Ovviamente è necessario un qualche tipo di controllo di accesso ai record. In che modo lo spostamento del controllo degli accessi dei record dal livello Web al livello del database peggiora, quando è più centralizzato? (I database tendono a vivere più a lungo delle applicazioni e talvolta i database hanno più di un'applicazione.)

L'autenticazione utente (archiviazione) avviene in un sistema diverso.

Gli utenti non sono superutenti e avrebbero i privilegi minimi richiesti (per questo intendo che non possono eseguire shell di comandi in SQL o altre sciocchezze).

Gli utenti non avrebbero accesso diretto a db, solo accesso attraverso un'applicazione web.

Utilizzerebbe i ruoli gerarchici.

Utilizzerebbero comunque query parametrizzate, tuttavia non tutte le query sono parametrizzabili, gli sviluppatori commettono errori e sistemi come Wordpress hanno dimostrato che i plugin possono farti ottenere.

sql-injection authorization web-application databases

posta Neil McGuigan 22.03.2015 - 23:32

fonte

2 risposte

Leggi altre domande sui tag sql-injection authorization web-application databases

Netflix può dire se sono dietro una VPN? [duplicare] Questa pagina di Facebook ha un aspetto diverso: tentativo di phishing?

score 3 · Answer 1

Non efficacemente, no. Avrai sempre casi in cui la sicurezza a livello di riga non può emulare correttamente i processi di business. Avresti anche bisogno di avere molti account "general purpose" per cose come la registrazione degli utenti. Il tutto sarebbe contorto, difficile da mantenere, e in gran parte inefficace.

Tenere presente, inoltre, che l'iniezione SQL potenzialmente non riguarda solo i dati, ma anche il database. I comandi speciali (come xp_cmdshell in TSQL, debug segfault in Redis) hanno tutti i tipi di impatti secondari al di fuori dei dati di riga.

Indipendentemente, l'injection SQL è in gran parte un problema risolto , quindi non vale davvero la pena creare soluzioni inferiori che siano molto più complesse e costoso.

score 1 · Answer 2

No , perché i riferimenti a Injection SQL e Insecure Direct Object includono il caso di "capacità di eseguire SQL a cui l'utente ha accesso ma l'applicazione è stata progettata per non consentire". Il tuo metodo limiterà la possibilità di ottenere contenuti al di fuori delle loro autorizzazioni, ma nella maggior parte dei casi include cose che non sono intese per essere aperte, così come le informazioni di sistema che di solito sono accessibili per impostazione.

Ciò che può aiutare è l'uso di stored procedure invece di codice lato applicazione, ma non è comune perché rende l'applicazione complessiva più statica e fragile.