Come sconfiggere raddoppiando gli apostrofi per creare un attacco SQLi?

17

Conosco alcuni sviluppatori che raddoppiano gli apostrofi per mitigare SQLi. (Questo è quando l'input è "così diventa")

C'è un modo per batterlo?

Questo è su MS SQl Server.

    
posta DomBat 18.12.2015 - 10:35
fonte

3 risposte

36

Cerco di mostrare entrambi i lati dello spettro di sicurezza. La sicurezza è importante, quindi non dovresti solo sapere come sconfiggere la sicurezza, dovresti sapere anche come implementarla. Quindi, elencherò prima una prevenzione. Se non vuoi leggere questo, scorri verso il basso.

Come posso prevenire l'SQL injection?

Raddoppiare gli apostrofi è non la risposta quando si tratta di sicurezza e può portare all'insicurezza. La risposta dipende dal linguaggio di programmazione che stai utilizzando.

  • Per SQL Server / Oracle / MySQL
    • Con Java, utilizza correttamente CallableStatements e PreparedStatements.
    • Con PHP, avrai bisogno delle appropriate istruzioni preparate.
    • Con C # / VB.NET, avrai bisogno di query parametrizzate.

Nota che questi sono tutti gli stessi concetti in ogni lingua. Hanno solo nomi diversi.

Anche con istruzioni preparate / callable o query con parametri, il seguente è errato:

// Bad code, don't use 
string sqlString = "SELECT * FROM [table] WHERE [col] = '"+ something +"' AND [col2] = @Param";

Devi mai concatenare le tue variabili SQL.

Con il server SQL, a seconda della lingua scelta da te scelta, la tua query dovrebbe assomigliare a questa:

  • C #

    using (SqlCommand command = new ("SELECT * FROM [tab] WHERE LName = @LName", connection))
    {
        // Add new SqlParameter to the command.
        command.Parameters.Add(new SqlParameter("LName", txtBox.Test));
    
        // Read in the SELECT results.
        SqlDataReader reader = command.ExecuteReader();
        while (reader.Read())
        {
        }
    }
    
  • Java

    Connection con = DriverManager.getConnection("database-connection-string","name","pass");
    
    // Question marks are the bound variables which are parsed in the defined column order. 
    PreparedStatement findLName = con.prepareStatement("SELECT * FROM [tab] WHERE LName = ?");
    
    // The order in which the question marks appear. You can have more than one in a prepared statement. First one is "1", second is "2", and so on.
    findLName.setString(1, Lastname);
    
    findLName.executeQuery();
    
    Statement stmt = con.createStatement();
    
  • PHP

    Controlla w3schools per un esempio, non voglio che la mia risposta diventi troppo lunga.

Si noti che questo ancora non si sbarazza della potenziale iniezione di script su una pagina web. È possibile inserire esattamente come chiedono, entro intervalli accettabili, quindi inviare i risultati in formato HTML.

Se inseriscono il seguente esempio (dumbed-down):

<script> window.location.href='hxxp://www.mymalwarewebsite.com/'; </script>

... e produci quel risultato nella tua pagina, allora sei nei guai. Quindi, cosa succede se rimuovi qualcosa da <script> a </script> ? Cosa succede se inseriscono:

<scri<script>pt> window.location.href='hxxp://www.mymalwarewebsite.com/'; </scri<script>pt>

...? Se rimuovi i tag dello script con la sostituzione, sei ancora bloccato con quell'exploit.

Ciò che veramente vuoi è il seguente oltre a quanto sopra :

Zitto, Mark! Come faccio a battere il raddoppio degli apostrofi?

  • Potresti riuscire batterli in modi diversi ; potresti essere in grado di forzare vari database SQL per tradurre unicode nel set di caratteri locale . Ad esempio, Ā potrebbe essere convertito in A . Ancora peggio: U+02BC o ʼ verrebbe tradotto come ' , che è U+0027 . Si chiama Contrabbando basato su Unicode .
  • Sebbene non sia un attacco di tipo SQL injection, puoi provare a forzare il sito Web a iniettare codice malevolo da mostrare ai propri utenti. Puoi provare a inserire tag di script (leggi sopra per un esempio). Immagina di iniettare un download drive-by quando gli utenti visualizzano la tua pagina o un elenco di utenti.
  • Sebbene non sia tecnicamente un attacco di SQL injection, potresti riuscire a superare questa protezione controllando la console nel browser e controllando la presenza di numeri interi inviati al database, e quindi modificando la richiesta. Questo è chiamato Direct Object Reference exploit. Esistono vari strumenti che possono farlo. Le dichiarazioni preparate non ti proteggono da questo attacco. Si prega di leggere l'articolo OWASP
risposta data 18.12.2015 - 14:35
fonte
13

Is there a way to beat this?

Forse (almeno con MySQL). Ed è davvero semplice (non hai bisogno di alcuna codifica speciale o assenza di virgolette o altro):

\' [injection] -- -

Quindi, ad esempio, hai questa query:

SELECT FROM table WHERE user = '[INPUT]';

L'input è \' [injection] -- - , ma con ' raddoppia, diventa: \'' [injection] -- - , che ci conduce a questa query:

SELECT FROM table WHERE user = '\'' [injection] -- -';

La parte iniettata verrà eseguita come query, poiché non è più all'interno di virgolette.

L'unica difesa adeguata contro l'iniezione SQL sono istruzioni preparate. Inoltre, non sono difficili da usare e spesso producono un codice migliore. Non c'è davvero una buona scusa per difese casalinghe come il raddoppio delle quotazioni.

// update: sembra che ciò non sia effettivamente possibile con MSSQL. In questo modo lascerebbero i due problemi già menzionati nelle altre risposte: è ancora vulnerabile se non vengono utilizzate virgolette nella query , o (eventualmente) per determinati set di caratteri.

Dipende anche da come avviene effettivamente il raddoppio. Se è ad esempio fatto tramite il database , potrebbe essere vulnerabile .

    
risposta data 18.12.2015 - 15:18
fonte
7

Questo impedisce solo attacchi di SQL injection tramite parametri stringa. A volte, il parametro è un numero intero (si pensi a http://www.example.org/?page=3 ), quindi non è necessario un apostrofo. A volte puoi verificare se i parametri sono vulnerabili se sostituisci page=3 con page=1+2 , ad esempio.

    
risposta data 18.12.2015 - 13:52
fonte

Leggi altre domande sui tag