Domanda:
Lo stesso JavaScript recuperato da HTTP e HTTPS verrà memorizzato nella cache separatamente dal browser?
SamTest
2019-12-12 14:07:45 UTC
view on stackexchange narkive permalink

Supponiamo che un server web supporti sia HTTP che HTTPS. Se un browser recupera lo stesso JavaScript con HTTP GET e HTTPS GET e JavaScript è in grado di memorizzare nella cache, il browser memorizzerà nella cache due copie dello stesso JavaScript?

Il motivo per cui lo chiedo è questo se solo una copia è memorizzata nella cache, sarebbe possibile per un utente malintenzionato prima indurre la vittima a scaricare JavaScript tramite HTTP e comprometterlo lungo il percorso, il che si tradurrà in un attacco di avvelenamento della cache?

@MechMK1: non è la stessa domanda.Il PO ha chiaramente un aspetto della sicurezza delle informazioni ora nella questione.
@SteffenUllrich Fare una nuova domanda non è però la risposta.Modificare la domanda originale e attendere la riapertura è la strada.
@MechMK1 hai ragione, ma ora ci sono risposte su questo.Questo ora ha il caso d'uso, rendendo la prima parte semplicemente un contesto e non la domanda centrale.
@MechMK1, mi scuso se ho violato di nuovo la regola, vedo che la mia ultima domanda era chiusa e non vedevo un modo per modificare e protestare, quindi ho aperto una nuova sessione.
@SamTest Il sistema non è spiegato molto bene, quindi non ti biasimo per non aver visto cosa avresti dovuto fare invece.Per quanto ne so, la procedura corretta sarebbe stata quella di modificare la tua domanda e quindi attendere che la domanda venga elaborata nella coda di riapertura.
@MechMK1 "_Fare una nuova domanda non è la risposta però_" Avere una domanda di modifica, esp.uno che andava bene e appropriato in primo luogo, dover aspettare fino a quando non viene sbloccato è umiliante.
@curiousguy Non lo considero * umiliante *, ma sono d'accordo che questo non è un flusso di lavoro ideale.Mi lamenterei su Twitter, ma non uso Twitter.
@MechMK1 L'umiliazione era probabilmente troppo forte, ma la trovo sgradevole, arbitraria, fastidiosa e leggermente vessatoria.
@curiousguy La riapertura automatica non è implementata perché alcune domande vengono semplicemente messe fuori tema, anche se OP non è d'accordo.Previene cicli di chiusura-modifica-chiusura-modifica inutili, che consumano solo risorse di moderazione che sono già distribuite così com'è.
Sette risposte:
MSalters
2019-12-12 22:32:37 UTC
view on stackexchange narkive permalink

Le risorse vengono memorizzate nella cache in base al loro URL e il protocollo ( http: // o https: // ) fa parte dell'URL. Poiché il protocollo è diverso, anche l'URL deve essere diverso e hai due voci separate della cache.

Steffen Ullrich
2019-12-12 15:07:05 UTC
view on stackexchange narkive permalink

Va ​​benissimo se una risorsa http: // e una https: // forniscono dati diversi, anche se tutto tranne il metodo di accesso è lo stesso. Ad esempio, l'accesso a http: // oggi spesso si tradurrà in una risposta di reindirizzamento mentre l'accesso a https: // fornisce il contenuto reale. Un browser memorizzerà quindi queste risorse indipendentemente l'una dall'altra.

Seguendo il tuo esempio, se `` http: // example.com / example.js``` viene reindirizzato a `` https: // example.com / example.js``` e `` `example.js`` `è stato finalmente recuperato, questo script verrà memorizzato nella cache in` `http: // example.com``` o` `https: // example.com```?
A seconda del codice di risposta esatto e delle intestazioni "Cache-Control", la risposta "http: ..." verrà memorizzata nella cache come reindirizzamento.La voce cache per la risposta "https: ..." memorizzerà quindi separatamente il JS effettivo.Nelle successive richieste di "http: ...", il browser controllerà la sua cache, vedrà un reindirizzamento e quindi inizierà una richiesta per il target di reindirizzamento, possibilmente senza inviare alcun byte sulla rete.Nel tuo scenario, il browser cercherà il `https: ...` JS, che può servire anche direttamente dalla cache o andare alla rete.Quanto sopra può anche essere modificato da HSTS.
Non credo che questo risponda alla domanda: queste risorse sono gestite come uguali nella cache?
Le risorse @Daan: vengono memorizzate nella cache dall'URL che era * direttamente * (ovvero nessun reindirizzamento intermedio) utilizzato per richiedere la risorsa memorizzata nella cache.Ciò significa che queste risorse hanno voci di cache diverse.
Teoricamente, potresti esprimere che le posizioni sono equivalenti usando le intestazioni `Content-Location` o` Location`, e quindi una cache sarebbe autorizzata a trattarle allo stesso modo.Non so se qualche implementazione comune lo faccia effettivamente.
@StopHarmingMonica La cache di un programma utente si basa sulla _request_, non sulla _response_.Ciò potrebbe includere la memorizzazione nella cache _il fatto che il risultato è stato un reindirizzamento_, ma non è lo stesso che _considerare i due URI come equivalenti_.In particolare, la relazione è unidirezionale: se la risorsa A reindirizza alla risorsa B, una modifica alla risorsa A non avrà alcun effetto sulla cache per la risorsa B.
@IMSoP Spiacente, volevo dire "Link", non "Location".Non sono coinvolti reindirizzamenti.Il comportamento della cache di un programma utente è molto determinato dalle intestazioni di risposta.
@StopHarmingMonica Se una risposta potesse indurre un programma utente a considerare due risorse equivalenti, sarebbe di per sé un enorme problema di sicurezza.Considera se scrivo una pagina su `https: // esempio.com / qualunque` che afferma, in qualsiasi modo tu voglia, di essere" equivalente a `https: // apple.com`";in seguito, cambio quella pagina per servire invece contenuti dannosi.Se il browser unisse semplicemente le due voci della cache, potrei sovrascrivere la cache dell'utente di `https: // apple.com` con il mio contenuto dannoso.La risposta può _ restringere_ i casi in cui una cache è valida, ma non può _widen_.
@IMSoP sì, farlo attraverso le origini sarebbe sicuramente insicuro
IMSoP
2019-12-13 19:15:24 UTC
view on stackexchange narkive permalink

Riassunto:

  • La chiave della cache primaria per qualsiasi browser conforme agli standard è un URI assoluto
  • L'URI assoluto inizia http: per tutte le richieste non sicure e https: per tutte le richieste protette
  • Di conseguenza, una risorsa recuperata in modo sicuro non può mai utilizzare la stessa chiave di cache di una risorsa recuperata in modo non sicuro

L'attuale standard per HTTP è suddiviso in più documenti "RFC", con RFC 7234 interamente dedicato alla memorizzazione nella cache, poiché è coinvolta molta complessità.

Nella sezione 2, "Panoramica del funzionamento della cache", c'è questo riepilogo:

La chiave della cache primaria è costituita dal metodo di richiesta e dall'URI di destinazione. Tuttavia, poiché le cache HTTP di uso comune oggi sono tipicamente limitate alla memorizzazione nella cache delle risposte a GET, molte cache rifiutano semplicemente altri metodi e utilizzano solo l'URI come chiave della cache primaria.

Questo è più formalmente indicato nel primo punto dell'elenco nella sezione 4, che dice:

Quando viene presentata una richiesta, una cache NON DEVE riutilizzare una risposta memorizzata, a meno che [...] l'URI della richiesta effettiva presentata ( Sezione 5.5 della RFC7230) quella della corrispondenza della risposta memorizzata [...]

La sezione 5.5 della RFC 7230 inizia dicendo

Per un programma utente, l'URI della richiesta effettiva è l'URI di destinazione.

Un browser è un "agente utente", quindi questo è il caso che ci interessa qui. "Target URI" è definito nella sezione 5.1:

Un riferimento URI (Sezione 2.7) viene solitamente utilizzato come identificatore per la "risorsa di destinazione", che un utente l'agente si risolverebbe nella sua forma assoluta per ottenere l '"URI di destinazione". L'URI di destinazione esclude l'eventuale componente di frammento di riferimento, poiché gli identificatori di frammento sono riservati per l'elaborazione lato client (RFC3986, sezione 3.5).

La definizione generica di un URI è in RFC 3986 e le preoccupazioni specifiche per HTTP occupano tre pagine della RFC 7230. La parte più rilevante per i nostri scopi è RFC 3986 sezione 4.1 che definisce questa grammatica per gli URI assoluti:

absolute-URI = schema ":" hier-part ["?" query]

Fondamentalmente, nota che schema è una parte obbligatoria di qualsiasi URI assoluto. Poiché gli URI HTTP utilizzano sempre lo schema http e gli URI HTTPS utilizzano sempre lo schema https , ciò significa che i loro URI assoluti, e quindi le loro "chiavi cache primarie" in un browser, non possono mai entrare in collisione.

Altre risposte hanno menzionato le porte. RFC 7230, sezione 2.7.1 definisce gli http URI come includenti una sezione "authority", che è definita in [RFC 3986, sezione 3.2]:

authority = [userinfo "@"] host [":" port]

La porta è facoltativa, con RFC 7230, sezione 2.7.1 definizione del valore predefinito per lo schema URI http :

Se il sottocomponente della porta è vuoto o non viene fornito, la porta TCP 80 (la porta riservata per i servizi WWW) è quella predefinita .

E la sezione seguente che definisce il valore predefinito per "https":

Tutti i requisiti sopra elencati per lo schema "http" sono anche requisiti per lo schema "https", tranne per il fatto che la porta TCP 443 è l'impostazione predefinita se il sottocomponente della porta è vuoto o non è specificato, e ...

Segue quindi che:

  • Qualsiasi richiesta HTTP non sulla porta 80 deve includere un numero di porta nel suo URI assoluto
  • Qualsiasi richiesta HTTPS non sulla porta 443 deve includere un numero di porta nel suo URI assoluto
  • Nessuna delle due richieste con numeri di porta diversi specificati avrà la stessa chiave di cache, poiché avranno URI assoluti distinti

Quindi questi URI sarebbero tutti memorizzati nella cache separatamente :

L'unica cosa su cui non sono chiaro è se il browser debba, può o deve normalizzare gli URI che menzionare esplicitamente la porta che sarebbe comunque quella predefinita. In altre parole, indipendentemente dal fatto che questi due URI vengano memorizzati nella cache separatamente o meno:

Non riesco a pensare a nessuna conseguenza pratica di normalizzarli sulla stessa chiave di cache, perché dalle definizioni precedenti si garantisce che rappresentino la stessa risorsa.

[RFC 7230 section 2.7.3] (https://tools.ietf.org/html/rfc7230#section-2.7.3) e [RFC 3986 section 6.2.3] (https://tools.ietf.org/html/rfc3986#section-6.2.3) rende abbastanza chiaro che i browser _può_ normalizzare `http: //example.com: 80 / path` in` http: // example.com / path`, ma sembra che smettano di direche _devono_ farlo ai fini della memorizzazione nella cache.
Ho fatto dei test veloci.Firefox, Safari e Chrome normalizzano tutti l'URL per tutti gli scopi.Edge normalizza l'URL per la memorizzazione nella cache, ma non per scopi di visualizzazione.Internet Explorer è ... strano (non sono riuscito a ottenere un comportamento coerente della cache indipendentemente dall'URL).
Oltre ad avere l'URI assoluto nella chiave, i browser aggiungeranno anche l'origine del frame superiore nella chiave (chiamata cache a doppia chiave).Questo per proteggere da XS-Leaks.Safari aveva già la cache a doppia chiave (ma in modo leggermente diverso) per un po '.https://www.jefftk.com/p/shared-cache-is-going-away
@IlmariKaronen Dato che la memorizzazione nella cache è opzionale all'inizio, sembra naturale che richiedano solo di differenziare tra cose che possono riferirsi a risorse diverse, mentre non richiedono di identificare necessariamente tutti i casi di risorse uguali.
Jonathan
2019-12-12 16:10:40 UTC
view on stackexchange narkive permalink

Sì, perché sono destinazioni di rete diverse. La porta TCP non viene mostrata nella barra degli indirizzi quando si utilizza la porta standard.

Il valore predefinito di HTTP è la porta tcp 80. Www.example.com:80

Il valore predefinito di HTTP è la porta tcp 443Www.example.com:443

Anche se il dominio e ip sono gli stessi, le porte non lo sono. Dal punto di vista del browser, il browser comunica con diversi siti.

La rete non lo influenza tanto quanto la S in https. È anche un URI diverso.

La prima riga qui non dovrebbe dire "sì", se è per rispondere al titolo?(si, mi rendo conto che la domanda contiene qualche riformulazione del titolo con senso inverso alla domanda del titolo).
Grazie!.Immagino che sia lo stesso caso a livello di CDN e proxy inverso?
Questo sembra essere sbagliato.Se la memorizzazione nella cache è avvenuta a livello TC / IP, avresti problemi con SNI (Server Name Indication).Più siti possono condividere lo stesso TCP / IP.
Sono sicuro al 99% che la memorizzazione nella cache sia impostata su _URIs_ ("Uniform Resource Identifiers"), non sulle connessioni di rete.Se ci fosse uno scenario in cui HTTP e HTTPS fossero serviti sulla stessa porta, le due richieste sarebbero comunque distinte, perché richiedono risorse diverse, con URI diversi.
Sono d'accordo con @IMSoP, almeno la cache del browser web è basata sull'URL.Quello che non sono certo è se il protocollo HTTPS / HTTP o la porta 443/80 sono considerati chiave di cache e se questo comportamento è coerente per tutti i browser e le cache intermedie (CDN o proxy inverso).
Sto downvoting perché hai ragione per le ragioni sbagliate.Non è la porta (implicita o meno) che distingue un indirizzo HTTP da un indirizzo HTTPS, è il protocollo.
@Mark no, `http: //www.example.com: 80` è anche un URI diverso (e quindi non equivalente alla cache) di` http: //www.example.com: 8080`
@Mark: Bene, no, questa risposta è esattamente corretta.Direi che la porta è il discriminatore principale, anche se non mi sorprenderebbe se un browser _anche_ discriminasse il protocollo (quando la porta è, per qualche strana ragione, e sfida la logica, lo stesso)
@LightnessRaceswithMonica La memorizzazione nella cache è un concetto a livello HTTP, non a livello di rete, e definito in termini di URI, non di destinazioni di rete.La porta è rilevante _solo a causa della sua interazione con gli URI_.Ho appena pubblicato una risposta con riferimenti completi, quindi non abbiamo bisogno di speculare.
@IMSoP Non abbiamo mai avuto bisogno di speculare, perché è chiaramente ovvio - vedi l'esempio di StopHarmingMonica.Ma sono contento che i riferimenti che hai trovato confermino questo.:)
@IMSoP In realtà non sono sicuro di cosa stavi dicendo nel tuo commento.Certo, un URI non _have_ per descrivere una risorsa che si trova su una rete.Ma nessuno ha affermato che lo abbia fatto.
@LightnessRaceswithMonica Volevo dire che non abbiamo bisogno di speculare sul fatto che sia la porta o lo schema a fare la differenza o come potrebbero funzionare diversi browser, possiamo cercarlo nelle specifiche.E la risposta è che lo schema fa sempre parte dell'URI, quindi creerà sempre una voce di cache diversa, indipendentemente da qualsiasi cosa abbia a che fare con le porte.La menzione di "livello di rete" si riferiva alla prima riga di questa risposta, che afferma erroneamente che la cache varierà "perché sono destinazioni di rete diverse".
@IMSoP ma non ha nulla a che fare con ciò che è a livello di rete.Sia il protocollo che la porta fanno parte dell'URI.Entrambi fanno la differenza.
@StopHarmingMonica Sono d'accordo.La domanda che stiamo commentando afferma altrimenti.
@IMSoP Bene, se sono destinazioni di rete diverse, allora hanno URI diversi;) Ma, se dobbiamo fare un pelo nell'uovo, sono d'accordo che l'affermazione è forse fuorviante restrittiva.Comunque penso che siamo tutti fondamentalmente d'accordo.
Supponiamo che HTTPS sia stato implementato da una sorta di stile `STARTTLS` o da una procedura di intestazione` Upgrade` sulla porta 80. Ciò renderebbe `https: //example.com: 80 /` equivalente a `http://example.com:80/ `?
@curiousguy no, quegli URL sono ancora diversi
symcbean
2019-12-13 05:37:40 UTC
view on stackexchange narkive permalink

Tralasciando il fatto che la specifica è abbastanza chiara che URL diversi dovrebbero essere trattati come risorse diverse, non credi che qualcuno l'avrebbe notato e sfruttato se non fosse stato il caso? Dopo che tutti i problemi esposti dai cookie (e risolti dal flag "secure") sono noti da 20 anni o più.

Quindi il browser deve recuperare entrambi gli URL. È concepibile che una cache possa conservare una singola copia di un file scaricato da fonti diverse ma accessibile tramite chiavi diverse - o che questa deduplicazione possa avvenire più in profondità nel filesystem (deduplicazione). Ma questo sarebbe accaduto solo dopo che la cache (o il filesystem) avesse determinato che i file erano gli stessi.

Bene, grazie per il tuo commento, ma non posso essere d'accordo sul tuo primo punto.La maggior parte delle vulnerabilità di sicurezza sembravano "semplici" solo dopo che qualcuno le aveva trovate.Per me, mi è capitato di pensare a questo punto e sono curioso di come si comporta davvero nella pratica.
Martin
2019-12-13 19:33:46 UTC
view on stackexchange narkive permalink

Da una prospettiva lato server, lo stesso URL (es. www.test.com) su diversi protocolli (es. HTTP vs HTTPS) può utilizzare una diversa sorgente di file. Quindi un URL con TLS può generare un sito Web completamente diverso dall'URL senza TLS. Questo da solo mi fa pensare che i browser non utilizzeranno la stessa cache per entrambi i file.

Sembra un duplicato esatto della [risposta di Steffen Ullrich] (https://security.stackexchange.com/a/222648/51961).
Aaron Cicali
2019-12-14 03:47:20 UTC
view on stackexchange narkive permalink

Sì, queste sono origini diverse. Sebbene sia molto probabile che offrano lo stesso contenuto, tecnicamente possono servire contenuti completamente diversi. Per questo motivo, il browser non è autorizzato a trattarli come la stessa risorsa.

Ciao, questo in realtà non aggiunge nulla che altre risposte non abbiano già detto.È anche problematico utilizzare la parola "origine" qui, perché ha un significato particolare nelle tecnologie web e molti URL possono avere la stessa origine ma richiedono comunque voci di cache completamente diverse.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...