Änderungsprotokoll: Das OWASP-Top-10-Projekt

Die Komplexität von Webanwendungen ist in den letzten zehn Jahren explodiert. Sie haben sich von einfachen Containern für Kontaktformulare und Umfragen zu ausgewachsenen Anwendungen entwickelt. Wir können sie sowohl in Größe als auch Leistung mit den schweren Desktop-Anwendungen vergleichen. Mit einem steilen Anstieg der Komplexität und einer steigenden Anzahl funktionsreicher Anwendungen ist es zu einer Notwendigkeit geworden, viel Zeit und Sorgfalt zu investieren, um alle Anwendungskomponenten so sicher wie möglich zu machen. Der massive Anstieg der Internetnutzer hat es noch wichtiger gemacht, sich mit dem Thema Schutz der Daten und Anwendungsnutzer auseinanderzusetzen. Es gibt einen riesigen Pool von Bedrohungen, die versuchen, sich einzuschleichen und allen Beteiligten schwere Kopfschmerzen zu bereiten.

2001 betrat eine neue Organisation die Bühne. Sein Ziel war es, die Sicherheitsprobleme zu bekämpfen, die Websites und Anwendungen betreffen. Es erhielt den passenden Namen Open Web Application Security Project (OWASP). Heutzutage veröffentlicht es Ressourcen, organisiert Konferenzen und schlägt Standards für Web- und Anwendungssicherheit vor. Ein De-facto-Standard für die Sicherheit von Webanwendungen ist das OWASP Top Ten Project. Es listet die zehn häufigsten Sicherheitsbedrohungen auf. Einflussfaktoren bei der Entscheidung, was aufgenommen wird, waren eine umfangreiche Datenmenge und Community-Feedback. Ende 2017 gab es ein Update des Projekts. Mehrere neue Probleme, die für viele moderne Webanwendungen kritisch sind, haben ihren Platz erhalten, während einige von der Liste verschwunden sind.

Dieser Artikel ergänzt die ursprüngliche Liste und veranschaulicht die neuesten Änderungen an der Liste. Es beschreibt die Bedrohungen, versucht, klare Beispiele zum leichteren Verständnis zu liefern, und schlägt Wege zur Bekämpfung von Sicherheitsbedrohungen vor.

Probleme aus der OWASP-Top-10-Liste entfernt

Vor dem Update 2017 war die Liste von 2013 die aktuellste. In Anbetracht der Veränderungen in der Art und Weise, wie Webanwendungen jetzt erstellt und verwendet werden, war es nur sinnvoll, eine gründliche Überarbeitung vorzunehmen. Microservices nehmen sich ihr Stück vom Kuchen ab, und neue coole und glänzende Frameworks ersetzen Vanilla-Code-Battle-Ausrüstung. Diese Tatsachen bedeuten, dass einige der zuvor aufgeführten Bedrohungen entfernt wurden und einige neue an ihre Stelle traten.

Wir werden in diesem Artikel unsere Erinnerung an die längst vergessenen Probleme auffrischen und die neuen bösen Wölfe vorstellen. Geschichte zu lernen ist der einzig sichere Weg, dieselben Fehler nicht zu wiederholen.

Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) ist einer der „Verlierer“ in der jüngsten Iteration des Projekts. Es verschwand, weil viele moderne Web-Frameworks CSRF-Verteidigungsmechanismen enthalten. Die Wahrscheinlichkeit, Ihre Anwendungen der Bedrohung auszusetzen, sinkt somit rapide.

Unabhängig davon, ob CSRF die Liste verlässt, ist es immer noch gut, unser Gedächtnis aufzufrischen. Sorgen wir dafür, dass es nicht stärker als je zuvor zurückkommt.

Im Wesentlichen ist CSRF ein Exploit, das sich wie eine Rauchbombe anfühlt. Ein Angreifer bringt einen ahnungslosen Benutzer dazu, eine unerwünschte Anfrage oder Aktion innerhalb einer Webanwendung auszuführen. Einfach ausgedrückt, ein Angreifer zwingt sein Opfer, eine Anfrage an eine Anwendung eines Drittanbieters zu senden, und das Opfer weiß nicht, dass die Anfrage jemals gesendet wurde. Die Anfrage könnte eine HTTP-GET-Anfrage zum Abrufen einer Ressource oder noch schlimmer eine HTTP-POST-Anfrage sein, die eine Ressource unter der Kontrolle des Opfers ändert. Während des Angriffs denkt das Opfer, dass alles in Ordnung ist, meist ohne zu bemerken, dass im Hintergrund etwas passiert. Nachdem die Luft klar ist, ist der Schaden angerichtet oder etwas fehlt, und niemand weiß, was passiert ist.

Eine erfolgreiche frühere Benutzerauthentifizierung innerhalb der Zielanwendung ermöglicht die Wirksamkeit der Falle. Der Benutzer hatte sich irgendwann vor dem Angriff bei einer Anwendung angemeldet. Die Anwendung schickte dem Opfer ein Cookie, um sich an sie zu erinnern. Sobald der Webbrowser die böswillige Anfrage sendet, wird das Cookie automatisch zusammen mit potenziellen Nutzdaten gesendet, und die Anwendung hat nichts dagegen, die Anfrage einem bereits bekannten Benutzer zuzustellen.

Eines der bekanntesten Beispiele ist, einen Benutzer dazu zu bringen, Geld von seinem Konto auf das Konto zu überweisen, das ein Angreifer kontrolliert. Ein Benutzer meldet sich bei einem E-Banking-System an, um seinen Kontostand zu überprüfen. Danach besuchen sie ein Online-Forum, um die Bewertungen eines neuen Mobiltelefons zu überprüfen. Ein Angreifer, der mit Dynamit fischt, veröffentlicht eine Bewertung, die ein Bild mit einem scheinbar defekten Bild-Hyperlink enthält. Anstelle eines echten Hyperlinks verwendet der Angreifer einen Hyperlink, über den das E-Banking-System intern Geld von Konto A auf Konto B überweist: https://payments.dummybank.com?receiver=attacker&amount=100 . Das Bankensystem macht den authentifizierten Benutzer zum Absender und den Wert aus dem Parameter „Empfänger“ zum Empfänger der Gelder. Natürlich gibt der Angreifer sein Offshore-Konto als Empfänger an.

Da der Browser beim Rendern der Seite automatisch Bilder lädt, erfolgt die Anfrage im Hintergrund. Wenn das Zahlungssystem der Bank Geldüberweisungen über eine HTTP-GET-Anforderung implementiert, steht der Katastrophe nichts mehr im Weg. Beachten Sie, dass das Beispiel einfach ist und Übertragungen höchstwahrscheinlich nicht über HTTP GET abgewickelt werden. Der Angreifer kann es jedoch mit etwas mehr Schwierigkeiten schaffen, das Attribut „Aktion“ im HTML-Formular zum Veröffentlichen von Nachrichten zu ändern. Der Browser sendet dann die Anfrage an das Zahlungssystem der Bank, anstatt an das Back-End des Forums.

Geld zu stehlen ist nur eines von vielen Beispielen da draußen. Auch das Ändern der E-Mail-Adressen von Benutzern oder unbeabsichtigte Käufe fallen in diese Kategorie. Wie es oft vorkommt, sind Social Engineering und etwas technisches Wissen ein wirksames Mittel gegen einen Software-Engineering-Fehler.

Beachten Sie beim Entwerfen Ihrer Systeme Folgendes:

• Verwenden Sie keine HTTP-GET-Anforderungen zum Einkapseln von Aktionen, die eine Ressource ändern. Sie sollten diese Anfragen nur zum Abrufen von Informationen verwenden. Denken Sie daran, dass die Faustregel lautet, GET-Anforderungen idempotent zu machen.
• Senden Sie bei der internen Übertragung von Daten mithilfe von HTTP-POST-Anforderungen die Daten in der Regel in JSON, XML oder einem anderen Format als der Codierung der Parameter als Abfragezeichenfolge. Die Verwendung eines nicht trivialen Datenformats verringert die Gefahr, dass jemand ein gefälschtes HTML-Formular erstellt, das die Daten an Ihren Dienst sendet.
• Stellen Sie sicher, dass Sie ein eindeutiges und unvorhersehbares Token erstellen und in Ihre HTML-Formulare einfügen. Diese Token sollten auch für jede Anfrage eindeutig sein. Durch die Überprüfung des Vorhandenseins und der Korrektheit solcher Token wird das Risiko des Auftretens von Bedrohungen verringert. Um das Token herauszufinden und es in ihren gefälschten Anfragen zu verwenden, müssten Angreifer auf Ihr System zugreifen und direkt von dort ein Token nehmen. Da die Token nur einmal verwendet werden, können sie sie nicht im bösartigen Code wiederverwenden.

Diese Schwachstelle wirkt sich noch schlimmer aus, wenn sie mit Cross-Site-Scripting (XSS) gekoppelt ist. Wenn ein Angreifer schädlichen Code in eine bevorzugte Website oder Anwendung einschleusen kann, wird das Ausmaß des Angriffs viel bedeutender und gefährlicher. Noch kritischer ist, dass Angreifer einige der Schutzmechanismen gegen CSRF umgehen können, wenn XSS-Angriffe möglich sind.

Denken Sie daran, dass CSRF nicht verschwunden ist, es ist nur nicht mehr so ​​verbreitet wie früher.

Nicht validierte Umleitungen und Weiterleitungen

Viele Anwendungen leiten einen Benutzer nach Abschluss einer Aktion zu einem anderen Teil derselben oder sogar einer anderen Anwendung um oder leiten ihn weiter. Beispielsweise löst die erfolgreiche Anmeldung bei einer Anwendung eine Umleitung auf die Startseite oder die Seite aus, die der Benutzer ursprünglich besucht hat. Sehr oft ist das Ziel Teil der Aktions- oder Linkadresse des Formulars. Wenn die Komponente, die die Umleitung oder Weiterleitung handhabt, nicht sicherstellt, dass die Zieladresse tatsächlich die von der Anwendung generierte ist, entsteht eine potenzielle Bedrohung. Dies ist eine Sicherheitslücke namens „unvalidierte Umleitungen und Weiterleitungen“.

Die beiden Hauptgründe, warum nicht validierte Um- und Weiterleitungen jemals als gefährlich angesehen werden, sind Phishing und Credential Hijacking. Ein Angreifer kann es schaffen, den Umleitungs-/Weiterleitungszielort zu ändern und einen Benutzer zu einer bösartigen Anwendung zu schicken, die von der ursprünglichen kaum zu unterscheiden ist. Ein ahnungsloser Benutzer gibt seine Anmeldeinformationen und vertraulichen Informationen an einen böswilligen Dritten weiter. Bevor sie realisieren, was passiert ist, ist es bereits zu spät.

Beispielsweise implementieren Webanwendungen sehr oft eine Anmeldung mit Unterstützung für Weiterleitungen auf die zuletzt besuchte Seite. Um dies einfach tun zu können, könnte das Aktionsattribut eines HTML-Formulars etwa so aussehen: http://myapp.example.com/signin?url=http://myapp.example.com/puppies . Sie sind ein großer Bewunderer von Welpen, daher war es sinnvoll, eine Browsererweiterung zu installieren, die Website-Favicons durch die Miniaturansichten Ihrer Lieblingswelpen ersetzt. Leider ist es eine Hunde-Essen-Hund-Welt. Der Autor der Browser-Erweiterung hat beschlossen, von Ihrer bedingungslosen Liebe zu profitieren und ein zusätzliches „Feature“ einzuführen. Jedes Mal, wenn Sie Ihre Lieblings-Welpen-Fanseite besuchen, ersetzt sie den „url“-Parameter im Aktionsattribut des Formulars durch einen Link zu ihrer eigenen Seite. Da die Seite genauso aussieht, finanzieren Sie, wenn Sie Ihre Kreditkartendaten angeben, um Welpenspielkarten zu kaufen, tatsächlich einen böswilligen Angreifer, nicht Ihr Hobby.

Um die Schwachstelle zu beheben, muss der Zielort überprüft werden, indem sichergestellt wird, dass es der beabsichtigte ist. Wenn ein Framework oder eine Bibliothek die vollständige Umleitungs- oder Weiterleitungslogik übernimmt, ist es vorteilhaft, die Implementierung zu überprüfen und den Code bei Bedarf zu aktualisieren. Andernfalls müssen Sie manuelle Überprüfungen durchführen, um sich vor dem Angriff zu schützen.

Es gibt verschiedene Arten von Überprüfungen, die Sie durchführen können. Verwenden Sie für den besten Schutz eine Kombination mehrerer Ansätze, anstatt nur bei einem von ihnen zu bleiben.

• Validieren Sie die ausgehende URL und stellen Sie sicher, dass sie auf die von Ihnen kontrollierte Domain verweist.
• Anstatt explizite Adressen zu verwenden, codieren Sie sie am Front-End und decodieren und validieren Sie sie dann am Back-End.
• Erstellen Sie eine Whitelist mit vertrauenswürdigen URLs. Lässt Weiterleitungen und Umleitungen nur zu den Orten auf der Whitelist zu. Ziehen Sie diesen Ansatz dem Führen einer schwarzen Liste vor. Schwarze Listen werden normalerweise nur dann mit neuen Elementen gefüllt, wenn etwas Schlimmes passiert. Whitelists sind restriktiver.
• Verwenden Sie einen Ansatz, der von LinkedIn und einigen anderen Anwendungen verwendet wird: Präsentieren Sie Ihren Benutzern eine Seite, auf der sie aufgefordert werden, eine Umleitung/Weiterleitung zu bestätigen, und machen Sie deutlich, dass sie Ihre Anwendung verlassen.

Zusammengeführte Ausgaben

Die meisten der Probleme auf der Liste können als Mängel in der Implementierung bezeichnet werden, entweder aufgrund mangelnder Kenntnisse oder unzureichender Untersuchung potenzieller Bedrohungen. Beide Gründe können auf mangelnde Erfahrung zurückgeführt werden, und die Lösung für die Berücksichtigung in der Zukunft ist einfach – stellen Sie einfach sicher, dass Sie mehr lernen und gründlicher sind. Eine besonders knifflige beruht auf einer Kombination aus der gefährlichen (aber sehr menschlichen) Eigenschaft, zu viele Annahmen zu treffen, gepaart mit der Schwierigkeit, komplexe Computersysteme zu entwickeln und zu warten. Eine Schwachstelle, die in diese Kategorie passt, ist „gebrochene Zugriffskontrolle“.

Gebrochene Zugriffskontrolle

Eine Schwachstelle wird durch unzureichende oder völlig fehlende Autorisierung und Zugriffskontrolle für bestimmte Teile der Anwendung verursacht. In den vorherigen Iterationen des OWASP-Top-Ten-Projekts gab es zwei Probleme: unsichere direkte Objektreferenzen und fehlende Zugriffskontrolle auf Funktionsebene. Sie werden jetzt aufgrund ihrer Ähnlichkeit zu einer verschmolzen.

Direkte Objektreferenzen

Direkte Objektreferenzen werden häufig in URLs verwendet, um Ressourcen zu identifizieren, auf denen gearbeitet wird. Wenn sich ein Benutzer beispielsweise anmeldet, kann er sein Profil besuchen, indem er auf einen Link klickt, der seine Profilkennung enthält. Wenn dieselbe Kennung in der Datenbank gespeichert und zum Abrufen von Profilinformationen verwendet wird und die Anwendung davon ausgeht, dass Personen nur über eine Anmeldeseite auf die Profilseite zugreifen können, werden durch Ändern der Profilkennung in der URL Profilinformationen eines anderen Benutzers offengelegt.

Eine Anwendung, die die URL des Profillöschformulars http://myapp.example.com/users/15/delete setzt, macht deutlich, dass es mindestens 14 andere Benutzer innerhalb der Anwendung gibt. Herauszufinden, wie man an das Löschformular anderer Benutzer gelangt, ist in diesem Fall kein Hexenwerk.

Die Lösung für dieses Problem besteht darin, Autorisierungsprüfungen für jede Ressource durchzuführen, ohne davon auszugehen, dass nur bestimmte Pfade genommen werden können, um zu einigen Teilen der Anwendung zu gelangen. Darüber hinaus ist das Entfernen direkter Verweise und das Verwenden indirekter Verweise ein weiterer Schritt nach vorne, da es böswilligen Benutzern erschwert wird, herauszufinden, wie der Verweis erstellt wurde.

Schreiben Sie während der Entwicklung vorsichtshalber ein einfaches Zustandsmaschinendiagramm auf. Lassen Sie die Zustände verschiedene Seiten innerhalb Ihrer Anwendung und Übergänge der Aktionen darstellen, die Benutzer ausführen können. Dies erleichtert das Auflisten aller Übergänge und Seiten, die besondere Aufmerksamkeit erfordern.

Fehlende Zugriffskontrolle auf Funktionsebene

Fehlende Zugriffskontrolle auf Funktionsebene ist unsicheren direkten Objektreferenzen sehr ähnlich. In diesem Fall ändern Benutzer die URL oder einen anderen Parameter, um zu versuchen, auf geschützte Teile der Anwendung zuzugreifen. Wenn es keine angemessene Zugriffskontrolle gibt, die Zugriffsebenen prüft, kann ein Benutzer privilegierten Zugriff auf Anwendungsressourcen oder zumindest etwas Wissen über deren Existenz erlangen.

Angelehnt an das Beispiel für direkte Objektreferenzen: Wenn eine Anwendung davon ausgeht, dass ein Benutzer, der das Löschformular besucht, ein Superuser ist, nur weil Superuser den Link zum Löschformular sehen können, ohne eine weitere Autorisierung vorzunehmen, öffnet sich eine riesige Sicherheitslücke. Sich auf die Verfügbarkeit einiger UI-Elemente zu verlassen, ist keine ordnungsgemäße Zugriffskontrolle.

Das Problem wird gelöst, indem Sie immer sicherstellen, dass alle Ebenen Ihrer Anwendung überprüft werden. Die Front-End-Oberfläche ist möglicherweise nicht die einzige Möglichkeit, wie böswillige Benutzer auf Ihre Domänenebene zugreifen können. Verlassen Sie sich auch nicht auf Informationen, die von Benutzern über ihre Zugriffsebenen weitergegeben werden. Führen Sie eine ordnungsgemäße Sitzungskontrolle durch und überprüfen Sie die empfangenen Daten immer doppelt. Nur weil der Anfragetext besagt, dass der Benutzer ein Administrator ist, bedeutet das nicht wirklich, dass er es ist.

Unterbrochene Zugriffskontrolle fasst nun alle Probleme zusammen, die mit einer unzureichenden Zugriffskontrolle zusammenhängen, sei es auf Anwendungsebene oder auf Systemebene, wie beispielsweise eine Fehlkonfiguration des Dateisystems.

Neuerscheinungen in der OWASP Top 10 Liste

Das Aufkommen neuer Front-End-Frameworks und die Einführung neuer Softwareentwicklungspraktiken verlagerten die Sicherheitsbedenken auf völlig neue Themen. Neue Technologien haben es auch geschafft, einige häufige Probleme zu lösen, mit denen wir uns zuvor manuell befasst haben. Daher war es von Vorteil, die Liste zu überarbeiten und an moderne Trends anzupassen.

Externe XML-Entitäten

Der XML-Standard bietet eine wenig bekannte Idee namens externe Entität, die Teil der Datentypdefinition (DTD) des Dokuments ist. Es ermöglicht Dokumentautoren, Links zu externen Entitäten anzugeben, auf die dann verwiesen und die in das Hauptdokument aufgenommen werden können. Ein ganz einfaches Beispiel wäre:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Während des Parsens wird eine Referenz &bar; wird durch den Inhalt der definierten Entität ersetzt, wodurch <foo>baz</foo> .

Wenn die Anwendung externe Eingaben aufnehmen und ohne Überprüfung direkt in die XML-Dokumentdefinition aufnehmen würde, wäre eine Vielzahl von Datenlecks und Angriffen möglich.

Das Wunderbare daran ist, dass die Entität kein einfacher String sein muss – sie kann ein Verweis auf eine Datei im Dateisystem sein. Der XML-Parser übernimmt gerne den Inhalt der angegebenen Datei und fügt ihn in die generierte Antwort ein, wodurch möglicherweise vertrauliche Systeminformationen preisgegeben werden. Wie von OWASP veranschaulicht, wäre es sehr einfach, Informationen über die Benutzer des Systems zu erhalten, indem die Entität als definiert wird

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Ein besonders störendes „Feature“ dieser Schwachstelle ist die Möglichkeit, auf einfache Weise einen Denial-of-Service-Angriff auszuführen. Eine einfache Möglichkeit wäre, den Inhalt einer endlosen Datei wie /dev/random . Die andere besteht darin, eine Folge von Entitäten zu erstellen, die jeweils mehrfach auf die vorherige verweisen. Dadurch wird die endgültige Referenz zu einer Wurzel eines möglicherweise sehr breiten und tiefen Baums, dessen Analyse den Systemspeicher erschöpfen könnte. Dieser Angriff ist sogar als Billion Laughs bekannt. Wie auf Wikipedia gezeigt, wird eine Reihe von Dummy-Entitäten definiert, die einem Angreifer die Möglichkeit bieten, eine Milliarde Lols in das endgültige Dokument aufzunehmen.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

Das Verhindern von Exploits externer XML-Entitäten könnte durch die Verwendung eines weniger komplexen Datenformats erfolgen. JSON ist ein guter Ersatz, vorausgesetzt, dass aufgrund möglicher Angriffe auch Vorsichtsmaßnahmen getroffen werden. Das Aktualisieren von XML-Bibliotheken ist ein Muss, verbunden mit dem Deaktivieren der Verarbeitung externer Entitäten und der DTD. Validieren und bereinigen Sie wie immer die Daten aus nicht vertrauenswürdigen Quellen, bevor Sie sie verwenden oder in Ihre Dokumente aufnehmen.

Unsichere Deserialisierung

Beim Schreiben von Code haben Entwickler die Möglichkeit, die Systeme, die sie entwickeln, mit dem von ihnen geschriebenen Code zu steuern. Wie großartig wäre es, das Verhalten von Drittsystemen zu kontrollieren, die nur wenig oder gar keinen Code schreiben? Dank der Tatsache, dass Menschen nicht perfekt sind und Bibliotheken Fehler haben, ist dies durchaus möglich.

Anwendungsstatus und -konfiguration werden häufig serialisiert und gespeichert. Manchmal dienen Browser als Speicher-Engines, wenn die serialisierten Daten eng an den aktuellen Benutzer gekoppelt sind. Eine Anwendung, die versucht, clever zu sein und Verarbeitungszeit zu sparen, könnte ein Cookie verwenden, um zu markieren, dass sich ein Benutzer angemeldet hat. Da das Cookie nur nach erfolgreicher Anmeldung erstellt werden kann, ist es sinnvoll, den Benutzernamen im Cookie zu speichern. Ein Benutzer wird dann basierend auf der Existenz und dem Inhalt des Cookies authentifiziert und autorisiert. Wenn die Leute keine bösen Absichten hätten, könnte nichts schief gehen. Ehrlich gesagt dürfen sie auch nicht neugierig sein.

Wenn ein neugieriger Benutzer ein Cookie auf seinem Computer findet, könnte er so etwas sehen:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

Ein perfekt gültiges Python-Wörterbuch, serialisiert in JSON, nichts Besonderes. Der immer neugierige Benutzer kann das Ablaufdatum ändern, um zu verhindern, dass die Anwendung die Abmeldung erzwingt. Ein noch neugierigerer Benutzer könnte versuchen, den Benutzernamen in "jane.doe" zu ändern. Wenn es diesen Benutzernamen gäbe, würde er dem ahnungslosen Benutzer, der jetzt Zugriff auf private Daten hat, eine ganz neue Welt eröffnen.

Ein einfaches Beispiel dafür, Daten in JSON zu serialisieren und alles transparent zu halten, ist bei weitem nicht das Schlimmste, was Ihnen passieren kann. Wenn es einem Angreifer gelingt, einige serialisierte Daten zu ändern, kann er sie möglicherweise so ändern, dass Ihr System gezwungen wird, beliebigen Code auszuführen.

Angenommen, Sie erstellen eine REST-API, mit der Benutzer ihre eigenen Modelle für maschinelles Lernen in Python schreiben und in Ihren Dienst hochladen können. Der Dienst bewertet die hochgeladenen Modelle und trainiert sie mit Ihren Datensätzen. Auf diese Weise können Benutzer Ihre Computerressourcen und eine große Menge verfügbarer Datensätze für eine schnelle und einfache Modellerstellung nutzen.

Der Dienst speichert den Code nicht im Nur-Text-Format. Benutzer picken ihren Code, verschlüsseln ihn mit ihrem privaten Schlüssel und senden ihn zum Training an die API. Wenn der Dienst ein Modell ausführen muss, entschlüsselt er den Code, entpickt ihn und führt ihn aus. Der knifflige Teil ist, dass das Pickle-Protokoll unsicher ist. Der Code kann so konstruiert werden, dass während der Deserialisierung beliebiger bösartiger Code ausgeführt werden kann.

Das Pickle-Protokoll von Python ermöglicht es Klassen, eine Methode __reduce__ zu definieren, die Informationen darüber zurückgibt, wie ein benutzerdefiniertes Objekt deserialisiert wird. Einer der unterstützten Rückgabewerte ist ein Tupel aus zwei Argumenten: ein aufrufbares Argument und ein Tupel von Argumenten, die an das aufrufbare Argument übergeben werden. Unter Berücksichtigung, dass Ihr ML-Modell-Trainingssystem darauf abzielt, maximale Flexibilität der Codestruktur bereitzustellen, ist es möglich, den folgenden Code zu schreiben:

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Sobald das Objekt deserialisiert (entpickelt) werden muss, wird eine Funktionsliste mit nur einem Argument list . Die Funktion list ist ein Listenkonstruktor in Python, und die Funktion itertools.count erzeugt einen unendlichen Iterator von Werten, beginnend mit dem übergebenen Parameter. Die Umwandlung eines unendlichen Iterators in eine endliche Liste kann verheerende Folgen für die Leistung und Stabilität Ihres Systems haben.

Die einzige wirkliche Abhilfe für diese Art von Schwachstelle besteht darin, sich dafür zu entscheiden, Daten aus externen Quellen nicht zu deserialisieren. Falls dies nicht möglich ist, wird empfohlen, eine Prüfsumme oder eine digitale Signatur zu verwenden, um eine Deserialisierung von Daten zu verhindern, die möglicherweise von einem böswilligen Benutzer geändert wurden. Versuchen Sie außerdem, eine von Ihrem Hauptsystem entkoppelte Sandbox-Umgebung einzurichten, um die Auswirkungen von möglicherweise auftretenden Problemen zu begrenzen.

Wenn Sie externe Bibliotheken zum Deserialisieren von Daten verwenden, z. B. aus XML oder JSON, versuchen Sie, diejenigen auszuwählen, mit denen Sie Objekttypprüfungen durchführen können, bevor eine tatsächliche Deserialisierung ausgeführt wurde. Dies könnte unerwartete Objekttypen abfangen, deren einziger Zweck darin besteht, Ihrem System Schaden zuzufügen.

Erzwingen Sie wie bei allen anderen Aktionen, die Ihre Anwendung durchführt, eine umfassende Protokollierung und Überwachung. Deserialisierungen, die häufig auftreten oder häufiger als normal fehlschlagen, sind Anzeichen dafür, dass etwas Schlimmes passiert. Fangen Sie die Probleme frühzeitig.

Unzureichende Protokollierung und Überwachung

Wie viel Zeit verbringen Sie damit, alle Warnungen und Fehler zu protokollieren, die in Ihrer Anwendung auftreten? Speichern Sie nur Fehler, die im Code auftreten, oder protokollieren Sie auch Validierungsfehler? Was passiert, wenn die Geschäftsregeln Ihrer Domain nicht erfüllt werden? Das Versäumnis, alle fehlerhaften und verdächtigen Aktivitäten in Ihrer Anwendung fortzusetzen, stellt eine Sicherheits- und Datenkompromittierung dar.

Stellen Sie sich folgendes Szenario vor. Ihre Anwendung enthält wie die meisten eine Anmeldeseite. Das Formular hat zwei Felder, eines für die Eingabe einer E-Mail und das andere für ein Passwort. Wenn ein Benutzer versucht, sich anzumelden und ein falsches Kennwort angibt, kann er es erneut versuchen. Leider ist die Anzahl der Fehlversuche nicht begrenzt, sodass die Anmeldeseite nach N erfolglosen Versuchen nicht gesperrt wird. Ein Angreifer kann diese Gelegenheit nutzen und bei einer richtigen E-Mail so lange Passwörter aus einer Regenbogentabelle eingeben, bis schließlich eine Kombination gelingt. Vorausgesetzt, Ihre Anwendung ist sicher genug und Sie hashen die Passwörter, bevor Sie sie in eine Datenbank eingeben, funktioniert dieser spezielle Angriff nicht. Haben Sie jedoch einen Mechanismus zur Identifizierung von Eindringlingen?

Nur weil dieser eine Versuch fehlgeschlagen ist, Ihre Anmeldeseite zu öffnen, heißt das nicht, dass ein anderer es nicht tut. Die Anmeldeseite ist wahrscheinlich auch nicht die einzige potenzielle Hintertür, die Sie haben. Andernfalls könnte jemand versuchen, eine kaputte Zugriffskontrolle gegen Sie zu verwenden. Selbst perfekt gestaltete Anwendungen sollten wissen, dass jemand versucht, sie anzugreifen, auch wenn dies möglicherweise nicht möglich ist. Es ist es aber immer.

Führen Sie die folgenden Schritte aus, um sich bestmöglich vor solchen Angriffen zu schützen:

• Protokollieren Sie alle Fehler und Warnungen, die in der Anwendung auftreten, seien es im Code ausgelöste Ausnahmen oder Zugriffssteuerungs-, Validierungs- und Datenmanipulationsfehler. Alle gespeicherten Informationen müssen repliziert und so lange aufbewahrt werden, dass eine nachträgliche Einsichtnahme und Analyse möglich ist.
• Die Bestimmung des Formats und der Persistenzschicht ist wichtig. Es ist einfach, eine riesige Datei mit beliebigem Textformat zu haben; Eine spätere Verarbeitung ist es nicht. Wählen Sie eine Speicheroption, die das Speichern und Lesen der Daten erleichtert, und ein Format, das eine einfache und schnelle (De-)Serialisierung ermöglicht. Das Speichern von JSON in einer Datenbank, die einen schnellen Zugriff ermöglicht, erleichtert die Verwendung. Halten Sie die Datenbank klein, indem Sie sie regelmäßig sichern.
• Wenn Sie es mit wichtigen und wertvollen Daten zu tun haben, verfolgen Sie die Aktionen, die Sie verfolgen können, um den Endzustand zu prüfen. Implementieren Sie einen Mechanismus zur Verhinderung von Datenmanipulation.
• Lassen Sie Hintergrundsysteme die Protokolle analysieren und Sie benachrichtigen, wenn etwas auftaucht. Prüfungen – die so einfach sind wie das Testen, ob ein Benutzer wiederholt versucht, auf einen geschützten Teil der Anwendung zuzugreifen – helfen. Überladen Sie das System jedoch nicht mit Dummy-Checks. Überwachungssysteme müssen als separate Dienste ausgeführt werden und dürfen die Leistung des Hauptsystems nicht beeinträchtigen.

Achten Sie beim Lösen des Problems besonders darauf, Fehlerprotokolle nicht an externe Benutzer weiterzugeben. Wenn Sie dies nicht tun, sind Sie anfällig für die Offenlegung sensibler Informationen. Protokollierung und Überwachung sollen Ihnen helfen, Probleme zu lösen, nicht Angreifer dabei, ihre Arbeit effizienter zu erledigen.

Nächste Schritte

Es ist wichtig, sich der potenziellen Bedrohungen und Schwachstellen in Webanwendungen bewusst zu sein. Es ist sogar noch wichtiger, sie in Ihren Anwendungen zu identifizieren und die Patches anzuwenden, um sie zu entfernen.

Die Beachtung der Anwendungssicherheit ist ein wichtiger Bestandteil aller Schritte des Softwareentwicklungsprojekts. Softwarearchitekten, Entwickler und Tester müssen alle Softwaretestverfahren in ihre Arbeitsabläufe integrieren. Es ist vorteilhaft, Sicherheitschecklisten und automatisierte Tests in geeigneten Schritten des Softwareentwicklungsprozesses einzusetzen, um das Sicherheitsrisiko zu verringern.

Unabhängig davon, ob Sie eine vorhandene Anwendung analysieren oder eine neue entwickeln, sollten Sie sich das OWASP Application Security Verification Standard Project (ASVS) ansehen. Ziel des Projekts ist die Entwicklung eines Standards zur Prüfung der Anwendungssicherheit. Der Standard zählt Tests und Anforderungen für die Entwicklung sicherer Webanwendungen auf. Den Tests sind Stufen von eins bis drei zugeordnet, wobei eins die geringste Gefahr und drei die höchste potenzielle Bedrohung bedeutet. Anhand der Klassifizierung können Anwendungsmanager entscheiden, welche der Bedrohungen wahrscheinlicher und wichtiger sind. Es ist nicht notwendig, jeden Test in jede Anwendung aufzunehmen.

Sowohl neue als auch bestehende Webanwendungsprojekte, insbesondere solche, die agilen Prinzipien folgen, profitieren von einer strukturierten Planung der Bemühungen zur Sicherung ihrer Anwendungen. Die Planung von OWASP ASVS Tests wird einfacher, wenn Sie sich für OWASP Security Knowledge Framework entscheiden. Es handelt sich um eine Anwendung zur Verwaltung sicherheitstestorientierter Sprints, die mit einer Reihe von Beispielen zur Lösung häufiger Sicherheitsprobleme und leicht verständlichen Checklisten auf der Grundlage von OWASP ASVS geliefert wird.

Wenn Sie gerade erst mit der Erforschung der Sicherheit von Webanwendungen begonnen haben und einen sicheren Sandbox-Spielplatz benötigen, verwenden Sie eine Webanwendungsimplementierung von OWASP – WebGoat. Es ist eine absichtlich unsichere Implementierung einer Webanwendung. Die Anwendung führt Sie durch die Lektionen, wobei sich jede Lektion auf eine Sicherheitsbedrohung konzentriert.

Stellen Sie während der Anwendungsentwicklung Folgendes sicher:

• Identifizieren und priorisieren Sie Bedrohungen. Definieren Sie, welche Bedrohungen realistischerweise eintreten können und ein Risiko für Ihre Anwendung darstellen. Priorisieren Sie die Bedrohungen und entscheiden Sie, welche den größten Entwicklungs- und Testaufwand verdienen. Es macht nicht viel Sinn, viel Mühe in die Lösung unzureichender Protokollierung und Überwachung zu stecken, wenn Sie einen statischen Blog bedienen.
• Bewerten Sie die Architektur und das Design Ihrer Anwendung. Einige Schwachstellen sind in den späteren Phasen der Anwendungsentwicklung nur sehr schwer zu beheben. Wenn Sie beispielsweise beabsichtigen, Code von Drittanbietern auszuführen und keine Sandbox-Umgebung verwenden möchten, wird es sehr schwierig sein, sich gegen unsichere Deserialisierung und Injection-Angriffe zu verteidigen.
• Aktualisieren Sie den Softwareentwicklungsprozess. Das Testen auf Bedrohungen von Webanwendungen muss so weit wie möglich ein automatisierter Prozess sein. Es ist vorteilhaft, Ihre CI/CD-Workflows mit automatisierten Tests zu erweitern, die versuchen, Sicherheitslücken zu finden. Sie können sogar Ihr vorhandenes Komponententestsystem verwenden, um Sicherheitstests zu entwickeln und diese regelmäßig auszuführen.
• Lernen und verbessern. Die Liste der Probleme und Schwachstellen ist nicht statisch und definitiv nicht auf zehn oder fünfzehn Bedrohungen beschränkt. Neue Funktionen und Ideen öffnen die Türen für neue Arten von Angriffen. Es ist wichtig, sich über die aktuellen Trends in der Welt der Sicherheit von Webanwendungen zu informieren, um auf dem Laufenden zu bleiben. Wenden Sie an, was Sie lernen; Andernfalls verschwenden Sie Ihre Zeit.

Fazit

Auch wenn das OWASP Top Ten Project, wie der Name schon sagt, nur zehn Sicherheitslücken auflistet, gibt es Tausende möglicher Fallen und Hintertüren, die Ihre Anwendungen und vor allem Ihre Benutzer und deren Daten bedrohen. Halten Sie Ausschau und frischen Sie Ihr Wissen ständig auf, denn technologische Veränderungen und Verbesserungen haben sowohl Vor- als auch Nachteile.

Oh, und vergiss nicht, die Welt ist nicht schwarz und weiß. Sicherheitslücken kommen nicht allein; sie sind oft miteinander verflochten. Einem ausgesetzt zu sein bedeutet oft, dass ein Haufen anderer um die Ecke wartet und darauf wartet, ihre hässlichen Köpfe zu erheben, und manchmal, auch wenn es nicht Ihre Schuld ist, als Entwickler der Systemsicherheit, sind Sie immer noch dazu bestimmt, Schlupflöcher zu flicken, um sie einzudämmen Cyberkriminalität. Ein Beispiel finden Sie unter Gehackte Kreditkartennummern sind immer noch Google-fähig .