SQL Injection Attack - Autorizzazioni difese

Question

SQL Injection Attack - Autorizzazioni difese

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

0

Gli attacchi di SQL injection funzionano da parte dell'utente malintenzionato che inserisce SQL valido nel testo che risale dalla pagina al server; qualcosa come "Elimina * da tblAccounts dove 1 = 1" Quello che non riesco a capire è perché questo non può essere sconfitto dando l'account che il post di un utente Web viene eseguito come autorizzazioni di sola lettura. Non solo, ma di sola lettura solo sui tavoli che vuoi che legga, e nessun accesso a nessun altro tavolo. In passato si potevano concedere autorizzazioni molto granulari nei database, fino al livello di riga.

sql-injection

posta Mike 27.05.2015 - 23:23

fonte

2 risposte

Leggi altre domande sui tag sql-injection

C'è un modo per distribuire biglietti sicuri senza archiviarli? Dovrei preoccuparmi di SQL Injection per le Web App interne?

score 3 · Answer 1

Un'iniezione SQL aggiunge un nuovo comando SQL al comando che il sito Web utilizza per recuperare / aggiornare / aggiungere dati al Database. Poiché quasi tutti i siti Web che utilizzano un database devono avere alcune tabelle da scrivere nell'attaccante possono sempre aggiungere dati lì.

Ancora più importante, la maggior parte delle volte il database contiene informazioni non disponibili per tutti gli utenti del sito Web (come ad esempio la tabella utente con nomi utente indirizzi e password (-hashes) .una tabella che il sito stesso utilizza (quindi ha bisogno di accesso )

Quando si applica la sicurezza in profondità, si blocca l'utente del database che il sito Web utilizza per accedere solo a quelli a cui il sito Web deve accedere (limitato se necessario) Questo non elimina il rischio di un'iniezione, limita solo fino a che punto può diffondersi. ma tutte le tabelle disponibili per il sito Web sono disponibili per un utente di iniezione quando l'iniezione SQL non viene mitigata.

score 1 · Answer 2

La tua soluzione funzionerebbe solo in un ristretto insieme di circostanze. È raro che l'utente del database e la persona che visualizza il tuo sito web abbiano esattamente lo stesso set di permessi, che è lo scenario che stai immaginando.

Immagina questo scenario:

seleziona passwordhash da usernamePasswordtable dove username = $ username;

Anche se potessi limitare questo a un utente di DB che esegue SOLO accessi, E il tuo database consente di limitare l'accesso fino al livello di riga (in genere non l'ho visto), devi comunque aprire l'accesso all'utente di login a tutti gli utenti attivi nella tabella usernamePassword. Un attacco di SQL injection potrebbe facilmente consentire a un utente malintenzionato di accedere come utente diverso, dato che potrebbero inserire qualsiasi cosa a loro piace in $ username.

Ci sono anche molti altri problemi, il minimo dei quali è avere un utente del database per ogni singolo utente del tuo sito web.

L'unico scenario in cui ciò potrebbe funzionare è se il tuo sito web è interamente pubblico e tutto nel tuo database è già pubblicato sul tuo sito web. Quindi eseguire la lettura sola potrebbe funzionare.