MIT-Kurs "Computer Systems Security". Vorlesung 8: Netzwerksicherheitsmodell, Teil 1

Massachusetts Institute of Technology. Vorlesung # 6.858. "Sicherheit von Computersystemen." Nikolai Zeldovich, James Mickens. 2014 Jahr

Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitstechniken, die auf jüngsten wissenschaftlichen Arbeiten basieren. Zu den Themen gehören Betriebssystemsicherheit, Funktionen, Informationsflussmanagement, Sprachsicherheit, Netzwerkprotokolle, Hardwaresicherheit und Sicherheit von Webanwendungen.

Vorlesung 1: „Einführung: Bedrohungsmodelle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 2: „Kontrolle von Hackerangriffen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 3: „Pufferüberläufe: Exploits und Schutz“ Teil 1 / Teil 2 / Teil 3
Vorlesung 4: „Trennung von Privilegien“ Teil 1 / Teil 2 / Teil 3
Vorlesung 5: „Woher kommen Sicherheitssysteme?“ Teil 1 / Teil 2
Vorlesung 6: „Chancen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 7: „Native Client Sandbox“ Teil 1 / Teil 2 / Teil 3
Vorlesung 8: „Netzwerksicherheitsmodell“ Teil 1 / Teil 2 / Teil 3

Beginnen wir den nächsten Teil unserer faszinierenden Reise in die Welt der Computersicherheit. Heute werden wir über Web-Sicherheit sprechen. Tatsächlich ist Internetsicherheit eines meiner Lieblingsthemen, weil es Sie in die wahren Schrecken dieser Welt einführt.

Natürlich ist es einfach, Student zu sein und zu denken, dass alles großartig wird. Man muss nur seinen Abschluss machen. Der heutige und der nächste Vortrag werden Ihnen jedoch sagen, dass dies in Wirklichkeit nicht der Fall ist und Sie auf anhaltende Schrecken warten.



Was ist das Internet? Früher war das Netzwerk viel einfacher als heute. Clients, d. H. Browser, konnten mit der Anzeige fester oder aktiver Inhalte nichts anfangen. Im Wesentlichen konnten sie nur statische Bilder und statische Texte empfangen.

Die Serverseite war jedoch etwas interessanter, auch wenn die Clientseite statischen Inhalt hatte. Der Server könnte mit Datenbanken kommunizieren und mit anderen Computern auf der Serverseite "kommunizieren". Daher ist das Konzept der Websicherheit seit sehr langer Zeit im Prinzip mit dem verbunden, was der Server tut. In unseren Vorlesungen werden wir tatsächlich den gleichen Ansatz verfolgen.

Wir haben so etwas wie einen Pufferüberlaufangriff betrachtet. Da Clients den Server dazu verleiten können, ihn zu zwingen, das zu tun, was er nicht tun möchte. Sie haben sich auch den OKWS-Server angesehen und erklärt, wie die Berechtigungsisolierung dort durchgeführt werden kann.

Bisher haben wir die Sicherheit anhand der Erfahrungen untersucht, die durch die Verwendung der Sicherheitsressourcen selbst erzielt wurden. Aber jetzt sind Browser aus Sicherheitsgründen sehr interessante Objekte, bei denen alles sehr kompliziert ist.

Betrachten Sie alle Arten von verrückten, dynamischen Dingen, die ein Browser tun kann. Zum Beispiel haben Sie wahrscheinlich von JavaScript gehört. Mit JavaScript können Seiten jetzt clientseitigen Code ausführen. Es gibt ein DOM-Modell, über das wir heute ausführlicher sprechen werden. Das DOM-Modell ermöglicht es dem JavaScript-Code im Wesentlichen, das Erscheinungsbild der Seite dynamisch zu ändern, z. B. um Schriftarten und dergleichen zu formatieren.

Wir haben HTTP-XML-Anfragen. Dies ist im Grunde eine Möglichkeit für JavaScript, Inhalte asynchron von Servern abzurufen. Sie können auch über HTTP-XML-Anforderungen namens AJAX - asynchrones JavaScript-Abrufen hören.

Es gibt Dinge wie Web-Sockets. Dies ist eine neu eingeführte API, eine Programmierschnittstelle. Web-Sockets ermöglichen die Vollduplex-Kommunikation zwischen Clients und Servern, dh die Kommunikation in beide Richtungen.

Wir haben auch alle Arten von Multimedia-Unterstützung, zum Beispiel ein Tag:

<video> 

Ermöglicht einer Webseite das Abspielen von Videos ohne Verwendung einer Flash-Anwendung. Es kann dieses Video einfach nativ abspielen.



Wir haben auch Geolocation. Jetzt kann die Webseite physisch bestimmen, wo Sie sich befinden. Wenn Sie beispielsweise eine Webseite auf einem Smartphone verwenden, kann der Browser tatsächlich auf das GPS-Modul Ihres Geräts zugreifen. Wenn Sie über einen Browser auf Ihrem Desktop auf eine Webseite zugreifen, kann diese Ihre Wi-Fi-Verbindung anzeigen und eine Verbindung zum Wi-Fi-Geolokalisierungsdienst von Google herstellen, um genau herauszufinden, wo Sie sich befinden. Klingt verrückt, nicht wahr? Aber jetzt können Webseiten solche Dinge tun. Wir haben auch eine Sache wie den Native Client erwähnt, mit der Browser nativen Code ausführen können.
Es gibt viele andere Funktionen im Browser, die ich hier nicht erwähnt habe. Es genügt jedoch zu sagen, dass ein moderner Browser eine unglaublich komplexe Sache ist.

Was bedeutet das für die Sicherheit? Im Allgemeinen bedeutet dies, dass wir uns in großen Schwierigkeiten befinden. Weil es wirklich ein riesiges Tätigkeitsfeld für Sicherheitsbedrohungen gibt. Wenn Sie an Sicherheit denken, können Sie sich grob gesagt ein Diagramm vorstellen, das ungefähr so ​​aussieht: Die vertikale Achse ist die Wahrscheinlichkeit für die korrekte Ausführung von Funktionen, und die horizontale Achse ist die Anzahl der verfügbaren Funktionen. Die vertikale Achse ist auf 100 begrenzt, was wir selbst mit dem einfachsten Code nicht erreichen können.



Tatsächlich sieht diese Kurve ungefähr so ​​aus, und Webbrowser befinden sich hier am Ende des Diagramms unter dem Pfeil. Die Abhängigkeit ist einfach: Je mehr Prozesse im System vorhanden sind, desto unwahrscheinlicher ist es, dass sie korrekt ausgeführt werden. Deshalb werden wir heute alle Arten von dummen Sicherheitsfehlern diskutieren, die ständig auftreten. Und sobald die alten behoben sind, treten sofort neue Fehler auf, da die Benutzer dem Browser weiterhin neue Funktionen hinzufügen, oft ohne darüber nachzudenken, welche Sicherheitsfolgen sie verursachen können.

Wenn Sie also darüber nachdenken, was eine Webanwendung heute ist, können Sie sagen, dass es sich sowohl um eine Client- als auch um eine Serversache handelt. Eine moderne Webanwendung umfasst mehrere Programmiersprachen, mehrere Computer und viele Hardwareprogramme.
Sie können Firefox beispielsweise auf einem Windows-Computer verwenden. Dieser Browser kommuniziert dann mit dem Computer in der Cloud, auf dem Linux ausgeführt wird, und "läuft" mit dem Apache-Server. Möglicherweise läuft es auf einem ARM-Chip, der nicht mit der x86-Plattform kompatibel ist, oder umgekehrt. Kurz gesagt, es gibt Probleme mit der Zusammensetzung verschiedener Komponenten. Alle diese Software- und Hardwareebenen können die Sicherheit beeinträchtigen.

Daher ist dies alles schwierig, da wir keine Ahnung haben, wie wir diese gesamte Zusammensetzung von „Software“ und „Hardware“ als Ganzes abdecken sollen. Eines der häufigsten Probleme mit dem Internet ist beispielsweise die Kontextanalyse.

Angenommen, die Seite hat ungefähr Folgendes:

 <script> var x = 'UNTRUSTED'; </script> 

Sie deklarieren ein Skript-Tag. Darin befindet sich eine Variable, die den Wert von der unzuverlässigen Seite empfängt - dem Benutzer oder einem anderen Computer. Dann schließen wir das Skript-Tag und diesem Teil kann vertraut werden. Das heißt, wir haben eine Linie, an deren Rändern sich vertrauenswürdige Dinge befinden, und in der Mitte nicht vertrauenswürdiger, nicht vertrauenswürdiger Code. Warum können wir Probleme haben, wenn wir etwas von einer nicht verifizierten Partei in die Mitte des Skripts setzen?

Zielgruppe: Möglicherweise haben Sie irgendwo in diesem Code ein falsches Anführungszeichen, das die Skriptzeile unterbricht.

Professor: absolut richtig! Das Problem ist der unterschiedliche Kontext, der diesen unzuverlässigen Code in Teile zerlegen kann. Befindet sich das schließende Anführungszeichen beispielsweise in der Mitte von nicht vertrauenswürdigem Code, schließen wir die Definition dieser JavaScript-Zeile.



Nachdem wir den JavaScript-Zeichenfolgenkontext hinzugefügt haben, starten wir die Ausführung dieses Kontexts. In diesem Fall kann der Angreifer hier einfach das schließende Tag des Skripts einfügen, den JavaScript-Kontext verlassen und den HTML-Kontext eingeben, um beispielsweise neue HTML-Knoten oder ähnliches zu finden.



Daher sollten Sie solche Kompositionsprobleme im gesamten Internet berücksichtigen, da es viele verschiedene Sprachen verwendet: HTML, CSS, JavaScript, möglicherweise MySQL auf der Serverseite usw. Deshalb habe ich ein klassisches Beispiel gegeben, warum Sie eine sogenannte „Inhaltsstandardisierung“ durchführen sollten. Wenn Sie unzuverlässige Eingaben von jemandem erhalten, müssen Sie diese sehr sorgfältig analysieren, um sicherzustellen, dass sie nicht als Angriffsvektor verwendet werden können.

Ein weiterer Grund, warum die Internetsicherheit schwierig ist, besteht darin, dass Webspezifikationen unglaublich lang, langwierig, langweilig und oft inkonsistent sind. Wenn ich Webspezifikationen meine, meine ich Dinge wie JPEG-Definition, CSS-Definition, HTML-Definition. Diese Dokumente haben die gleiche Größe wie die EU-Verfassung und sind ebenso schwer zu verstehen. Wenn Browser-Anbieter all diese Spezifikationen sehen, müssen sie den Entwicklern einfach sagen: „Okay, und danke dafür“, sie dann lesen und mit ihren Freunden darüber lachen.

Daher sind diese Spezifikationen eher vage und spiegeln nicht immer genau wider, was echte Browser tun. Wenn Sie diesen Horror verstehen wollen, können Sie die Website https://www.quirksmode.org/ besuchen, aber wenn Sie glücklich sein wollen, gehen Sie besser nicht dorthin. Dort werden all diese schrecklichen Inkonsistenzen dokumentiert, die Browser beim Drücken einer Taste verursachen. Auf dieser Seite können Sie überprüfen, was passiert.

In dieser Vorlesung konzentrieren wir uns auf jeden Fall auf die Client-Seite der Webanwendung. Insbesondere werden wir untersuchen, wie es möglich ist, Inhalte von verschiedenen Webanbietern zu isolieren, die irgendwie auf demselben Computer und in demselben Browser koexistieren müssen. Es gibt einen grundlegenden Unterschied zwischen dem, was Sie normalerweise von der Desktop-Anwendung halten, und dem, was Sie von der Webanwendung halten.

Abstrakt gesehen können die meisten von Ihnen verwendeten Desktop-Anwendungen als Produkt eines Entwicklers angesehen werden, z. B. Microsoft. Oder vielleicht verwenden Sie die TurboTax-Software von Mr. und Mrs. TurboTax und so weiter und so fort. Wenn Sie sich jedoch Webanwendungen ansehen, besteht das, was für Sie als Ganzes visuell aussieht, tatsächlich aus einer Reihe von Anwendungen mit unterschiedlichen Inhalten von einer Reihe verschiedener Entwickler.



Wenn Sie beispielsweise zur CNN-Seite gehen, scheint es Ihnen, dass sich hier alles auf einer Registerkarte befindet. Aber jedes dieser visuellen Dinge, die Sie sehen, kann tatsächlich von jemand anderem stammen. Schauen wir uns ein sehr einfaches Beispiel an.

Angenommen, wir sind online unter http://foo.com/index.html gegangen. Woraus besteht die betrachtete Seite?



Oben befinden sich möglicherweise Anzeigen, die möglicherweise von ads.com heruntergeladen wurden. Links befindet sich beispielsweise ein Analyseblock von google.com. Diese Bibliotheken sind sehr beliebt, um die Anzahl der Personen zu verfolgen, die diese Seite heruntergeladen haben, um zu überwachen, auf welche Links Personen klicken, mit welchen Teilen der Seite sie interagieren möchten usw.

Auf der rechten Seite befindet sich möglicherweise eine andere JavaScript-Bibliothek, z. B. jQuery, die von cdn.foo.com stammt. Dies sind einige Inhalte, die für den Betrieb von foo.com bereitgestellt werden.

jQuery ist eine sehr beliebte Bibliothek zum Bearbeiten der GUI, daher ist jQuery auf vielen Websites verfügbar, obwohl sie von verschiedenen Stellen abgerufen werden. Weiter auf dieser Seite sehen Sie einige HTML-Textdaten, Schaltflächen für den Benutzer, Texteingabefelder usw. Das ist also einfach nur HTML auf der Seite.

Sie können dann sehen, wie sie den integrierten JavaScript-Code von foo.com nennen. Zum Beispiel haben wir oben ein Eröffnungs-Tag, und JavaScript-Code ist direkt in der Mitte zwischen ihnen eingebettet. In unserem Fall gibt es so genanntes eingebettetes JavaScript - dies ist der obere Rand des Bildes.

Unten in der Zeile werde ich ein sogenanntes JavaScript-Skript zeichnen, da dort der Inhalt etwas entspricht, das sich auf dem Remote-Server befindet. Dies wird als externe JavaScript-Inhaltsdefinition bezeichnet. Das Skript und der eingebettete Code unterscheiden sich voneinander. Auf unserer Seite ist JavaScript von foo.com integriert.



Und eine weitere Sache, die hier sein kann, ist der Rahmen. Ein Frame kann als separates JavaScript-Universum betrachtet werden. Dies entspricht in etwa einem UNIX-Prozess. Vielleicht stammt dieser Frame von facebook.com/likethis.html und darin ist JavaScript von Facebook integriert.

Außerdem haben wir möglicherweise einige f.jpeg-Bilder, die auch von facebook.com stammen . All dies sieht also wie eine einzige Registerkarte aus, obwohl es aus verschiedenen Inhalten besteht, die möglicherweise auf völlig unterschiedlichen Prinzipien basieren können. Daher können Sie eine ganze Reihe interessanter Fragen zu einer Anwendung stellen, die so aussieht.



Kann dieser Google.com-Analysecode beispielsweise Zugriff auf JavaScript-Inhalte haben, die sich im jQuery-Code befinden? In erster Näherung scheint dies vielleicht eine schlechte Idee zu sein, da die beiden Teile des Codes von verschiedenen Stellen stammen. Andererseits kann es sein, dass dies tatsächlich gut ist, da foo.com anscheinend beide Bibliotheken hier abgelegt hat, damit sie miteinander arbeiten können. Also wer weiß?

Eine andere Frage, die Sie möglicherweise haben, ist, ob Analytics-Code tatsächlich mit Text interagieren kann, der im unteren HTML-Block platziert ist. Kann sich Analytics-Code beispielsweise auf Ereignishandler auswirken?

JavaScript ist ein verwaltetes Single-Threaded-Modell, daher verfügt jeder Frame über eine Ereignisschleife, die ständig verarbeitet wird. Hier finden wichtige Prozesse statt, Netzwerkereignis-Timer funktionieren und dergleichen. Und wenn dieser JavaScript-Code feststellt, dass es einige andere Handler gibt, die versuchen, dieselben Ereignisse zu verwalten, werden sie entfernt.

Wer sollte also in der Lage sein, Ereignishandler für diesen HTML-Code zu definieren? Erstens sollte google.com dazu in der Lage sein. Es kann auch foo.com sein oder nicht.
Eine andere Frage: Was verbindet diesen Facebook-Frame mit dem gemeinsamen großen foo.com-Frame? Der Facebook-Frame ist HTTPS, dh sicher, foo.com ist HTTP, dh eine unsichere Verbindung. Wie können diese beiden Dinge interagieren?

Um diese Fragen zu beantworten, verwenden Browser ein Sicherheitsmodell, das als Richtlinie desselben Ursprungs oder als Richtlinie desselben Ursprungs bezeichnet wird. Dies ist eine Art vages Ziel, da viele Dinge, die sich auf die Websicherheit beziehen, ziemlich vage sind, da niemand genau weiß, was sie tun. Die Grundidee ist jedoch, dass zwei Websites nicht in der Lage sein sollten, sich gegenseitig in die Arbeit einzumischen, wenn sie dies nicht möchten. Somit war es einfacher festzustellen, was solche Störungen bedeuteten, wenn das Internet selbst einfacher war. Da wir jedoch weiterhin neue APIs hinzufügen, wird es für uns immer schwieriger zu verstehen, was der Zweck der Richtlinie zur Nichteinmischung ist. Zum Beispiel ist es offensichtlich schlecht, wenn zwei Websites, die sich nicht vertrauen, ihre Daten auf einer gemeinsamen Anzeige anzeigen können. Dies scheint eine eindeutig schlechte Sache zu sein, und offensichtlich ist es eine gute Sache, wenn zwei Websites, die zusammenarbeiten möchten, Daten auf sichere Weise austauschen können.

Sie haben vielleicht von gemischten Seiten gehört, genau das habe ich gesagt. Daher werden Sie im Internet auf ähnliche Dinge stoßen, wenn jemand Daten von einer Google-Karte nimmt und den Standort von Food Trucks darauf platziert. So haben Sie diese erstaunliche „Kartoffelpüree“, mit der Sie günstig essen und gleichzeitig Salmonellen vermeiden können. Aber wie genau entstehen Kompositionen dieser Art?

Es gibt andere komplizierte Dinge. Wenn der JavaScript-Code beispielsweise von Ursprung X innerhalb der Ursprungs-Y-Seite stammt, wie sollte dann der Inhalt dieses Codes sein? Somit kann die Strategie, die von einer Politik desselben Ursprungs verwendet wird, ungefähr wie folgt beschrieben werden.

Jeder Ressource wird eine eigene Ursprungsquelle zugewiesen, und JavaScript-Code kann nur auf Ressourcen zugreifen, die über eine solche Quelle verfügen. Dies ist eine Strategie auf höchster Ebene, die von Politikern derselben Herkunft angewendet wird.

Aber der Teufel steckt im Detail, daher gibt es viele Ausnahmen, die wir uns gleich ansehen werden. Bevor wir fortfahren, definieren wir den Ursprung.
Grundsätzlich ist origin ein Netzwerkprotokolldiagramm plus ein Hostname plus ein Port. Zum Beispiel könnten wir so etwas wie http: // foo.com/index.html haben.



Das Schema unseres Netzwerkprotokolls lautet also HTTP, der Hostname lautet foo.com und der Port ist 80. In diesem Fall ist der Port implizit. Ein Port ist ein serverseitiger Port, über den der Benutzer eine Verbindung zum Server herstellt. Wenn Sie also eine URL mit einem HTTP-Schema sehen, für das kein explizit angegebener Port vorhanden ist, wird hier Port 80 verwendet.

Wenn Sie sich so etwas wie https: // foo.com/index.html ansehen, haben diese beiden Adressen denselben Hostnamen, aber tatsächlich unterschiedliche Schemata - das Protokoll https vs. http. Außerdem ist hier implizit Port 443 vorhanden, der der Standardport für das sichere HTTPS-Protokoll ist. Diese beiden URLs sind also unterschiedlichen Ursprungs.

Betrachten Sie als letztes Beispiel die Website http: // bar.com:8181 / ...

Die Ellipse nach dem Schrägstrich zeigt an, dass diese Dinge in Bezug auf Politik gleichen Ursprungs keine Rolle spielen, zumindest in Bezug auf dieses sehr einfache Beispiel.
Wir sehen, dass wir ein HTTP-Schema haben, der Hostname ist bar.com und hier haben wir einen explizit angegebenen Port. In diesem Fall handelt es sich um einen nicht standardmäßigen Port 8181. Tatsächlich ist dies die Ursprungsquelle. Grob gesagt kann man sich Origin als eine UID in Unix vorstellen, bei der ein Frame als Prozess betrachtet wird.

Daher gibt es vier Hauptideen, die der Implementierung eines Browsers derselben Ursprungsrichtlinie zugrunde liegen.

Erste Idee: Jede Herkunftsquelle hat einen Client-Teil der Ressource. Diese Client-Seite ist Cookies. Cookies können als sehr einfache Möglichkeit angesehen werden, den Status in einem nicht persistenten Protokoll wie HTTP zu implementieren.

Grundsätzlich ist ein Cookie eine winzige Datei, die jeder Originalquelle zugeordnet ist. Später werden wir ein wenig über diese Besonderheit sprechen.

Die Hauptidee ist jedoch, dass der Browser, wenn er eine Anfrage an eine bestimmte Site sendet, alle Cookies enthält, die der Client für diese Site hat. Und diese Cookies können zum Beispiel zum Speichern eines Passworts verwendet werden.

Wenn Sie beispielsweise eine E-Commerce-Website besuchen, können diese Cookies die Erwähnung von Waren im Warenkorb des Benutzers usw. enthalten.

Cookies sind also eine Sache, mit der jede Herkunftsquelle in Verbindung gebracht werden kann. Darüber hinaus betrachten Sie das Repository von DOM-Dokumentobjektmodellen als eine weitere Quelle dieser Ressourcen. Dies ist eine ziemlich neue Schnittstelle, die jedoch bereits als Schnittstelle für die Strukturierung von HTML- und XML-Dokumenten von entscheidender Bedeutung ist.

So können Sie im DOM-Repository der Quelle mitteilen: „Lassen Sie mich einen bestimmten Schlüssel, der eine Zeichenfolge ist, mit diesem angegebenen Wert verknüpfen, der auch eine Zeichenfolge ist.“

Eine andere Sache, die mit dem Ursprung zusammenhängt, ist der JavaScript-Namespace. Dieser Namespace bestimmt, welche Funktionen und Schnittstellen für die Ursprungsquelle verfügbar sind.

Einige dieser Schnittstellen umfassen beispielsweise String-Prototypen und dergleichen. Dann kann die Anwendung den JavaScript-Namespace tatsächlich mit anderen Inhalten füllen.
Es gibt immer noch so etwas wie den DOM-Baum. Wie Sie wissen, bedeutet DOM "Dokumentobjektmodell". Und der Dom-Baum spiegelt im Wesentlichen den HTML-Code auf der Seite mit JavaScript wider.



Sie können sich also vorstellen, dass sich oben im DOM-Baum ein HTML-Knoten befindet, unten ein Knoten für den Kopf des Kopfnachrichten-Tags und ein Knoten für den Textkörper des Nachrichtennachrichtens usw.



So viele dynamische Webseiten ändern sich dank JavaScript-Code, der auf die Daten dieser Struktur in JavaScript zugreifen kann, die den HTML-Inhalt widerspiegeln.
Sie können sich also vorstellen, dass die Animation auf der Browserseite aufgrund der Änderung einiger Knoten des Baums erfolgt, um verschiedene Organisationen mit unterschiedlichen Registerkarten zu implementieren. Dies ist der DOM-Baum. Es gibt auch einen visuellen Anzeigebereich, der, wie wir später sehen werden, sehr seltsam mit derselben Herkunftsquellenrichtlinie interagiert, und so weiter und so fort.

Somit hat jede Quelle auf hoher Ebene Zugriff auf einen bestimmten Satz von Client-Ressourcen der von uns aufgelisteten Typen.

Die zweite Idee ist, dass jeder Frame eine Ursprungsquelle für seine URL erhält. Wie ich bereits erwähnt habe, entspricht der Frame in etwa dem Prozess unter Unix. Es ist eine Art Namespace, der eine Reihe anderer Ressourcen zusammenbringt.

Die dritte Idee ist, dass Skripte oder JavaScript-Code mit Berechtigungen ausgeführt werden, die denen der Quelle des Ursprungs des Frames entsprechen.

Dies bedeutet, dass beim Importieren einer JavaScript-Datei von foo.com aus bar.com die JavaScript-Datei mit den Berechtigungen von foo.com arbeiten kann. Grob gesagt ähnelt dies dem, was in der Unix-Welt passiert, wenn Sie eine Binärdatei ausführen müssen, die zum Home-Verzeichnis einer anderen Person gehört. Dies sollte gemäß Ihren Berechtigungen durchgeführt werden.

Die vierte Idee ist passiver Inhalt. CSS , , .



, . . , , Google Analytics jQuery foo.com. , cookie, , .

Facebook foo.com, , , . . , . , Post Message. .



Post Message , Facebook , , , foo.com. , foo.com , Facebook , , , .

, JavaScript , Facebook, XML HTTP foo.com, , . - , Facebook.com origin, foo.com, HTML-.

, , , ads.com. , , , . , .

, – , !

Tatsache ist, dass es Sicherheitsbedenken gibt. Dies ist die Subtilität, die in der 4. Idee verborgen ist.

28:00 min

Fortsetzung:

MIT-Kurs "Computer Systems Security". Vorlesung 8: Netzwerksicherheitsmodell, Teil 2


Die Vollversion des Kurses finden Sie hier .

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder sie Ihren Freunden empfehlen. Habr-Benutzer erhalten 30% Rabatt auf ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s $ 20 oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s bis Dezember kostenlos, wenn Sie für einen Zeitraum von sechs Monaten bezahlen, können Sie hier bestellen .

Dell R730xd 2 mal günstiger? Nur wir haben 2 x Intel Dodeca-Core Xeon E5-2650v4 128 GB DDR4 6 x 480 GB SSD 1 Gbit / s 100 TV von 249 US-Dollar in den Niederlanden und den USA! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?