Dies ist das erste Material aus einer Reihe von Artikeln über das OWASP Top 10-Projekt, ein Projekt, das als Idee für Enthusiasten begann und zur maßgeblichsten Quelle für die Klassifizierung von Angriffsmethoden und Schwachstellen in Webanwendungen wurde.
In diesem Artikel werden wir kurz alle Hauptschwachstellen aus der OWASP Top 10-Liste analysieren und herausfinden, warum es so wichtig ist, typische Schwachstellen zu kennen, um sichere Anwendungen zu entwickeln.
Vor ungefähr 10 Jahren formulierte eine sehr aufmerksame Person ein neues Mantra - HTTP ist neues TCP. Natürlich nicht in dem Sinne, dass die Person beschlossen hat, HTTP auf Transportebene zu setzen. Auf keinen Fall! Es ist nur so, dass für die moderne Kommunikation das HTTP-Protokoll auf seiner Ebene dieselbe Funktion wie TCP erfüllt - die überwiegende Mehrheit der modernen Anwendungen, einschließlich mobiler, verwendet HTTP als Transportmittel. Und mit dem Aufkommen von HTTP 2.0 hat sich diese Situation gebräunt und wird sich in naher Zukunft anscheinend nicht ändern. Das Protokoll ist zum De-facto-Standard für die Bereitstellung von Inhalten geworden, und HTTP kann nicht mehr als Webprotokoll angesehen werden.
Es scheint, dass HTTP schon immer existiert hat, und dies ist fast richtig, wenn man bedenkt, dass die erste offizielle Spezifikation in RFC 1997 erschien, obwohl das Protokoll selbst viel früher verwendet wurde.
Es hat einige Zeit gedauert, um zu verstehen, dass sobald das Protokoll populär wird, jeder es verwenden wird, um Inhalte zu liefern, oft ohne entsprechende Qualifikationen. Das Ergebnis werden Hunderttausende anfälliger Systeme auf der ganzen Welt und vage Aussichten für eine Behebung der Situation sein.
Bei Entscheidungen bestimmter Anbieter können Sie sich jederzeit an seine Materialien wenden oder direkt fragen: „Wie kann man am besten handeln?“ - und erhalten eine qualifizierte Antwort, denn am Ende ist nur der Verkäufer für sein Produkt verantwortlich. Wenn offene Standards und Tools zum Erstellen von Anwendungen verwendet werden sollen, ist eine unvoreingenommene Informationsquelle zu Best Practices erforderlich. Eine solche Quelle können Enthusiasten oder vielleicht eine ganze Gemeinschaft von Fachleuten auf diesem Gebiet sein.
Wespe fliegt
Im Bereich der Sicherheit von Webanwendungen ist das OWASP (Open Web Application Security Project) zu einer solchen Community geworden. Natürlich ist OWASP eine gemeinnützige Organisation, die keinem Technologieunternehmen angeschlossen ist. In dieser Situation können Sie Organisationen, Bildungseinrichtungen, Regierungsbehörden und sogar Personen, die an dem Problem interessiert sind, unparteiische praktische Informationen zu Technologien zum Schutz von Webanwendungen geben.
Was genau macht OWASP? Im Rahmen seiner Zuständigkeit hat OWASP zwei Hauptaufgaben: Dokumentation zu erstellen und Tools bereitzustellen, und zwar absolut kostenlos.
In dieser Artikelserie werden wir vielleicht das beliebteste Material des OWASP TOP 10-Projekts analysieren. Dies ist ein Dokument, in dem die wichtigsten und kritischsten Risiken von Webanwendungen aufgeführt sind. Die Entscheidung, Schwachstellen in diese Liste aufzunehmen, basiert auf der Expertenmeinung von Experten für Informationssicherheit aus der ganzen Welt (wo ohne diese). Im Großen und Ganzen ist das Verständnis dieser Schwachstellen der erste Schritt, um die Kultur der Softwareentwicklung zu ändern.
Sie müssen klar verstehen, dass all diese Schwachstellen in der Regel nicht auf den Fehlern bestimmter Programmierer oder den Schwachstellen der Protokolle selbst beruhen, sondern auf den Architekturproblemen des Software-Designs.
Zehn tödliche Zauber
Die Liste der Schwachstellen wird ständig aktualisiert und lautet für 2017 wie folgt:
• A1: 2017 - Injektionen, auch bekannt als „Code Injection“
Wir sprechen über alle Arten von Injektionen: SQL, NoSQL, LDAP - alles. Die Code-Injection wird möglich, wenn nicht verifizierte Daten als Teil eines Befehls oder einer Anforderung an den Interpreter gesendet werden. Eine solche "böswillige" Anfrage wird sicher ausgeführt und fügt ihren eigenen Schaden zu. In 90% der Fälle, wenn Sie hören, dass auf eine private Datenbank über das Internet zugegriffen wurde, ist dies nur unsere A1.
• A2: 2017 - Falsche Authentifizierung
Anwendungsfunktionen, die für die Authentifizierung und das Sitzungsmanagement verantwortlich sind, werden häufig falsch verwendet, was den Kompromiss zwischen Kennwörtern, Schlüsseln, Sitzungstoken und sogar die Möglichkeit zum vollständigen Abfangen einer Benutzersitzung zur Folge hat. Wenn Sie im öffentlichen WLAN sitzen und plötzlich feststellen, dass in Ihrem Namen einige Aktionen für öffentliche Webressourcen ausgeführt werden, ist dies A2.
• A3: 2017 - Offenlegung sensibler Informationen
Viele Webanwendungen und APIs speichern und verarbeiten möglicherweise vertrauliche Informationen wie z. B. personenbezogene Daten falsch. Angreifer können solche Informationen stehlen oder ändern, was zur Grundlage für schwerwiegende finanzielle oder Reputationsverluste werden kann. Sensible Informationen müssen ordnungsgemäß gespeichert und auch während der Übertragung über Kommunikationskanäle geschützt werden.
• A4: 2017 - Implementierung externer XML-Entitäten (XXE)
Viele ältere oder schief konfigurierte XML-Prozessoren können externe Daten von Links in XML-Dateien verwenden. Solche externen Daten können schädlichen Code enthalten, mit dem Sie fast jeden fremden Code auf dem Zielcomputer ausführen können.
• A5: 2017 - Zugriffskontrolle verletzt
Die Zugriffsmatrix, die auf dem Papier so gut war, kann für ein bestimmtes System falsch anprobiert werden, sodass unzulässige Benutzer leicht Zugriff auf geschlossene Bereiche von Websites erhalten oder die Möglichkeit erhalten, die Rechte an Ressourcen nach eigenem Ermessen zu ändern.
• A6: 2017-Sicherheitsfehlkonfiguration - Fehler in der Konfiguration
Hier geht es um einige weitere globale Dinge, wie das Fehlen zeitnaher Updates von Server- und Anwendungssoftware, das Vorhandensein wichtiger Informationen in Fehlermeldungen oder sogar in HTTP-Headern. Die Anwendung mag fast perfekt sein, aber wenn der Webserver, auf dem sie ausgeführt wird, Probleme mit der Grundkonfiguration hat, ist alles nutzlos.
• A7: 2017 - Crossite Scripting (XSS)
XSS tritt auf, wenn eine Anwendung nicht vertrauenswürdige Daten ohne ordnungsgemäße Überprüfung enthält. Beispielsweise kann der Programmcode eines Werbebanners ein Skript enthalten, um Benutzerdaten, das Gesicht der Site abzufangen oder sogar transparent auf andere Sites umzuleiten.
• A8: 2017 - Unsichere Deserialisierung
Unsichere Deserialisierung führt normalerweise zur Remotecodeausführung. Unter dem Strich können nicht vertrauenswürdige Daten die Logik Ihrer Anwendung zerstören, sobald sie deserialisiert werden. Eine auf den ersten Blick eher exotische Verwundbarkeit nimmt jedoch ihren Ehrenplatz in der Liste ein.
• A9: 2017 - Verwenden von Komponenten mit bekannten Schwachstellen
Bibliotheken, Frameworks, Betriebssysteme und andere Komponenten von Informationssystemen müssen rechtzeitig aktualisiert werden. Andernfalls kann eine bekannte Sicherheitsanfälligkeit in einer Bibliothek einen großen Dienst gefährden, der auch nur eine Funktion aus einer anfälligen Bibliothek verwendet.
• A10: 2017 - Unzureichende Protokollierung und Überwachung
Hier ist alles einfach - Sie haben ein wunderbares System gebaut, aber Sie haben vergessen, die Überwachungswerkzeuge zu befestigen. Es geht nicht einmal um ein verbundenes SIEM-System, sondern einfach um die banale Protokollierung der Hauptserverereignisse. Leider ist es nicht ungewöhnlich, dass Hacking-Systeme sechs Monate nach dem Hacking selbst bemerkt werden und dies nicht aus den Protokollen, sondern von externen Beobachtern erfahren.
In den folgenden Artikeln werden wir beginnen, jede dieser Schwachstellen genauer zu analysieren. Wir werden uns mit den notwendigen Tools ausstatten und sehen, wie diese Schwachstellen in der Praxis umgesetzt werden.
Vorbereitet von
Sergey Polunin .