Un attacco di SQL Injection può essere eseguito tramite qualcosa di diverso da SqlCommand?

Se si dispone di un'applicazione Web ASP.NET con un database SQL Server, è sicuro assumere che se un attacco SQL Injection verrà eseguito passerà attraverso un'istanza della classe SqlCommand?Un attacco di SQL Injection può essere eseguito tramite qualcosa di diverso da SqlCommand?

Background:

mi trovo in una situazione in cui ho ereditato una piuttosto grande applicazione web che ha alcune vulnerabilità di SQL Injection. Ne ho trovate diverse semplicemente esaminando il codice per altri problemi, ma mi chiedo se un modo sicuro per trovare tutte le vulnerabilità di SQL Injection sia cercare tutti i file per le istanze di SqlCommand e quindi controllare se sono query parametrizzate. È un piano solido?

fonte

2012-11-21 Abe Miessler

io non guarderei solo per SqlCommand specificamente - il codice potrebbe utilizzare DbCommand o IDbCommand. Potrebbe essere avvolto in ORM come EF, L2S o NHibernate (tutti offrono un certo livello di accesso non elaborato). Potrebbe usare qualcosa come "dapper" o simple.data. O DataTable/DataAdapter. È possibile che il codice utilizzi l'accesso OLEDB o ADODB legacy. Diamine, per quello che sappiamo, avresti potuto scrivere la tua API TDS di basso livello.

Quindi: si tratta di controllare il codice di accesso ai dati, che potrebbe assumere molte forme. Se il tuo approccio dipartimentale è "usa SqlCommand direttamente", allora questo cambia le cose.

anche: SQL injection non è limitata a NET - è possibile, ad esempio, creare un rischio di iniezione SQL in un testo del comando crudo o stored procedure anche se si parametrizzare, se il TSQL fa alcun tipo di concatenazione per rendere dinamico SQL, per essere invocato tramite EXEC. Nota che sp_executesql può esserti d'aiuto.

fonte

2012-11-21 00:25:22

Quest'ultimo bit è molto importante se stai parlando del progetto di qualcun altro. Se ci sono sprocs, devi controllarli accuratamente. Solo perché i dati sono già nel db non significa che sia sicuro concatenare in un comando sql. – Wedge

Ottima risposta! Ultima domanda: se un attacco di iniezione dovesse avvenire a livello di SQL Server dovrebbe essere fatto attraverso l'uso di 'EXEC'? –

Si avrà bisogno anche di cercare le cose che uso o contengono un SqlCommand. Questi includono SqlDataAdapter, tra gli altri.

fonte

2012-11-21 00:19:10

Inoltre, cercare specificamente gli usi che concatenano i parametri nella stringa di query, anziché impostarli come parametri. Se si dispone di una funzione che esegue semplicemente qualsiasi stringa passata, contrassegnarla come obsoleta e rifattorizzare qualsiasi utilizzo tale errore per utilizzare un sovraccarico che accetta una raccolta di parametri. – KeithS

Nell'affrontare il codice che utilizza la concatenazione di stringhe, ho trovato un primo passo utile per utilizzare ReSharper per trasformare la concatenazione in una chiamata su String.Format. Quindi refatterò le stringhe di formato in costanti, oppure refatterò String.Formats in metodi denominati. Diventa quindi molto più facile trovare la duplicazione e rifattarla in metodi che creano uno SqlCommand invece di metodi che creano stringhe. –

Potrebbero esserci librerie di supporto. Il 'Blocco di accesso ai dati' o il vecchio SqlHelper consentono una facile vulnerabilità di iniezione. – Tass

Solo perché si sta utilizzando una libreria di query parametrizzata non significa che sia stata utilizzata correttamente. Durante il controllo del codice ho visto casi in cui vengono utilizzati i parametri parametrizzati, ma alcune parti della query sono ancora costruite utilizzando la concatenazione di stringhe. Più in particolare il nome della tabella e la parte limite/ordine della query sono errori comuni.

Se si è completamente impostati sull'analisi statica, la soluzione migliore è di fare il grep per tutte le query nell'applicazione e quindi assicurarsi che ognuna sia costruita correttamente. Sì, ci vorrà molto tempo, e può essere anestetico. Fai delle pause, prendi appunti e vai avanti. Quando trovi SQL injection sarà gratificante!

fonte

2012-11-21 00:20:13 rook

A seconda dello schema del database, potrebbe anche essere necessario verificare gli attacchi nei processi memorizzati (presupponendo che si stia utilizzando stored proc). Ho visto la gente usa le stored procedure paramterised nel loro codice, ma nel proc che basta usare EXEC per interrogare:

CREATE PROC Dummy 
(
    @Str VARCHAR(50) 
) 
AS 
EXEC ('SELECT * FROM Table Where Column = ''' + @Str + '''')

fonte

2012-11-21 00:24:19 Greg

Un attacco di SQL Injection può essere eseguito tramite qualcosa di diverso da SqlCommand?

risposta

Problemi correlati