TLS per proteggere l'autenticazione HTTP di base

2

L'autenticazione di base, inclusi i token bearer, dipendono dall'uso di TLS per impedire agli intercettatori di ottenere credenziali o token sensibili. Ma penso che ci sia un elefante nella stanza di cui nessuno parla.

Gli utenti spesso digitano solo "www.somesite.com" invece di " link ". AFAIK quando non si specifica il protocollo, il browser client prima tenterà la connessione HTTP predefinita e non crittografata.

Il problema è che l'utente chiede in sostanza una connessione non crittografata al server perché è quella predefinita quando non viene specificato alcun protocollo. Il browser potrebbe potenzialmente includere informazioni sensibili nelle intestazioni delle richieste, incluse le credenziali di autenticazione di base, i token (e anche i cookie che non sono impostati su "Secure")

Per i client API che inviano token la situazione è simile, ma parzialmente attenuata dalle applicazioni client, fortunatamente ben scritte, che

  1. Effettivamente utilizza solo la porta crittografata SSL a cui connettersi e
  2. Lo sviluppatore ha effettivamente attivato il "Verifica il certificato SSL" opzione prima di pubblicare la propria app.

Ho intenzione di configurare un proxy MITM sulla mia rete domestica per avviare il controllo e la registrazione delle app che uso. In particolare, voglio spoofare alcuni record DNS e vedere se le app in realtà riescono a inviare credenziali / token al server sbagliato.

Personalmente avrei preferito che JWT fosse specificato come inviato solo in un cookie SECURE, piuttosto che nelle intestazioni ... Qualcuno qui pensa che la mia preoccupazione non sia giustificata?

EDIT: Per chiarire: non sono così preoccupato dalla debolezza di SSL o attacchi contro DNS, sono più preoccupato per le credenziali esposte perché i client finiscono per inviarlo su connessioni non criptate in ogni caso, sia a causa di cattivo comportamento o perché il client segue semplicemente i reindirizzamenti alle porte SSL ma solo dopo aver inviato le credenziali dell'utente. Quando creerò le API, d'ora in poi aggiungerò un listener sulla porta non criptata. Se riceve alcun token su quella porta, sarà

  1. Non reindirizza e
  2. annulla le credenziali e
  3. invia all'utente un avviso.

Speriamo che gli sviluppatori che scrivono app che consumano queste API avranno il suggerimento. La lista nera dell'IP per poche ore sarebbe troppo dura?

P.S. Nota: con i cookie di sicurezza dipendiamo ancora dal corretto utilizzo del browser.

    
posta Johan 04.10.2016 - 14:52
fonte

3 risposte

3

the client browser will first try the default, un-encrypted HTTP connection, potentially including your Authorization header if the browser has got this details.

Penso che questa ipotesi sia errata : il browser distingue tra http: // e https: //, cioè le credenziali immesse in https: // non saranno incluse quando accederai a http: // e vice versa. Ciò significa che il browser includerà le credenziali per l'autenticazione di base su http: // se l'utente ha inserito le credenziali in precedenza su http: //. E il browser ha chiesto solo le credenziali su http: // se il server ha emesso un 401 (autenticazione richiesta) su http: //. Se invece il server semplicemente reindirizza a https: // e invia solo il 401, il browser non chiederà mai le credenziali su http: // e quindi non memorizzerà le credenziali per http: // e non includerà le credenziali su http: //.

    
risposta data 04.10.2016 - 16:24
fonte
1

Qualsiasi autenticazione basata su token ha un problema con gli attacchi MiTM. Gli standard dei token non includono alcun meccanismo per prevenirli.

Ciò significa che ogni app deve tenerne conto. È possibile ridurre il rischio mantenendo molto breve il ciclo di vita dei token oppure è possibile aggiungere un meccanismo sul lato server per verificare se il token proviene dal client originale.

In questo modo, praticamente tutti gli esempi di autenticazione token che vedi sono sbagliati. O almeno mi manca questo dettaglio cruciale.

Quindi sì, in generale hai assolutamente ragione.

    
risposta data 04.10.2016 - 15:15
fonte
0

Prima di tutto, HTTP Basic Authentication e REST sono entrambi stateless. Significato: spetta esclusivamente al Cliente gestire la sessione. A meno che non sia utilizzato per le comunicazioni Server-Server, l'autenticazione HTTP di base con REST è solo un Bad Combo . Suggerirei di cambiare il metodo di autenticazione. fare riferimento alla sezione Autenticazione nella risposta accettata qui

Per l'indirizzamento della perdita di nome utente / password, il mio suggerimento sarà:

  • il servizio API viene eseguito separatamente nel link ( link non è accessibile)

  • avere un client API JavaScript (o il tuo script preferito) incorporato nella pagina Web ( link ) in modo che il client API si connetta al ( link ) per rendere la connessione API al posto del browser.

risposta data 06.10.2016 - 17:03
fonte

Leggi altre domande sui tag