Divulgazione e codici di stato HTTP

2

Dichiarazione di non responsabilità: sì, ho controllato Quali codici di stato HTTP sono interessanti dal punto di vista della sicurezza? che suona rilevante ma non del tutto.

In questi giorni dovrebbe essere una buona pratica non divulgare dati extra per utenti non autenticati. Es: indirizzi e-mail per la funzione "password dimenticata": quando invece di dire "questa e-mail non è registrata" quindi rivelando che un utente non è lì / o c'è sempre si restituisce lo stesso messaggio come "controlla la tua e-mail con il link di reimpostazione della password ".

Fin qui tutto bene.

Ma per quanto riguarda i codici di stato HTTP, maggiori dettagli: per 404 contro 403.

Supponiamo di avere un'area protetta in cui più persone hanno un accesso diverso. Supponiamo che si tratti di una gestione degli utenti per più organizzazioni.

E se hai una chiave primaria basata sulla sequenza per gli utenti che è usata nel link al profilo dell'utente, ad es .: /admin/users/42 allora potresti iterare sul contatore e confrontare il codice di risposta dello stato 404 - per non esistente, 403 per esistente determinare quanti utenti ci sono.

È un semplice esempio e penso che ci siano molte cose simili in giro.

Quindi la domanda: dovremmo preferire la sicurezza rispetto alla semantica e usare solo 403 (o 404) esclusivamente in tutti i casi?

    
posta zerkms 12.04.2015 - 23:46
fonte

2 risposte

3

Praticamente hai risposto alla tua domanda, è completamente possibile utilizzare una semplice risposta per indurire il tuo sistema contro un tentativo di analisi.

Un'altra opzione potrebbe essere: utilizzare un UUID casuale per identificare pubblicamente gli utenti e mantenere la chiave primaria solo per uso interno. Un UUID di 16 caratteri dovrebbe essere sufficiente per mitigare questo tipo di attacco.

Infine dovresti considerare di registrare tutte le richieste fallite per ottenere informazioni sugli utenti (403, 404).

Ora, What method is better for your situation? è qualcosa che devi decidere, considera i seguenti punti:

  1. Se il tuo sistema è già in fase di produzione, allora potrebbe essere meglio fare una piccola patch per formalizzare tutte le richieste fallite a una risposta 403/404.
  2. Se sei in fase di progettazione, puoi optare per il secondo opzione e crea un sistema interessante per i tuoi utenti.
risposta data 13.04.2015 - 04:18
fonte
1

È un caso di usabilità vs sicurezza "implicita". Facendo in modo che le richieste abbiano lo stesso codice di risposta, un utente ha perso la capacità di determinare se "il sito web non funziona" a causa della digitazione dell'URL errato o della password errata.

Poiché il valore del codice di risposta in sé non è necessario per il funzionamento di HTTP o anche direttamente correlato all'URL richiesto. L'utente malintenzionato dovrebbe semplicemente trasferire il login dello scanner / attacco per operare sul corpo della risposta anziché sull'intestazione, proprio come faresti quando sfrutti un'iniezione SQL cieca.

In breve, aumenti la complessità della risoluzione dei problemi e diminuisci l'esperienza utente del sito web per un guadagno trascurabile in "sicurezza". Nel complesso, l'aumento dei costi finanziari nell'implementazione e nel supporto di questi cambiamenti probabilmente supererà qualsiasi vantaggio.

    
risposta data 13.04.2015 - 04:03
fonte

Leggi altre domande sui tag