it-swarm.dev

Exploit di personaggi multibyte - PHP / MySQL

Qualcuno potrebbe indicarmi un link con alcune informazioni sugli exploit di personaggi multibyte per MySQL? Un amico li ha portati alla mia attenzione, ma non sono stato in grado di trovare molte informazioni su Internet.

20
Matthew S

Riepilogo. Sì, il problema è che, in alcune codifiche di caratteri (come UTF-8), un singolo carattere è rappresentato come più byte. Un modo in cui alcuni programmatori tentano di impedire l'iniezione SQL è quello di evitare tutte le virgolette singole in input non attendibile, prima di inserirlo nella loro query SQL. Tuttavia, molte funzioni di escape di virgolette standard ignorano la codifica dei caratteri che il database utilizzerà ed elaborerà il loro input come una sequenza di byte, ignaro del fatto che un singolo carattere potrebbe riempire diversi byte. Ciò significa che la funzione di escape delle virgolette interpreta la stringa in modo diverso rispetto al database. Di conseguenza, ci sono alcuni casi in cui la funzione di escape delle virgolette potrebbe non riuscire a sfuggire a parti della stringa che il database interpreterà come codifica multi-byte di una singola virgoletta; o potrebbe inavvertitamente spezzare una codifica di caratteri multi-byte in un modo che introduce una virgoletta singola in cui non era presente in precedenza. Pertanto, gli exploit di caratteri multi-byte offrono agli aggressori un modo per eseguire attacchi di iniezione SQL anche quando il programmatore pensava di sfuggire adeguatamente ai propri input nel database.

L'impatto. Se usi istruzioni preparate/parametrizzate per formare tutte le connessioni al database, sei al sicuro. Gli attacchi multi-byte falliranno. (Escludendo i bug nel database e nella libreria, ovviamente. Ma empiricamente, quelli sembrano essere rari.)

Tuttavia, se si tenta di sfuggire a input non attendibili e quindi si forma una query SQL in modo dinamico utilizzando la concatenazione di stringhe, si può essere vulnerabili agli attacchi multi-byte. Il fatto che tu sia effettivamente vulnerabile dipende dai dettagli specifici della funzione di escape che usi, dal database che utilizzi, dalla codifica dei caratteri che stai utilizzando con il database e, eventualmente, da altri fattori. Può essere difficile prevedere se gli attacchi multi-byte avranno successo. Di conseguenza, la formazione di query SQL mediante la concatenazione di stringhe è fragile e sconsigliata.

Dettagli tecnici. Se desideri leggere i dettagli degli attacchi, posso fornirti una serie di link che spiegano gli attacchi in modo eccezionale dettaglio. Esistono diversi attacchi:

  • Attacchi di base su, ad esempio, UTF-8 e altre codifiche di caratteri, mangiando barre rovesciate/citazioni aggiuntive introdotte dalla funzione di quotazione: vedi, ad esempio qui .

  • Attacchi subdoli, ad esempio, GBK, che funzionano ingannando la funzione di quotazione per introdurre un preventivo aggiuntivo per te: vedi, ad esempio, blog di Chris Shiflett , qui , oppure - qui .

  • Attacchi, ad esempio, UTF-8, che nascondono la presenza di una citazione utilizzando una codifica non canonica (troppo lunga) non valida della singola citazione: vedere, ad esempio qui . Fondamentalmente, il modo normale di codificare una virgoletta singola si adatta a una sequenza a byte singolo (vale a dire, 0x27). Tuttavia, esistono anche sequenze multi-byte che il database potrebbe decodificare come virgoletta singola e che non contengono 0x27 byte o qualsiasi altro valore di byte sospetto. Di conseguenza, le funzioni di escape delle virgolette standard potrebbero non riuscire a sfuggire a quelle virgolette.

20
D.W.

Gli attacchi a più byte non si limitano a SQL Injection. In generale, gli attacchi multi-byte portano a una condizione di "consumo di byte" in cui l'attaccante sta rimuovendo i caratteri di controllo. Questo è l'opposto del classico ' or 1=1--, In cui l'attaccante sta introducendo il carattere di controllo a virgoletta singola. Per mysql esiste mysql_real_escape_string() progettato per risolvere i problemi di codifica dei caratteri. Le librerie di query parametrizzate come PDO utilizzeranno automaticamente questa funzione. MySQLi in realtà invia i parametri della query come elemento separato all'interno di una struttura, il che evita del tutto il problema.

Se una pagina HTML viene visualizzata tramite Shift-JIS, è possibile utilizzare caratteri di controllo per ottenere XSS. Un eccellente esempio di ciò è stato fornito in " A Tangled Web " (libro fantastico!) A pagina 207:

<img src="http://fuzzybunnies.com/[0xE0]">
...this is still a part of the mkarup...
...but the srever dosn't know...
" onload="alert('this will execute!')"
<div>
...page content continues...
</div>

In questo caso 0xE0 è un byte speciale che indica l'inizio di un simbolo di 3 byte. Quando il browser visualizza questo codice HTML, il flusso "> Verrà consumato e trasformato in un singolo simbolo Shift-JIS. Se l'attaccante controlla il seguente input per mezzo di un'altra variabile, può introdurre un gestore eventi per ottenere l'esecuzione del codice.

5
rook