Devo restituire un codice di errore significativo in caso di errore interno?

Which practice is better?

Dipende dai tuoi bisogni. Non c'è "sicuro" o "non sicuro", solo "abbastanza sicuro per le mie esigenze". Quale è meglio dipende dalla vostra particolare propensione al rischio / beneficio. In quanto tale, si tratta raramente di una domanda rispondente in un contesto di sicurezza.

Does returning specific internal error codes can help attackers in their penetrations attempts?

Probabilmente no. Certamente non dovresti restituire tracce dello stack o simili, ma una descrizione errata dell'errore probabilmente non è probabilmente in grado di aiutare un potenziale aggressore. Tuttavia, è probabile che anche una descrizione di errore vaga sia molto utile durante il debug. Di conseguenza, farò una domanda ovvia:

Non hai accesso nel tuo sistema?

Ad esempio, nelle mie chiamate API se c'è un errore nella produzione, restituisco semplicemente (un documento JSON) che dice "Errore interno" insieme a un codice di stato 500. Questo funziona bene per i nostri sviluppatori front-end. Quando vedono che si fermano e vengono a sbattermi perché sanno che il problema non è dalla loro parte. Da parte mia, poi guardo nei miei registri del server che mi dicono esattamente cosa è successo. Non c'è nulla che possa potenzialmente trapelare agli estranei, e ho tutte le informazioni per il debug che ho bisogno di risolvere qualunque sia il problema.

In breve, sembra che quello di cui hai bisogno sia una registrazione dettagliata accessibile solo internamente.

Potresti oscurare gli errori usando hash / hmac. Un'opzione dovrebbe avere la chiave segreta K codificata in app (o in un file se si è pedanti, o l'app è ampiamente distribuita). In caso di errore generare un token casuale T, quindi visualizzare l'errore come HMAC (K, T + error_code);

Durante il debug, basta usare una semplice utility per provare tutti i possibili errori e vedere quale ha generato l'HMAC. Ciò oscura l'errore abbastanza da consentire all'utente di non scoprire quale errore fosse, ma consente comunque il debugging non troppo difficile.

PS: anche l'uso di codici di errore non sequenziali può aiutare.

Sì, Sì, restituisci errori significativi

La sicurezza è abbastanza difficile. Rendi più facile lo sviluppatore o l'esperienza utente. In questo caso, il compromesso è minimo.

Does returning specific internal error codes can help attackers in their penetrations attempts?

Sì, ma (si spera) non in misura significativa.

In che modo il messaggio di errore dettagliato ti può ferire?

In realtà nessuna delle tue attenuazioni previene alcuni attacchi temporali. Ecco un semplice attacco a tempo. Diciamo che stai confrontando una stringa di password con una stringa di password come questa:

$password = "bobcat"

Il modo in cui il computer verifica ciò è:

for char1 in $password: for char2 in "bobcat": if char1 != char2: break

Ora, se invio la password "p", e fallisce più lentamente di quando invio la password "a", saprò che il primo carattere è "p".

Ora ho solo bisogno di scorrere il resto dell'alfabeto fino a ottenere il resto dei caratteri.

Se i tuoi errori sono resistenti all'attacco temporale, non preoccuparti della verbosità.