The Web Origin Concept | Cerca per titolo, autore, parola chiave | ||||||||
The Web Origin Concept RFC ( Request for Comments ) 6454, Dicembre 2011, A. Barth. Gli User Agent ( browser ) interagiscono con contenuti creati da differenti autori. La gran parte di questi autori sono certamente corretti, mentre alcuni altri potrebbero avere intenzioni non proprio benevoli. Visto che gli User Agent modellano il proprio comportamento in base ai contenuti che si trovano ad analizzare, gli implementatori degli User Agent potrebbero desiderare di restringere la capacità degli autori con intenzioni malevoli di spezzare la confidenzialità o l'integrità proprie di altri contenuti o di altri server. Come esempio, prendiamo uno User Agent HTTP, che interpreta i contenuti HTML in arrivo da vari server. Quando lo User Agent eseguisse gli script presenti in quei documenti, è molto probabile che l'implementatore dello User Agent desidererebbe che uno script scaricato da un server malevolo non fosse in grado di leggere i documenti in arrivo da un server onesto, che potrebbe, addirittura, trovarsi protetto da un firewall. Da sempre, gli User Agent dividono i contenuti in base alla loro "origine", permettendo ai contenuti originati da un server di interagire con altri contenuti originati dallo stesso server, ponendo, invece, alcune restrizioni all'interazione tra contenuti originati da server differenti. Questa RFC descrive i principi che sottostanno alla politica definita "della stessa origine" ( same-origin policy ) e gli aspetti essenziali della comparazione e serializzazione delle origini. Vediamo un esempio: <script src="https://example.com/library.js"></script> Quando uno User Agent analizza questo elemento, lo preleva all'indirizzo designato ( URI ) e lo esegue con i privilegi assegnati al documento. In questo modo, il documento trasferisce tutti i privilegi a lui assegnati alla risorsa designata dallo URI ( Uniform Resource Identifier ). In pratica, il documento dichiara la propria fiducia nell'integrità delle informazioni prelevate a quell'indirizzo ( URI ). Oltre ad importare documenti dall'indirizzo ( URI ), lo User Agents invia informazioni al server remoto designato dall'indirizzo stesso, come nel caso di un modulo HTML ( form ): <form method="POST" action="https://example.com/login"> ... <input type="password"> ... </form> Quando l'utente inserisce la password ed invia i dati, lo User Agent invia la password al computer di destinazione ( endpoint ), designato dallo URI. In questo modo, il documento esporta dati sensibili verso lo URI designato, dichiarando, essenzialmente, di fidarsi della confidenzialità delle informazioni inviate al server di destinazione. Anche nel caso di nuovi protocolli, che utilizzino la same-origin policy, è importante che rendano visibili nello URI questa distinzione nella fiducia. Per esempio, se risorse TLS ( Transport Layer Security ) e non TLS usassero, entrambe, lo schema http, un documento non sarebbe in grado di specificare che desidera ricevere script solo via TLS. Utilizzando, invece, lo schema https, i documenti sono in grado di indicare che desiderano interagire esclusivamente con risorse protette da attacchi esterni. In principio, gli User Agent trattavano ciascun URI come un dominio separato, richiedendo un consenso esplicito per permettere ad un contenuto ricevuto da un URI di interagire con un contenuto ricevuto da un URI differente. Sfortunatamente, questa impostazione si dimostrò un vero incubo, per gli sviluppatori, poichè le applicazioni web, spesso, utilizzano più risorse contemporaneamente. Oggi, invece, gli User Agent raggruppano gli URI in domini chiamati "origini": due URI appartengono alla stessa origine se hanno lo stesso schema, lo stesso host e la stessa porta. Perchè non usare solo l'host? Includere lo schema nell'origine è essenziale per la sicurezza. Se lo User Agent non tenesse conto dello schema, non ci sarebbe alcuna distinzione tra i due indirizzi seguenti: http://example.com https://example.com visto che entrambi condividerebbero l'host. Grazie a questa mancata distinzione, un malintenzionato potrebbe corrompere il contenuto in arrivo da: http://example.com e far sì che quel contenuto istruisca lo User Agent,al fine di compromettere la confidenzialità e l'integrità anche del contenuto in arrivo da: https://example.com bypassando la protezione offerta da TLS. Perchè usare il fully qualified host name, invece del top-level domain? Nonostante il sistema DNS preveda una delega di tipo gerarchico, le relazioni di affidabilità tra differenti nomi di host dipendono anche dall'uso. Per esempio, in molti istituti scolastici, gli studenti possono conservare i loro contenuti all'indirizzo: https://example.edu/~student/ ma questo non significa che un documento di uno studente debba vedersi assegnare la stessa origine ( rientrando nello stesso dominio di sicurezza ) di un'applicazione web che gestisce i voti, conservata all'indirizzo: https://grades.example.edu/ Vediamo alcuni esempi. Tutte le seguenti risorse hanno la stessa origine: http://example.com/ http://example.com:80/ http://example.com/path/file poichè condividono, nell'indirizzo web ( URI ) lo schema, l'host, la porta. Ciascuna delle risorse seguenti, invece, ha una differente origine rispetto alle altre: http://example.com/ http://example.com:8080/ http://www.example.com/ https://example.com:80/ https://example.com/ http://example.org/ http://ietf.org/ poichè almeno un componente dell'indirizzo, o lo schema, o l'host oppure la porta, non è mai condiviso dagli altri. Autorità Sebbene gli User Agent raggruppino gli URI in origini, occorre ricordare che non tutte le risorse, aventi la stessa origine, condividono lo stesso grado di autorità. Per esempio, un'immagine è un contenuto passivo e non trasporta, di conseguenza, alcuna autorità, nel senso che un'immagine non ha alcun accesso agli oggetti disponibili nella sua origine. Al contrario, un documento HTML trasporta la piena autorità sulla sua origine: gli script compresi o importati nel documento HTML possono accedere a qualsiasi risorsa della sua origine. Gli User Agent stabiliscono il grado di autorità da assegnare ad una risorsa, in base al tipo di media associato alla risorsa (media type ). Per esempio, una risorsa del tipo: image/png verrà trattata come immagine, mentre una risorsa del tipo: text/html verrà trattata come documento HTML. Quando l'host ospita documenti inaffidabili ( quali le pagine utente ), le applicazioni web possono limitare l'autorità dei contenuti limitando i loro media type. Per esempio, rilasciare i contenuti utente come image/png è meno rischioso che rilasciarli come text/html. Naturalmente, molte applicazioni web incorporano contenuti inaffidabili, all'interno dei loro documenti HTML. Se non si presta attenzione, queste applicazioni rischiano di trasmettere l'autorità associata alle loro origini ai contenuti inaffidabili, una vulnerabilità chiamata comunemente cross-site scripting. Quando si implementano nuove parti di una piattaforma web, occorre prestare molta attenzione a non riconoscere autorità a risorse che non riflettono il media type. Molte applicazioni web rilasciano contenuti inaffidabili, restringendone il media type. Una nuova piattaforma web che dovesse concedere autorità a questi contenuti, rischierebbe di introdurre una serie di vulnerabilità in applicazioni già esistenti. Meglio sarebbe assegnare autorità a media type a cui sia già stata assegnata la piena autorità propria dell'origine, oppure a nuovi media type, progettati specificatamente per trasportare la nuova autorità. Per mantenere la compatibilità con i server che assegnano alle risorse media type non corretti, alcuni User Agent praticano il cosiddetto "content sniffing", trattando i contenuti come se appartenessero ad un diverso media type, rispetto al media type dichiarato dal server. Se eseguito con poca attenzione, il content sniffing può portare alla introduzione di vulnerabilità nella sicurezza, poichè gli User Agent potrebbero assegnare a media type con basso grado di autorità, quali le immagini, i privilegi di media type con elevata autorità, quali i documenti HTML. Molti oggetti ( noti anche come Application Programming Interfaces o API ) usati dagli User Agent sono disponibili solo all'interno della stessa origine. Più precisamente, contenuti prelavati da un indirizzo web ( URI ) possono accedere agli oggetti associati a contenuti prelevati da un URI differente, solo se i due URI appartengono alla stessa origine, cioè se hanno gli stessi schema, host e porta. Esistono alcune eccezioni a questa regola generale. Per esempio, parti dell'interfaccia HTML Location: document.location [ = value ] sono disponibili attraverso diverse origini, per permettere di navigare in differenti contesti di navigazione ( browsing context ). Un altro esempio è l'interfaccia HTML postMessage, visibile attraverso differenti origini, proprio per facilitare le comunicazioni tra origini differenti. Rendere disponibili degli oggetti ad origini differenti è pericioloso e dovrebbe essere fatto con estrema cautela, per evitare di esporli all'azione di potenziali attacker.
|
|||||||||
The Web Origin Concept | Disclaimer: questo è un link a contenuti ospitati su server esterni. |