Autenticazione degli utenti su un secondo sito Web con un ID one-time-time - è sicuro?

Naviga le tue risposte
0

Abbiamo bisogno di autenticare gli utenti su un secondo sito web che vengono "inviati" da un primo sito web senza dover effettuare nuovamente il login.

Il modo in cui intendiamo fare questo è che un ID monouso venga inviato al secondo sito in una querystring. Una volta ricevuto il secondo sito, contatta il primo server web tramite un servizio Web sicuro, che indica "sì" o "no", indipendentemente dal fatto che il codice sia autentico e possa effettuare il login.

Tutte le comunicazioni avverranno tramite HTTPS.

Ci sono grossi problemi di sicurezza in questo che abbiamo trascurato? È sicuro?

Grazie.

    
posta niico 01.02.2017 - 12:01
fonte

4 risposte

2

Non è il modo migliore.

Se ci sono risorse o collegamenti di terze parti sul sito di destinazione, la stringa di query nell'URL potrebbe essere rivelata a loro nell'intestazione referer .

Inoltre, i parametri della stringa di query vengono registrati per impostazione predefinita sul server, il che significa che un amministratore senza scrupoli potrebbe essere in grado di accedere alle sessioni. Lo stesso vale per tutti i server proxy in viaggio che eseguono ispezioni a livello di applicazione su cui è installato un certificato SSL / TLS attendibile.

Un altro punto minore è che è visibile sullo schermo in modo tale che un "surfista sulla spalla" o una fotocamera possano captare il token.

In breve, il metodo POST è molto più sicuro perché non ha i difetti precedenti.

    
risposta data 01.02.2017 - 12:35
fonte
0

Dovresti usare la parte frammento dell'URL, invece della porzione di ricerca per trasferire i segreti. Per validi motivi menzionati da altri, i parametri GET sono problematici, ma il frammento di URL ( #secret ) non si spegne nemmeno sul filo, rendendo impossibile l'intercettazione dall'esterno del computer.

Questo evita complicazioni CORS derivanti dal POSTing dei dati tra domini, ed è in realtà più sicuro del POST perché il segreto rimane locale alla macchina.

tutto quello che dovresti fare è collegare un hash anziché una query:

<a href="https://site2.com/auth?id=abc123 target=_blank>Log In</a>
diventa
<a href="https://site2.com/auth#abc123 target=_blank>Log In</a>

non sarai in grado di raggiungere il segreto trasmesso dal server del secondo sito, ma sarà disponibile per il JS della pagina come location.hash o più esattamente, location.hash.slice(1) .

Per quanto riguarda il problema minore della visibilità umana, puoi rimuovere il segreto dalla barra dell'URL della nuova pagina immediatamente dopo aver catturato il segreto chiamando location.hash=""; o per tenerlo fuori dalla cronologia del browser: history.replaceState("","","#"); .

Se utilizzi HTTPS per intero, il POST potrebbe essere sicuro e consentire più contenuti; l'hash (nei miei test) è limitato a circa 20kb nei browser più vecchi. Se hai solo bisogno di una chiave, l'hash è veloce, fisicamente sicuro, ampiamente compatibile e facile da usare.

EDIT: seguendo questa nozione, puoi usare un'altra proprietà, questa visibilmente nascosta, chiamata window.name . AFAIK, non è possibile utilizzare solo collegamenti HTML per questo, ci vuole un frammento di JS per organizzare. Puoi utilizzare un iframe con solo HTML, ma dovrai comunque leggere il valore di JS:

<iframe name=secret123 href=https://site2.com/auth></iframe>

all'interno del frame, window.name verrà impostato su secret123 . La speciale proprietà name si aggira tra i ricaricamenti della pagina e anche dopo la navigazione verso domini di terze parti, quindi se la pagina con frame continua a navigare, dovresti innanzitutto disinfettare tramite window.name=""; .

puoi anche usare facilmente il nome "trucco" su un popup lanciato da js: window.open("https://site2.com/auth", "secret123");

    
risposta data 01.02.2017 - 20:47
fonte
0

Se la generazione di ID univoci è casuale, è sicura. Per puro caso intendo, un utente malintenzionato non dovrebbe essere in grado di trovare ID validi appartenenti ad altri utenti. Nell'esempio, un semplice md5 di ID numerici o nomi utente incrementali per l'autenticazione non sarà sicuro. Se si utilizza un sale segreto reciprocamente conosciuto nel processo, lo è. Se non si espone l'ID una sola volta all'utente (che non si dovrebbe per le ragioni summenzionate) e non si lascia che l'utente lo modifichi in alcun modo. Quindi, puoi passare con semplici ID numerici se convalidi che la richiesta provenga dall'IP del server .

    
risposta data 01.02.2017 - 12:11
fonte
0

In generale, dovresti evitare di passare i token di sessione tramite l'URL in quanto fornisce un'opportunità di dirottamento di sessione. Il fatto che il tuo sia monouso e 'verificato' su un secondo canale in qualche modo lo mitiga. Se segui questo approccio, assicurati che gli ID di sessione siano lunghi e abbastanza casuali, mai riutilizzati e invalidati immediatamente dopo l'uso. Ricorda se le chiavi non sono abbastanza forti, dato un traffico intercettato sufficiente potresti determinare le chiavi future.

I cookie potrebbero essere un'opzione più sicura se impostati su secure e solo http

Un vettore di attacco qui è l'API per il controllo delle chiavi, in quanto utente malintenzionato cerco modi per aggiungere le mie chiavi a questo, quindi è necessario verificare che sia sicuro contro gli attacchi di iniezione.

Inoltre, non vedo come questi ID siano legati a un utente specifico? O stai anche inviando un ID utente con il tuo ID di sessione.

    
risposta data 01.02.2017 - 12:41
fonte

Leggi altre domande sui tag

git firma del file con eID Quali dati (o della app) rimangono nel dispositivo dopo aver disinstallato l'app?