Qual è il difetto di sicurezza in questo esempio di "parametri magici"?

Qui, se un utente conosce la stringa magica ottiene i privilegi di amministratore se invia una richiesta che contiene la stringa "sf8g7sfjdsurtsdieerwqredsgnfg8d" come valore per il parametro "magic".

Le credenziali / stringhe magiche sono spesso utilizzate dagli sviluppatori per i test. Spesso dimenticano di rimuoverli quando distribuiscono l'applicazione in fasi di produzione che si traducono in una vulnerabilità.

In realtà ce n'è un altro più importante, a causa della mancanza di un'implementazione costante di pari tempo, un attacco di temporizzazione può essere utilizzato per calcolare magic .

Vedi link

public static boolean isEqual(byte[] a, byte[] b) {
    if (a.length != b.length) {
        return false;
    }

    int result = 0;
    for (int i = 0; i < a.length; i++) {
      result |= a[i] ^ b[i]
    }
    return result == 0;
}

Non esiste alcuna vulnerabilità intrinseca nello stesso snippet di codice in quanto non sembra incline all'iniezione - presumendo ovviamente che la variabile magica locale non venga esposta da qualche parte nel codice di 'elaborazione normale' lungo la linea. Si potrebbe discutere sulla qualità del codice, ma non riesco a vedere cosa lo renderebbe vulnerabile in questa istanza.

La vulnerabilità dell'intera struttura deriva dal design.

Naturalmente nessuno tenterà di trovare la stringa magica con la forza bruta di taglio - ci vorrebbe del tempo, finirebbe nei registri del server e sarebbe facilmente scoperta molto prima di ogni possibilità statistica di indovinare la stringa magica. Invece l'attacco più semplice all'intero sistema è quello di metterti di fronte al server (o in qualsiasi punto tra gli utenti legittimi e il server, il WiFi pubblico è la soluzione migliore se gli amministratori sono abbastanza stupidi) e i pacchetti di richiesta della cache inviati al server server - prima o poi un amministratore accederà e praticamente ti darà la stringa magica su un piatto d'argento.

E tutto ciò presuppone che il server stesso sia correttamente protetto - se perde log di accesso, o backs accede ai log in una posizione non protetta, non è nemmeno necessario eseguire foo di rete in ordine per ottenere la stringa magica.

Vorrei averlo visto prima, ma sto solo leggendo la guida ai test OWASP da solo. Per me, lo snippet di codice ha i seguenti difetti evidenti:

• La password memorizzata è in chiaro.
• La password memorizzata viene confrontata con la password di testo chiaro fornita dall'utente
• La password è memorizzata nel codice sorgente e potrebbe essere impegnata nel controllo della versione

È come memorizzare le password utente in un database come testo in chiaro. Se il database viene violato (o rubato il codice sorgente), la password diventa immediatamente nota. Non ci sono scuse o motivi per archiviare password di testo chiare. È abbastanza brutto memorizzare le password che non sono salate o crittografate con forza.

Per migliorare questo codice e lasciare lo sviluppatore a casa per testare ...

• Archivia una versione salata / hash della stringa come una variabile ENVIRONMENT (non sarà impegnata in un VCS)
• confronta la stringa crittografata memorizzata con la versione salata / hash della password in chiaro fornita dall'utente. (Simile al login standard)

In PHP, potrebbe essere:

public function doPost(HttpRequest $request, HttpResponse $response){

    $admin = password_verify($request->get('magic'), $_ENV['ENCRYPTED_STRING']);

    if($admin) {
        $this->doAdmin($request, $response);
    } else {
        // do normal processing of request and response
    }

}

Questo lascia ancora il problema di passare la password di testo in chiaro in una stringa di query che potrebbe essere registrata o annusata ... ma questo è un problema al di fuori della portata della domanda.

Nello scenario di attacco reale il parametro magico di ricerca è quasi desolante, poiché la casualità nel parametro magico è abbastanza alta da proteggerla dal probabile attacco di forza bruta. Tuttavia, quando si tratta della revisione del codice sorgente, è chiaro che se il parametro magico corrisponde all'hash casuale, l'utente arriverà nella dashboard dell'amministratore.