whitelist API REST CORS

2

Ho un'API REST. Voglio utilizzare questa API da più applicazioni web. Voglio consentire solo le richieste dei client autorizzati. Il mio primo punto sarebbe quello di aggiungere tutte le intestazioni necessarie al server Web API REST (domini consentiti). Ma fa questo solo ai client di whitelist che usano i browser ?. C'è un modo per impedire effettivamente l'accesso tramite script all'API? Per accesso tramite script intendo PHP, JAVA, .NET o un altro linguaggio lato server che effettua una chiamata web direttamente all'URL dell'API REST e, naturalmente, poiché la richiesta viene creata manualmente, è possibile aggiungere qualsiasi intestazione desiderata (ORIGIN, ecc.), Quindi potrebbe falsificare una richiesta di dominio. Non penso nemmeno che hai bisogno di uno script, una richiesta composta da violinista avrebbe lo stesso risultato.

È possibile consentire solo le richieste dai browser (che passano la configurazione di CORS) e negare a tutti gli altri.

In definitiva è un'API REST che consente a CORS di essere intrinsecamente insicuro. Anche se le intestazioni CORS ti forniscono un meccanismo per i client di whitelisting basato su HTTP e le richieste HTTP costruite manualmente possono facilmente aggirare questo problema.

Una configurazione CORS consentirà di impedire l'incorporamento arbitrario nel sito Web che non si desidera, quindi è utile.

È stato un argomento che è emerso alcune volte nel mio team. In questi giorni stiamo scrivendo sempre più applicazioni API (REST) Web, il che è un buon motivo per cui la funzionalità può essere riutilizzata in una nuova applicazione semplicemente, ma sono state sollevate riflessioni sulla sicurezza. Non sicurezza nell'esposizione dei dati, ma solo permesso l'accesso all'API in base ai client consentiti, che autorizziamo.

    
posta OJay 13.09.2016 - 23:38
fonte

2 risposte

3

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.

    
risposta data 14.09.2016 - 00:02
fonte
1

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

    
risposta data 14.09.2016 - 00:14
fonte

Leggi altre domande sui tag