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

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

Zum Beispiel nimmt Django diese spitzen Klammern, übersetzt sie in HTML-Form und wiederholt den Rest der Zeichen. Das heißt, wenn der benutzerdefinierte Namenswert spitze Klammern, doppelte Anführungszeichen und dergleichen enthält, werden alle diese Zeichen ausgeschlossen. Dadurch wird der Inhalt auf der Client-Browserseite nicht als HTML-Code interpretiert.



Jetzt wissen wir also, dass dies keine sehr zuverlässige Verteidigung gegen einige Cross-Site-Scripting-Angriffe ist. Der Grund, wie wir im Beispiel gezeigt haben, ist, dass diese Grammatiken für HTML, CSS und JavaScript so komplex sind, dass sie den Browser-Parser sehr leicht verwirren können.

Zum Beispiel haben wir eine sehr häufige Sache im Rahmen von Django gemacht. Sie haben also eine div-Funktion, und wir möchten eine dynamische Klasse dafür festlegen. Wir geben der Klasse den Wert var und so weiter und so fort. Die Idee ist, dass Django, wenn er dies verarbeitet, herausfinden muss, was der aktuelle Stil ist, und ihn dann hier einfügen muss.

In diesem Fall kann ein Angreifer eine Zeichenfolge erstellen, die diese Klasse definiert, z. B. "Klasse 1" schreibt. Bis zu diesem Punkt läuft alles gut, da es sich um einen gültigen CSS-Ausdruck handelt.

Aber dann setzt der Angreifer hier den Onclick-Operator, der dem JavaScript-Code entspricht, der den Systemaufruf ausführt.



Da dies falsch ist, sollte der Browser hier einfach anhalten. Das Problem ist jedoch, dass, wenn Sie jemals den HTML-Code einer echten Webseite gesehen haben, alles kaputt und verwirrt ist, selbst bei legitimen, "freundlichen" Websites. Wenn der Browser also vor jedem fehlerhaften HTML-Ausdruck stoppt, funktioniert keine einzelne Site, die Ihnen gefällt, einfach nie. Wenn Sie jemals von der Welt enttäuscht werden möchten und ich Ihnen nicht genug geholfen habe, öffnen Sie einfach die JavaScript-Konsole in Ihrem Browser, wenn Sie die Website anzeigen, um zu sehen, wie viele Fehler Sie erhalten.

Sie können beispielsweise zu CNN gehen und sehen, wie viele Fehler Sie erhalten. Ja, im Grunde funktioniert CNN, aber sehr ungleichmäßig. Um beispielsweise den Acrobat Reader zu öffnen, müssen Sie ständig Nullzeigerausnahmen auslösen, und gleichzeitig fühlen Sie sich vom Leben ein wenig getäuscht. Aber im Internet haben wir gelernt, dies ohne große Empörung zu akzeptieren.
Da Browser gegenüber solchen Dingen sehr tolerant sein sollten, werden sie versuchen, bösartigen Code in etwas zu verwandeln, das ihnen vernünftig erscheint. Und das ist die Sicherheitslücke.

So funktioniert die Desinfektion von Inhalten und sie ist immer noch besser als nichts. Sie kann viele schädliche Dinge fangen, sich aber nicht gegen alles verteidigen.

Es gibt noch etwas zu bedenken - die Verwendung einer weniger ausdrucksstarken Auszeichnungssprache. Mal sehen, was gemeint ist.

Zielgruppe: Was soll ich tun, wenn die Inhaltsbereinigung nicht funktioniert?

Professor: Ja, das ist zum Beispiel möglich. In diesem Fall kann Django statisch nicht feststellen, dass es schlecht ist. Zum Beispiel in diesem speziellen Fall. Aber in dem Fall, wenn ich ein bösartiges Bild-Tag einfüge ...

Teilnehmerin: In diesem speziellen Fall würde ich erwarten, dass die Klassenzuordnung in Anführungszeichen steht und in diesem Fall keine Auswirkungen haben sollte ...

Professor: Nun, Sie sehen, es gibt kleine Tricks. Unter der Annahme, dass die Grammatik von HTML und CSS sorgfältig definiert ist, können Sie sich eine Welt vorstellen, in der ideale Parser diese Probleme irgendwie erfassen oder in normale Dinge umwandeln könnten. Tatsächlich leiden HTML-Grammatik und CSS-Grammatik unter Ungenauigkeiten. Darüber hinaus implementieren Browser keine Spezifikationen. Wenn Sie weniger ausdrucksstarke Grammatik verwenden, ist es für uns daher viel einfacher, den Inhalt zu bereinigen.

Hier wird der Begriff Markdown verwendet - "leicht lesbares Markup" anstelle des Begriffs Markup - gewöhnliches Markup. Die Hauptidee von Markdown ist, dass es als eine Sprache konzipiert ist, die es Benutzern beispielsweise ermöglicht, Kommentare zu veröffentlichen, jedoch nicht die Möglichkeit enthält, ein leeres Tag, Applet-Unterstützung und dergleichen zu verwenden. Daher ist es in Markdown viel einfacher, die Grammatik eindeutig zu identifizieren und dann einfach anzuwenden.



Die Desinfektion ist in einer einfachen Sprache viel einfacher als in HTML, CSS und JavaScript. In gewisser Weise ist dies wie der Unterschied zwischen dem Verständnis von C-Code und Python-Code. Es ist wirklich ein großer Unterschied, eine ausdrucksstärkere Sprache zu verstehen. Durch die Einschränkung der Ausdruckskraft verbessern Sie daher häufig die Sicherheit.

Zum Schutz vor Cross-Site-Scripting-Angriffen wird auch CSP (Content Security Policy) verwendet. Die Idee von CSP ist, dass es dem Webserver erlaubt ...
Teilnehmerin: Ich bin nur neugierig, etwas über diese Markdown-Sprache herauszufinden. Können alle Browser eine Sprachanalyse durchführen?

Professor: nein, nein, nein. Sie können einfach verschiedene Arten von Sprachen in HTML konvertieren, aber Browser verstehen sie nicht in ihrer ursprünglichen Form. Mit anderen Worten, Sie haben ein Kommentarsystem, das Markdown verwendet. Das heißt, die Kommentare werden vor dem Anzeigen auf der Seite an den Markdown-Compiler gesendet, der sie in das HTML-Format übersetzt.

Teilnehmerin: Warum also nicht immer Markdown verwenden?

Professor: Mit Markdown können Sie eingebettetes HTML verwenden. Soweit ich weiß, gibt es eine Möglichkeit, es im Compiler zu deaktivieren. Aber da könnte ich mich irren. Tatsache ist, dass es nicht immer möglich ist, eine begrenzte Sprache zu verwenden, und das will nicht jeder.

Lassen Sie uns also die Diskussion darüber fortsetzen, wie die Sicherheit mithilfe der Inhaltssicherheitsrichtlinie erhöht werden kann. Mit dieser Richtlinie kann der Server dem Webbrowser mitteilen, welche Arten von Inhalten auf die zurückgesendete Seite geladen werden können und woher diese Inhalte stammen sollen.

In der HTTP-Antwort kann der Server beispielsweise Folgendes verwenden: Er enthält den Header "Inhalt - Sicherheit - Richtlinie", die Standardquelle ist "Selbst" und empfängt Daten von * .mydomain.com.



Mit dem Betreiber selbst gibt der Server an, dass der Inhalt dieser Website nur aus der Domain einer bestimmten Seite oder einer Subdomain von mydomain.com stammen soll. Dies bedeutet, dass der Server diese Seite an den Browser zurücksenden würde, wenn wir eine Selbstbindung an foo.com hätten.

Angenommen, ein Cross-Site-Scripting-Angriff versucht, einen Link zu bar.com zu erstellen. In diesem Fall erkennt der Browser, dass bar.com nicht selbst und keine Domain von mydomain.com ist, und überspringt diese Anfrage nicht weiter. Dies ist ein ziemlich leistungsfähiger Mechanismus, mit dem Sie detailliertere Steuerelemente festlegen können. Sie legen Parameter fest, die angeben, dass Ihre Bilder aus einer solchen und einer solchen Quelle stammen sollen, Skripte aus einer solchen und einer solchen Quelle und so weiter. Es ist eigentlich bequem.

Darüber hinaus verhindert diese Richtlinie tatsächlich eingebettetes JavaScript, sodass Sie das Tag nicht öffnen, keine Skripte schreiben und das Tag schließen können, da alles, was zum Browser gelangen kann, nur aus einer bedingten Quelle stammen sollte. CSP verhindert gefährliche Dinge wie die Verwendung des Arguments für die Funktion eval (), mit der eine Webseite dynamisch generierten JavaScript-Code ausführen kann. Wenn also der CSP-Header gesetzt ist, führt der Browser eval () nicht aus.

Teilnehmerin: Ist das alles, vor dem CSP schützt?

Professor: nein. Es gibt eine ganze Liste von Ressourcen, die tatsächlich geschützt werden, und Sie können den Schutz gegen viele unerwünschte Dinge konfigurieren. Geben Sie beispielsweise an, wo ausgehendes CSS und eine Reihe anderer Dinge akzeptiert werden dürfen.

Teilnehmerin: Aber neben eval () gibt es noch andere Dinge, die die Sicherheit bedrohen?

Professor: Ja, sie existieren. Daher stellt sich immer die Frage nach der Vollständigkeit des Schutzes. So kann beispielsweise nicht nur eval dynamisch JavaScript-Code generieren. Es gibt auch einen Konstruktor von Funktionen, es gibt bestimmte Möglichkeiten, ein bestimmtes Zeitlimit aufzurufen, Sie gehen zur Zeile und können den Code auf diese Weise analysieren. CSP kann alle diese gefährlichen Angriffsmethoden deaktivieren. Dies ist jedoch kein Allheilmittel für die vollständige Isolierung böswilliger Exploits.

Zielgruppe: Stimmt es, dass CSP so konfiguriert werden kann, dass nicht alle internen Skripts auf der Seite überprüft werden?

Professor: Ja, es hilft, die Ausführung von dynamisch generiertem Code zu verhindern, während der eingebettete Code ignoriert werden sollte. Der Browser sollte den Code immer aus dem Quellattribut abrufen. Eigentlich weiß ich nicht, ob dies alle Browser tun. Persönliche Erfahrungen zeigen, dass Browser unterschiedliche Verhaltensweisen aufweisen.

Im Allgemeinen ist die Internetsicherheit den Naturwissenschaften ähnlich, daher stellen die Leute nur Theorien darüber auf, wie Browser funktionieren. Und dann sehen Sie, wie das tatsächlich passiert. Und das wirkliche Bild kann enttäuschen, weil uns beigebracht wird, dass es Algorithmen, Beweise und dergleichen gibt. Diese Browser verhalten sich jedoch so schlecht, dass die Ergebnisse ihrer Arbeit nicht vorhersehbar sind.

Browser-Entwickler versuchen, Angreifern einen Schritt voraus zu sein, und weiter unten in der Vorlesung sehen Sie Beispiele dafür. In der Tat ist CSP eine ziemlich coole Sache.

Eine weitere nützliche Sache ist, dass der Server einen HTTP-Header namens X-Content-Type-Options setzen kann, dessen Wert nosniff ist.



Dieser Header verhindert, dass MIME die Antwort vom angekündigten Inhaltstyp verwirft, da der Header den Browser anweist, den Antwortinhaltstyp nicht zu überschreiben. Wenn der Server mit der Option nosniff angibt, dass der Inhalt Text / HTML ist, zeigt der Browser ihn als Text / HTML an.
Einfach ausgedrückt, dieser Header verhindert, dass der Browser die Antwort des deklarierten Inhaltstyps "schnüffelt", sodass die Situation nicht eintritt, wenn der Browser sagt: "Ja, ich habe die Nichtübereinstimmung zwischen der Dateierweiterung und dem tatsächlichen Inhalt festgestellt, sodass ich diesen Inhalt in einen anderen verständlichen Inhalt umwandle." mir eine Sache. " Es stellt sich heraus, dass Sie den Barbaren plötzlich die Schlüssel zum Königreich gegeben haben.

Wenn Sie diesen Header festlegen, weisen Sie den Browser daher an, so etwas nicht zu tun. Dies kann die Auswirkungen bestimmter Arten von Angriffen erheblich abschwächen. Hier finden Sie eine kurze Übersicht über einige Sicherheitslücken bei Cross-Site-Scripting-Angriffen.

Schauen wir uns nun einen anderen beliebten Angriffsvektor an - SQL. Sie haben wahrscheinlich von Angriffen gehört, die als "SQL-Injection" - oder SQL-Injection-Attacke bezeichnet werden. Das Wesentliche dieser Angriffe ist die Verwendung der Website-Datenbank. Um die dem Benutzer angezeigte Seite dynamisch zu erstellen, werden Datenbankabfragen ausgegeben, die an diesen internen Server gesendet werden. Stellen Sie sich vor, Sie müssen alle Werte aus einer bestimmten Tabelle auswählen, wobei das Feld Benutzer-ID dem entspricht, was im Internet aus einer möglicherweise unzuverlässigen Quelle ermittelt wurde.



Wir alle wissen, wie diese Geschichte enden wird - sie wird sehr schlecht enden, es wird keine Überlebenden geben. Denn was aus einer nicht überprüften Quelle stammt, kann viel Ärger verursachen. Alternativ können Sie der Benutzer-ID den folgenden Wert geben: Benutzer-ID = “0; TABELLE LÖSCHEN “.

Was wird hier also passieren? Grundsätzlich sagt die Serverdatenbank: "OK, ich setze die Benutzer-ID auf Null und führe dann den Befehl" Tabelle löschen "aus." Und das war's, du bist fertig!

Sie sagen, dass vor ein paar Jahren ein bestimmtes virales Bild aufgetaucht ist. Einige Leute in Deutschland installierten Nummernschilder an Autos, auf denen 0 stand; TABELLE LÖSCHEN. Die Idee war, dass Straßenkameras OCR verwenden, um Ihre Nummer zu erkennen und diese Nummer dann in die Datenbank aufzunehmen. Im Allgemeinen haben die Leute von Volkswagen beschlossen, diese Sicherheitsanfälligkeit auszunutzen, indem sie bösartigen Code auf ihre Nummern setzen.

Ich weiß nicht, ob das funktioniert hat, weil es lustig klingt. Aber ich würde gerne glauben, dass dies wahr ist. Also wiederhole ich noch einmal - die Idee der Desinfektion besteht darin, die Ausführung von Inhalten aus nicht vertrauenswürdigen Quellen auf Ihrer Website zu verhindern.



Achten Sie daher darauf, dass es einige einfache Dinge gibt, die nicht so funktionieren, wie sie sollten. Sie könnten also denken: "Nun, warum kann ich nicht einfach ein weiteres Zitat am Anfang der Zeile und ein weiteres am Ende einfügen, um die Ausführung von Schadcode des Angreifers auszuschließen, der zwischen dreifachen Anführungszeichen eingeschlossen ist?"

Benutzer-ID = '“+ Benutzer-ID +'“

Dies funktioniert jedoch nicht, da ein Angreifer immer einfach Anführungszeichen in die angreifende Zeichenfolge einfügen kann. In den meisten Fällen bringt Ihnen ein solches "halbes Hacken" nicht so viel Sicherheit, wie Sie erwarten.

Die Lösung hier ist, dass Sie Ihre Daten sorgfältig verschlüsseln müssen. Und ich wiederhole noch einmal: Wenn Sie Informationen von einer unzuverlässigen Quelle erhalten, fügen Sie sie nicht in der Form in das System ein, in der sie vorliegen. Stellen Sie sicher, dass es nicht aus der Sandbox springen kann, wenn Sie es dort ablegen, um einen böswilligen Exploit auszuführen.

Sie möchten beispielsweise eine Escape-Funktion einfügen, um die Verwendung des Rohkommaoperators zu verhindern. Zu diesem Zweck verfügen viele Web-Frameworks, wie z. B. Django, über integrierte Bibliotheken, mit denen Sie SQL-Abfragen vermeiden können, um solche Ereignisse zu verhindern. Diese Frameworks ermutigen Entwickler, niemals direkt mit der Datenbank zu interagieren. Zum Beispiel bietet Django selbst eine übergeordnete Oberfläche, die Sie desinfiziert.

Aber die Leute kümmern sich immer um die Leistung, und manchmal denken die Leute, dass diese Web-Frameworks zu langsam sind. Wie Sie gleich sehen werden, werden die Benutzer immer noch unformatierte SQL-Abfragen durchführen, was zu Problemen führen kann.

Probleme können auftreten, wenn der Webserver Pfadnamen von nicht vertrauenswürdigen Bildern akzeptiert. Stellen Sie sich vor, Sie machen irgendwo auf Ihrem Server etwas Ähnliches: Öffnen Sie mit "www / images /" + Dateiname, wobei Dateiname durch etwas wie ... / ... / ... / ... / dargestellt wird. etc / Passwort.



Das heißt, Sie geben den Befehl, das Bild an dieser Adresse aus einer nicht vertrauenswürdigen Benutzerdatei zu öffnen, was Ihnen in Wirklichkeit ernsthaften Schaden zufügen kann. Wenn Sie also einen Webserver oder ein Webframework verwenden möchten, sollten Sie in der Lage sein, diese gefährlichen Zeichen zu erkennen und zu vermeiden, um die Ausführung dieser nicht behandelten Befehle zu verhindern.

Machen wir eine Pause von der Diskussion über die Desinfektion von Inhalten und sprechen wir ein wenig über Cookies. Cookies sind eine sehr beliebte Methode zum Verwalten von Sitzungen, um einen Benutzer an bestimmte Ressourcen zu binden, die auf der Serverseite vorhanden sind. Viele Frameworks wie Django oder Zoobar, die Sie später kennenlernen werden, fügen tatsächlich eine zufällige Sitzungskennung in Cookies ein. Die Idee ist, dass diese Sitzungs-ID ein Index in einer Art serverseitiger Tabelle ist:

Tabelle [Sitzungs-ID] = Benutzerinformationen.

Das heißt, die Sitzungskennung entspricht einigen Benutzerinformationen. Infolgedessen sind diese Sitzungs-ID und Cookies in ihrer Erweiterung sehr sensible Teile. Viele Angriffe beinhalten den Diebstahl von Cookies, um diese Sitzungs-ID zu erhalten. Wie wir in unserer letzten Vorlesung besprochen haben, kann Ihnen dieselbe Politik derselben Herkunftsquelle in gewissem Maße gegen einige dieser Cookie-Diebstahl-Angriffe helfen. Weil es Regeln gibt, die auf derselben Ursprungsrichtlinie basieren und die willkürliche Änderung von Cookies verhindern.

Die Subtilität besteht darin, dass Sie eine Domain oder Subdomain nicht mit jemandem teilen sollten, dem Sie nicht vertrauen. Denn wie bereits in der letzten Vorlesung erwähnt, gibt es Regeln, nach denen zwei Domänen oder Subdomänen desselben Ursprungs auf die Cookies der anderen zugreifen können. Wenn Sie einer Domain vertrauen, der Sie nicht vertrauen sollten, kann diese möglicherweise direkt die Sitzungskennung in diesen Cookies festlegen, auf die Sie beide Zugriff haben. Auf diese Weise kann der Angreifer den Benutzer zwingen, die Sitzungskennung nach Wahl des Angreifers zu verwenden.



Angenommen, ein Angreifer setzt ein Google Mail-Benutzercookie. Ein Benutzer meldet sich bei Google Mail an und gibt einige Buchstaben ein. Ein Angreifer kann dann dieses Cookie verwenden, insbesondere diese Sitzungskennung verwenden, Google Mail herunterladen und dann auf Google Mail zugreifen, als wäre er ein Opferbenutzer. Daher gibt es viele Feinheiten, die Sie mit diesen Cookies tun können, um Ihre Sitzungen zu verwalten. Wir werden einige von ihnen heute und in nachfolgenden Vorträgen diskutieren.

Vielleicht denkst du, du kannst Cookies einfach loswerden? Schließlich bringen sie mehr Probleme als Vorteile. Warum kannst du sie nicht ablehnen?

stateless cookie, « », - , , , .

, , , . , . , , . , , , , .

— MA — Message Authentication Codes, . , . HCK - m. , , K. , , . , , .



, . , stateless cookie, Amazon, , x3. - Amazon, AWS, . – K, – AWS, .



, AWS HTTP, .

, , , :

GET /photos/ cat; .jpg HTTP/1.1, - AWS:

HOST: — - — - — , , :

DATE: Mon, June 4, , , . , ID , , , .



? , 3- .

, String To Sign :

— HTTP, GET;
— MDS;
— , html jpg;
— ;
— , , .



, , HCK MAC. , . , . , . ?

, , , - . Amazon , stateless cookie, MD5 .

, , , cookie, . – , , .

, . , , “HCK, m”.



. GET /photos/ cat; .jpg HTTP/1.1 , , . , , . , ? : «, , , ».

56:15

MIT-Kurs "Computer Systems Security". 9: « Web-», 3


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?