È buona norma mostrare all'utente l'errore di accesso non autorizzato 403?

Nell'ambiente di produzione, di solito vuoi rivelare meno informazioni possibili. A tale scopo, è preferibile mostrare i codici di errore generici:

• Errore 400 per errori relativi ai client: richiesta errata, autenticazione necessaria, ecc.
• Errore 500 per errori relativi al server: database inattivo, sito inattivo per manutenzione, ecc.

Idealmente, non dovresti optare per le pagine di errore predefinite fornite dal tuo webserver. Puoi creare le tue pagine di errore o modificare le pagine di errore predefinite in modo da nascondere tutte le informazioni che potrebbero essere usato da un aggressore. Ad esempio, ecco un errore da uno dei nostri server durante l'accesso a un URL protetto da password:

Oltreaciò,sitrattadiunproblemadiusabilitàpuroedèmoltodipendentedalcaso.Nondovrestireindirizzaregliutentiallahomepage?Questeareesonoprotettedapassword?Dovrestivisualizzareunmodulodiaccesso?Ovuoisemplicementemostrareilmessaggiodierroregenericoconlostiledeltuosito?

Eccounesempiodiunapaginadierroresulnostrosito(Security.StackExchange)

Come dice @Adnan, in qualsiasi ambiente di produzione si desidera limitare la perdita di informazioni. Un reindirizzamento può anche essere utile per un utente malintenzionato.

Vorrei prendere la raccomandazione un po 'oltre e dire che non dovresti limitare solo i tipi di errori, ma dovresti anche solo consegnare pagine di errore personalizzate all'utente finale.

Le pagine 400 o 500 predefinite spesso includono una grande quantità di informazioni sull'errore e questo è molto utile per un utente malintenzionato: possono scoprire quale software è in esecuzione, quale server Web, quale sistema operativo ecc.

Quindi la raccomandazione generale in un contesto di errore è di fornire una pagina personalizzata all'utente che riconosca un errore ma non dia nulla, ad esempio:

Internamente devono essere registrati tutti gli errori, quindi possono essere gestiti.

Sì, tutto ciò significa che l'autenticazione ha avuto successo ma l'account non è autorizzato a visualizzare questa risorsa. Per RFC2616 , potrebbe essere usato un HTTP 404. Tuttavia, sconsiglio di farlo poiché restituire un 403 offre i seguenti vantaggi:

1. Per i sistemi con più account (ad esempio la directory attiva), questo fornisce le informazioni necessarie all'utente che forse hanno effettuato l'accesso con l'account sbagliato e dovrebbero provare un altro.
2. Se l'utente ha legittimamente bisogno di accesso, il ticket dell'helpdesk può essere elaborato rapidamente sapendo di ottenere un 403.

Nel tuo scenario, i "cattivi" hanno già effettuato l'accesso con successo. Speriamo che il processo di autorizzazione sia abbastanza robusto da ostacolare ulteriori danni (ad esempio, non utilizzare le stringhe di query).

Mentre molti hanno commentato di disattivare i messaggi di errore dettagliati, sono d'accordo che questa è una best practice. Tuttavia, un 403 è molto diverso da un errore del server come un HTTP 500 in cui informazioni interessanti vengono stampate sullo schermo. Di nuovo, un 403 significa semplicemente che non sei autorizzato a visualizzare una particolare risorsa dopo aver effettuato correttamente l'accesso. Quindi continua a restituire un 403 ma non includere informazioni diagnostiche dettagliate.

Se si tratta di una risorsa estremamente sensibile, prendere in considerazione la separazione e richiedere l'autenticazione a due fattori. Ciò fornirà ulteriore sicurezza che la persona è veramente quella che sostengono di essere quando accede alla risorsa protetta.

Per rispondere alla tua domanda prima , non è buona per mostrare questo errore all'utente finale.

La visualizzazione di una pagina di errore predefinita contenente i dettagli tecnici esatti è non una buona pratica . Ha sia problemi di sicurezza che di esperienza dell'utente.

Se l'utente è una persona non tecnica, questo tipo di messaggi di errore può infastidirlo con tutte le cose tecniche in esso contenute. Non saprà cosa fare per risolvere l'errore che non capirà.

D'altra parte, se l'utente è una persona tecnica (diciamo una brutta), c'è la possibilità per lui di dare un'occhiata o un'idea generale della struttura di sicurezza della tua applicazione . C'è una buona probabilità di essere esposto se scopre gli schemi di sicurezza nella tua applicazione perché gli attacchi che cerca di violare la tua applicazione saranno accurati o almeno un po ' più specifici .

Per rispondere alla tua domanda secondo , il reindirizzamento a un'altra pagina non sembra essere una buona idea di facile utilizzo.

Quando l'utente tenta di accedere a qualcosa e lo reindirizza direttamente alla pagina iniziale o a qualsiasi altra pagina, rovina l'usabilità e l'interesse degli utenti nella tua applicazione. Se vuoi davvero reindirizzare da qualche parte, mostragli un messaggio personalizzato chiaro e poi reindirizzalo. In modo che almeno sappia cosa sta succedendo.

La gestione degli errori è la soluzione per il tuo problema. Pensare sempre nella prospettiva dell'utente quando si preparano i messaggi di errore. Mostra personalizza i messaggi di errore che l'utente può facilmente comprendere e inoltre non espone alcuna struttura di sicurezza della tua applicazione.

Bottom line - Qualsiasi tipo di errore deve essere gestito e personalizzato prima di informare l'utente.

È una buona pratica? Dipende. Sono d'accordo sul fatto che probabilmente non vuoi semplicemente inviare la pagina predefinita all'utente. Ciò rovina l'usabilità e può fornire troppe informazioni a un utente malintenzionato se ci sono dettagli tecnici.

Tuttavia, per quanto riguarda l'invio di errori 403 in generale? Qui sono meno convinto che sia una cattiva idea in generale, e la domanda più ampia è cosa sta succedendo o perché si verifica l'errore 403?

Se vedo un errore 403 con una pagina di errore predefinita, o in particolare quando non sono nemmeno loggato, questo urla "amministratore incompetente" e quindi potrebbe sembrare che inviti un attacco non tanto attraverso ciò che rivela sul tuo sito tanto come ciò che rivela sui tuoi amministratori.

Supponiamo però di aver effettuato l'accesso. Sono stato autenticato. C'è qualche ragione quando provo ad accedere a una risorsa che non sono autorizzato a vedere che dovrebbe restituire qualcosa di diverso da un messaggio di errore 403 di accesso negato? Il passaggio del codice di errore consente di gestirlo a livello di codice sul lato client, aspetto importante per cose come i servizi web.

Ora ovviamente questo non dovrebbe mai accadere quando si tenta di fare qualcosa esposto nell'interfaccia utente. Ma come ulteriore livello di difesa e opportunità per la gestione degli errori, non vedo nulla di sbagliato nel restituire il codice di errore in questo caso, perché potrebbero esserci delle cause (di nuovo, i servizi web mi vengono in mente) dove passare il codice di errore è la migliore via da seguire.

Quindi, con questo in mente, vedo alcune cose che devono essere guardate in modo non pregiudizievole:

Quali informazioni sono trapelate che possono aiutare un utente malintenzionato? Quali informazioni dovrebbero essere fornite con il messaggio di errore?

In generale, con LedgerSMB registriamo in modo estensivo, ma qualsiasi cosa negata per accesso è un messaggio molto breve sul lato client. Ciò consente all'amministratore di vedere cosa sta succedendo ma non l'utente.

Che cosa deve minimamente sapere il client per gestire l'errore?

Di solito, IMO, solo quell'accesso è stato negato nonostante l'accesso. Il 403 può essere utile qui, ma non si vuole inviare molto più di questo.

Quali altre preoccupazioni hai?

Molte cose dipendono dal modello di minaccia. Il modello di minaccia di un'applicazione web rivolta al cliente è molto diverso da una linea di app web aziendale e queste sono diverse da un servizio web di sottoscrizione. Devi sapere cosa stai proteggendo e da cosa prima di andare oltre.

Guardando il contesto della tua domanda, sembra essere una pagina di amministrazione che richiede l'accesso per accedere. Sei preoccupato che la visualizzazione di un errore 403 agli utenti non autorizzati consenta a chiunque indovina l'URL di sapere che la pagina è presente ma non è possibile accedervi.

Ovviamente, la pagina di errore, se presente, non dovrebbe rivelare informazioni come l'architettura del server e la versione. Non ripeterò più queste cose basilari. Ci sono alcune opzioni qui. Diamo un'occhiata alle varie opzioni:

Un reindirizzamento alla pagina di accesso dell'amministratore:

Questo è utile dal punto di vista dell'amministratore. Potrebbe essersi verificato un timeout della sessione. L'amministratore che ha fatto clic sul collegamento a questa pagina verrebbe reindirizzato direttamente alla pagina di accesso per continuare l'accesso privilegiato. Come per gli altri, verrebbero anche reindirizzati alla pagina di accesso. Se si tratta di un login nascosto, sarebbe equivalente a mostrare la porta di un hacker. In questo caso, vorrei strongmente sconsigliare il reindirizzamento.

Visualizza errore 403:

Questo errore non è ambiguo. Sia l'amministratore che l'utente sarebbero in grado di capire che il loro accesso è negato perché non autorizzati. Per l'amministratore, potrebbe essere dovuto a un timeout della sessione o all'accesso della pagina da un indirizzo IP non riconosciuto. Ora, un hacker determinato può, per tentativi ed errori, anche su questa pagina. La domanda è, dovresti essere preoccupato per questo? Se la pagina stessa non accetta alcun input dell'utente e sei sicuro che il codice sia pulito e ben scritto, non dovresti esserlo.

Visualizza errore 404:

Visualizzando un errore 404, stai in effetti facendo una sicurezza attraverso l'oscurità . Non c'è dubbio che guadagni in sicurezza, ma non devi fare affidamento esclusivamente su di esso. Un utente normalmente si muoverà vedendo un errore 404 file non trovato. Qui c'è un compromesso in quanto l'amministratore potrebbe confondersi quando viene mostrato un codice di errore diverso da quello che ci si aspetta. Se il tuo amministratore lo sa, quindi, non dovrebbe essere un grosso problema.

Stai facendo questa domanda perché sei preoccupato. Per avere la pace della mente, vorrei andare per la terza opzione. Ma alla fine, spetta a te decidere in base ai requisiti di sicurezza della tua applicazione web.