Apertura del browser con utente già autenticato in un'altra app

Naviga le tue risposte
0

Scenario: ho effettuato l'accesso ad alcune applicazioni (java - swing). L'autenticazione è tipica: l'accesso e la password controllati dal server (J2EE) all'avvio dell'applicazione client, dopo il normale lavoro nell'app includendo molte richieste / risposte:

Client <------------------> Server1

Ora desidero fare qualcosa di simile: l'utente fa clic su un pulsante dell'applicazione e dopo di ciò, l'app apre il browser Internet predefinito con qualche URL che punta ad altri server www ( Server2 ) ma con "contesto / sessione utente" per l'elaborazione successiva (invio della richiesta a Server1 ), in questo modo:

Client -----> Browser -----> Server2 -----> Server1

La pagina dovrebbe "catturare" l'ID della sessione utente del client presente (tipo di single sign-on). Per quanto ne so, non è in grado di avviare il browser con il cookie creato "prima di iniziare", quindi l'idea è:

  1. Apertura del browser con / Server2ServiceUrl / JSESSIONID.
  2. Il browser va a Server2ServiceUrl.
  3. L'utente sta eseguendo alcune operazioni sulla pagina (modulo di riempimento) e facendo clic su "salva" in questa pagina.
  4. Il risultato è richiesto a Server2.
  5. Server2 crea un cookie di sessione (JSESSIONID) basato su JSESSIONID nell'URL iniziale e invia la richiesta a Server1 con cookie di sessione (nell'intestazione HTTP "Cookie") in modo che Server1 sappia quale utente invia la richiesta.

Naturalmente è molto lontano essere sicuri. Uno dei grandi problemi è l'ID di sessione visibile tutto il tempo nella barra degli indirizzi del browser. Una delle idee per aumentare un po 'la sicurezza è:

  1. Il browser va a Server2Url, ma non al servizio, solo a qualche URL che:
    • creerà un cookie di sessione del browser basato su JSESSIONID nell'URL iniziale
    • invierà il comando di reindirizzamento al browser.
  2. Browser crea cookie di sessione e reindirizza al servizio (Server2ServiceUrl). Per questo motivo l'ID di sessione sarà visibile nella barra degli indirizzi del browser solo fino al reindirizzamento.

Tuttavia ritengo che questo concetto dovrebbe essere più sicuro. Cosa dovrei fare allora? Forse c'è qualche tecnica standard per risolvere questo problema?

    
posta Buffalo 05.11.2017 - 01:44
fonte

2 risposte

1

Non appena l'utente fa clic sul pulsante, crea un token casuale monouso e invialo al server (qualcosa come yourdomain.com/setsession?session=SESSIONID&single-use-token=TOKENID . Questo token verrà utilizzato in seguito per recuperare l'id di sessione.

Successivamente, l'applicazione avvia un server HTTP molto semplice e pubblica la propria pagina HTML sul browser predefinito. Questa pagina reindirizzerà a yourdomain.com/getsession?token=single-use-id , che a sua volta aprirà la pagina desiderata e imposterà il cookie di sessione.

Il componente getsession eseguirà una ricerca per il token e, se proviene dallo stesso IP di setsession , eliminerà il token e invierà i cookie di sessione al browser.

Con i token di autodistruzione, non devi preoccuparti degli attacchi di riproduzione e del riutilizzo dei token, anche se qualcuno vede il token.

    
risposta data 25.04.2018 - 15:11
fonte
0

Per trasmettere in modo sicuro un ID di sessione da Spring tramite il browser locale, è possibile creare una pagina HTML locale con un modulo di invio automatico e un valore di campo nascosto impostato sull'ID di sessione, quindi basta aprire questa pagina con il browser.

Per rendere le cose più sicure, è possibile fornire l'ID di sessione alla pagina tramite un servizio Web locale, in modo che non venga mai memorizzato su disco.

In ogni caso, anche molti sistemi di autenticazione centrale utilizzano token all'interno delle richieste GET, quindi, a meno che non si abbia bisogno della sicurezza di livello militare, l'apertura di un URL GET con token incorporato dovrebbe funzionare correttamente.

    
risposta data 25.04.2018 - 13:33
fonte

Leggi altre domande sui tag

L'url casuale a 32 caratteri conta come protezione? (UUID) [chiuso] È sicuro usare la stessa password per crittografare copie degli stessi dati memorizzati in posti diversi?