Finestra di apertura dal sito protetto domainA.com, al sito partner domainB.com - con stringa di query crittografata TTL breve

2

Sto esaminando una proposta e ho bisogno di trovare dei motivi per spiegare perché potremmo non eseguire la soluzione suggerita.

Ecco il problema:

www. domain-a .com è un sito Web sicuro che si occupa delle funzioni relative ai clienti.

www. domain-b .com è un sito web partner che si occupa di una nuova serie di funzioni correlate ai clienti che domain-a .com non è coinvolto in, che indirizzando l'utente che ha effettuato l'accesso a domain-b .com sull'utente che intraprende un viaggio specifico.

Fin qui tutto bene, ma poi introduciamo il fatto che domain-a deve passare informazioni crittografate (riservate) a domain-b tramite la stringa di query, e questo sarebbe naturalmente un'operazione GET HTTPS perché stiamo aprendo una nuova finestra.

La mia domanda circonda davvero il processo di crittografia delle informazioni della stringa di query riservate nel modo migliore possibile tra domain-a e domain-b in un modo che ridurrà o eliminare la possibilità di riproduzione, MITM e altri attacchi comuni.

Esistono schemi comuni per affrontare questo tipo di scenario, dal punto di vista della crittografia? Vorremmo ovviamente assicurarci che gli URL di accesso siano essenzialmente "one-shot", ovvero un cliente che ha tentato di copiare / aggiungere un segnalibro a questo URL tornerebbe a una sessione / endpoint non definitiva se dovesse accedervi di nuovo.

Capisco anche che le richieste HTTP GET possono essere memorizzate nella cache in IIS / infrastruttura Web, e non è forse il modo migliore di andare su questo, ma è lo scenario che attualmente devo affrontare qualsiasi input sarebbe stato accolto con gratitudine!

    
posta Cmac 84 15.10.2015 - 18:10
fonte

1 risposta

0

Penso che un canale laterale possa essere un mezzo migliore per passare i dati rispetto al tentativo di passare tutto in una stringa di query. Il flusso sarebbe:

  • Il dominio A invia tutti i dati rilevanti direttamente al dominio B su HTTPS.
  • Il dominio B memorizza i dati in una sessione temporanea e crea un ID casuale sicuro per la sessione. (Nota che questa non è una sessione regolare per il Dominio B, solo una lista temporanea con un timeout molto breve.)
  • Il dominio B restituisce l'ID di sessione al dominio A.
  • Il dominio A apre quindi la nuova finestra con l'URL https://domain-B/landingpage?tempID=XXXXX .
  • Quando il dominio B riceve il token, rimuove la sessione temporanea corrispondente e utilizza i dati. Se la sessione temporanea non esiste, si trattava di un URL obsoleto o di un URL ripetuto e dovevano essere gestiti in modo appropriato.

In questo modo i dati sono sicuri perché ci affidiamo a HTTPS, puoi passare qualsiasi quantità di dati perché il canale laterale non ha limiti alle stringhe di query, non c'è bisogno di scherzare con le chiavi di crittografia o simili perché HTTPS gestisce tutti di questo per te, e la riproduzione della protezione è solo una parte naturale del processo.

    
risposta data 15.10.2015 - 19:07
fonte

Leggi altre domande sui tag