In ambienti di produzione (contrariamente allo sviluppo), le tracce di stack e i messaggi di errore devono essere registrati su file anziché su dumped on screen. Questo perché un utente malintenzionato può apprendere cose sul tuo sistema che potrebbero compromettere il tuo sistema.

Informazioni come sistema operativo, versione del server Web, versione di PHP e altro. Alcune tracce dello stack possono contenere variabili di sistema / ambiente che non dovrebbero essere rese pubbliche!

L'utente / visitatore dovrebbe ottenere una bella pagina di errore HTTP invece di un messaggio che non serve al visitatore.

Ci sono due diversi aspetti:

• Il bug che causa lo stack traccia una vulnerabilità alla sicurezza.
• Il framework è configurato per mostrare tracce di stack agli estranei.

Il messaggio di errore Invalid Character Error sembra molto simile alla fuga dimenticata, che può essere sfruttata molto spesso in qualche modo. Quindi dovresti preoccuparti della traccia dello stack perché è un sintomo di una possibile vulnerabilità della sicurezza.

L'altra domanda è se dovresti preoccuparti che le tracce dello stack vengano mostrate agli estranei. Da un lato nascondere le informazioni sugli interni di un sistema può essere visto come sicurezza attraverso l'oscurità. Nella maggior parte dei casi sono d'accordo, ma non nel caso di tracce dello stack.

Le tracce dello stack vengono visualizzate solo quando c'è un problema, quindi se c'è una traccia dello stack c'è un rischio significativo che ci sia un bug, e se c'è un bug c'è un rischio significativo che può essere sfruttato. Quindi tenere traccia dello stack lontano dagli estranei è una buona idea. Inoltre se la traccia dello stack contiene non solo i nomi delle funzioni chiamate ma anche i valori dei parametri, può facilmente perdere chiavi, password, cookie o altri tipi di credenziali.

Per entrambi i motivi sopra esposti, è importante fare attenzione a dove vengono visualizzate le tracce dello stack.

È comunque importante che le tracce dello stack siano disponibili per coloro che devono risolvere il problema. Quindi la registrazione delle tracce dello stack è importante. Se i casi in cui le tracce dello stack sono indicazioni di reali vulnerabilità di sicurezza, si desidera risolverli il prima possibile. Anche se un messaggio di errore non descrittivo non darà molto a un aggressore con cui lavorare, semplicemente rendendosi conto di quali personaggi funzionano e quali no, possono comunque capire come sfruttarlo comunque.

Qui ci sono due problemi e l'OP chiede il problema meno importante.

Visualizzazione della traccia

Questo è il problema che l'OP chiede. Ci sono dibattiti su quanto di un problema che mostra una traccia sia in generale e questo particolare esempio mostra bene che la visualizzazione di una traccia può essere un problema di sicurezza . Il motivo è che ci consente di sapere (tu, io e l'hacker) dell'esistenza del secondo problema.

Non filtrare l'input dell'utente

Questo è un vero problema. Non solo so (grazie alla traccia) che l'applicazione sta passando l'input utente non filtrato e non convalidato alle funzioni native di PHP, so anche che DOMDocument->createElement() è la funzione in questione. Ora inizierò ad attaccare questo sito e tutti i siti che posso identificare con questa azienda per altri problemi di filtraggio, come l'iniezione SQL, XSS, CSRF, fino alla nausea.

Si noti che le tracce dello stack includono parametri. Se ci sono chiamate di funzione che passano le password come argomenti, queste finiranno in tracce di stack.

Ovviamente è un disastro se un utente può causare la visualizzazione della password di un altro. Meno ovviamente, le password degli utenti sono ora contenute nei file di registro; che farà impazzire i tuoi utenti. Per lo meno, è necessario assicurarsi che la registrazione della password non avvenga.

Nel tuo esempio, le persone possono vedere la struttura delle tue directory che potrebbero utilizzare per potenziali attacchi. Sareste sorpresi di quanto un "hacker" possa fare con pochissime informazioni. Quindi Sì in generale è un grosso problema in termini di sicurezza. Come Alasjo sta dicendo, non è nemmeno facile da usare e una pagina di errore è una buona alternativa.

Ad esempio in alcuni casi di mostrare errori agli utenti potrebbe portare a: Path Traversal

Path traversal is also known as the ../ (dot dot slash) attack, directory climbing, and backtracking.

Mentre è stato accennato ai commenti sopra, potrebbe essere utile notare che un motivo

"Informazioni come sistema operativo, versione del server Web, versione di PHP e altro .. Alcune tracce dello stack possono contenere variabili di sistema / ambiente che non dovrebbero essere rese pubbliche!" (Vedi i commenti sopra di @Alasjo e @Danny Beckett)

è negativo, perché conoscere lo stack software utilizzato per creare l'applicazione consente agli aggressori di sfruttare i difetti di sicurezza in questi componenti (i problemi di sicurezza nel software comune sono informazioni ampiamente pubblicizzate (vedere link )) oltre a eventuali difetti / difetti nella tua applicazione resi evidenti nelle tracce dello stack.

Ad esempio, dal momento che so che il tuo sito utilizza PHP ora, potrei provare tutti i difetti di sicurezza relativi al PHP (nel caso in cui tu non abbia corretto l'installazione di PHP per risolvere quel difetto ... mantieni la patch dello stack del software livelli aggiornati giusto? :-)) anche se la tua applicazione non ha rivelato nessuno dei suoi difetti nella traccia dello stack.