Se un'applicazione web restituisce errori HTTP veri?

Direi di non ostacolare gli RFC nel vano tentativo di fornire sicurezza attraverso l'oscurità, creeranno più mal di testa quando qualcuno si collega alla tua API e sta ricevendo 200 codici quando il server lancia davvero 500.

Onestamente: se in qualche modo ottieni un elenco di tutte le mie firme API, non mi interessa e restituirò 403 tutto il giorno. Anche su un'API aperta i tuoi 500 messaggi dovrebbero essere abbastanza generici da non sapere realmente cosa stia succedendo, se non "il server non ha gradito l'input, si prega di seguire le specifiche, ecc.".

Anche se i codici non restituiti possono fornire una piccola misura di sicurezza attraverso l'oscurità, ognuno di questi è una cosa utile da sapere da solo come utente. Se il tuo server dà il via a un 500, so come utente legittimo che non è colpa mia se non grattarmi la testa su un falso 404.

Considera di alterare quei messaggi di errore solo quando sai che c'è una perdita di qualche tipo che vuoi evitare (404 per una pagina utente che non sei autorizzato a conoscere rispetto a 403 impedirebbe l'enumerazione). L'alterazione di tutto all'ingrosso comporta più svantaggi che svantaggi.

Come gli altri intervistati finora, sono d'accordo sul fatto che una piccola quantità di sicurezza per oscurità non superi il vantaggio di restituire un codice di risposta semanticamente significativo. Oltre a informare l'utente dello stato, è di grande aiuto avere dati significativi registrati nei log per diagnosticare errori, problemi di prestazioni e analisi della sicurezza.

Un avvertimento se lo è per un errore 401 - questo di solito induce il browser a richiedere una password che, in assenza di una direttiva digest, può essere inviata in chiaro - se la richiesta non è autorizzata e (come nella maggior parte casi) l'autenticazione è gestita dal codice in esecuzione sul server web, quindi utilizzare un codice diverso (io sono una teiera?).

In effetti andrei oltre e ti suggerirei di pensare attentamente se puoi trasmettere ulteriori informazioni usando i codici di stato indefiniti.

Presumo che tu sia già a conoscenza dell'abitudine di MSIE di sostituire HTML restituita con codici non-2XX.

Ci sono due aspetti da considerare qui e devi prendere una decisione in base a cosa stai proteggendo e quali vulnerabilità potrebbero essere esposti dai codici di errore. Da un lato i messaggi di errore espliciti facilitano il debugging e sto parlando del debug basato sulla reale esperienza utente. I bug più pericolosi sono quelli che non hai mai sperimentato fino a quando il sistema non sarà attivo. Quanto più velocemente riuscirai a schiacciare chi è il migliore sia dal punto di vista della sicurezza che del business.

Nel mondo più spaventoso, le minacce (i cappelli neri) là fuori ora sono molto sofisticate. Prenderanno le impronte digitali su sistema operativo, rete, linguaggi di programmazione, librerie e ore di picco operative prima di lanciare un attacco. Dare loro più informazioni è pericoloso, specialmente se i tuoi sistemi non vengono aggiornati e aggiornati frequentemente. Permettere una minaccia per sondare le aree sensibili con errori di autenticazione aumenterà il rischio.

Detto questo, sono tendenzialmente d'accordo con Jeff e StrangeWill. Le informazioni che verrebbero ritirate saranno probabilmente utilizzate più frequentemente dalla tua stessa squadra piuttosto che dal cappello nero opportunista. A meno che ciò che stai proteggendo abbia un valore elevato (oltre gli indirizzi e-mail e le password), la capacità di correggere rapidamente gli errori è più importante per l'azienda, quindi la negazione di un piccolo bit di informazione ai cappelli neri (otterranno comunque un molto comunque).