Protezione sicura tra reindirizzamento dal dominio A al dominio B

Question

Protezione sicura tra reindirizzamento dal dominio A al dominio B

#1 da (2 voti)

1

Sto costruendo un'estensione speciale (sul dominio B) al presente e-commerce ospitato su un dominio A. L'obiettivo è reindirizzare l'utente da A a B e viceversa. Simile alla tecnica in cui l'utente lascia il sito di e-commerce sull'interfaccia web di pagamento con carta di credito e poi reindirizzato. Entrambi i domini sono protetti con SSL / TLS. L'utente si registra solo sul sito A. Il sito B deve conoscere solo il numero di cellulare dell'utente.

Sono arrivato con una soluzione: Pagina A codifica i dati degli utenti e il segreto comune in hash. Dati e hash sono pubblicati su B. La pagina B riceve dati e hash. Quindi rende il proprio hash dei dati e del segreto comune e lo confronta con l'hash dalla richiesta post.

Difetti con questa idea. Qualche idea migliore. Cookies?

Modifica: Sto cercando di impedire che qualcuno possa indirizzare il dominio B da un'altra parte. Il sito B prevede un processo di prenotazione (numero di cellulare come riferimento, invio di codici di check-in tramite sms). Qualcuno di cattivo potrebbe fare la prenotazione e rendere il nostro sistema a corto di slot vuoti o spam noi e altri utenti - cattivo per affari.

hmac tls url-redirection

posta Gregor Pohajač 01.11.2014 - 12:31

fonte

1 risposta

Leggi altre domande sui tag hmac tls url-redirection

Database condiviso e conformità PCI Come posso essere il più anonimo possibile mentre su Tor? [duplicare]

score 2 · Accepted Answer

Quello che hai proposto è essenzialmente un codice di autenticazione dei messaggi basato su hash o HMAC. Finché il segreto condiviso rimane segreto, nessuno sarà in grado di passare i dati al sito B diverso dal sito A.

Ci sono alcune sfumature nell'usare un hash per l'autenticazione dei messaggi, incluso l'attacco lunghezza> , ma a seconda della lingua stai usando, probabilmente c'è già una funzione di libreria HMAC disponibile.

{time passes} Dopo aver riflettuto su questo per un po ', dovresti includere un timestamp nei dati. (E così anche il timestamp verrà passato alla funzione HMAC). Questo serve a prevenire gli attacchi di replay, in cui un utente malintenzionato cattura un messaggio valido (che sarebbe difficile se le connessioni sono TLS / SSL) e lo invia di nuovo in seguito. Entrambi i server devono avere una buona idea di che ora è, cosa che si può fare con NTP. Dovrai anche stabilire un periodo di timeout, dopo il quale scade un messaggio. Per evitare un replay di attacco durante il periodo di timeout, dovrai inserire nella cache i messaggi e rifiutare i duplicati.

Potresti voler semplicemente fare affidamento su TLS / SSL per impedire attacchi di replay a seconda di quanto danno potrebbe fare un simile attacco. Se lo fosse, includerei comunque il timestamp e controllerei i messaggi "vecchi" in modo anomalo se non altro.