Risanamento SQL query (lista nera)

Question

Risanamento SQL query (lista nera)

#1 da (13 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (0 voti)

3

Ho il seguente problema / sfida:

L'applicazione Web (ASP.NET 3.5) installata sulla LAN aziendale e funzionante su DB SQL Server deve fornire la possibilità di generare report personalizzati. Questi report possono essere fondamentalmente qualsiasi cosa, dal DB di sottolineatura, includono articolazioni complicate, unioni e qualsiasi cosa tu possa pensare. (Basta selezionare, no Inserisci / elimina / rilascia / aggiorna)

Il modo più semplice per farlo - consentire al sistema di eseguire query SQL. L'amministratore di sistema aggiungerà query personalizzate al sistema e gli utenti "normali" saranno in grado di eseguirle. Se hanno bisogno di una nuova query, chiederanno all'amministratore di creare una query per loro e poi saranno in grado di eseguirla tramite l'ID query.

L'approccio alla White List non funzionerà qui (almeno non riesco a vedere come).

E riguardo la lista nera? Stavo pensando a qualcosa del genere:

blackList={"--", ";", "/*", "*/", "@@", "@",
                  "char", "nchar", "varchar", "nvarchar",
                  "alter", "begin", "cast", "create", "cursor",
                  "declare", "delete", "drop", "end", "exec",
                  "execute", "fetch", "insert", "kill", "open",
                   "sys", "sysobjects", "syscolumns",
                  "table", "update"};

Ancora una volta - l'unica persona che può creare tale Query personalizzata è admin (e molto probabilmente ha il pieno controllo su DB in ogni caso).

Qualsiasi aiuto sarebbe benvenuto.

Grazie

A

sql-injection web-application appsec injection

posta AaronS 18.01.2012 - 09:27

fonte

4 risposte

2

Leggi solo account per principianti, nega aggiornamento / eliminazione, ecc. dagli utenti.

Personalmente mi piace usare le stored procedure per cose del genere. E se non ti fidi dei tuoi amministratori, chi potrebbe fare tutto ciò che probabilmente vorrebbe sul back-end esterno se la tua applicazione, di chi ti puoi fidare?

risposta data 18.01.2012 - 18:29

fonte

1

La soluzione migliore sarebbe quella di eseguire tutte le query utilizzando un account di database privo di privilegi senza autorizzazioni di scrittura per tutti i dati, autorizzazione di sola lettura di alcuni dati e nessuna autorizzazione di lettura per dati sicuri come gli hash delle password di altri utenti (esp utenti che sono amministratori).

Se l'utente finale fornisce un input che va nella query SQL, assicurati di utilizzare i parametri associati anziché la formattazione / concatenazione di stringhe, che potenzialmente dà all'utente la possibilità di modificare fondamentalmente il tipo di query in SQL attacchi di iniezione.

Si noti che le blacklist possono spesso essere ignorate in modo molto sottile. Ad esempio, se la lista nera update si assicura che UpDaTe sia nella lista nera e una stringa contenente caratteri unicode (come úpdãtÊ) che il database possa mappare con caratteri ascii dopo aver passato la lista nera.

Tieni presente anche le varie altre minacce che un utente malintenzionato può fare oltre a modificare i tuoi dati; che vanno dal furto di dati (ad esempio, forza in LIMIT 100 ) o denial of service da una query che richiede molto tempo.

risposta data 18.01.2012 - 19:34

fonte

0

Metti gli utenti nel ruolo del database db_datareader. Usa VISUALIZZA per limitare ciò che possono interrogare (accertati di specificare l'elenco di colonne SELECT, non un SELECT * nell'istruzione CREATE VIEW). Pubblica le VISTE e ciò che forniscono. I tuoi utenti SELEZIONANO dalla VISTA e ottengono i dati che desiderano.

risposta data 20.01.2012 - 19:35

fonte

Leggi altre domande sui tag sql-injection web-application appsec injection

I repository git privati sono sicuri? Un utente malintenzionato può riutilizzare la chiave privata SSL rubata per ricreare quel dominio sul proprio server

score 13 · Accepted Answer

Stai fornendo un elenco per disinfettare, che include drop, create, exec, ...

Ma se hai solo bisogno dell'accesso "SELECT", sarebbe più facile semplicemente togliere i diritti che l'utente che sta eseguendo le query non ha bisogno. (privilegiato meno di tutti i privilegiati)

Se fossi in te definirei le stored procedure perché sono abbastanza infallibili. Se questo è troppo difficile nella tua applicazione web, allora puoi provare l'SQL parametrizzato dove usi i parametri.

Non andare mai a disinfettare te stesso e quindi interrogare direttamente sul database. SQL parametrizzato è abbastanza flessibile e genera un ambiente più sicuro normalmente di quello che avresti con Dynamic SQL.

Ricorda anche di non rivelare alcun errore! (So che è la sicurezza attraverso l'oscurità, ma il tempo extra che guadagni con esso potrebbe consentirti di rilevarlo.)