Passaggio dell'identità utente a un servizio REST interno

4

Ho due servizi - A e B - che espongono entrambi un'API HTTP / REST. Il servizio A è esposto al pubblico e autentica i suoi utenti. Delega parte del carico di lavoro al servizio B che deve anche conoscere l'identità dell'utente autenticato ed eseguire alcuni controlli di accesso. Il servizio B non ha un indirizzo IP pubblico e accetta solo le connessioni dai servizi nella stessa rete interna (il servizio A è uno di questi).

Poiché considero attendibile la connessione tra A e B (sono entrambi dietro due firewall), ho semplicemente passato l'identità dell'utente in un'intestazione HTTP personalizzata. Ci sono vulnerabilità in questo setup a cui non sto pensando? Esistono metodi standard per trasmettere l'identità dell'utente anziché utilizzare un'intestazione HTTP personalizzata?

    
posta Muton 02.03.2017 - 19:44
fonte

2 risposte

1

Ho quasi esattamente lo stesso problema con due miei servizi.

Sto seguendo un percorso leggermente diverso per risolverlo a causa del seguente ragionamento: cosa succede se a causa di un errore di configurazione del firewall o di un router, il servizio B diventa improvvisamente disponibile su Internet o sulla rete interna della mia compagnia? Abbiamo modificato le regole del firewall senza che venissimo informati dei cambiamenti avvenuti in passato; quindi sono cresciuto attento.

Ecco cosa sto facendo attualmente: i servizi A e B condividono una password segreta che solo loro conoscono. Lo uso per costruire un hmac su una piccola struttura json (il mio "token di accesso") sul servizio A che contiene fondamentalmente il nome utente dell'utente autenticato, un nonce e una data di scadenza. Passo il token di accesso e hmac al servizio B (come una lunga stringa con codifica Base64 nell'intestazione Autorizzazione standard). Il servizio B convalida il token di accesso utilizzando hmac e, se viene estratto, può essere ragionevolmente sicuro che il token di accesso ricevuto provenisse dal servizio A. Tutto ciò che rimane è assicurarsi che il token di accesso non sia scaduto.

Potresti fare lo stesso con una JWT e con la crittografia a chiave pubblica per firmare digitalmente il token di accesso, invece di quello che sto facendo con un hmac.

Questo non è molto diverso da quello che stai facendo - costruire il mio token di accesso (solo una volta, quando l'utente accede al servizio A) non è molto lavoro, e nessuno dei due sta verificando il token sul servizio B, ma aggiunge ulteriore sicurezza, rispetto alla soluzione.

Proprio come te, sarei interessato a risposte che descrivono un modo generalmente accettato di risolvere questo problema - ho sempre pensato che la mia soluzione fosse un po 'troppo cresciuta in casa e potessi soffrire di problemi che non posso immediatamente vedere.

    
risposta data 03.03.2017 - 00:40
fonte
0

La "difesa in profondità" riguarda la pianificazione del fallimento. In questo modello di rete, una vulnerabilità vulnerabilità richiesta lato server (SSRF) sarebbe estremamente preziosa per un avversario .

Tieni presente che nessuno sviluppatore intende implementare software non sicuro, e tuttavia questi problemi sono dilaganti.

    
risposta data 02.03.2017 - 20:16
fonte

Leggi altre domande sui tag