it-swarm.dev

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

Ogni volta che vediamo una pagina di errore di accesso proibito 403 pensiamo di essere arrivati ​​a un luogo in cui sono presenti alcuni dati segreti o privati. Ora a questo punto i cattivi sanno che questo potrebbe essere di interesse e iniziano a vedere se possono fare qualcosa per ottenere l'accesso a questi dati segreti.

Quindi è bene mostrare questo errore o semplicemente reindirizzare verso un altro posto?

Edit

Sto pensando di gestire l'errore è di reindirizzare a una pagina di accesso separata per accedere a quel particolare risorsa. Ma in questo caso anche se semplicemente non volessi che nessuno (magari anche un amministratore) abbia accesso a queste risorse tramite la mia applicazione. L'amministratore esterno può accedere alla stessa risorsa con qualche altro mezzo nel back-end.

28
ThankYouSRT

Nell'ambiente di produzione, di solito si desidera divulgare il minor numero di informazioni possibile. A tale scopo, è preferibile mostrare codici di errore generici:

  • Errore 4 per errori relativi al client: richiesta errata, autenticazione necessaria, ecc.
  • Errore 5 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 server web. O crea le tue pagine di errore oppure modifica le pagine di errore predefinite in modo da nascondere tutte le informazioni che potrebbero essere utilizzate da un utente malintenzionato. Ad esempio, ecco un errore di uno dei nostri server quando si accede a un URL protetto da password:

enter image description here

Oltre a ciò, è un puro problema di usabilità ed è fortemente dipendente dal caso. Non dovresti reindirizzare gli utenti alla home page? Queste aree sono protette da password? Dovresti visualizzare un modulo di accesso? Oppure vuoi semplicemente mostrare il messaggio di errore generico con lo stile del tuo sito?

Ecco un esempio di una pagina di errore sul nostro sito (Security.StackExchange)

enter image description here

10
Adi

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

Vorrei portare la raccomandazione un po 'più avanti e direi che non dovresti solo limitare i tipi di errori, ma dovresti anche consegnare pagine di errore personalizzate all'utente finale.

Le pagine predefinite da 400 o 500 includono spesso molte informazioni sull'errore e questo è molto utile per un utente malintenzionato: possono scoprire quale software è in esecuzione, quale web server, quale sistema operativo ecc.

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

enter image description here

Internamente tutti gli errori dovrebbero essere registrati, in modo che possano essere gestiti.

9
Rory Alsop

Sì, tutto ciò significa che l'autenticazione ha avuto esito positivo ma l'account non è autorizzato a visualizzare questa risorsa. Per RFC2616 , è possibile utilizzare invece un HTTP 404. Tuttavia, lo sconsiglio dal momento che la restituzione di una 403 offre i seguenti vantaggi:

  1. Per i sistemi con più account (ad esempio Active Directory), questo fornisce le informazioni necessarie per l'utente che forse hanno effettuato l'accesso con un account errato e dovrebbero provarne un altro.
  2. Se l'utente necessita legittimamente dell'accesso, il ticket dell'helpdesk può essere rapidamente elaborato sapendo che sta ricevendo un 403.

Nel tuo scenario, i "cattivi" hanno già effettuato l'accesso correttamente. Si spera che il processo di autorizzazione sia abbastanza robusto da contrastare ulteriori danni (cioè non usare stringhe di query).

Mentre molti hanno commentato la disattivazione di messaggi di errore dettagliati, sarei d'accordo sul fatto che questa è una buona pratica. Tuttavia, un 403 è molto diverso da un errore del server come un HTTP 500 in cui informazioni interessanti vengono stampate sullo schermo. Ancora una volta, un 403 significa solo che non sei autorizzato a visualizzare una particolare risorsa dopo aver eseguito 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 doppio fattore. Ciò fornirà ulteriore sicurezza che la persona è veramente chi dichiarano di essere quando accede alla risorsa protetta.

6
user2320464

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

Mostrare una pagina di errore predefinita che contiene i dettagli tecnici esatti è non una buona pratica. Ha sia problemi di sicurezza che di esperienza utente.

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

D'altra parte se l'utente è una persona tecnica (diciamo una persona cattiva), c'è una possibilità per lui di avere un'idea o un'idea generale della tua struttura di sicurezza della tua applicazione. C'è una buona possibilità di essere scoperto se scopre i modelli di sicurezza nella tua applicazione perché attacchi cerca di rompere l'applicazione sarà accurato o almeno un po 'più specifico =.

Per rispondere alla tua domanda seconda, il reindirizzamento verso 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 Home page o a qualsiasi altra pagina, rovinerà l'usabilità e l'interesse degli utenti per la tua applicazione. Se vuoi davvero reindirizzarlo da qualche parte, mostragli un chiaro messaggio personalizzato e quindi reindirizzalo. In modo che almeno sappia cosa sta succedendo.

Gestione degli errori è la soluzione al tuo problema. Pensa sempre nella prospettiva dell'utente quando prepari i messaggi di errore. Show personalizza i messaggi di errore che l'utente può facilmente comprendere e inoltre non espone alcuna struttura di sicurezza dell'applicazione.

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

4

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

Tuttavia, che dire dell'invio di errori 403 più in generale? Qui sono meno convinto che sia una cattiva idea in generale, e la domanda più grande è cosa sta succedendo o perché si sta verificando l'errore 403?

Se vedo un errore 403 con una pagina di errore predefinita, o in particolare quando non ho nemmeno effettuato l'accesso, questo urla "admin incompetente" e quindi potrebbe sembrare che inviti all'attacco non tanto attraverso ciò che rivela sul tuo sito tanto quanto rivela sui tuoi amministratori.

Supponiamo che io abbia effettuato l'accesso. Sono stato autenticato. C'è qualche motivo quando provo ad accedere a una risorsa non sono autorizzato a visualizzare che dovrebbe restituire qualcosa di diverso da un messaggio di errore Accesso negato 403? Passare indietro il codice di errore consente di gestirlo programmaticamente sul lato client, il che è una considerazione importante con cose come i servizi web.

Ora ovviamente questo non dovrebbe mai accadere quando provi a fare qualcosa esposto nell'interfaccia utente. Ma come ulteriore livello di difesa e opportunità per la gestione degli errori, in questo caso non vedo nulla di sbagliato nel restituire il codice di errore, perché potrebbero esserci cause (di nuovo, vengono in mente i servizi Web) in cui il passaggio del codice di errore è il modo migliore per andare avanti.

Quindi, con questo in mente, vedo alcune cose che devono essere guardate senza pregiudizi:

Quali informazioni trapelano che possono aiutare un utente malintenzionato? Quali informazioni devono essere fornite con il messaggio di errore?

In generale, con LedgerSMB registriamo ampiamente, ma tutto ciò che è negato l'accesso è un messaggio molto breve sul lato client. Ciò consente all'amministratore di vedere cosa sta succedendo ma non l'utente.

Cosa deve sapere minimamente il cliente per gestire l'errore?

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

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 un'app Web line of business e questi sono diversi da un servizio Web in abbonamento. Devi sapere cosa stai proteggendo e da cosa prima di andare oltre.

2
Chris Travers

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

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

Un reindirizzamento alla pagina di accesso dell'amministratore:

Ciò è 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 accesso nascosto, sarebbe equivalente a mostrare la porta a un hacker. In questo caso, consiglierei vivamente di non reindirizzare.

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 sono autorizzati. Per l'amministratore, potrebbe essere dovuto a un timeout della sessione o quando accedono alla pagina da un indirizzo IP non riconosciuto. Ora, un determinato hacker può, per caso, tentare per errore 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 effettivamente facendo un sicurezza attraverso l'oscurità . Non c'è dubbio che un guadagno in termini di sicurezza non si dovrebbe fare affidamento solo su di esso. Un utente normalmente passa alla visualizzazione di un errore 404 non trovato nel file. C'è un compromesso qui poiché l'amministratore potrebbe essere confuso quando viene visualizzato un codice di errore diverso da quello che ci si aspetta. Se il tuo amministratore lo sa, allora non dovrebbe essere un grosso problema.

Stai ponendo questa domanda perché sei preoccupato. Per stare tranquillo, sceglierei la terza opzione. Ma alla fine, spetta a te decidere in base ai requisiti di sicurezza della tua applicazione web.

2