Ho un'app mobile basata su Cordova che sta raggiungendo alcune API tramite un server locale su dispositivo mobile. L'app mobile imposta l'origine come Localhost. Qui Cors entra e io non posso fare la richiesta. Ora queste API possono essere utilizzate tramite un terminale, postino e altri ambienti senza browser senza attivare CORS.
Ora in questo scenario quali sono i rischi di abilitare cors su localhost? Giusto per chiarire voglio inserire nella whitelist cors per localhost in produzione.
La risposta dipende molto dall'API che hai creato e da come funziona. Questo sito fornisce un'ottima spiegazione sui prodotti e sui cattivi di CORS. In breve, l'autore crea un'API fittizia che viene utilizzata per inviare e-mail da un altro dominio. Dichiara:
If you are using authentication based on session cookies, you probably shouldn’t allow CORS requests by everyone. A malicious website can issue e-mail sending requests to api.yoursebsite.com via an AJAX request without the specific permission of your user.
Questo è (nel suo caso ipotetico) la risposta alla domanda "quali sono i rischi di abilitare cors"? In tal caso, fornisce anche ulteriori informazioni su come pensare alla mitigazione:
If the user has valid session cookies in their browser, they will be used to authenticate on api.yoursebsite.com and that would lead to unwanted e-mail sending. In most cases, dangerous requests will be “preflighted,” which means the domain needs to be approved before they can even send a request. This will prevent any malicious activities from happening.
Questo afferma (in un modo un po 'nascosto) cosa ha già detto dandavis: CORS non ha molto a che fare con la sicurezza. La sicurezza viene eseguita sul lato server. In ogni caso, il SOP non verrà rispettato dagli hacker.
Nel tuo caso, da quanto ho capito, vuoi abilitare localhost come dominio tramite CORS in modo che le richieste possano essere fatte attraverso un dominio diverso? Se è corretto, penso che non dovrai affrontare alcun problema di sicurezza reale . Nella condizione in cui si opta per alcuni socket legati solo all'indirizzo loopback (localhost), l'unico modo in cui qualcuno sarebbe in grado di accedervi (in modo malevolo o in un altro modo) sarebbe: Ha già accesso all'indirizzo loopback. Ciò significa che ha già ottenuto l'accesso al dispositivo.
Sulla base del giusto commento di Conor Mancone: CORS protegge principalmente da richieste di lettura non autorizzate. Non protegge il server dalle scritture o dall'attivazione di azioni non autorizzate. Questo deve essere applicato da un concetto di autorizzazione.
No, questo è NON (necessariamente) sicuro. Le altre risposte sono per lo più corrette, tranne che stanno facendo due ipotesi (comuni, ma errate): che localhost è sempre 127.0.0.1 e che un server web in esecuzione sul tuo computer è quello che si desidera eseguire. QUESTI NON SONO ASSUNZIONI SICURE .
Alcune macchine, a causa di modifiche intenzionali per qualche scopo o semplicemente perché il file HOSTS è minimo (o mancante), non definire localhost come 127.0.0.1 (o :: 1 per IPv6) e quindi effettuare una ricerca DNS per quel nome Il DNS, naturalmente, generalmente non è sicuro; un utente malintenzionato sulla stessa rete (o ovunque tra te e un server DNS che desideri stabilire autorevolmente l'indirizzo IP "localhost") può inserire una risposta DNS che specifica il proprio indirizzo IP. La tua app carica quindi il contenuto Web dal server web dell'attaccante. L'autore dell'attacco può inviare alla vittima contenuti Web dannosi che rubano i crediti al tuo servizio, ruba i contenuti dal tuo account, usa male il tuo account, usa bridge API JS-native per attaccare il tuo dispositivo (o almeno accede maliziosamente ai dati del cellulare app può vedere), e così via.
OK, quindi cosa succede se hai usato "127.0.0.1" invece di "localhost"? Gli indirizzi IP non hanno mai bisogno di andare oltre il DNS, 127.0.0.1 è sempre indirizzato solo alla tua macchina, e dovresti stare bene, giusto?
Ancora una cattiva idea! I socket TCP non rispettano l'isolamento dei privilegi tra gli utenti (o tra le app sandboxed). Se il tuo utente mobile ha una app imprecisa che sta eseguendo un server web su quella porta, la tua app si collegherà al server malevolo anziché a quella che l'app ha tentato di avviare (il che non è riuscito a collegare il socket, poiché è già in uso ). Potresti quasi certamente averlo anche nell'app store; non utilizza alcuna API non consentita o altro, serve solo il contenuto web su un socket di loopback associato a una porta specifica (come te). Analogamente su server / desktop / laptop, se la macchina consente ai non amministratori di effettuare il remote-in (tramite SSH, desktop remoto, ecc.), Uno di questi utenti potrebbe far ruotare un server Web dannoso sulla porta che si utilizza e attendere il proprio app per connettersi ad esso.
Naturalmente, anche senza alcun tentativo malevolo, l'intera idea è solo fragile . Come accennato in precedenza, non c'è alcuna garanzia che nessun altro processo stia eseguendo un server web sulla stessa porta che hai scelto. Ce ne sono solo 2 ^ 16 tra cui scegliere, e per alcuni intervalli il sistema operativo stesso può vincolare casualmente le connessioni in uscita a quella porta in modo che possa essere utilizzata da un'app client (come un browser Web) di un server. In entrambi i casi, il server utilizzato per offrire il tuo contenuto web non riuscirà a collegare la porta, la tua app non sarà in grado di comunicare con il server che si aspetta e l'utente avrà una brutta esperienza.
Si noti che questo non ha nulla a che fare con CORS. WHATEVER da cui carichi il contenuto, il tuo server dovrà consentire a quell'origine di visualizzare le risposte web.
Il punto importante è assicurarsi che il contenuto web sia caricato in modo sicuro e che HTTP su TCP normale, ovvero senza TLS o altri modi per autenticare e proteggere la connessione, non sia sicuro!
Soluzione: carica il contenuto (tramite HTTPS) dai tuoi server web con connessione Internet. Quindi la tua app non ha bisogno di caricare nulla su HTTP, il tuo servizio web non deve consentire alcuna richiesta da nessuna pagina web caricata su HTTP e l'app può essere certa che sta caricando il contenuto dal server giusto.
Puoi persino servire il contenuto dello stesso dominio, in modo che le richieste di cross-origin (cioè CORS) non siano nemmeno necessarie! Usa semplicemente XMLHttpRequests (o Fetch, senza CORS) della vecchia scuola e strappa qualsiasi cosa sia correlata a CORS dal servizio web.
Tempo della storia:
La precedente azienda per cui lavoravo aveva un prodotto che faceva qualcosa di simile a quello che stai descrivendo - il caricamento dei dati da un server web localhost in una webview - e ci imbattiamo in un problema davvero divertente in cui alcune persone riportavano che la vista web era solo ... vuoto. Nessun contenuto. Il server locale era in esecuzione, il contenuto era impacchettato e installato correttamente, la webview stava cercando di fare le richieste web ... ma sembrava che il server non rispondesse. Per farla breve, alla fine l'abbiamo rintracciata in "localhost" essendo indefiniti su quelle macchine. Erano solo pochi utenti su ~ 10.000 (su Mac, poiché questa era l'unica piattaforma su cui girava la nostra app), ma è stato sufficiente un problema che abbiamo smesso di usare "localhost". Ovviamente, "127.0.0.1" è risultato non sicuro, come ho spiegato sopra, ma quella decisione è stata presa prima che avessero una persona della sicurezza nel team.
Leggi altre domande sui tag javascript access-control cors