Sto progettando un'API RESTful per la mia organizzazione. Usiamo l'autenticazione basata su password, che genera token. Una parte della nostra API richiede che gli utenti siano fisicamente in ufficio, vale a dire che non vi è alcun caso di utilizzo in cui qualcuno avrebbe bisogno di utilizzare quegli endpoint particolari mentre lavorano in remoto. (Ha a che fare con uno scenario fisico di scansione delle carte di controllo.)
Stiamo scrivendo l'API REST in API Web ASP, quindi la mia prima inclinazione era semplicemente quella di controllare l'oggetto Request per vedere qual è l'indirizzo IP remoto e consentire l'accesso alla risorsa solo se quell'indirizzo IP rientra in un lista bianca. (Per quelle chiamate che dovrebbero essere limitate)
Il mio collega, tuttavia, ritiene che questo sia insicuro. Ritiene che vi siano modi per abusare di HTTP in modo tale che un client dannoso possa causare a ASP.NET di segnalare l'indirizzo IP remoto errato; quindi, si sente fino a quando qualcuno conosce la gamma valida di indirizzi (ad esempio un lavoratore potrebbe semplicemente "ipconfig" sulla propria macchina mentre è in ufficio per determinare un IP valido), quella persona potrebbe abusare dell'API e accedervi da qualsiasi luogo.
Suggerisce, invece, di dipendere esclusivamente da un segreto del cliente. Stiamo già utilizzando l'autenticazione della password, quindi non è questo il problema. Quello di cui non sono sicuro è come implementare un client secret in modo tale che 1. non possa essere copiato da una macchina all'altra, e 2. che non possa essere rimosso accidentalmente. Ovviamente tutto il lato client sarebbe in JavaScript, quindi la console "dev tools" è l'equivalente di un disassemblatore.
Devo pensare che una combinazione dei due metodi sia almeno un inizio - forse rendere il segreto del client coinvolgere l'indirizzo IP in questione, e poi fare in modo che l'API remota controlli il segreto del client contro l'IP che la richiesta sembra venire da (Tuttavia, se un utente può in qualche modo copiare il segreto del client, ciò non aiuterà comunque poiché potrebbero semplicemente combinare entrambi i metodi di hacking ...) Questo inoltre non risponde come avremmo "preinstallato" un segreto client nel cliente. Se avessimo l'API REST come segreto per un utilizzo futuro, sei tornato al punto in cui hai iniziato: un hacker malintenzionato potrebbe (apparentemente) alterare il proprio IP e recuperare un segreto che non dovrebbero avere.
La mia conoscenza del protocollo TCP / IP mi dice che non è possibile falsificare l'indirizzo IP di origine su qualsiasi cosa tu desideri e ottenere una connessione TCP di successo. Dato che stiamo usando una lista bianca, qualcuno dovrebbe in qualche modo essere in grado di spoofare il proprio IP dall'esterno per apparire nella nostra rete e impegnarsi in una connessione TCP completa al server HTTP. Non penso nemmeno che sia possibile, ma il mio collega crede ancora che ci sia un modo per abusare della whitelist IP.
Quale di noi ha ragione? O nessuno di noi ha proprio ragione e c'è un approccio completamente diverso e migliore?