Video e sottotitoli · Direct Media Downloader
Una breve storia della politica della stessa origine e di CORS nei browser web
· Sfondo
cor cronologia web sicurezza
La regola che impedisce a uno strumento del browser di leggere liberamente i file di un altro sito risale ai primi browser di scripting. Questo post traccia la policy della stessa origine, XMLHttpRequest e lo standard CORS che alla fine ha reso possibile il recupero controllato tra siti.
Perché un browser si rifiuta di consegnare alla tua scheda i byte appena ricevuti: l'effetto quotidiano di una regola vecchia di decenni
Un browser può visualizzare un file remoto ma rifiutarsi di fornire il corpo della risposta alla pagina JavaScript. L’apparente contraddizione è una separazione di sicurezza tra navigazione e lettura programmatica multiorigine.
Direct Media Downloader rileva la regola perché deve leggere blocchi in un BLOB. Il collegamento nativo Salva come può funzionare laddove il recupero fallisce poiché segue un percorso del browser diverso. Il rifiuto protegge i cookie e le risorse intranet in altre parti del browser, anche se questo particolare downloader omette deliberatamente le credenziali dalle proprie chiamate. Il limite protegge i cookie e le pagine Intranet non correlati nello stesso browser anche se questa particolare richiesta omette le credenziali.
Netscape, JavaScript e la regola della prima origine: il problema di sicurezza che ha portato alla politica della stessa origine
I primi script web rendevano necessario impedire a un sito di leggere le pagine sensibili di un altro sito attraverso l’accesso ambientale di un visitatore. I browser hanno organizzato quel confine attorno alle origini.
I dettagli storici variano a seconda delle implementazioni, quindi l'ereditarietà pratica conta di più: schema, host e porta definiscono un compartimento di fiducia per le risorse leggibili da script. Trattare un'origine come un'unità era un limite tecnico che poteva essere applicato in modo coerente su documenti, script e API di rete. Il raggruppamento di origine forniva un'unità applicabile che i motori del browser potevano applicare a documenti, script, archiviazione e risposte di rete. Il modello è imperfetto ma offre agli sviluppatori un valore predefinito prevedibile anziché un'autorità ambientale illimitata.
XMLHttpRequest e il web isolato: come le richieste basate su script hanno ereditato la regola e perché i mashup hanno avuto difficoltà
XMLHttpRequest ha abilitato il lavoro in background HTTP ma ha mantenuto le restrizioni sull'origine. Ciò ha reso utili le applicazioni sullo stesso sito mentre i mashup tra siti richiedevano cooperazione o intermediari del server.
Un override universale del client avrebbe distrutto la protezione. Il server proprietario della destinazione necessitava di un modo per esprimere quali origini esterne potessero leggere le risposte selezionate. Gli inoltri dei server sono diventati soluzioni alternative comuni, ma hanno spostato la fiducia, la larghezza di banda e il rischio di falsificazione delle richieste verso l'infrastruttura al di fuori della sandbox del browser. Le soluzioni alternative all'inoltro hanno spostato la larghezza di banda, l'affidabilità e il rischio di falsificazione delle richieste lato server oltre la sandbox del client anziché eliminare la policy. Questi intermediari necessitano di controlli propri in materia di sicurezza, privacy e abusi quando vengono utilizzati intenzionalmente.
Lo standard CORS: in che modo le intestazioni di controllo dell'accesso consentono a un server di attivare la lettura multiorigine senza allentare l'impostazione predefinita
CORS fornisce tale cooperazione tramite intestazioni di risposta HTTP interpretate dai browser. `Access-Control-Allow-Origin` può autorizzare un'origine richiedente o, in casi idonei senza credenziali, un pubblico più ampio.
Il meccanismo non disabilita la politica della stessa origine a livello globale. Concede l'accesso in lettura con ambito alle risposte il cui host sceglie di esporle nel protocollo. I risultati del preflight possono essere memorizzati nella cache dal browser in base alle regole del protocollo, quindi un controllo non dovrebbe dedurre che "nessun controllo della politica sia mai avvenuto" da una traccia calda. Ciò preserva l'isolamento predefinito consentendo ai proprietari delle risorse di pubblicare un'eccezione deliberata per chiamanti e metodi selezionati.
Preflight, richieste semplici e risposte opache: il vocabolario che spiega la maggior parte degli errori di download
Alcune richieste multiorigine sono abbastanza semplici da non richiedere un preflight; altri prima inviano OPTIONS per chiedere se il metodo e le intestazioni sono consentiti. Il preflight è una negoziazione, non l'effettivo trasferimento multimediale.
Le risposte opache derivano dalla modalità no-cor e nascondono lo stato, le intestazioni e il corpo dallo script. ToolAcre non seleziona quella modalità perché un corpo illeggibile non può diventare il BLOB salvabile previsto. Un errore CORS può coesistere con una richiesta lato server riuscita, rafforzando il motivo per cui l'errore dell'applicazione non significa che l'origine non ha ricevuto nulla. Le decisioni di preflight memorizzate nella cache possono modificare ciò che appare in una traccia calda, quindi l'assenza storica di OPTIONS non è la prova che la negoziazione non sia mai esistita.
Cosa significa CORS per un downloader solo per browser: l'host decide, lo strumento non può sovrascrivere e l'onestà al riguardo è la risposta giusta
Per questo downloader, l'host decide se le risposte HEAD e GET sono leggibili. ToolAcre non può allegare un'intestazione di risposta consentire l'origine per conto dell'host e non inoltrerà il corpo tramite la propria origine.
L'errore combina CORS e le possibilità di rete perché Fetch trattiene deliberatamente informazioni dettagliate in alcuni errori. DevTools può rivelare al visitatore più di quanto riceve il codice dell'applicazione. Gli operatori host dovrebbero autorizzare solo origini, metodi e intestazioni previsti e quindi verificare le loro esatte risposte di produzione anziché fare affidamento sull'intento di configurazione locale. Una lettura bloccata può coesistere con un server che ha ricevuto la richiesta, motivo per cui l'interfaccia non equipara mai il fallimento dell'applicazione al mancato contatto.
Conclusione: una regola che ti protegge anche quando ti dà fastidio: come funziona Direct Media Downloader al suo interno anziché attorno ad esso
La regola protegge gli utenti anche quando ostacola un trasferimento di file legittimo. Un host che desidera che le applicazioni browser leggano i media pubblici può configurare le risposte CORS appropriate; uno che non rimanga inaccessibile attraverso questo percorso di script.
Direct Media Downloader funziona all'interno di questo modello: convalida localmente, richiede apertamente, spiega il rifiuto e suggerisce il salvataggio nativo ove opportuno. Non trasforma un limite di sicurezza del browser in un problema di bypass. Comprendere tale cronologia trasforma l'errore dall'ostilità arbitraria del browser in una conseguenza visibile di un modello di lettura tra siti con rifiuto predefinito. I proprietari dell'origine dovrebbero testare esatte intestazioni di produzione per i metodi previsti invece di fare affidamento esclusivamente su una configurazione del dashboard.