Die meisten Produkte, die Sie kaufen, sind auf Netzwerk- und Endpunktsicherheit ausgerichtet. Gegen Schwachstellen in Webanwendungen sind diese jedoch nicht besonders wirksam. Daher beleuchten wir in diesem Beitrag die häufigsten Probleme, die wir in unserer Arbeit beobachten – von schwachen Netzwerken bis hin zur Benutzeraufzählung. Das Verständnis dieser Herausforderungen ist nicht nur für IT-Fachleute unerlässlich, sondern auch für Einzelpersonen und Organisationen, die bestrebt sind, ihre Sicherheitslage in einer zunehmend vernetzten Welt zu verbessern.
Wenn Sie eine Anwendung nutzen, werden Sie als Erstes mit einer Art Authentifizierung konfrontiert. Dabei handelt es sich in der Regel um eine Kombination aus Benutzername und Passwort. Und natürlich unterscheiden sich die Anforderungen von Website zu Website erheblich. Es ist durchaus üblich, dass Groß- und Kleinbuchstaben sowie möglicherweise Zahlen und Sonderzeichen vorgeschrieben sind. Auch die Länge spielt eine wichtige Rolle. Eine gute Richtlinie lautet: Das Passwort sollte lang genug sein, um Brute-Force-Angriffe zu verhindern, und komplex genug, damit es nicht in einem Wörterbuch vorkommt. Eine gute, empfohlene Länge beträgt mindestens 10 Zeichen. Vorzugsweise deutlich mehr.
Wir sind auf zahlreiche Anwendungen gestoßen, bei denen die einzige Anforderung eine Länge von sechs Zeichen war. Ein Passwort wie „111111“ wäre also völlig akzeptabel. Selbst ein leistungsschwacher Computer würde nur wenig Zeit benötigen, um den Hash dieses Passworts zu knacken. Ganz zu schweigen davon, dass es wahrscheinlich in einem Wörterbuch vorkommt, sodass auch ein Brute-Force-Angriff durchaus möglich wäre. Mehr darüber, wie Passwörter geknackt werden, finden Sie hier.
Ein praktisches Tool zur Bewertung des aktuellen Zustands der SSL-Implementierung ist„SSLLabs“ – es ist schnell, benutzerfreundlich und umfassend. Außerdem gibt es das Tool„SSLChecker“, eine vereinfachte Version, die für Laien leichter zu verstehen ist. Es bietet zudem den zusätzlichen Vorteil, dass es SSL-Sicherheits-Header überprüft. Wir werden hier nicht auf alle Details der SSL/TLS-Implementierung eingehen – das würde mindestens mehrere Seiten mehr in diesem Beitrag erfordern. Wir werden also in einem separaten Beitrag darauf zurückkommen müssen. Wenn Sie wirklich schon jetzt mehr wissen möchten, gibt es noch ein weiteres praktisches Tool. Man nennt es Google; wir glauben, es setzt sich langsam durch!Oder wenden Sie sich gerne anuns, und wir sorgen dafür, dass Sie die richtigen Informationen erhalten.
Es gibt mehrere gängige Methoden, mit denen Anwendungen dir ermöglichen, gültige Benutzer zu ermitteln. Eine der gängigsten und einfachsten ist die Anmeldefunktion. Ein Beispiel: Du versuchst, dich bei einer Anwendung anzumelden. Wenn du den richtigen Namen eingibst, dich aber beim Passwort vertippst, und die Antwort lautet: „Das Passwort ist falsch“. Dies ist ein Hinweis darauf, dass es sich um einen gültigen Benutzer handelt. Wenn du einen anderen Benutzernamen (der nicht gültig ist) ausprobierst und die Antwort lautet: „Kein gültiger Benutzer“, kannst du nun leicht feststellen, dass der erste Benutzer tatsächlich ein gültiger Benutzer war.
Für einen Angreifer wäre dies eine gute Gelegenheit, die Benutzer der Anwendung mit Brute-Force-Angriffen zu testen. Denn die Anwendung gibt eine Rückmeldung, ob der Benutzer gültig ist oder nicht.
Das größte Problem der Jahre 2017 und 2018 waren Injektionen verschiedener Art. Was kann also injiziert werden? SQL-Abfragen, Betriebssystembefehle, HTML-Inhalte, ganze Seiten mit Inhalten und Skripte. Wo könnte jemand solche Inhalte injizieren? Überall dort, wo Benutzereingaben erforderlich sind oder Nutzer Daten ändern können, z. B. in Textfeldern, Feldern für Benutzername und Passwort, Suchfunktionen, Feedback- und Kommentarfeldern, URLs usw.
Hochgeladene Dateien können schwerwiegende Folgen sowohl für die Anwendung als auch für das Dateisystem haben. Oftmals gibt es keine Filter dafür, welche Dateiendungen hochgeladen werden dürfen. Wenn nur ein oder zwei Dateitypen benötigt werden, sollten alle anderen auf der Sperrliste stehen.
Stellen Sie sich eine in PHP geschriebene Anwendung vor, bei der der Benutzer ein Profilbild hochladen kann. Man würde annehmen, dass diese Funktion nur das Hochladen von Bilddateien (JPG und PNG) zulässt. Es dürfen jedoch auch andere Dateiformate hochgeladen werden. Da es sich in diesem Fall um PHP handelt (und PHP direkt mit dem Betriebssystem interagieren kann), laden wir einen kleinen PHP-Code hoch, der uns direkten Zugriff auf das Dateisystem des Servers selbst ermöglicht. Dies kann zu weiteren schwerwiegenden Folgen führen, wie zum Beispiel dem Diebstahl von Informationen sowie dem möglichen Eindringen in das Netzwerk.
Dies geschieht, wenn keine ordnungsgemäßen Überprüfungen für die gesamte Sitemap durchgeführt werden. Dadurch kann ein Benutzer auf Informationen zugreifen, die ihm aufgrund seiner Berechtigungen eigentlich nicht zugänglich sein sollten (oder er ist gar nicht authentifiziert). Stellen Sie sich vor, Sie navigieren mit Ihrem Konto mit geringen Berechtigungen durch Ihre Zeiterfassungsanwendung. Das Einzige, was Sie davon abhält, Ihren eigenen Zeiterfassungsbericht zu genehmigen, ist im Grunde nur eine kosmetische Maßnahme. Die Schaltfläche „Genehmigen“ ist für Ihr Konto nicht sichtbar, sondern nur für die Administratoren der Anwendung. Wenn Sie jedoch die Anfragedaten kennen würden, könnten Sie den Zeiterfassungsbericht tatsächlich selbst genehmigen.
In dieser Anwendung haben Sie und Ihr Unternehmen einige interne Dokumente gespeichert, die als sensibel einzustufen sind. Sie rufen eine der PDF-Dateien auf und laden sie herunter – während Sie angemeldet sind. Wenn Sie sich aus der Anwendung abmelden und anschließend dieselbe URL für dieses Dokument aufrufen und die Datei weiterhin zugänglich ist, wäre dies erneut ein Beweis für mangelhafte Zugriffskontrollen.
Einheitliche Benutzer-/Gruppenberechtigungen. Es wäre schön, in einer Welt zu leben, in der alle gleich sind. Doch in der IT ist dies ein absolutes No-Go, kommt aber dennoch sehr häufig vor. Alle Konten für eine Anwendung oder ein Netzwerk verfügen über gleiche Berechtigungen – das führt zu Chaos, insbesondere wenn diese Anmeldedaten von einem Angreifer kompromittiert werden. Das kommt mehr oder weniger darauf hinaus, dem Angreifer die Schlüssel zum Königreich zu übergeben, und wird gemeinhin als „eine schlechte Idee“ bezeichnet. Die Frage, die man sich hier stellen muss, lautet: Braucht Janice aus der Buchhaltung tatsächlich Zugriff auf die streng geheimen Dokumente, die für Leann und Kurt bestimmt sind? Benutzerrollen sollten nach dem Prinzip der geringsten Berechtigungen zugewiesen werden: Was man nicht wissen muss, sollte man einfach nicht wissen und darauf auch keinen Zugriff haben.
Ein gutes Beispiel für dieses Problem ist der WannaCry-/EternalBlue-Ausbruch am 12. Mai 2017. Infrastrukturen auf der ganzen Welt waren von dieser Sicherheitslücke betroffen; bei Unternehmen unterschiedlicher Größe wurden Server und Computer mit einer Ransomware-Variante namens „Cryptolocker“ infiziert. LautIBM X-Forcebelief sich der gemeldete Gesamtschaden allein durch den WannaCry-Vorfall auf über 8 Milliarden US-Dollar in 150 Ländern. Ich denke, das spricht für sich: Wenn Sie Ihre eigenen Daten und Server verwalten, können Sie selbst bestimmen, wann und welche Patches installiert werden. Bei einem Drittanbieter haben Sie keine Ahnung, was dieser tut. Deshalb ist dies eine wichtige Frage, die Sie jedem Drittanbieter stellen sollten, dessen Einsatz Sie in Erwägung ziehen.
Es gab Fälle, in denen uns mitgeteilt wurde, dass das Netzwerk oder die Datenbank ordnungsgemäß segmentiert sei – zumindest laut den Personen, mit denen wir gesprochen haben. Als wir uns einige Zeit später erneut bei ihnen meldeten, konnten wir nachweisen, dass dies nicht der Fall war. Anwendungen, bei denen die Vorproduktions- und die Produktionsversion auf demselben Server wie die „ordnungsgemäß segmentierte“ Datenbank gespeichert waren. Die tatsächliche Segmentierung der Datenbank bestand jedoch lediglich darin, dass es sich um zwei separate Zweige innerhalb derselben Datenbank handelte. Das bedeutete, dass die in der Vorproduktionsanwendung entdeckte SQL-Injection auch zu einer vollständigen Kompromittierung der Produktionsdatenbank führte. Dies wurde auch bei Multi-Tenant-Systemen beobachtet, bei denen die Daten mehrerer Unternehmen alle in derselben Datenbank gespeichert sind.