Se l'utente del mio database è di sola lettura, perché devo preoccuparmi di SQL injection?

Question

Possono (utenti malintenzionati) descrivere tabelle e ottenere informazioni vitali? Che dire se blocco l'utente a tabelle specifiche? Non sto dicendo che voglio l'iniezione sql, ma mi chiedo del vecchio codice che è suscettibile ma l'utente db è bloccato. Grazie.

MODIFICA: capisco cosa stai dicendo, ma se non ho risposta.write per gli altri dati, come possono vederli. Il portare a gattonare e dosare ha senso, così come gli altri, ma come potrebbero effettivamente vedere i dati?

Answer 1

Qualcuno potrebbe iniettare SQL per causare un controllo di autorizzazione per restituire l'equivalente di vero anziché falso per ottenere l'accesso a cose che dovrebbero essere off-limits.

Oppure potevano iniettare un join di una tabella di catalogo su se stesso 20 o 30 volte per portare le prestazioni del database a una scansione.

Oppure possono chiamare una stored procedure eseguita come un altro utente di database che fa modifica dati.

Answer 2

'); SELECT * FROM Users 

Sì, è necessario bloccare giù per solo i dati (tabelle/viste) che dovrebbe essere effettivamente in grado di vedere, soprattutto se è pubblicamente rivolto.

Answer 3

Solo se non vi dispiace che gli utenti arbitrari leggano l'intero database. Ad esempio, ecco una semplice, iniettabili sequenza di login:

select * from UserTable where userID = 'txtUserName.Text' and password = 'txtPassword.Text' 

if(RowCount > 0) { 
    // Logged in 
} 

mi resta che effettuare il login con qualsiasi nome utente e la password 'o 1 = 1 Per accedere come quell'utente.

Answer 4

Stai molto attento. Suppongo che tu abbia rimosso il drop table, alter table, create table e truncate table, giusto?

Fondamentalmente, con una buona SQL Injection, dovresti essere in grado di modificare tutto ciò che dipende dal database. Potrebbe trattarsi di autorizzazione, permessi, accesso a sistemi esterni, ...

Scrivi mai dati sul disco che sono stati recuperati dal database? In tal caso, potrebbero caricare un eseguibile come perl e un file perl e quindi eseguirli per ottenere un accesso migliore alla tua casella.

È inoltre possibile determinare quali sono i dati sfruttando una situazione in cui è previsto un valore di ritorno specifico. Cioè se l'SQL restituisce true, l'esecuzione continua, in caso contrario, l'esecuzione si interrompe. Quindi, puoi usare una ricerca binaria nel tuo SQL. selezionare count (*) dove user_password> 'H'; Se il conteggio è> 0 continua. Ora è possibile trovare la password esatta del testo in chiaro senza che sia necessario stamparla sullo schermo.

Inoltre, se l'applicazione non è indurita dagli errori SQL, potrebbe esserci un caso in cui è possibile iniettare un errore nell'SQL o nell'SQL del risultato e visualizzare il risultato sullo schermo durante il gestore degli errori. La prima istruzione SQL raccoglie una bella lista di nomi utente e password. La seconda istruzione cerca di sfruttarli in una condizione SQL per la quale non sono appropriati. Se l'istruzione SQL viene visualizzato in questa condizione di errore, ...

Jacob

Answer 5

Sì, continuare a preoccuparsi di SQL injection. Le dichiarazioni SQL dannose non riguardano solo le scritture.

Immaginate anche se ci fossero server collegati o la query sia stata scritta per accedere alle risorse cross-db. vale a dire

SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary; 

Answer 6

C'è stato un errore Oracle che vi ha permesso di schianto l'istanza chiamando un metodo pubblico (ma non documentato) con parametri sbagliati.

Answer 7

Ho letto questa domanda e le risposte perché stavo creando un SQL tutorial website con un utente readonly che consentirebbe agli utenti finali di eseguire qualsiasi SQL.

Ovviamente questo è rischioso e ho fatto diversi errori. Ecco cosa ho imparato nelle prime 24 ore (sì la maggior parte di questo è coperto da altre risposte ma questa informazione è più attuabile).

• non consentono l'accesso al vostro tavolo o di sistema tabelle utente:

Postgres:

REVOKE ALL ON SCHEMA PG_CATALOG, PUBLIC, INFORMATION_SCHEMA FROM PUBLIC 

• Assicuratevi che il vostro utente in sola lettura ha accesso solo alle tabelle necessarie nello lo schema che si desidera:

Postgres:

GRANT USAGE ON SCHEMA X TO READ_ONLY_USER; 
GRANT SELECT ON ALL TABLES IN SCHEMA X TO READ_ONLY_USER 

• Configurare il database di cadere lungo l'esecuzione di query

Postgres:

Set statement_timeout in the PG config file 
/etc/postgresql/(version)/main/postgresql.conf 

• Valutare l'ipotesi le informazioni sensibili all'interno del proprio schema

Postgres:

GRANT USAGE ON SCHEMA MY_SCHEMA TO READ_ONLY_USER; 

GRANT SELECT ON ALL TABLES IN SCHEMA MY_SCHEMA TO READ_ONLY_USER; 

ALTER USER READ_ONLY_USER SET SEARCH_PATH TO MY_SCHEMA; 

• fare attenzione a bloccare eventuali stored procedure e garantire che essi non possono essere eseguiti dalla sola lettura all'utente

Modifica: Nota rimuovendo completamente l'accesso alle tabelle di sistema non è più consentito all'utente t o effettuare chiamate come cast(). Quindi si consiglia di eseguire di nuovo per consentire l'accesso:

GRANT USAGE ON SCHEMA PG_CATALOG to READ_ONLY_USER;