Devo limitare l'origine in un'app API?

Trovato un blog . Da questo jolly non sembra pericoloso a meno che il sito non stia utilizzando la rete client come una sorta di misura di sicurezza.

Posso immaginare che qualcuno cerchi di raggiungere una VPN, ad esempio attraverso il browser della vittima. Avrebbe bisogno di molte conoscenze interne, ma se l'attaccante è un ex dipendente, ad esempio, lui / lei può avere tale conoscenza può anche usare i contatti interni e ingannarli per aprire una pagina web canaglia per eseguire l'attacco.

Qual è lo stesso criterio di origine?

Da Mozilla :

The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents.

Tutti i browser moderni lo applicano.

Perché ce l'abbiamo?

Ciò impedisce a un utente malintenzionato di ingannare un utente nel caricare un URL dannoso nel client e di fare qualcosa come trasferire denaro all'autore dell'attacco perché un browser esegue semplicemente il codice che vede.

Controlla le informazioni OWASP su CSRF . Nello specifico, sotto esempi e "Come funziona l'attacco?"

Che cos'è la condivisione delle risorse tra origini?

Da Mozilla :

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use.

Riassumendo, un MECCANISMO DI BYPASS DI SICUREZZA.

Perché le persone hanno bisogno di CORS?

Perché le persone pensano ancora che AJAX sia bello. Scherzo. In alternativa, si potrebbe dire, gli sviluppatori usano ancora un modello asincrono lato client per caricare i dati nelle loro applicazioni.

EDIT aggiunto in base al commento

Perché limitare questo dominio di origine se l'intestazione Access-Control-Allow-Credentials è impostata su false (o mancante)?

Probabilmente lo sai, ma Access-Control-Allow-Credentials controlla solo se il client / server accetta le credenziali esposte al sito.

In base alle tue risposte, la tua API non richiede credenziali, quindi questo flag è irrilevante, ma dovresti utilizzare CORS con un carattere jolly * o restituire l'origine o limitare l'origine?

Probabilmente c'è un sacco di testo rosso su internet, ma se la tua API è aperta / pubblica piuttosto che usare la wild o echeggiare l'origine va bene.

Se la tua API è più specifica per l'organizzazione, è meglio includere nella whitelist i domini che la userebbero, confrontarti con quell'elenco e restituire l'origine nella whitelist. Queste sono solo buone pratiche di sicurezza.

Non lo disabiliterei però

Sembra che tu abbia un po 'di confusione su come funziona CORS e quando è applicabile, in particolare a causa di questo dalla tua domanda:

Another question is whether there is any security issue in allowing wildcard * all domains to access the API? I don't care if user uses curl, or has his/her own script or has built custom UI for this API. Why should I put restrictions?

La cosa che devi tenere a mente è che CORS e le richieste OPTION pre-volo contano solo per i browser. Se qualcuno sta costruendo la propria API e utilizza CURL o altre richieste da server a server, non ci sarà mai una richiesta pre-volo e tutte le intestazioni Access-Control-Allow-Origin saranno completamente ignorate.

Se, tuttavia, si tenta di effettuare una richiesta Ajax da un browser tramite javascript, il browser stesso imporrà CORS: invierà una richiesta OPTION pre-volo (se necessario) e respingerà la risposta se tutto non lo fa 't check out.

Ricorda anche che CORS protegge da letture, non da scritture. Se si effettua una richiesta POST tramite javascript / ajax, la richiesta verrà comunque inviata al server: l'applicazione javascript di chiamata semplicemente non rileverà la risposta se il controllo CORS non viene convalidato.

La tua risposta sta arrivando al motivo per cui probabilmente vorresti usare CORS (anche se ci sono sicuramente momenti in cui potresti voler consentire tutte le origini). Ricorda che tutte le richieste del browser vengono fornite anche con i cookie. Di conseguenza, se l'applicazione viene autenticata tramite i cookie e se è consentita qualsiasi origine, in teoria chiunque può inserire javascript in qualsiasi sito che effettui chiamate API per conto di utenti autenticati.

Ad esempio, immagina che Amazon abbia una chiamata API effettuata tramite javascript quando fai clic sul pulsante "Acquisto con un clic" in una pagina di destinazione del prodotto (per riferimento, tale chiamata API esiste certamente). Immagina inoltre che le credenziali di autenticazione siano gestite tramite cookie (possibilmente vero) e che un utente malintenzionato abbia trascorso del tempo a capire la struttura della chiamata API (il che non è impossibile poiché il codice Javascript è sempre disponibile per l'ispezione).

Inserisci te (l'attaccante). Stai vendendo un sacco di sporcizia su Amazon per $ 200. Nessuno sta acquistando il tuo prodotto. Quindi scrivi qualche javascript che chiama l'endpoint amazon per eseguire l'acquisto con un solo clic sul tuo sacco di sporco. Non vuoi comprarlo da solo, quindi invece crei un sito Web con video di gatti che diventa molto popolare (dopotutto, a chi non piacciono i gatti?). Su quel sito web metti il tuo javascript che chiama automaticamente il one-click-bag-of-dirt-purchase al caricamento della pagina. Ora, ogni volta che qualcuno visita il tuo sito web mentre sta effettuando l'accesso su Amazon, acquista immediatamente la tua sacca di terra senza intraprendere alcuna azione. I tuoi ordini iniziano a rotolare e Amazon ha un grande casino sulle loro mani a causa della loro mancanza di sicurezza.

Questo potrebbe non essere il miglior esempio del perché avere un'origine aperta possa morderti, ma si spera che riesca a raggiungere il punto. Di nuovo, ci sono certamente alcune chiamate API per le quali un'origine aperta è perfettamente ragionevole. Un buon esempio è la maggior parte delle app di social media: twitter / facebook / etc specificatamente fornisce javascript che deve essere eseguito su altri siti Web in modo da poter facilmente estrarre un feed di Twitter recente. In cambio, hanno i propri cerchi da superare per autenticare le chiamate API. Quindi ci sono sicuramente dei motivi per cui vuoi aprire la tua API. Tuttavia, ci sono anche ragioni per le quali non lo fai. In entrambi i casi, ciò è importante solo per le chiamate all'API del browser. Curl e altre richieste HTTP "dirette" ignorano CORS nel loro insieme.