SQLi possibile con istruzioni preparate fatte da te e stringhe real_escape_string?

Question

SQLi possibile con istruzioni preparate fatte da te e stringhe real_escape_string?

#1 da (0 voti)
#2 da (0 voti)

3

Il mio attuale compito è trovare una possibile iniezione SQL in una WebApp PHP. Mentre osservavo il codice sorgente, ho notato che il modo in cui lo script gestisce le statistiche preparate è strano.

$query = db::prepare("SELECT password FROM vault where id=%s", $_POST['id']);
$res = db::commit($query);

La parte interessante della funzione prepare ha il seguente aspetto:

    // escape
    foreach ($args as &$value){
        $value = static::$db->real_escape_string($value);
    }

    // prepare
    $query = str_replace("%s", "'%s'", $query);
    $query = vsprintf($query, $args);
    return $query;

Ora, cercando un modo per aggirare questo, ho notato che le virgolette singole sono sfuggite, ovviamente a causa della funzione real_escape_string. Guardando da queste parti, ho trovato il seguente post che afferma che l'impostazione di% s nelle virgolette singole appare in modo molto sospetto . Tuttavia, non ho ancora trovato il modo di sfruttarlo o se è addirittura sfruttabile.

Qualcuno può dirmi se c'è qualcosa di sbagliato da evadere ed elaborare l'input dell'utente in questo modo? So che usare le funzioni di istruzioni preparate su mysqli / PDO originali è un'idea migliore, ma dato che questo non è il mio codice, sarebbe bello scoprire cosa c'è di sbagliato qui e perché non dovresti farlo in questo modo.

php sql-injection web-application

posta Nirusu 20.12.2018 - 16:43

fonte

2 risposte

Leggi altre domande sui tag php sql-injection web-application

In che modo Malwarebytes intercetta il traffico web? Posso scoprire quale crittografia viene utilizzata dalla mia tastiera Bluetooth Android?

score 0 · Answer 1

Potrebbe portare a problemi che non sono correlati direttamente alla sicurezza. Poiché $value deve essere convertito in una stringa prima che real_escape_string() possa fare la sua magia, potrebbero verificarsi tutti i tipi di problemi di localizzazione. Pensa a , invece di punti decimali o formati di data che non saranno accettati dal database. Non è una buona idea gestire tutti i parametri come se fossero delle stringhe.

score 0 · Answer 2

if there is anything wrong to escape and process user input like that?

Per chiarire, non c'è nulla di sbagliato nell'escludere di per sé fintanto che viene usato di proposito - per evitare non l'"input dell'utente" arbitrario, ma in particolare i dati da usare nelle stringhe letterali in Query SQL. Francamente, fintanto che i dati nella query SQL sono entrambi citati e sfuggiti, non dovrebbero esserci danni.

Il codice in questione è un caso speciale. Sebbene sia utilizzata la fuga in blocco (che di solito è una grande bandiera rossa), in questo caso dovrebbe essere considerata sicura fino a quando vengono utilizzati solo segnaposti di printf di base (cioè %s, %d, %f ecc.), Senza scambio di argomenti e altre cose di fantasia. Di conseguenza, ogni variabile di input potrebbe essere

racchiuso tra virgolette se viene usato %s segnaposto (e quindi viene quotato ed eseguito l'escape per soddisfare la regola da quanto sopra);
o viene formattato come un numero nel caso in cui venga utilizzato un altro segnaposto.

Quindi non vedo alcuna possibilità per l'iniezione.

L'unico problema di sicurezza qui è usare mysqli :: set_charset () per impostare la codifica della connessione, per evitare una vulnerabilità virtuale quando viene utilizzata una codifica obsoleta particolare.