Impostazione Access-Control-Allow-Origin: * quando gli identificatori di sessione sono iniettati nelle intestazioni HTTP

0

È considerato sicuro per un'applicazione impostare un'intestazione access-control-allow-origin: * se durante il normale utilizzo dell'applicazione, le credenziali del client vengono iniettate nelle intestazioni dal codice JS? Per esempio:.

GET /application/secretStuff

X-Authorization-Key: aaa
X-Authorization-Secret: bbbb

Ciò significa che se un codice dannoso esterno tenta di effettuare una chiamata a questo URL sarà in grado di vedere la risposta, ma questo sarà comunque un errore di autorizzazione.

Capisco che c'è almeno un importante inconveniente in questo, vale a dire l'aumento della superficie di attacco. Ma sto cercando di capire se questo approccio ha altri problemi importanti.

    
posta christophetd 11.04.2017 - 10:20
fonte

2 risposte

1

Le richieste di origine incrociata sono pericolose solo quando il tuo browser mostra qualcosa di diverso dal browser del pirata informatico . Questo è il caso se il sito web è accessibile solo dalla tua posizione e non dall'aggressore, o quando hai effettuato l'accesso a qualche sito web. Se sei loggato, le richieste forgiate portano i tuoi cookies per quel sito web, dove le richieste normali da parte dell'aggressore non lo fanno. Se il sito che utilizzi non ha cookie o altra forma di autenticazione implicita , gli attaccanti non possono ottenere nulla dalle richieste di origine incrociata.

Quindi non è proprio la presenza di intestazioni, ma l'assenza di cookie che renderebbe l'applicazione sicura contro le richieste di origine incrociata.

    
risposta data 15.05.2017 - 15:44
fonte
1

This means that if an external malicious code tries to make a call to this URL it will be able to see the response, but this will be an authorization error anyway.

Sì, è corretto. Per essere in grado di ricavarne qualcosa di valore, l'autore dell'attacco deve ottenere le credenziali. Se questi sono memorizzati nell'archivio locale, nelle variabili JS o in qualsiasi modo saranno protetti dallo stesso criterio di origine applicato dal browser.

Quindi non ci sono grossi problemi con la tua politica CORS in se stessa. Ma ci sono molti problemi correlati a cui devi pensare: lo schema di autenticazione è buono? Presumo che le terze parti debbano utilizzare l'API poiché si desidera abilitare richieste di origine incrociata, quindi come ottengono i segreti le terze parti? E così via.

    
risposta data 14.05.2017 - 18:25
fonte