Le password dovrebbero essere rivelate nel messaggio di errore?

Questa domanda è stata caricata, ma sono completamente d'accordo sulla risposta: no, le password non dovrebbero essere rivelate nei messaggi di errore. Le password non dovrebbero mai essere scritte ovunque senza il consenso esplicito dell'utente. Considera i seguenti ruoli e in che modo potrebbero accedere alla password errata che l'utente ha appena digitato:

• L'utente. Questo è l'unico ruolo che dovrebbe essere in grado di sapere cosa ha appena digitato. Bene.
• Qualcuno spinge il surfing. La maggior parte dei moduli di inserimento password oscura la password in **** ; mostrando una password sullo schermo, questa protezione viene sconfitta. Ciò è irrilevante se la password non viene mostrata in un ambiente di produzione (ma più avanti in questo).
• Un amministratore del sistema in cui si trovava la password. Un amministratore canaglia può generalmente ottenere la password inserendo un codice di registrazione surrettizio, tuttavia si tratta di un attacco attivo, a rischio di essere rilevato. Anche se la password viene mostrata solo nelle configurazioni di sviluppo, significa che il codice è presente e può essere riattivato con un cambiamento innocuo di molte variabili di configurazione contemporaneamente. È prassi comune nascondere le password agli amministratori: non vengono registrati da software non pubblico generale non pubblico che io abbia mai visto; gli amministratori di sistema e il personale di supporto IT distolgono sistematicamente gli occhi quando un utente digita una password in loro presenza.
• Uno sviluppatore dell'applicazione a cui è stata effettuata una segnalazione di bug. Quel ruolo non dovrebbe mai avere accesso alle password. Includere le password in tracce di errore, anche se sono mostrate solo a coloro che hanno più uso dalle tracce, non va bene.
• Un utente malintenzionato che ruba un backup di tracce di errore o che è in grado di vedere una backtrace du a una configurazione errata (come l'impostazione accidentale display_errors=on ).

Il valore della password errata come una risorsa dipende da cosa è. Se si tratta di un errore di battitura sulla password corretta, la password errata è praticamente valida quanto la password corretta. Se la password è una password per un altro sito (oops, ho digitato la password del mio sito di produzione nel modulo di accesso utente nell'ambiente di test), è praticamente altrettanto preziosa di una credenziale per quel sito. Rivelare la password errata ha un alto rischio di rivelare un asset di alto valore.

La risposta dello sviluppatore è profondamente insoddisfacente:

Yes, running production server with display_errors=on and printing out backtraces with argument is a security risk. That's why you should never do it.

In primo luogo, esiste un strong problema di sicurezza anche in un ambiente di sviluppo, anche se i registri vengono sempre mostrati solo a coloro che li vedrebbero legittimamente.

In secondo luogo, tutto "è un rischio per la sicurezza", ma alcuni rischi sono peggiori di altri. I backtrace possono rivelare informazioni riservate che possono essere risorse in sé o possono diventare un passaggio è un percorso di attacco. Non è così male come distribuire le password su un piatto d'argento.

Zeroth e soprattutto, questa risposta mostra una visione molto ristretta della sicurezza: "se usi correttamente il mio software, non avrai alcun rischio diretto". Anche se fosse vero (non lo è), la sicurezza è una preoccupazione olistica. È difficile garantire che ogni componente di un sistema più grande venga utilizzato esattamente come l'autore di quel componente è stato progettato. Quindi i componenti devono essere robusti - questo è noto anche come "difesa in profondità". Una regola come "mai loggare le password" è più semplice di "non mostrare backtrace a chi (chi?) Che non dovrebbe vederli e disattivarli comunque (e se ne hai bisogno, troppo male)".

Potrebbe esserci una difficoltà nel riconoscere cos'è una password e cosa no. Si può sostenere che nascondere le password crea l'aspettativa che le password siano sempre nascoste, il che è una cosa negativa se non lo sono. Penso che il tasso di successo sia più che sufficiente per giustificare il massimo sforzo qui.

Non avrei mai restituito credenziali per nessuna ragione durante un'eccezione, spetta allo sviluppatore fare qualcosa come una stampa di var_dump per verificare cosa stanno passando, qualsiasi altra cosa può perdere dati che non dovrebbero essere.

Ovviamente è consigliabile non mostrare mai messaggi di eccezione agli utenti, e in altre circostanze può essere facilmente utilizzato per sfruttare ulteriormente il sito, ma questo è troppo facile e non vedo una ragione chiara PERCHÉ passeresti sorta di dettaglio indietro.

Gli errori di MySQL sono molto migliori (user @ address, password yes / no), informativo ma non troppa perdita di dati (anche se si potrebbe sostenere che non voglio che la gente conosca gli indirizzi interni, o il mio meccanismo di autenticazione).

PHP è anche noto per non tenere affatto la mano e per lanciarti dagli squali quando fai qualcosa di sbagliato (perché è scarsamente documentato), quindi sembra par per il corso però.

Il modo in cui funziona PDO è assolutamente sbagliato e non ci sono scuse per questo.

I messaggi di errore, anche su un sistema configurato correttamente, finiscono in tutti i tipi di posti: registri degli errori, messaggi di errore rivolti all'utente, ecc. Le persone commettono errori e il rischio di esporre le credenziali del database è troppo alto , mentre il vantaggio (individuando una password errata) è marginale nella migliore delle ipotesi. Quando si verifica un errore di questo tipo, il colpevole può essere qualcosa come un SQL non valido, una violazione del vincolo, problemi di rete o un server DB corrotto. Anche se la password è davvero sbagliata, non c'è motivo di mostrarla; basterebbe lanciare con un messaggio sulla falsariga di "credenziali del database non valide" o "accesso al database negato"; se si sospetta che la password non sia quella che si desidera, esistono molti modi per eseguire il debug in modo specifico. Anche se non ci fossero rischi, inclusa la password nel messaggio di errore sarebbe comunque inutile.

Se sfogli il repository di bug di PHP, sono sicuro che troverai molte discussioni su questo problema e su argomenti simili. Per farla breve: il problema è stato discusso a morte e gli sviluppatori responsabili non sembrano concordare sul fatto che il comportamento attuale sia problematico, quindi è altamente improbabile che venga modificato in qualsiasi momento.

Questo significa che dovrai trovare una soluzione tu stesso. Una soluzione di ultima generazione che funziona è configurare un gestore di eccezioni globale che solo str_replace s sia la vera password con una serie di asterischi. In alternativa, è possibile forzare PDO a non lanciare, ma in questo modo si perde il comfort della gestione degli errori basata su eccezioni e si devono ancora disinfettare i messaggi di errore di PDO (solo ora è necessario toglierli di nascosto dai PDO e PDOStatements stessi).

Nascondi la password usando str_replace ().

// Connect using PDO
try 
{   
    $this->dbh = new PDO('mysql:host='.DB_HOST.';dbname='.DB_NAME , DB_USER , DB_PASS); 
    $this->dbh->setAttribute(PDO::ATTR_ERRMODE , PDO::ERRMODE_EXCEPTION);           
}
catch(PDOException $e)
{
    echo str_replace(DB_PASS, ' *** LOOK @CONFIG FOR YOUR SECRET PASSWORD! *** ' , $e);
}

Normalmente, quando viene attivata un'eccezione, significa che si è verificato un errore non definito. E ciò che segue è il perché e cosa dell'eccezione. PHP Core Developers ha assolutamente ragione di visualizzare le password in base al tipo di errore che ha attivato l'eccezione.

E, naturalmente, la visualizzazione delle password per qualsiasi ragione non è sicura. È compito degli sviluppatori di produzione nascondere le password e nascondere i messaggi di errore.

Quando sviluppi un'applicazione che deve essere utilizzata da altri, fai attenzione ad essere il più esplicito possibile. Per questo motivo, quasi tutte le app sono configurate per opzioni predefinite minime ed efficienti, ed è responsabilità dell'utente finale assicurarsi che le configurazioni siano ottimali per la sua applicazione.