whitelist API REST CORS

TLDR: No, e se pensi di averne bisogno, probabilmente stai facendo qualcosa di sbagliato.

Non c'è letteralmente alcun modo possibile per impedire l'accesso non del browser a tutto ciò che è esposto anche ai browser. Per quanto riguarda un server, un browser web è solo un programma che invia e riceve traffico HTTP (e protocolli correlati). Questo è tutto. Puoi farlo usando curl , puoi farlo usando uno dei tanti tipi di oggetto WebRequest disponibile per diversi framework di programmazione, puoi farlo aprendo un semplice socket TCP al server e digitando manualmente i byte per invia (vedi il nc / ncat / netcat programma). Qualsiasi informazione fornita normalmente da un browser (cookie, intestazione User-Agent, HTTPS specifici del browser e peculiarità dell'URL, autorizzazione HTTP, certificati client TLS, analisi JavaScript, ecc.) Può essere falsificata da qualche altro programma. Questo include assolutamente tutte le intestazioni e i comportamenti CORS.

Quello che puoi fare è richiedere l'autenticazione. Se il consumatore del tuo servizio web è autenticato, a chi importa se sta utilizzando un normale browser Web, uno screen reader per non vedenti, un'applicazione mobile, un server web PHP, un programma telnet su un Commodore 64 o bit individualmente molto rapidamente dal semaforo?

In teoria, l'autenticazione cross-origin non è così difficile. Devi inviare l'intestazione di risposta CORS Access-Control-Allow-Credentials: true (che consente le intestazioni e i cookie di autorizzazione HTTP) o l'intestazione di risposta CORS Access-Control-Allow-Headers: <HEADERNAME> (con un'intestazione dell'autorizzazione personalizzata). In entrambi i casi, è inoltre necessario fornire in qualche modo un client per ottenere un token di autenticazione valido (che potrebbe essere tramite un'app Web o un servizio Web o altri mezzi, potrebbe anche essere un altro servizio Web abilitato per CORS) . Ovviamente, in modo simile non hai modo di impedire l'accesso tramite script al servizio auth, in modo che chiunque / qualsiasi persona con credenziali possa ottenere un token valido e quindi utilizzarlo.

Qual è il tuo caso d'uso, qui? Perché stai tentando di bloccare l'accesso tramite script? Perché ti aspetti che funzioni? Voglio dire che i browser web possono eseguire script, quindi non c'è nulla che impedisca a un browser web di caricare una pagina che contiene JavaScript per accedere al servizio web, recuperare i risultati e inviarli a un'applicazione desktop o server.

Modifica

Ultimately is a REST API that enables CORS intrinsically insecure

O non capisci cosa significa "sicuro" o non capisci cosa fanno i server web. I server Web analizzano le richieste HTTP in arrivo (HTTP è un protocollo basato su testo tipicamente inviato sulla porta TCP 80, o racchiuso all'interno di un flusso SSL / TLS inviato alla porta TCP 443) e, in base ai contenuti del Richiesta HTTP, rimandare una risposta HTTP. I server Web sono "intrinsecamente insicuri" nel senso che, se si espongono informazioni sensibili su uno, chiunque può connettersi ad esso attraverso la rete e può inviare la giusta stringa di byte può recuperare tali dati. Ovviamente, è così che funziona approssimativamente ogni server di rete per ogni protocollo al mondo, quindi ...

Come nota a margine, questo non è un problema CORS. Se non si consente affatto a CORS, non farà assolutamente alcuna differenza per il tipo di "attaccante" che si sta immaginando. CORS è un modo per aprire un buco in una parte critica del modello di sicurezza del browser (chiamato " criterio della stessa origine "), ma è assolutamente irrilevante per le cose che non sono browser.

Questo è abbastanza simile alla risposta di CBHacking. Ho appena aggiunto un addo CSRF.

I want to only allow requests from Whitelisted clients.

Se sei sul web, allora sei già morto con gli stivali lì. L'unico vero modo di utilizzare i client di whitelisting è:

1. Crittografia a chiave pubblica per firmare l'intero sistema operativo (e probabilmente anche l'hardware) del dispositivo che esegue il client.
2. Crittografia a chiave pubblica per stabilire un canale sicuro tra il client e il server (anche se HTTPS potrebbe essere sufficiente se i certificati CA fanno parte di ciò che hai firmato sopra).

Seriamente, non provare a farlo, è una commissione stupida.

Ultimately is a REST API that enables CORS intrinsically insecure.

Al contrario. Ma CORS riguarda la sicurezza del browser , riguarda le aspettative dell'utente di fronte a una finestra del browser. In altre parole se la tua API REST in http://rest.com usa questo:

Access-Control-Allow-Origin: http://example.com

Quindi una persona che esplora example.com con un browser può eseguire una richiesta (contenente Origin: http://example.com ) che soddisferà il requisito.

Ma una pagina web canaglia non può farlo dal browser.

Se non vuoi che l'intera rete internet veda una pagina web (o un'API REST) devi autenticare gli utenti che possono vederla. E semplicemente non inviarlo agli utenti che non si autenticano correttamente.

Per impedire le chiamate spoofed è necessario difendere da CSRF, non l'accesso da un determinato client. Esegui l'autenticazione con l'API REST e quindi invia i dati dell'utente solo agli utenti autorizzati.

Ora ciò richiede la protezione CSRF perché CSRF non è realmente coperto da CORS (che non è strettamente vero poiché l'intestazione Origin può essere utilizzata come protezione CSRF ma è una protezione piuttosto scarsa). Utilizza le linee guida OWASPs e produce token di prevenzione CSRF sincronizzati, questo sarà (decentemente) prevenire gli script non autorizzati che possono fiutare il traffico di un utente per iniettare le proprie richieste.

Letture aggiuntive sui CORS rispetto ai token CSRF: vecchio (ma ancora attuale) SO risposta di SilverlightFox