2013-07-03 10 views
17

L'ho appena visto nei nostri registri delle richieste. Cosa stavano cercando di ottenere?Iniezione SQL? CHAR (45,120,49,45,81,45)

La stringa di richiesta completo è:

properties?page=2side1111111111111 UNION SELECT CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45) -- /* 

Edit: Come una ricerca su Google non ha restituito nulla di utile che volevo fare la domanda per le persone che incontrano la stessa cosa.

+0

In modo divertente questo è ora il secondo risultato per la ricerca originale che ho fatto su google. – roo

risposta

7

Questo è solo un test per l'iniezione. Se un utente malintenzionato può vedere xQ nell'output, saprà che l'iniezione è possibile.

Non esiste alcun "rischio" da questa particolare query.

Uno sviluppatore non dovrebbe prestare attenzione a qualsiasi meccanismo di iniezione, formato o significato: questi non sono affari suoi.

C'è solo uno causa per il numero infinito di iniezioni - una query formattata in modo errato . Finché le query sono formattate correttamente, le iniezioni SQL non sono possibili. Concentrati sulle tue query piuttosto che sui metodi di SQL injection.

+0

"Uno sviluppatore non dovrebbe prestare attenzione a qualsiasi meccanismo di iniezione, formato o significato: questi non sono affari suoi." - Puoi elaborare?A me sembra che non mi interessi affatto l'iniezione SQL. O riponi tutta la mia fiducia in qualsiasi struttura che uso. – roo

+0

Sì, sì. Questo è tutto - non dovresti. –

+0

Questa è follia! Se consigliare alle persone di pensare in quel modo, allora perché hai scritto https://github.com/colshrapnel/safemysql? – roo

5

La funzione Char() interpreta ciascun valore come un numero intero e restituisce una stringa in base ai caratteri forniti dai valori di codice di tali numeri interi. Con Char(), i valori NULL vengono saltati. La funzione viene utilizzata all'interno di Microsoft SQL Server, Sybase e MySQL, mentre il codice CHR() viene utilizzato da RDBMS.

La funzione SQL Char() è utile quando (ad esempio) addslashes() per PHP viene utilizzata come misura precauzionale all'interno della query SQL. L'utilizzo di Char() rimuove la necessità di virgolette all'interno della query inserita.

Un esempio di codice PHP vulnerabile ad un'iniezione SQL utilizzando Char() sarebbe simile al seguente:

$uname = addslashes($_GET['id']); 
$query = 'SELECT username FROM users WHERE id = ' . $id; 

Mentre addslashes() è stato utilizzato, lo script non riesce correttamente disinfettare l'ingresso in quanto non v'è alcuna citazione finale marchio. Questo potrebbe essere sfruttata utilizzando la seguente stringa SQL injection per caricare il file /etc/passwd:

Fonte: http://hakipedia.com/index.php/SQL_Injection#Char.28.29

+0

Nice intro to injection ma in realtà non risponde alla domanda, che è "qual è stato quello SQL _specific_ cercando di ottenere?" – paxdiablo

+0

Sono interessato sia allo specifico SQL che stavano cercando di eseguire, ma anche a come questo potrebbe funzionare. Poiché una ricerca su google non ha restituito nulla di utile, ho voluto iniziare una discussione per le persone che potrebbero essere a rischio. – roo

+0

@roo, le discussioni non sono davvero ciò che SO è per. Se stai dicendo che vuoi sapere come funzionerebbe l'attacco attuale (e sembra che sia il caso qui), questa è un'altra questione. Ma il desiderio di iniziare una discussione è probabile che le domande vengano chiuse e cancellate. – paxdiablo