Invio HTTP 403 come. 200 - "Identificazione silenziosa dell'amministratore"

In generale ...

Non restituirei 200 OK a meno che tu non voglia dire ai web-client che c'è una risorsa disponibile all'URI richiesto e che è accessibile (es .: per essere indicizzati dai motori di ricerca) . Soprattutto, non restituirei mai un 200 OK per le aree protette a condizione che il client richiedente non sia autorizzato.

Dettagli ...

Vorrei provare a fornirti un po 'di informazioni sui codici di stato HTTP che hai menzionato:

200 OK 

Indica ai bot (e ai geek) che la richiesta URI è valida e la risorsa di destinazione (pagina html, file css, download ZIP, qualunque) esiste e viene restituita insieme a quella intestazione.

Cosa succede: viene chiesto al client che la risorsa esiste ed è disponibile. Può e verrà indicizzato da bot come i motori di ricerca.

403 Forbidden

Indica ai bot (e ai geek) che la richiesta URI non è valida poiché il client che richiede i dati non dispone dell'autorizzazione appropriata per richiedere tale risorsa.

Cosa succede: il client richiedente viene informato che la risorsa esiste ma che non è autorizzato a recuperarla. È come sbattere la porta sul naso di qualcuno mentre dici "non ti è permesso farlo" perché è richiesta l'autenticazione. I robot benigni e i motori di ricerca rispetteranno questo e trattano questo 403 Proibito quasi come se fosse un 404 non trovato . Non riproveranno a visitare l'URI a meno che non abbiano una buona ragione per rivisitare l'URI. Esempio: durante il controllo di nuovi collegamenti che puntano a quell'URI.

404 Not Found

Indica ai bot (e ai geek) che la richiesta URI non è valida poiché l'URI utilizzato non punta ai dati esistenti sul server.

Cosa succede: viene chiesto al client che la risorsa non esiste. È come dire "niente qui, non riprovare" . I robot benigni e i motori di ricerca non riproveranno a visitare l'URI a meno che non abbiano una buona ragione per rivisitare l'URI. Esempio: durante il controllo di nuovi collegamenti che puntano a quell'URI.

Dal punto di vista della sicurezza ...

Devi sempre restituire l'intestazione corretta che corrisponde alla situazione. Oltre alle ovvie ragioni del protocollo , lasciatemi dare un semplice esempio del perché sono necessari intestazioni corretti: immagina qualcuno che cerca di hackerare il tuo sito. Se restituisci sempre 200 OK avrai difficoltà a filtrare buono dalle richieste non valide . Ma se tu - per esempio - noti una serie di 403 Proibiti nei tuoi log del server, è facile inchiodare timestamp, IP e User Agent ... che ti aiuta a filtrare e / o bloccare tali richieste del cliente.

Quando un utente tenta di accedere a una pagina "admin", il suo browser otterrà sicuramente un codice di risposta HTTP (200, 403 ...) ma otterrà anche una pagina che sarà sicuramente distinto a seconda che l'utente sia "un amministratore" o "non un amministratore". Il Javascript che attiva il caricamento può guardare il codice ma anche nella pagina. Masquerading the 403 come 200 danneggerà solo il più stupido degli attaccanti, a cui non interessa molto, cioè il meno preoccupante degli attaccanti.

È possibile notare che quando un utente raggiunge un sito che richiede l'autenticazione, tale sito reindirizzerà spesso l'utente a una "pagina di accesso". Cioè, il sito non invia una risposta 401 (che sarebbe ciò che HTTP prescrive ), ma invece una risposta di 200 per una pagina che contiene solo del testo per consumo umano , il testo che dice "Devi effettuare il login". Questo non è, e non è mai stato, una funzionalità di sicurezza; siti a quello perché le finestre di popup che il browser visualizza di fronte a un 401 sono semplicemente brutte.

Il tuo caso di "403 vs 200" è lo stesso: non lo vuoi fare per ragioni di sicurezza (perché non porterà alcuna sicurezza di cui valga la pena parlare) ma potresti volerlo fare per ragioni estetiche ( ad es. per reindirizzare senza problemi gli utenti non autorizzati a una pagina "non amministratore" di bell'aspetto).

IMHO questo crea solo un ostacolo molto piccolo per chiunque attacca il sito da bypassare. Significa che anche tu simuli il contenuto quando il login non è valido? Crea un intero honeypot per tutti gli accessi non validi?

La maggior parte degli accessi non validi non è causata da terroristi che cercano di provocare la fine della civilizzazione come la conosciamo, di solito è solo il pulsante di blocco maiuscole. Quindi è necessario dire agli utenti che le informazioni di autenticazione fornite non hanno avuto successo.

Se la risposta di autenticazione è intesa per essere leggibile da una macchina, c'è ancora più motivo per renderla semplice e non ambigua (ma potrei dedurre troppo dall'uso di Javascript).

will only send attacks for users they know are admins

... poi di nuovo forse no. Questo, combinato con il codice javascript, mi fa pensare che ci sia qualcosa di un po 'strano nel modello di sicurezza qui.

Ci sono molte cose che dovresti fare per proteggere le transizioni di autenticazione, ma penso che deliberatamente falsificare il codice di risposta HTTP in risposta a credenziali non valide nel tentativo di scoraggiare gli aggressori è controproducente.

(Il falso del codice di risposta in risposta a una richiesta già ritenuta un attacco è una storia diversa).

Se questo è un problema, puoi implementare l'intestazione del controllo di accesso CORS , rifiutando / richieste false fornite con un'origine che non proviene da un dominio trusted.

I browser CORS-header aware invieranno un'intestazione Origin quando si effettua una richiesta di origine incrociata, dando al server la possibilità di rifiutare / falsificare la richiesta. Se gli amministratori del tuo sito utilizzano un browser che può rendere CORS-request ma non CORS-header aware, allora dovrebbero davvero prendere in considerazione il passaggio a un browser più sicuro.