String sql injection vs sql injection

Esistono casi in cui un'iniezione SQL è cieca, quindi non restituisce dati espliciti e le tecniche note su iniezioni SQL cieche falliscono a causa del fatto che il risultato non ha un impatto diretto sul comportamento del programma. Quindi non è possibile estrapolare dal comportamento ai dati.

Tuttavia, per far sì che lo scenario funzioni effettivamente, che il risultato dell'iniezione SQL cieca sia mostrato in un messaggio di errore, la query deve essere stata eseguita correttamente altrimenti non restituirebbe alcun risultato (specialmente non quelli di il codice iniettato). Quindi deve esserci qualcos'altro che usa il risultato e fallisce.

Può trattarsi di un'altra istruzione SQL che utilizza i valori selezionati di un'istruzione SQL precedente. Mi piace il seguente:

SELECT vendor_id FROM products WHERE id = $product_id

E più tardi:

SELECT name FROM vendors WHERE id = $vendor_id

Ora se si effettua la prima istruzione SELECT selezionare qualcosa di diverso da un valore che è valido nella seconda istruzione, i. e., il risultato di @@version :

product_id: 0 UNION SELECT @@version

Quale risulta in:

SELECT vendor_id FROM products WHERE id = 0 UNION SELECT @@version

Quindi la seconda query fallirebbe come, e. g., 5.5.32-standard non è riconosciuto come valido nella seconda istruzione SQL risultante:

SELECT name FROM vendors WHERE id = 5.5.32-standard

Ecco il messaggio di errore corrispondente riportato da MySQL, inclusa l'istruzione fallita con il valore di @@version :

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '.32-standard' at line 1: SELECT name FROM vendors WHERE id = 5.5.32-standard

Questo può essere usato per trasformare un'iniezione SQL cieca in una non cieca. E ciò può anche accadere con altre routine che utilizzano il valore selezionato e segnalano errori contenenti il valore selezionato.

A proposito, non ho mai sentito parlare di una distinzione tra questo tipo di iniezioni. Si potrebbe piuttosto dire che è basato sull'errore come un messaggio di errore rivela l'informazione. Tuttavia, alcuni potrebbero chiamare questa anche una seconda iniezione SQL di secondo livello poiché l'iniezione avviene in una seconda fase. Questo esempio mostra anche che non è sufficiente semplicemente "disinfettare tutti gli input utente" poiché non è nell'input dove avviene l'iniezione ma nell'output nell'istruzione SQL.

Modifica: alla luce del riferimento di OP a Blind SQL Injection

Non riesco a vedere in alcun modo in cui "l'iniezione SQL basata su stringhe" possa essere interpretata in modo specifico come una forma di iniezione SQL cieca. L'iniezione SQL invisibile può verificarsi su qualsiasi tipo di dati, non su stringhe solo . Ovviamente può essere basato su stringhe, ma non più di quanto possa fare la normale iniezione SQL.

Certo, ci sono almeno un paio di articoli online, ma credo che questi abbiano confuso il termine. Per es.

• link

• link

Articoli da fonti più affidabili come OWASP non sembrano fare alcun collegamento tra i termini "basato su stringhe" e "cieco", ma per favore sentiti libero di correggermi. Inoltre, la tua domanda sembra descrivere ciò che è noto come SQL basato su errori Injection che non è cieco, né è specificamente "basato su stringhe".

Tuttavia, ecco la mia risposta originale che copre l'SQL Injection delle stringhe rispetto ad altri tipi di dati ...

Questo arriva fino al punto in cui viene iniettato il parametro vulnerabile; più specificamente, se viene iniettato all'interno di virgolette (una stringa) o in altro modo (ad esempio interi, timestamp, ecc.)

Ad esempio, considera il seguente URL:

http://www.example.com/search?id=23&txt=my+search+string

Ora supponiamo che questi feed in una query in modo dinamico tramite PHP come segue:

$id = $_GET('id');
$txt = $_GET('txt');
$querystring = "SELECT * FROM items WHERE id = $id OR txt = '$txt'"

Se $querystring doveva essere eseguito in SQL, in questo caso entrambi i parametri sarebbero vulnerabili (sono stati concatenati senza validazione o sanificazione).

Tuttavia, il parametro txt è contenuto all'interno di virgolette ' , il che significa che per eseguire istruzioni SQL arbitrarie, devi prima eseguire l'escape della stringa includendo un carattere ' (cioè finiamo noi stessi la stringa in modo che il nostro SQL è incluso successivamente). Questo perché qualsiasi cosa all'interno delle virgolette fa parte della stringa di ricerca e pertanto non verrà eseguita.

Ad esempio:

http://www.example.com/search?id=23&txt='+OR+1=1--

Ne risulterebbe un $querystring che assomigliava a:

SELECT * FROM items WHERE id = 23 OR txt = '' OR 1=1--'

Quindi abbiamo "scappato" la stringa iniettando il nostro ' . Pertanto, questo caso si basa molto sulla possibilità di includere il carattere ' .

Mentre il parametro id ha solo bisogno di spazi bianchi:

http://www.example.com/search?id=23+OR+1=1--&txt=my+search+string

...

SELECT * FROM items WHERE id = 23 OR 1=1 OR txt = 'my search string' 

I principi sono gli stessi sia per sfruttare il modo in cui le stringhe sono gestite per abusare del database e ottenere dati o ottenere l'accesso a un sito.

L'unica differenza è che quando le persone parlano di "iniezione SQL basata su stringhe" (o iniezione SQL cieca ) di solito si riferiscono a un server vulnerabile a questo attacco ma non ricevi alcun suggerimento su cosa sta succedendo, quindi potresti ricevere una pagina Web valida ma è davvero vulnerabile, quindi devi prendere un approccio diverso.

Se usi qualcosa come:

http://example.org/index.php?id=potato order by 10--

Riceverai la normale pagina web, ma quando usi:

http://example.org/index.php?id=potato' order by 10--+

Nota e + . Qui si riceve un errore e con ciò la risposta alla query DB.

Puoi avere ulteriori letture su SQL Injection in questo bellissimo tutorial OWASP .

So che esiste già una risposta accettata e che questa domanda è un po 'vecchia, ma penso che qui ci sia un equivoco.

L'iniezione SQL basata su stringhe ha nulla da fare con l'iniezione cieca.

Nei molti tutorial là fuori, dicono che quando

http://example.org/index.php?id=12+order+by+1000--

non funziona perché non ti dà un errore, puoi provare

http://example.org/index.php?id=12'+order+by+1000--+

Questa è non una nuova tecnica. Non c'è nulla di magico in questo.

Molto semplicemente, il primo URL non è efficace perché, anche se il parametro è un numero, il codice sul server lo tratta come una stringa. Il tuo codice viene iniettato tra due virgolette singole:

SELECT id, author FROM news WHERE id = '12' order by 1000-- '

Si noti che quest'ultimo + è importante perché in MySQL i due trattini devono essere seguiti da uno spazio bianco o da un carattere di controllo (si veda here ).

Quindi aggiungere una singola citazione e un plus non è un metodo magico che costringe un sito a mostrare un errore.