MIT-Kurs "Computer Systems Security". Vorlesung 9: Sicherheit von Webanwendungen, Teil 3

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
Vorlesung 9: „Sicherheit von Webanwendungen“ Teil 1 / Teil 2 / Teil 3

Zielgruppe: Was hindert einen Angreifer daran, einen Schlüssel zu finden? Wo befindet sich dieser geheime Schlüssel?



Professor: Ja, das ist eine gute Frage. In den meisten Fällen ist der Client für AWS kein Browser, sondern einige virtuelle Maschinen, die in der Cloud ausgeführt werden. Sie sehen also nur die Kommunikation zwischen virtuellen Maschinen. Sie können sich auch vorstellen, dass Benutzer diese Links irgendwie herausgeben oder sie irgendwie in HTML einbetten können. Wenn Sie so etwas wie das im HTML- oder JavaScript-Quellcode auf der Tafel gezeigte haben, haben Sie den Code, um eine solche Anfrage zu erstellen. Wenn ich Ihnen eines dieser Dinge zur Verfügung stelle, können Sie daher in meinem Namen eine Anfrage stellen.

Zielgruppe: Ist es möglich, MAC für normale Clients zu verwenden?

Professor: Für normal - meinen Sie Browser?

Zielgruppe: für normale Benutzer.

Professor: Tatsache ist, dass die Frage, wo der Schlüssel tatsächlich lebt, von entscheidender Bedeutung ist. Denn wenn der Schlüssel so einfach gestohlen werden kann wie Cookies, haben wir nichts gewonnen. Daher werden all diese Dinge in vielen Fällen irgendwo in der Cloud gespeichert und dienen zum Datenaustausch zwischen virtuellen Maschinen und werden auch in der Cloud von Server zu Server übertragen. Daher startet der Anwendungsentwickler die VM, bei der eine Reihe von in AWS gespeicherten Dingen ausgelagert werden.

Zielgruppe: Gibt es hier ein Problem mit der Netzwerkverzögerung, sodass der Angreifer dieselbe Anforderung unmittelbar nach dem Benutzer senden und auch Zugriff erhalten kann?

Professor: Ja, es genügt zu sagen, dass mehrere Personen Dissertationen zum Thema Sicherheit von Zeitstempeln verteidigten. Aber Sie haben absolut Recht, denn wir haben ein ziemlich grobes Beispiel betrachtet.



Stellen Sie sich vor, dass wir in diesem String To Sign-Beispiel in der DATE-Zeile den Wert "Montag, 4. Juni" haben. Wenn der Angreifer dann irgendwie Zugriff auf all dies erhält, kann er die Anfrage des Benutzers wiederholen. Tatsache ist, dass Sie mit AWS das Ablaufdatum dieser Dinge verwenden können. Sie können also hier das Feld Expires hinzufügen, und wir gehen davon aus, dass ein Ablaufdatum festgelegt wurde.



Dann kann ich diesen Link einer Reihe verschiedener Personen geben, und der Server prüft, ob ihre Anforderungen abgelaufen sind.

Zielgruppe: Selbst wenn das Ablaufdatum nur 200 Millisekunden beträgt, der Angreifer jedoch das Netzwerk überwacht, kann er nur für den Fall senden, dass mehrere Kopien der Anforderung anstelle einer Kopie vorhanden sind.

Professor: Es ist absolut richtig, dass der Angreifer diesen Angriff definitiv ausführen kann, wenn er das Netzwerk angreift und sieht, wie diese Dinge per Kabel übertragen werden und das Ablaufdatum genügend Spielraum bietet.

Dies war also ein Überblick über die Funktionsweise zustandsloser Cookies. Dies wirft eine interessante Frage auf: Was bedeutet es, sich mit Cookies dieses Typs abzumelden? Die Antwort ist, dass Sie nicht wirklich ausgehen. Ich meine, Sie haben diesen Schlüssel und wann immer Sie eine Anfrage senden möchten, senden Sie sie einfach. Der Server kann Ihren Schlüssel jedoch widerrufen.

Angenommen, der Server hat den Schlüssel widerrufen. Sie können jedoch eines dieser GET-Elemente erstellen. Wenn Sie eine Nachricht an den Server senden, wird Folgendes angezeigt: "Ja, ich kenne Ihre Benutzer-ID bereits. Der Schlüssel wurde widerrufen, sodass ich Ihre Anfrage nicht erfüllen kann." Es gibt jedoch Nuancen, und wenn wir über Dinge wie SSL sprechen, ist es viel einfacher, eine Person zu befähigen, als sie abzurufen.

Daher können Sie verschiedene andere Dinge verwenden, wenn Sie herkömmliche Cookies zur Implementierung der Authentifizierung vermeiden möchten. Eine davon ist die Verwendung von DOM - Speicher, der Informationen zur Authentifizierung der Client-Seite enthält. Sie können das DOM-Repository verwenden, um einige Sitzungsstatus zu speichern, die normalerweise in Cookies platziert werden.



Wenn Sie sich an die letzte Vorlesung erinnern, ist das DOM-Repository eine wichtige Schnittstelle der Werte, die der Browser für jede Quelle bereitstellt, dh der Browser nimmt sie von dort und fügt sie in eine Zeichenfolge ein.

Das Gute ist, dass das DOM keine so dummen Regeln für dieselben Richtlinien desselben Ursprungs hat. Wenn dies also normale Cookies wären, könnten Sie all diese Subdomain-Tricks und dergleichen ausführen. Das DOM-Repository ist streng an eine einzelne Quelle gebunden, sodass Sie keine Subdomain erweitern können. Daher verwenden Frameworks wie Meteor diesen Speicher.

Beachten Sie jedoch, dass Sie, wenn Sie Authentifizierungsinformationen im DOM-Repository speichern möchten, selbst JavaScript-Code schreiben müssen, um diese Informationen auf den Server zu übertragen, zu verschlüsseln usw. In diesem Fall müssen Sie Folgendes tun.
Man könnte clientseitige Zertifikate verwenden, zum Beispiel das x.509-Format, das Informationen über den Eigentümer, einen öffentlichen Schlüssel, Informationen über eine Zertifizierungsstelle und eine elektronische digitale Signatur enthält. Das Gute an diesen Zertifikaten ist, dass JavaScript keine explizite Schnittstelle für den Zugriff auf diese Dinge hat. Im Gegensatz zu Cookies, bei denen es immer zu einem „Wettrüsten“ kommt, um Richtlinienfehler desselben Ursprungs zu finden, verfügen die Zertifikate hierfür nicht über eine explizite JavaScript-Schnittstelle. Das ist also aus Sicherheitsgründen sehr gut.

Eines der Probleme, die ich kurz erwähnt habe und auf die wir in den folgenden Vorlesungen ausführlich eingehen werden, ist der Widerruf von Zertifikaten. Wenn ein Benutzer Ihre Organisation verlässt, wie können Sie ihm ein Zertifikat abnehmen? Das ist ziemlich kompliziert.



Darüber hinaus sind diese Dinge nicht sehr bequem zu verwenden, da niemand eine Reihe von Zertifikaten für jede Site installieren möchte, die Sie besuchen. Daher sind Authentifizierungszertifikate nicht sehr beliebt, mit Ausnahme von Unternehmen oder Organisationen, die mit großer Verantwortung für die Sicherheit verantwortlich sind. Damit ist unsere Diskussion über Cookies abgeschlossen.

Lassen Sie uns nun über Protokollschwachstellen im Webstack sprechen. Eine der interessanten Arten von Angriffen besteht darin, Fehler in Browserkomponenten zu verwenden, beispielsweise beim Parsen von URLs. Wie kann das Parsen von URLs Probleme für uns verursachen?

Angenommen, wir haben eine URL, in die am Ende aus irgendeinem Grund seltsame Zeichen eingebettet sind:

example.com : 80 @ foo.com.

Die Frage ist, woher diese bestimmte URL stammt. Flash hätte gedacht, der Hostname ist example.com. Wenn der Browser die Adresse analysiert, wird er denken, dass der Ursprung des Hosts in diesem Fall foo.com ist.



Das ist sehr schlecht, denn wenn wir zwei verschiedene Entitäten haben, die über den Ursprung des Ursprungs derselben Ressource verwirrt sind, ist dies mit unangenehmen Problemen behaftet.
Beispielsweise kann ein Flash-Code bösartig sein und Material von example.com herunterladen. Wenn der Exploit in die Seite mit foo.com integriert wurde, könnte er dort auch einige böse Dinge tun. Und dann nimmt er einen Code von example.com und führt ihn mit den Fähigkeiten von foo.com aus. Viele komplexe Parsing-Regeln wie diese machen das Leben sehr schwierig. Es passiert die ganze Zeit.

Wir haben gerade die Desinfektion von Inhalten untersucht, deren Hauptidee darin besteht, dass es oft viel besser ist, wenn es einfachere Parsing-Regeln für diese Art von Dingen gibt. Rückblickend ist dies jedoch schwierig, da HTML bereits vorhanden ist.
Lassen Sie uns nun über meine bevorzugte Sicherheitslücke sprechen - Dateien mit der Erweiterung .jar, die ein ZIP-Archiv mit einem Teil eines Java-Programms sind. Browser-JAR-Dateien werden zum Ziel des Angriffs, hauptsächlich Java-Applets. Um 2007 erklärte eine ausgezeichnete Website namens lifehacker.com, wie man Zip-Dateien in Bilder einbettet. Es ist nicht klar, vor wem Sie sich auf diese Weise verstecken möchten, aber lifehacker.com stellt sicher, dass Sie dies tun können.

Sie verwenden hauptsächlich die Tatsache, dass der Parser in der Regel von oben nach unten funktioniert, wenn Sie Bildformate wie GIFs betrachten. Zuerst findet er die Informationen in der Kopfzeile und betrachtet dann die verbleibenden Bits unten.



Wie sich herausstellte, arbeiten Programme, die normalerweise ZIP-Dateien bearbeiten, von unten nach oben, dh entgegen der Richtung der Bildanalyse. Zuerst finden sie die Informationen in der Fußzeile der Datei und entpacken, was sich im Archiv befindet. Wenn Sie also eine Bilddatei platzieren, die ein ZIP-Archiv enthält, besteht sie wie jedes andere Bild alle Prüfungen, auch die Flickr-Prüfung, und wird sogar als Bild in Ihrem Browser angezeigt.

Aber nur du wirst die verborgene Wahrheit kennen. Nur Sie werden wissen, dass Sie diese Datei entpacken und die dort enthaltenen Informationen verwenden können, wenn Sie sie nehmen. Es scheint ein billiger Trick zu sein, aber Hacker schlafen nie, sie wollen ständig unser Leben ruinieren. Wie setzen sie diese Idee um?

Sie verstehen, dass JAR-Dateien vom ZIP-Format abgeleitet sind. Dies bedeutet, dass Sie ganz unten eine GIF-Animation oder ein statisches Bild erstellen können, das eine JAR-Datei enthält, dh ausführbaren JavaScript-Code.

Später nannten die Leute diese Angriffsmethode GIFAR, halb GIF, halb JAR, und beide Hälften sind böse. Es war großartig. Als die Leute eine solche Gelegenheit zum ersten Mal entdeckten, fanden sie sie erstaunlich, verstanden aber überhaupt nicht, wie man sie nutzt. Aber wie sich herausstellte, können auf seiner Grundlage die folgenden Dinge getan werden.



Wie können Sie das tun? Sie verwenden nur CAD. Nehmen Sie .gif, nehmen Sie .jar, verwenden Sie das selbstextrahierende Archiv - boom, und GIFAR hat Sie angegriffen!

Was können Sie tun, wenn Sie dies haben? Es gibt einige vertrauliche Websites, auf denen Benutzer Daten bereitstellen können, jedoch keine beliebigen Datentypen. Flickr oder ähnliches erlaubt Ihnen möglicherweise nicht, beliebiges ActiveX oder anderes beliebiges HTML zu senden. Sie dürfen jedoch Bilder senden. Sie können also eines dieser Dinge erstellen und an eine dieser vertraulichen Sites senden, auf denen Sie Bilder senden können. Was müssen Sie tun, um in diesem Fall einen erfolgreichen Angriff durchzuführen?



Senden Sie dieses „ausgestopfte“ Bild zunächst an eine dieser Websites. Verwenden Sie zweitens die Cross-Site-Scripting-Angriffsmethode XSS unter Verwendung der vorhandenen Sicherheitsanfälligkeiten. Dazu müssen Sie das Applet einfügen und in JavaScript einen solchen Ausdruck schreiben:

Dieser Code nutzt die Sicherheitsanfälligkeit bezüglich Cross-Site-Scripting aus und wird daher im Site-Inhalt gestartet. GIFAR besteht die Ursprungsprüfung, da es von einer Site mit einer gemeinsamen Ursprungsquelle stammt, obwohl dieser Code von einem Angreifer eingefügt wurde.

Jetzt hat der Angreifer die Möglichkeit, dieses Java-Applet im Kontext der Site des Opfers mit allen Ursprungsberechtigungen auszuführen. Und eines dieser Dinge wird tatsächlich korrekt als GIF-Bild identifiziert. Aber hier gibt es versteckten Code. Ich möchte Sie daran erinnern, dass der Browser zunächst die archivierten Dateien entpackt und daher zunächst den JAR-Teil startet und den oberen Teil des GIF ignoriert. Das ist eigentlich ziemlich erstaunlich.

Es gibt einige ziemlich einfache Möglichkeiten, dies zu beheben. Sie können beispielsweise den Applet-Loader verwenden, der versteht, dass es keinen zufälligen Müll geben sollte. In vielen Fällen werden Metadateninformationen verwendet, die die Länge dieser Ressource anzeigen. In diesem Fall startet der Loader wie erwartet von oben, analysiert seine Länge, stellt sicher, dass das Applet oben endet, und stoppt. Er kümmert sich nicht um den unteren Teil, es ist möglich, dass er gerade 0 ist. In unserem Fall hilft ein solcher Lader nicht, da er die Anfrage vom unteren, archivierten Teil verarbeitet und vor dem oberen anhält und sie ignoriert.

Was mir daran gefällt, ist, dass es wirklich zeigt, wie breit der Internet-Software-Stack ist. Wenn Sie nur diese beiden Formate, GIF und JAR, verwenden, können Sie einen wirklich bösen Angriff erstellen.

Sie können dasselbe mit PDF-Dateien tun. Sie können ein PDF anstelle eines GIF einfügen und diesen Angriff als eine der Gefahren von PDFAR bezeichnen. Aber am Ende haben die Leute dieses Problem herausgefunden und Schwachstellen dieser Art sind jetzt beseitigt.

Zielgruppe: Was können Sie mit dieser Art von Angriff tun, was mit einem regulären XSS-Cross-Site-Scripting-Angriff nicht möglich ist?

Professor: Das ist eine gute Frage. Das Gute daran ist, dass Java oft ein leistungsfähigeres Werkzeug als normales JavaScript ist, da es leicht unterschiedliche Regeln, dieselbe Ursprungsrichtlinie und dergleichen verwendet. Sie haben jedoch Recht, dass das Ausführen von JavaScript selbst ziemlich schädlich sein kann, wenn Sie Cross-Site-Scripting ausführen können. Der Hauptvorteil dieser Methode besteht jedoch darin, dass diese Angriffstechnologie innerhalb des Applets funktioniert und das kann, was mit normalem bösartigem Skriptcode nicht möglich ist.

Wie gesagt, dies ist mein Lieblingsangriff aller Zeiten, vor allem, weil seriöse Leute aus dem Bereich Computersicherheit an ein Wort wie GIFAR denken.

Eine weitere interessante Sache ist die Verwendung von zeitbasierten Angriffen. Normalerweise betrachten Menschen Zeit nicht als Ressource, die ein Vektor für Angriffe sein kann. Aber wie ich vor ein paar Minuten bemerkt habe, kann diese Zeit tatsächlich ein Mittel sein, um einen Exploit in das System einzuführen.

Der spezifische Angriff, über den ich mit Ihnen sprechen werde, ist der verdeckte Kanalangriff. Die Idee dieses Angriffs ist, dass ein Angreifer einen Weg findet, Informationen zwischen zwei Anwendungen auszutauschen, und dieser Austauschvorgang nicht autorisiert ist. Ein Angreifer verwendet irgendwie einen Teil des Systems, um Informationsbits zwischen zwei verschiedenen Ressourcen zu übertragen.

Ein gutes Beispiel dafür ist ein schnüffelnder CSS-Angriff. Was ist so ein Angriff?

Angenommen, ein Angreifer hat eine Website, die ein Benutzer besuchen kann. Es ist eigentlich ganz einfach, einen Benutzer dazu zu bringen, eine Website zu besuchen. Sie erstellen eine Anzeige oder senden eine Phishing-E-Mail.

Somit hat der Angreifer eine Website, die der Benutzer besucht. Das Ziel des Angreifers ist es herauszufinden, welche anderen Websites der Benutzer besucht hat. Ein Angreifer möchte dies möglicherweise aus mehreren Gründen wissen. Vielleicht interessiert er sich für die Suchanfragen des Benutzers, oder er versucht herauszufinden, wo diese Person arbeitet, oder er möchte wissen, ob diese Person einige „beschämende“ Websites besucht und so weiter.



Wie wird ein Angreifer dies tun, wenn das einzige, was er kontrolliert, eine Website ist, die er einen Benutzer zum Besuch überreden möchte? Eine Möglichkeit besteht darin, Linkfarben zu verwenden. Wie Sie wissen, wird ein Link, wenn Sie ihm einmal gefolgt sind, beim nächsten Mal in einer anderen Farbe in Ihrem Browser angezeigt, um anzuzeigen, dass Sie bereits zu diesem Link übergegangen sind. Dies ist tatsächlich eine Sicherheitslücke.

Da dies bedeutet, dass ein Angreifer auf Ihrer Website eine große Liste möglicher URLs erstellen kann, die Sie besuchen können, und dann mithilfe von JavaScript feststellen kann, welche Farbe diese URLs erhalten haben. Und wenn die Farbe des URL-Links lila ist, bedeutet dies, dass Sie diese Site besucht haben. Das ist also ein ziemlich subtiler Trick.

Das Interessante ist, dass Sie in vielen Fällen nicht einmal URLs anzeigen müssen. Sie können die Links in Form von Überschriften auf dem Bildschirm entsprechend dem Domino-Typ anordnen. Diese Überschriften ändern ihre Farbe, wenn der Benutzer diesen Link verwendet. Vielleicht denken Sie, dass es zu mühsam ist, alle diese URLs der vom Benutzer besuchten Websites zu crawlen? Dieser Prozess kann jedoch optimiert werden, indem mehrere gefilterte Passagen durch die Adressliste verwendet werden. Beispielsweise können Sie zuerst feststellen, ob der Benutzer die URL der obersten Ebene besucht hat - cnn.com, Facebook.com usw. Wenn die Antwort Ja lautet, können Sie die am häufigsten besuchten Seiten der obersten Ebene auswählen. Auf diese Weise können Sie Ihre Suche wirklich einschränken.

Die harmlose Funktion, die Browser unterstützen, um dem Benutzer zu helfen und zu sagen: „Hey, Kumpel, hier sind Sie hingegangen!“ Kann von einem Angreifer als kompromittierender Beweis für Sie verwendet werden.



Wie kann ich einen verdeckten Kanalangriff verhindern? In der Praxis geschieht dies so, dass der Browser JavaScript einfach über die korrekte Farbe der Links täuscht. JavaScript , , . , . , , JavaScript , . , , ? , .

, , — . – , .

, , . , , .



, — , , , , , . , , , , . ?

, . . , .

, Google Map Tiles. , «» Google Map, , , , . .

? , . , , , . , .

, , , JavaScript . , , DNS.
: , , DNS , . , , -, , -. , , DNS . , , DNS , .



: JavaScript .

: , !

: , , , , ?

: , . , — - , , , - URL. , API– , .

: - , , ?
: . , API — . , ? , DNS , .

, , IP — ? ! , JavaScript . . , , ! .

Die Hauptidee hier ist, die zuvor besuchte URL schneller zu rendern.

       <iframe>,    , ,   , , , ,    ,        <iframe>.     <iframe> ,   ,   <iframe>      .       ,    origin,        . 

Somit kann der Angreifer nichts mehr berühren und kommt zu dem Schluss, dass er die zuvor besuchte Site ermitteln konnte.

Wir sehen uns bei der nächsten Vorlesung!


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 Ihren Freunden empfehlen, einen Rabatt von 30% für Habr-Benutzer 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 von $ 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?