Puoi dire se esiste una pagina anche se lancia un 404?

Naviga le tue risposte
7

È possibile determinare che una pagina esiste effettivamente quando è progettata per lanciare un 404 NOT FOUND ?

Sul mio server, quando viene fatta una richiesta ad uno script mentre si superano parametri non validi, sto lanciando un codice di stato http 404 perché non voglio che quelli senza conoscenza del sistema sappiano che la pagina (URL pubblico) esiste . Spero che il lancio di un 404 faccia credere a un attaccante che la sceneggiatura non esiste. Nessuna risorsa sul server stesso è diretta direttamente allo script, tutto proviene da richieste esterne.

Quello che voglio veramente sapere è, dalla sola risposta, qualcuno sarebbe in grado di dire la differenza tra una pagina che non esiste e una pagina configurata per restituire un 404?

Le intestazioni di risposta quando si effettua una richiesta non valida allo script indicano un link di 404 e non uno stato http di 200 con una pagina 404 visualizzata.

Di seguito è riportato l'intestazione della risposta che ottengo quando faccio una richiesta non valida. 

HTTP/1.1 404 Not Found
Date: Fri, 27 Jan 2017 23:32:28 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
X-Powered-By: PHP/5.4.16
X-XSS-Protection: 1; mode=block
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Modifica Di seguito è riportato l'intestazione della risposta che ottengo quando premo una pagina che non esiste realmente. 

HTTP/1.1 404 Not Found
Date: Tue, 31 Jan 2017 19:08:06 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Content-Length: 203
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
    
posta Mocking 27.01.2017 - 23:12
fonte

3 risposte

6

Lanciare l'errore 404 per ogni richiesta non valida potrebbe essere discutibile, un utente malintenzionato potrebbe iniziare a sospettare questo comportamento in particolare se conosce il servizio a cui è destinato.
Questo aiuta a proteggere il tuo servizio? questo dipende molto dalla perseveranza dell'attaccante.

Modifica :

L'autore dell'attacco può rilevare la differenza se non si crea l'intestazione della risposta 404 correttamente come farebbe il server

Ecco un caso del server PoC per Java (Tomcat8):
Questo è uno stato 404 "veritiero" restituito dal server stesso per qualsiasi risorsa non trovata: 

Content-Language:en
Content-Length:1026
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:15:54 GMT
Server:Apache-Coyote/1.1

Questo viene restituito dal servlet: 

Content-Language:en
Content-Length:992
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:18:04 GMT
Server:Apache-Coyote/1.1

Noti il valore del parametro "Lunghezza contenuto" in entrambi i casi, questo potrebbe attirare l'attenzione dell'attaccante.

    
risposta data 31.01.2017 - 08:56
fonte
2

Fai attenzione, nascondendo il codice di errore effettivo che emana un po 'di offuscamento. Non c'è niente di veramente brutto da un punto di vista della sicurezza, ma aggiunge poca sicurezza se ne ha. Pensi davvero che gli aggressori accettino ciecamente i codici di errore? Sai che possono essere cambiati a piacimento, e lo fanno anche loro. Ok, può essere utile contro gli script kiddies ma non affrontare un attacco serio, quindi dovresti davvero pensare a quale è il tuo modello di minaccia prima di andare in quel modo.

E potrebbe esserci un inconveniente qui. A meno che non si crei un sistema di log speciale che registra l'errore interno, si finirà nei registri contenenti solo 404 errori. Ciò significa che tu hai perso ogni possibilità di analisi dei log per cercare di scoprire attacchi al tuo sito e possibili falle nella sicurezza. Il codice di errore IMHO è più utile per il manutentore di un'applicazione che per un utente malintenzionato ...

    
risposta data 31.01.2017 - 08:57
fonte
1

La stessa idea si applica all'autenticazione utente.

La maggior parte dei servizi Web, come hai visto, non ti dirà cosa c'è di sbagliato nel tuo nome utente e password. Ti darà un suggerimento generale che dice che qualcosa con l'intera coppia non è valido. Questo lascia l'attaccante non sapendo se il nome utente è errato, la password non è corretta o la coppia stessa non è corretta.

È molto più rapido determinare se l'utente esiste rispetto a l'utente esiste ed è la password corretta . Alcuni aggressori ne terranno conto quando tentano di accedere a un sistema in base ai tempi.

Allo stesso modo, lo stesso vale per un 404 (non trovato) contro 403 (non autorizzato). È più veloce per il server web restituire un 404 rispetto a un 403, ma i tempi qui potrebbero essere così piccoli, il margine di errore potrebbe prendere il sopravvento.

Non è inaudito sputare sempre un 404 invece di entrambi 404/403. Un server Web come Apache può personalizzare la risposta a una richiesta di una pagina web. È un po 'più difficile modificare il codice di ritorno HTTP, ma è certamente più semplice modificare la pagina che l'utente vede. Proprio come con l'idea nome utente / password, l'autore dell'attacco viene lasciato con due casi:

  • Esiste realmente questa risorsa?
  • Devo essere autorizzato prima di avere accesso a questo?

È più comune ora che il codice lato server gestisca l'autorizzazione e l'autenticazione senza che il server Web restituisca un codice 404/403. Il codice lato server normalmente gestirà tali richieste e il server web restituirà semplicemente un codice di 200 o 300. Il contenuto della pagina potrebbe dire 403, ma il codice HTTP sarà 200 o 300. 403 è usato per l'autenticazione HTTP che ha perso popolarità nel tempo.

    
risposta data 27.01.2017 - 23:58
fonte

Leggi altre domande sui tag

Il malware persiste dopo aver cancellato il disco rigido e reinstallato il sistema operativo dal disco del produttore? [duplicare] Come patch Bash su OSX in seguito a "shellshock"? [duplicare]