none
SQL Server 2008 R2 - SQL Injection - Separatore query RRS feed

  • Domanda

  • Ciao a tutti,

    premetto che non sono un dba, SQL Server mi trovo ad utilizzarlo negli sviluppi dei siti e dei software che produciamo, ma una conoscenza di amministrazione mi manca.

    Ero consapevole che un nostro sito poteva avere delle vulnerabilità a degli attacchi di SQL Injection e ho cercato, per quanto potevo, di porvi qualche pezza sapendo che la soluzione "definitiva" sarebbe stata quella di evitare completamente le concatenazioni di stringhe nelle pagine web e passare tutta la logica su StoredProcedure e Viste con il controllo dei parametri.

    Pensavo che la rimozione dalle stringhe dei caratteri ; e -- mi mettesse un po' al riparo ma una pagina (Classic ASP) sfuggita al controllo dei parametri passati mi ha riportato alla realtà. Solo che non capisco come sia stato possibile. Ero convinto che una sequenza di istruzioni SQL (in una execute) potesse funzionare solo se separate dal carattere ;

    in realtà così non è e l'attacco è avvenuto concatenando un update alla select preesistente, una cosa del tipo:
    SELECT NomeCampo FROM TABELLA WHERE id = <1 update TABELLA SET NomeCampo = 'xxxxxxxxxxxx'>
    Dove ciò che è racchiuso tra uncinate e il parametro passato alla pagina.

    Oltre ovviamete a effettuare i cambiamenti che ho citato e ad assegnare all'utente del db dei controlli più precisi e restrittivi, mi piacerebbe sapere come è possibile fare in modo che una serie di comandi SQL non possano essere separati da spazio ma da un carattere come ;

    Spero di essere riuscito a spiegarmi.

    Grazie a tutti

    Ciao

    Stefano

    venerdì 9 marzo 2012 09:54

Risposte

  • Ciao Stefano,

    per proteggersi adeguatamente da SQL Injection non è sufficiente rimuovere -- e ;
    Inoltre, non è possibile modificare il simbolo che funge da separatore (che è il punto e virgola, come riportato anche qui).

    Ti rimando a questo articolo di MSDN di qualche anno fa, ma ancora attuale ed a questo articolo, applicabile invece ad ASP Classico.

    In generale, non è consigliabile concatenare direttamente l'input dell'utente ad un comando SQL, proprio perchè "spara" direttamente a SQL Server comandi potenzialmente pericolosi. Nel tuo caso ti suggerirei di usare una stored procedure e controllare i parametri (fissare una lunghezza max per i parametri, controllarne l'input, etc).

    HTH


    Danilo Dominici MCP MCDBA MCITP MCSE MCAD Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    venerdì 9 marzo 2012 16:54

Tutte le risposte

  • Ciao Stefano,

    per proteggersi adeguatamente da SQL Injection non è sufficiente rimuovere -- e ;
    Inoltre, non è possibile modificare il simbolo che funge da separatore (che è il punto e virgola, come riportato anche qui).

    Ti rimando a questo articolo di MSDN di qualche anno fa, ma ancora attuale ed a questo articolo, applicabile invece ad ASP Classico.

    In generale, non è consigliabile concatenare direttamente l'input dell'utente ad un comando SQL, proprio perchè "spara" direttamente a SQL Server comandi potenzialmente pericolosi. Nel tuo caso ti suggerirei di usare una stored procedure e controllare i parametri (fissare una lunghezza max per i parametri, controllarne l'input, etc).

    HTH


    Danilo Dominici MCP MCDBA MCITP MCSE MCAD Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    venerdì 9 marzo 2012 16:54
  • Ciao Danilo e grazie per la risposta.

    Come ho scritto, ero (e sono) conscio che la soluzione sia il non concatenamento delle stringhe. E' previsto infatti una riscrittura del prodotto, nel frattempo si era deciso di effettuare qualche controllo sull'attuale (solo che una pagina è sfuggita alle verifiche).

    Ero convinto che però il separatore fosse obbligatoriamente il ; (e mi andava bene così) in realtà non per tutto è richiesto e nel link che mi hai segnalato è specificato che diventerà (non ho controllato per il 2012) richiesto in una futura versione.

    In ogni caso grazie per i link e le delucidazioni.

    ciao

    stefano

    lunedì 12 marzo 2012 10:28