I need to application 1 make a POST on application 2, but on application 2 I need to make sure that POST comes from the application 1.
Per gli scopi di questo post, chiamerò l'applicazione 1 Client e l'applicazione 2 è Server .
Iniziamo con:
My biggest worry is Man In The Middle attack.
Assicurati che quando il client effettua una connessione al server, il client deve confermare l'identità del server e assicurarsi che non man in the middle . (MITM) Questo è lo stesso problema affrontato dai browser quando si cerca di stabilire una connessione sicura per l'Online Banking o altre operazioni sensibili.
-
Questo è facilmente protetto utilizzando un certificato HTTPS standard (che userebbe la crittografia TLS). La connessione è protetta utilizzando la crittografia asimmetrica, in modo che l'unico modo per realizzare MITM sia quello di rubare la chiave privata dal filesystem del server.
Un certificato può essere rilasciato da un'autorità di certificazione con rinnovo ogni pochi anni oppure è possibile creare un certificato autofirmato archiviato sul sistema Client senza alcun costo.
Ora con identità server e MITM con successo bloccato; devi solo verificare l'identità del Cliente . Ci sono diversi modi per procedere. Scegli uno
-
Segreto condiviso: è sufficiente includere una password sul computer client e il server deve verificare che corrisponda. Questo è il modo più diretto per verificare l'identità del cliente ed è sicuro grazie a HTTPS.
-
Certificato client come parte della connessione TLS: mentre HTTPS fornisce un mezzo per i certificati client, trovo che questo sia più complicato del necessario.
-
Ora del giorno con crittografia: crea te stesso una chiave privata e pubblica separata RSA. Archiviare la chiave pubblica sul client e il server utilizzerà la chiave privata per decrittografare. Il client crittografa l'ora del giorno e il server verificherà che sia corretto. (entro il raggio di azione)
-
Risposta alla sfida: in questo caso, una chiave RSA pubblica viene archiviata sul server e la chiave privata sul client. Il server invia una stringa casuale al client, insieme a un ID di richiesta, e il client deve essere in grado di decrittografare le informazioni e inviarlo di nuovo con l'ID della richiesta corrispondente. Se la decrittografia ha avuto esito positivo, viene verificata l'identità del cliente.
Il vantaggio che questo ha rispetto agli altri è che, supponendo, un utente malintenzionato ha hackerato il server e scaricato i file, non sarà in grado di impersonare un client senza un attacco più avanzato. (anche se sarebbe un passo avanti verso il MITM) Con le soluzioni 1, 2 e 3, il semplice download dei file appropriati dal file system del server fornirebbe le informazioni necessarie per impersonare un Cliente.
Le soluzioni 3 e 4 sarebbero meglio accompagnate da una protezione contro gli attacchi di replay. La soluzione 1 non è compatibile con la prevenzione degli attacchi di Replay. Tuttavia, nel tuo caso d'uso, usando HTTPS, penso che i Replay siano solo un problema dopo un hack riuscito del filesystem Server permettendo quindi MITM.
Bonus:
- Indirizzo IP: se possibile, fare in modo che il server verifichi che la connessione provenga da un indirizzo IP del client predeterminato. Se l'indirizzo IP del client è verificato per non cambiare, questa protezione Bonus fornirà una grande quantità di protezione contro eventuali attacchi alle soluzioni di cui sopra che ho fornito.