È sicuro visualizzare errori di query MySQL nella pagina Web se qualcosa è andato storto?

Gli utenti finali non dovrebbero mai vedere i dettagli cruenti del proprio ambiente.

Invece è più professionale mostrare una pagina generica "Scusa se qualcosa è andato storto". Almeno i visitatori possono vedere che hai un vero meccanismo di gestione degli errori presente sul tuo sito web.

Tuttavia, tali errori dovrebbero essere scritti nel log degli errori di mysql e dovrebbero anche attivare una notifica via e-mail o in altro modo al team IT. Questi errori non dovrebbero accadere, quindi potrebbe essere un segno che il tuo sito non sta funzionando o è potenzialmente sotto attacco.

No, non è sicuramente sicuro perché crea ulteriori vettori di attacco per iniezione SQL non presenti altrimenti. Esempio: se si dispone di un flusso di SQL injection in un insert, si tratta di una sorta di iniezione "cieca" poiché l'inserto non riporta alcuna riga di risultati al chiamante. Ma se porti un potenziale messaggio di errore di inserimento al client, rendi questo vulnerabile alla cosiddetta iniezione "XPath" (vedi questo documento per i dettagli). L'essenza è che si inietta una funzione xml che dovrebbe calcolare una variabile di tipo di dati xml. Uno degli argomenti della funzione è una variabile xpath che può essere nuovamente calcolata da istruzioni selezionate e concatenazione di stringhe. Invece di fornire un percorso x valido, fai una selezione (es. "Seleziona password_hash dagli utenti dove id = 'admin'"). Quindi il DB eseguirà un INSERT che è intenzionalmente sbagliato durante l'iniezione. Il risultato sarà un messaggio di errore come

'bb9af55cd325deaa89bb7b4e36085b4d' is not a valid xpath

Se si visualizzano messaggi di errore come questi al chiamante, questo può essere utilizzato per enumerare sostanzialmente il DB. Ho visto questo accadere di recente. Il messaggio di errore è stato tagliato a 30 caratteri ed era possibile selezionare solo una colonna e una riga alla volta, ma è comunque possibile enumerare l'intero DB con esso.

Altri hanno giustamente toccato il motivo per cui i dettagli di MySQL non dovrebbero essere esposti tramite l'interfaccia utente principale di un sito Web / applicazione su un server di produzione.

Ma c'è un problema più ampio, molto più alto in gioco quando si visualizzano errori in un utente finale come questo:

Fondamentalmente telegraph l'idea che il server / sito è mal gestito.

Significa che sei un obiettivo più maturo per l'hacking non a causa del contenuto dei dettagli, ma perché i dettagli sono stati esposti per cominciare.

La tua attitudine come sviluppatore di applicazioni-amministratore di sistemi e simili è quella di far fallire il tuo prodotto finale con grazia in un modo che non espone le "ossa" dell'architettura del sistema e tuttavia in qualche modo trasmette alcuni utili dati di debug.

Se la tua applicazione è progettata correttamente, la visualizzazione del testo dei messaggi di errore non dovrebbe essere un problema di sicurezza. Se lo fosse, significherebbe che la tua sicurezza si basa sull'offuscamento considerato una cattiva pratica.

Detto questo, la vera domanda è: quale sarà l'esperienza dell'utente di fronte a messaggi del genere? Se la tua applicazione è pensata per gli utenti medi, riceverà un messaggio che non porta loro alcuna informazione utile: o non capiscono nulla o non possono fare nulla di utile con esso. Peggio ancora, potevano pensare che quegli sviluppatori pigri non avessero elaborato correttamente i loro errori - questo è quello che penserei ...

Questo è il motivo per cui l'uso comune è quello di visualizzare un messaggio più morbido che dice che qualcosa è andato storto, ti preghiamo di riprovare e contattare l'assistenza se l'errore persiste, senza i dettagli cruenti. Il messaggio di errore completo dovrebbe essere visualizzato solo quando l'applicazione viene eseguita dal supporto in una modalità speciale perché i tecnici di supporto sono interessati ai dettagli dell'errore.

Se vuoi davvero fare il lavoro più carino con errori:

• assicurati di registrare l'errore e il suo contesto: data-ora, utente, parametri della richiesta, eventualmente i dati della sessione chiave per consentire al supporto di riempire un ticket è qualcosa che deve essere risolto nell'applicazione
• mostra solo informazioni esterne all'utente
• aggiungi un modo specifico per il supporto per accedere a tutti i dettagli degli errori quando cercano di riprodurli - ha un costo ma sarà molto apprezzato dai tecnici di supporto
• alla fine assegna un ID univoco all'incidente e lo mostra all'utente

Quest'ultima possibilità ha senso solo per applicazioni di alto valore con un numero limitato di utenti. Ciò consentirà al supporto di avere immediatamente tutti i riferimenti per il problema quando saranno contattati dall'utente. Ma significa anche che sei pronto a rispondere individualmente per qualsiasi errore che potrebbe essere molto costoso per le normali applicazioni.

Qualsiasi dettaglio tecnico che può essere ottenuto da un utente malintenzionato può potenzialmente essere sfruttato per sfruttare difetti o per ottenere una migliore comprensione del sistema (per poi sfruttare i difetti ..). Nel tuo caso potrebbe essere sfruttato per SQL Injection ma potrebbe anche consentire di identificare il tuo DBMS (se usi query native con funzioni proprie di MySQL per esempio), e quindi testare exploit specifici di DBMS se il sistema non è corretti.

Quindi, per rispondere alla domanda: no, non è sicuro divulgare le tue domande perché ciò aumenta il tuo rischio per la sicurezza.

Come menzionato nei commenti, la migliore pratica è quella di nascondere tali informazioni negli ambienti di produzione.

Una pratica comune (ad esempio i profili Maven per sviluppatori Java) consiste nel creare un progetto per un ambiente specifico. Il profilo "produzione" avrebbe una configurazione diversa che non mostra gli stacktrace sulle risposte HTML, ma li registra solo nel backend.

Come nota a margine, la visualizzazione di messaggi di errore tecnici potrebbe anche "attirare" attaccanti casuali che desiderano affinare le proprie abilità hackerando qualsiasi sistema, in quanto ti fa sembrare un bersaglio debole.

Diverse risposte hanno indicato che non è una buona pratica mostrare questi errori. Tuttavia, mi concentrerò sulla tua domanda: è sicuro?

Diamo un'occhiata a un messaggio di errore di esempio. Questa app è scritta in Python e Flask:

Questo ci dice alcune cose sull'applicazione: sta usando SQLite, l'app è in c:\jobs\token\ , c'è una tabella data e poche altre cose.

Qui non ci sono dati utente. Non rivela il saldo del conto di un'altra persona, i messaggi privati, niente di simile. Mentre è possibile che un messaggio di errore possa rivelarlo, in pratica è raro.

Quindi quanto sono confidenziali i dettagli dell'applicazione? La preoccupazione principale qui sta rendendo la vita più facile per un aggressore. Alcune vulnerabilità, come il path traversal e l'SQL injection, sono più facili da sfruttare con un po 'di perdita di informazioni nei messaggi di errore. Tuttavia, sono ancora sfruttabili senza la perdita di informazioni - è solo un lavoro più difficile. La limitazione dei messaggi di errore non blocca questi attacchi. Rende solo lo sfruttamento leggermente più difficile. Il cambiamento è così lieve che non lo considero neanche quando sto valutando il rischio di una vulnerabilità come l'iniezione SQL.

Quindi, la risposta alla tua domanda è sì, è sicura . Non è una buona pratica, ma in nessun modo è particolarmente pericolosa.

Fornire dettagli sulla configurazione del tuo database è generalmente una cattiva idea. Gli utenti legittimi non dovrebbero aver bisogno di saperlo e gli utenti malintenzionati potrebbero trovare qualcosa che altrimenti avrebbero dovuto fare.

Altre risposte hanno piuttosto ben dettagliato il tipo di rischio che questo può rappresentare per il tuo database.

La visualizzazione del rapporto errori può anche aprire un nuovo vettore di attacco nel tuo sito web. Dite, cosa succede se ho richiesto il documento con ID <script>alert('XSS')</script> - probabilmente non ne trovo uno nel database e ottengo il rapporto di errore. I gestori di errori spesso non sono la parte più accuratamente costruita di un codebase, quindi potrei semplicemente essere riuscito a eseguire un attacco XSS contro il sito.

I messaggi di errore di sintassi per le istruzioni SQL dovrebbero essere rivelati mai , in quanto ciò consentirebbe davvero di risparmiare tempo all'aggressore che tenta di sfruttare una vulnerabilità SQLi.

I numeri di riga delle applicazioni sono meno severi, ma dal punto di vista della sicurezza, la pagina di errore non dovrebbe rivelare dettagli, perché le pagine di errore sono spesso un passaggio intermedio utilizzato per completare un hack riuscito.

Se desideri mantenere la comodità di pagine di errore dettagliate, ti consiglio di configurare il tuo sistema in modo che riveli solo tali dati alle persone autorizzate in base all'indirizzo IP LAN e forse anche all'autenticazione basata su cookie. Se codice le tue pagine di errore personalizzate, questo dovrebbe essere ragionevolmente semplice da fare.

Altrimenti, dovrai semplicemente utilizzare l'approccio meno conveniente di cercare nei log degli errori ogni volta che ti servono tali dettagli.

Si consiglia vivamente di non mostrare l'errore effettivo agli utenti. Questo vale ovunque, non solo in MySQL. Dovresti utilizzare un blocco catch try per gestire gli errori.

Nel tuo caso, un utente o un utente malintenzionato potrebbe vedere il nome della tabella, i dettagli della riga e il nome. Un hacker può utilizzare SQL injection o qualsiasi altro attacco tramite l'errore fornito. Quindi è meglio nascondere questi dettagli sensibili.

È decisamente non una buona idea mostrare i dettagli del tuo ambiente di database agli utenti. Il backend del tuo sistema dovrebbe essere un mistero totale per gli utenti. I log del tuo server dovrebbero fornire sufficienti informazioni per diagnosticare errori come quello che hai mostrato.

Dovresti considerare anche cosa gli utenti possono vedere se visualizzano l'origine di qualsiasi pagina della tua applicazione web - l'origine della pagina rivela la tabella del database oi dettagli della colonna nei nomi dei campi del modulo?

Se hai tempo, potresti pasticciare con i malintenzionati presentando falsi messaggi di errore, che descrivono oggetti di database che non esistono nel tuo database. Quindi gli attaccanti sarebbero frustrati nel tentativo di attaccare quei tavoli.

La risposta è NO! Non è mai sicuro visualizzare QUALSIASI messaggio di errore di QUALSIASI tipo che offra agli attaccanti un serio vantaggio nell'entrare nel tuo sito web. La visualizzazione dei messaggi di errore di PHP non è buona, ma non è preziosa come un errore SQL, in quanto mostra il modo più semplice per eseguire un'iniezione SQL senza dover provare metodi diversi.