Denjenigen, die diese Blogserie lesen, werden viele Ähnlichkeiten zwischen der Sicherheitsanfälligkeit für die entfernte Dateieinbindung und der zuvor besprochenen Sicherheitsanfälligkeit für die lokale Dateieinbindung und Pfadüberwindung auffallen. Ihre Ursachen sind ähnlich, ebenso wie die empfohlenen Korrekturen.

In vielerlei Hinsicht ist die Sicherheitslücke bei der Einbindung entfernter Dateien viel gefährlicher und auch leichter auszunutzen als ihr Gegenstück bei lokalen Dateien. Als solche sollte sie so schnell wie möglich gefunden und behoben werden. Oder besser noch, Webanwendungen sollten so gestaltet werden, dass sie gar nicht erst auftreten.

In dieser Folge lernen wir:

• Wie Hacker die Remote File Inclusion-Schwachstelle ausnutzen
• Warum das Zulassen der Einbindung entfernter Dateien gefährlich ist
• Techniken, die dieses Problem beheben können.

Wie nutzen Angreifer die Remote File Inclusion aus?

Die Sicherheitsanfälligkeit durch Remote-Dateieinbindung nutzt den Befehl oder Mechanismus "Dynamic File Include" aus, der in den meisten Programmier-Frameworks vorhanden ist. Diese Fähigkeit soll es Entwicklern ermöglichen, Dateien, die sich auf einem sekundären Server befinden, zur Ausführung von Aktivitäten auf dem Anwendungsserver zu verwenden. Natürlich kann dies in den falschen Händen gefährlich sein.

Angreifer nutzen diese Fähigkeit aus, indem sie eine beliebige Website oder Anwendung finden, die unkontrollierte Benutzereingaben zulässt, die z. B. aus HTTP-Headern oder Eingabebereichen in interaktiven Formularen stammen können. Sie verwenden dies als Ausgangspunkt, um Datei-Include-Befehle zu generieren.

Wenn eine Website beispielsweise die GET-Funktion zum Laden von Seiten verwendet, z. B. page = request.getParameter("page'); include page; dann könnte ein Angreifer eine Abfrage mit dem page-Befehl senden, jedoch mit der URL einer von ihm kontrollierten Website und dem Dateipfad zu der Datei, die er ausführen möchte. Die Abfrage wird dann an den Server weitergeleitet und die Remote-Datei wird auf dem Host ausgeführt. Die Aktivität ist erlaubt, da sie nun Teil der vertrauenswürdigen App ist.

Warum ist die Sicherheitslücke "Remote File Inclusion" so gefährlich?

Der Grad der Gefahr, die von Remote File Inclusion ausgeht, ist extrem hoch. Anders als bei lokalen Dateieinbindungs-Schwachstellen, bei denen Dateien, die ein Angreifer ausführt, auf einem Host vorhanden sein müssen und vom Angreifer auch durch Ausprobieren gefunden werden müssen, gibt es bei der entfernten Dateieinbindung keine derartigen Einschränkungen. Natürlich kennt ein Angreifer den Speicherort der Dateien, die er ausnutzen möchte, da sie wahrscheinlich auf seinen eigenen Rechnern oder auf von ihm kontrollierten Websites vorhanden sind. Die Dateien können auch von ihnen selbst ausgewählt werden und müssen vor dem Exploit nicht auf dem Zielcomputer vorhanden sein. Die Datei kann sogar aus Skripten bestehen, die speziell für die Ausnutzung eines entfernten Hosts geschrieben wurden.

Kurz gesagt: Sobald ein Angreifer in der Lage ist, eine Remote File Inclusion-Schwachstelle zu finden und auszunutzen, gibt es nichts, was ihn daran hindert, die vollständige Kontrolle über eine Anwendung oder sogar eine ganze Website zu erlangen. Sicherlich werden keine dort gespeicherten Daten vor ihrem Eindringen sicher sein.

Beseitigung der Sicherheitsanfälligkeit "Remote File Inclusion

Lassen Sie niemals zu, dass Benutzereingaben direkt an einen Datei-Einbindungsbefehl zur Ausführung übergeben werden. Verwenden Sie stattdessen eine indirekte Referenz-Map von Befehlen und führen Sie Befehle nur von dort aus. Eine indirekte Referenz-Map ordnet nicht vertrauenswürdige Benutzereingaben einem Satz von fest kodierten vertrauenswürdigen Werten auf dem Server zu. Stellen Sie sicher, dass Sie alle Bereiche, in denen Benutzer Daten eingeben können, auf eine Whitelist setzen, und vergessen Sie nicht, HTTP-Header, Formularparameter und sogar Cookies in diese Liste aufzunehmen. Dadurch wird jedes Fenster geschlossen, das ein Angreifer zum Erstellen eines Datei-Include-Befehls nutzen kann.

Als Bonus wird die korrekte Bereinigung und Validierung von benutzergenerierten Inhalten und die Verwendung von Referenzkarten zur Ausführung von Befehlen nicht nur die entfernte Dateieinschluss-Schwachstelle beseitigen, sondern auch einige andere, einschließlich des gefährlichen Cousins dieses Fehlers, des lokalen Dateieinschluss- und Pfadüberquerungs-Exploits.

Weitere Informationen über Remote File Inclusion

Als weitere Lektüre können Sie einen Blick auf den OWASP-Referenzleitfaden für Remote File Inclusion Exploits werfen. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Im Gegensatz zu vielen anderen Schwachstellen erfordert das Ausnutzen lokaler Dateieinschluss- und Pfadüberquerungsprozesse für schändliche Zwecke einen ausreichend geschickten Angreifer, eine gehörige Portion Zeit und vielleicht auch ein bisschen Glück. Das soll nicht heißen, dass diese Sicherheitsanfälligkeit ignoriert werden kann. Geschickte Angreifer können sie nutzen, um interne Dateien gegen eine Organisation zu wenden, eine Verzeichnisstruktur abzubilden oder sogar Kennwort- und Benutzerinformationen zu stehlen, die für gefährliche sekundäre Angriffe verwendet werden können.

In dieser Folge lernen wir:

• Wie Hacker lokale File-Inclusion- und Path-Traversal-Schwachstellen ausnutzen
• Warum das Zulassen von uneingeschränkter lokaler Dateieinbindung und Pfadüberquerung gefährlich sein kann
• Richtlinien und Techniken, die eingesetzt werden können, um dieses Problem zu finden und zu beheben.

Wie nutzen Angreifer lokale Dateieinbindung und Pfadumgehung aus?

Der klassische TV-Detektiv Columbo pflegte immer zu sagen: "Nur noch eine Sache", kurz bevor er eine wertvolle Information lieferte, die den vorliegenden Fall aufklären würde. Es schien zu diesem Zeitpunkt belanglos und wurde fast immer vom Verdächtigen ignoriert, erwies sich aber immer als sein Verhängnis. Die Sicherheitslücken "Local File Inclusion" und "Path Traversal" ähneln dem sehr.

Die Schwachstellen "Local File Inclusion" und "Path Traversal" nutzen den dynamischen Datei-Include-Mechanismus, der in den meisten Programmier-Frameworks wie ASP-, JSP- und PHP-Skripten existiert. Bei der lokalen Dateieinbindung schiebt ein Angreifer den Namen einer Datei, die auf dem lokalen Server existiert, in einen Bereich in einer Webanwendung, z. B. in eine Kopfzeile oder einen Formulareingabebereich. Die Anwendung verarbeitet die Haupteingabe wie gewohnt, aber auch den include(page) oder ähnlichen Befehl. Beim Path Traversal definiert der Angreifer den Pfad zu einer verdächtigen Datei, wobei er normalerweise die Zeichen Punkt, Punkt und Schrägstrich (../) als Variablen verwendet. Ähnlich wie bei Columbo ist dem Hacker der erste Teil des Arguments völlig egal. Es ist einfach ein Mittel für sie, um "nur noch eine Sache" am Ende hinzuzufügen.

In beiden Fällen muss der Angreifer normalerweise eine beträchtliche Menge an Versuch und Irrtum durchführen. Wenn er nicht sehr gut mit der Struktur der Website vertraut ist, kann das Erraten von Pfadkonfigurationen und Dateinamen sehr lange dauern. Allerdings folgen die meisten Websites bestimmten Mustern und haben mehr oder weniger ähnliche Verzeichnisse und Dateinamen. Es könnte also nicht so lange dauern, wie Sie denken. Und da die Auszahlung potenziell sehr lukrativ ist, gibt es einen großen Anreiz für Hacker, zu versuchen, lokale Dateieinschlüsse und Pfadüberquerungsschwachstellen auszunutzen, sobald sie gefunden wurden.

Warum sind lokale Dateieinschlüsse und Pfadüberquerungsschwachstellen gefährlich?

Lokale Dateieinschluss- und Pfadüberquerungsschwachstellen sind gefährlich, da sie Angreifern den Zugriff auf sensible oder kritische Dateien ermöglichen können. Bei Datendateien besteht die Gefahr, dass der Hacker etwas Wertvolles wie Benutzerpasswörter oder andere persönliche Informationen erlangen könnte. Ein primäres Ziel sind oft Passwort- oder Benutzerkonfigurationsdateien, da diese den Zugriff auf den Rest der Website ermöglichen würden. Datenbanken sind ebenfalls ein Hauptziel. Lokale Dateieinbindung und Pfadüberquerungsschwachstellen könnten es einem Angreifer im schlimmsten Fall ermöglichen, den gesamten Inhalt einer Datenbank zu stehlen.

Bei ausführbaren Dateien besteht die Gefahr darin, dass ein Angreifer durch den Zugriff auf diese Dateien bösartige Aktivitäten durchführen kann, z. B. einen Teil einer Website zerstören oder sogar eine Art internen Denial-of-Service-Angriff durchführen kann, indem er Systemressourcen verschwendet. Das volle Ausmaß der Gefahr wird jedoch nur durch den Einfallsreichtum und die Fähigkeiten des Angreifers sowie durch die Dateien begrenzt, auf die er zugreifen kann und die bereits auf dem Zielserver vorhanden sind.

Beseitigung der Bedrohung durch lokale Dateieinbindung und Pfadumgehung

Die Gefahr, die von lokalen File-Inclusion- und Path-Traversal-Schwachstellen ausgeht, kann mit guten Cybersecurity-Praktiken beseitigt werden. Das Wichtigste ist, niemals Benutzereingaben in "file include" oder andere Befehle mit ähnlichen Funktionen zuzulassen. Wenn eine Anwendung sie zulassen muss, geben Sie sie nicht direkt weiter. Verwenden Sie stattdessen eine indirekte Referenz-Map. Eine indirekte Referenz-Map nimmt Benutzereingaben auf und ordnet sie einer Reihe von fest kodierten vertrauenswürdigen Werten zu, die dann sicher verwendet werden können.

Wie bei vielen anderen Schwachstellen sollten Sie besonders auf alle benutzergesteuerten Eingabebereiche wie Cookies, HTTP-Header und Formularparameter achten. Erlaubte Eingaben sollten auf einer Whitelist stehen, alles andere sollte explizit verweigert werden. Wo dies nicht möglich ist, verwenden Sie die Eingabevalidierung, um streng zu regeln, welche Werte erlaubt sind, wie z. B. Zahlen, alphanumerische Werte usw.

Weitere Informationen zu Local File Inclusion und Path Traversal

Als weitere Lektüre können Sie einen Blick auf den OWASP-Testleitfaden für lokale Dateieinschlüsse und Path Traversal Exploits werfen. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Selbst wenn Sie einen Anwendungsserver und die von ihm verwendeten Backend-Systeme vollständig abgesichert haben, ist die Kommunikation möglicherweise immer noch anfällig für Schnüffeleien, wenn die Transportschicht nicht ausreichend geschützt ist. In der physischen Welt ist der Grund, warum harte Währung mit gepanzerten Fahrzeugen transportiert wird, der Schutz während des Transports. Es spielt wirklich keine Rolle, wie sicher ein Geschäft oder eine Bank ist, wenn das Geld, das sie generiert, in einen Golfwagen geladen wird, um durch die Stadt zu fahren.

Das Gleiche gilt für Transportschichten im Cyber-Bereich. Selbst wenn eine Anwendung sicher ist, gibt es immer noch eine kritische Schwachstelle, wenn die Informationen, die dort ankommen, ungeschützt gesendet werden. Und es gibt eine zweite Schwachstelle bei einigen Anwendungen, wenn sie zusätzlich Informationen an andere Server oder eine Datenbank senden. Diese Informationen können von Insidern eingesehen werden, die kein Recht haben, diese Transaktionen auszuspionieren.

Um Benutzer und Daten vollständig zu schützen, muss die Transportschicht geschützt werden. Nur so können Sie eine gesamte Transaktion von Ende zu Ende vollständig absichern.

In dieser Folge lernen wir:

• Wie Hacker einen unzureichenden Schutz der Transportschicht ausnutzen können
• Warum es so gefährlich ist, die Transportschicht nicht zu schützen
• Was kann getan werden, um den Transport aller Daten, die sich in und durch eine Anwendung oder einen Server bewegen, zu sichern.

Wie nutzen Angreifer einen unzureichenden Schutz der Transportschicht aus?

Ein unzureichender Schutz der Transportschicht kann Angriffe an zwei Stellen innerhalb Ihres Datenstroms ermöglichen. Die am häufigsten ausgenutzte Stelle befindet sich zwischen einem Benutzer und dem Anwendungsserver. Wenn Informationen unverschlüsselt oder mit schwacher Verschlüsselung gesendet werden, können Hacker diese Informationen überwachen, stehlen und möglicherweise ändern. Auf diese Weise könnten Hacker die Kreditkarte eines Benutzers, seine Anmeldedaten oder alles andere, was an den Anwendungsserver gesendet wird, stehlen. Selbst wenn der Server selbst sicher ist, könnte ein Hacker, der den unsicheren Kanal zwischen ihm und den Benutzern überwacht, nahezu uneingeschränkten Zugriff auf eine Vielzahl von Informationen erhalten.

Der zweite Punkt, der oft ungeschützt bleibt, ist die Transportschicht zwischen einer Anwendung und dem Rest des Netzwerks. Zum Beispiel könnte ein Anwendungsserver Online-Einkaufsbestellungen verarbeiten und sie dann an ein Fulfillment-System weiterleiten, oder Daten könnten einfach an eine Datenbank zur Speicherung ausgelagert werden. Wenn diese internen Kanäle ungeschützt sind, können interne Benutzer diese Informationen möglicherweise sehen.

Es ist zwar schön zu glauben, dass alle internen Benutzer gute Menschen sind, aber Tatsache ist, dass Insider-Bedrohungen in vielen Branchen auf dem Vormarsch sind. Insider wurden schon dabei erwischt, wie sie Bestechungsgelder annahmen, um im Gegenzug sensible Informationen für Angreifer oder Konkurrenten zu sammeln. Und Zugang zu etwas wie Tausenden von gültigen Kreditkarten zu haben, könnte für einige Leute einfach zu verlockend sein, um es zu ignorieren.

Was die Angriffstechniken betrifft, so ist es nicht sehr schwierig, ungeschützte Kommunikation abzufangen. Selbst Hacker auf niedrigem Niveau wissen, wie man Man-in-the-Middle-Angriffe gegen unverschlüsselte Datenströme durchführt. Wenn sie es nicht wissen, gibt es im Internet Videos, mit denen sie es in weniger als einer halben Stunde lernen können.

Warum sind unzureichende Transport Layer Protection-Schwachstellen so gefährlich?

Ein unzureichender oder nicht vorhandener Schutz auf den Transportschichten ist gefährlich, weil er es Hackern extrem leicht macht, sensible Informationen zu sammeln. Sie müssen nicht in Ihren App-Server einbrechen oder Ihr Netzwerk hacken. Sie richten einfach einen Man-in-the-Middle-Angriff ein und lesen alles mit, was von Benutzern an einen Server gesendet wird. Dies kann Benutzernamen und Kennwörter enthalten, die dazu verwendet werden können, die Sicherheit in Zukunft mit gültigen Anmeldeinformationen zu umgehen. Je nach Anwendung kann dies auch Kreditkarteninformationen oder andere persönliche Daten von Benutzern enthalten.

Und es ist wichtig zu beachten, dass all diese Schnüffelei außerhalb Ihres Netzwerks stattfindet. Wenn Sie unsichere Transportkanäle verwenden, gibt es keine Möglichkeit zu wissen, ob jemand diese Informationen abfängt. Normalerweise ist das erste Anzeichen, wenn viele Benutzer anfangen, über kompromittierte Konten oder Kreditkartenkäufe zu berichten, und der gemeinsame Faktor ist Ihre Anwendung " kein guter Ort, um sich dort aufzuhalten. Hacker können auch Informationen verändern, sobald sie sie haben, z. B. die Lieferadresse ändern oder sogar bösartige Skripte in die Serverantwort einfügen, bevor sie diese an die Benutzer weitergeben.

Auf dem Backend werden durch die fehlende Absicherung der Transportschicht Daten für Insider offengelegt. Es ist wahrscheinlich viel unwahrscheinlicher, dass ein Insider die Transportschicht ausspäht, als dass Hacker von außen das Gleiche tun. Aber es ist auch gefährlicher, wenn es passiert, weil die Insider-Bedrohung nicht nur die Benutzerdaten sehen kann, sondern auch alle proprietären Informationen, die vom App-Server hinzugefügt werden, bevor diese Pakete weitergeschickt werden.

Beseitigung von Schwachstellen durch unzureichenden Schutz der Transportschicht

So gefährlich ein unzureichender Schutz der Transportschicht auch sein kann, es ist auch nicht unglaublich schwierig, alle Ihre Transportkanäle richtig abzusichern. Es beginnt mit der Backend-Infrastruktur. Diese sollte ausschließlich HTTPS sein, achten Sie darauf, HTTPS und HTTP auf einer Seite nicht zu mischen. Schließlich sollten Sie ein gültiges SSL-Zertifikat mit einer minimalen Schlüsselgröße von 2048 Bit vorhalten und alle Benutzer zwingen, mit gesicherten Browsern mit HTTP Strict Transport Security (HSTS) zu interagieren.

Sobald die Infrastruktur vorhanden ist, sollten Entwickler ein starkes Protokoll zum Schutz der Transportschicht verwenden. Idealerweise sollte TLS 1.2 verwendet werden, obwohl TLS 1.1 und 1.0 auch akzeptabel sind, wenn es absolut notwendig ist. Sobald das eingerichtet ist, sollten schwache Protokolle wie SSLv2 vollständig deaktiviert und niemals unterstützt werden.

Es sollte auch darauf geachtet werden, dass die kryptografischen Chiffren am Backend ausreichend leistungsfähig sind. Idealerweise sollte die minimale Sitzungsschlüsselgröße 128 Bit betragen. Wie bei den Protokollen sollte die Unterstützung für schwache kryptografische Algorithmen wie DES und RC4-40 deaktiviert werden. Und schließlich sollten Sie eine Anwendung erst dann als wirklich sicher betrachten, wenn sowohl der Server selbst als auch alle Datenpfade, die zu ihm hin und von ihm weg führen, ausreichend geschützt sind.

Weitere Informationen zu Schwachstellen mit unzureichendem Schutz der Transportschicht

Als weiterführende Lektüre können Sie einen Blick in den OWASP-Leitfaden zum Schutz von Transportschichten werfen. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

XML-Injection-Angriffe sind fiese kleine Exploits, die von Hackern erfunden wurden, um Systeme zu kompromittieren, die XML-Datenbanken hosten. Dazu gehören die Dinge, die einem in den Sinn kommen, wenn man an traditionelle Datenbanken denkt - detaillierte Informationsspeicher über alles Mögliche, von Medikamenten bis zu Filmen. Einige XML-Datenspeicher werden auch dazu verwendet, autorisierte Benutzer zu überprüfen, sodass durch das Einfügen von neuem XML-Code in diese Datenbanken neue Benutzer erstellt werden können, die das Host-System von diesem Zeitpunkt an akzeptiert.

Damit ein Angreifer eine XML-Injection implementieren kann, muss eine Anwendung vorhanden sein, die auf eine XML-Datenbank angewiesen ist oder zumindest darauf zugreift. Immer wenn dies der Fall ist und die Benutzereingaben nicht ordnungsgemäß überprüft werden, kann dem Datenspeicher neuer XML-Code hinzugefügt werden. Je nach Geschick des Angreifers kann das Hinzufügen von neuem XML-Code ziemlich viel Schaden anrichten oder sogar Zugriff auf die gesamte Datenbank ermöglichen.

Wenn Sie weiter lesen, werden Sie feststellen, dass XML-Injection eng mit den SQL-Injection-Angriffen verwandt ist, die wir zuvor behandelt haben. Denn obwohl sie auf unterschiedliche Arten von Datenbanken abzielen, sind sie sich extrem ähnlich. Und zum Glück sind auch die Abhilfemaßnahmen ähnlich. Wenn Sie lernen, wie Sie einen Angriff abwehren können, haben Sie einen großen Vorsprung, wenn es darum geht, den anderen zu verhindern.

In dieser Folge lernen wir:

• Wie XML-Injektionen funktionieren
• Warum sie so gefährlich sind
• Wie Sie Verteidigungsmaßnahmen ergreifen können, um sie vollständig zu stoppen.

Wie lösen Angreifer XML-Injektionen aus?

XML-Injektionen sind immer dann erfolgreich, wenn ein nicht autorisierter Benutzer in der Lage ist, XML-Code zu schreiben und diesen in eine bestehende XML-Datenbank einzufügen. Damit dies funktioniert, sind nur zwei Dinge erforderlich: eine Anwendung, die sich auf eine XML-Datenbank stützt oder mit ihr verbunden ist, und ein ungesicherter Datenpfad, über den der Angreifer seinen Angriff starten kann.

XML-Injektionen sind fast immer erfolgreich, wenn die Benutzereingabe nicht bereinigt oder anderweitig eingeschränkt wird, bevor sie zur Verarbeitung an einen Server gesendet wird. Dies kann es Angreifern ermöglichen, ihren eigenen Code zu schreiben oder am Ende des normalen Query-Strings zu injizieren. Wenn dies erfolgreich ist, wird der Server dazu verleitet, den XML-Code auszuführen, wodurch er Datensätze hinzufügen oder löschen oder sogar eine ganze Datenbank offenlegen kann.

Hacker implementieren einen XML-Injection-Angriff, indem sie XML-Code zu einer normalen Abfrage hinzufügen. Dies kann alles sein, von einem Suchfeld bis hin zu einer Anmeldeseite. Es kann sogar Dinge wie Cookies oder Header enthalten.

In einem Registrierungsformular könnte ein Benutzer z. B. den folgenden Code nach dem Feld für den Benutzernamen oder das Kennwort hinzufügen:

<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>

In diesem Beispiel würde ein neuer Benutzer namens "John_Smith" mit Administratorrechten erstellt. Wenigstens wendet der neue Benutzer gute Regeln für die Kennwortdichte an. Schade, dass er eigentlich ein Angreifer ist.

Hacker müssen nicht unbedingt immer einen solchen Homerun landen, um mit XML-Injections erfolgreich zu sein. Durch die Manipulation ihrer Abfragen und die Aufzeichnung der verschiedenen Fehlermeldungen, die der Server zurückgibt, können sie unter Umständen die Struktur der XML-Datenbank abbilden. Und diese Informationen können verwendet werden, um andere Arten von Angriffen zu verbessern.  

Warum sind XML-Injektionen so gefährlich?

Wie gefährlich ein XML-Injection-Angriff ist, hängt davon ab, welche Informationen in der anvisierten XML-Datenbank gespeichert sind bzw. wie diese Informationen verwendet werden. Im Falle einer XML-Datenbank, die zur Authentifizierung von Benutzern verwendet wird, kann eine XML-Injection einem Angreifer Zugriff auf das System verschaffen. Es könnte ihm sogar ermöglichen, Administrator im angegriffenen Netzwerk zu werden, was natürlich eine äußerst gefährliche Situation darstellt.

Bei XML-Injections, die sich gegen herkömmlichere Datenbanken richten, besteht die Gefahr darin, dass diese Informationen gestohlen werden, dass dem Speicher falsche Daten hinzugefügt werden oder dass möglicherweise gute Daten überschrieben werden. XML-Code ist nicht sehr schwer zu erlernen und einige der Befehle können extrem mächtig sein und ganze Informationsfelder überschreiben oder sogar den Inhalt eines Datenspeichers anzeigen.

Generell baut niemand eine Datenbank auf, wenn die dort gespeicherten Informationen keinen Wert haben. Hacker wissen das, weshalb sie es oft auf sie abgesehen haben. Wenn diese Daten Dinge wie persönliche Informationen über Mitarbeiter oder Kunden enthalten, kann eine Kompromittierung zu Reputationsverlust, finanziellen Konsequenzen, hohen Geldstrafen oder sogar Klagen führen.  

Stoppen von XML-Injektionsangriffen

XML-Injections sind aufgrund des geringen Schwierigkeitsgrads und der weiten Verbreitung von XML-Datenbanken relativ häufig. Aber diese Angriffe gibt es schon seit langem. Daher gibt es einige unumstößliche Fixes, die verhindern, dass sie jemals ausgeführt werden können.

Eine der besten Methoden zum Stoppen der Angriffe besteht darin, eine Anwendung so zu gestalten, dass sie nur vorkompilierte XML-Abfragen verwendet. Dadurch wird die Funktionalität der Abfragen auf eine autorisierte Teilmenge von Aktivitäten beschränkt. Alles, was mit zusätzlichen Argumenten oder Befehlen kommt, die nicht mit den vorkompilierten Abfragefunktionen übereinstimmen, wird einfach nicht ausgeführt. Wenn Sie nicht ganz so restriktiv sein wollen, können Sie auch Parametrisierung verwenden. Diese schränkt die Benutzereingabe auf bestimmte Abfrage- und Datentypen ein, z. B. nur auf Ganzzahlen. Alles, was außerhalb dieser Parameter liegt, wird als ungültig betrachtet und führt dazu, dass die Abfrage fehlschlägt.

Es ist auch eine gute Idee, vorkompilierte oder parametrisierte Abfragen mit angepassten Fehlermeldungen zu verbinden. Anstatt die standardmäßigen, beschreibenden Fehlermeldungen einer fehlgeschlagenen Abfrage zurückzusenden, sollten Anwendungen diese Antworten abfangen und durch eine allgemeinere Meldung ersetzen. Idealerweise wollen Sie dem Benutzer mitteilen, warum die Abfrage fehlgeschlagen ist, ihm aber keine Informationen über die Datenbank selbst geben. Wenn Sie diese benutzerdefinierten Meldungen auf einige wenige Auswahlmöglichkeiten beschränken, können Hacker keine nützlichen Informationen aus fehlgeschlagenen Abfragen zusammenstellen.

XML-Injektionen waren sehr erfolgreich, als sie zum ersten Mal entwickelt wurden. Aber wenn man bedenkt, wie lange das schon her ist, können wir heute ganz einfach Schutzmaßnahmen konstruieren, die nicht mehr durchbrochen werden können.

Mehr Informationen über XML Injections

Weitere Informationen finden Sie im OWASP-Artikel über XML-Injektionen. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber Warriors ausbildet. Weitere Informationen über die Beseitigung dieser Sicherheitslücke und einer Reihe anderer Bedrohungen finden Sie im BlogSecure Code Warrior .

Während wir die Themen in diesen Blogs untersucht haben, haben wir einige gefährliche Schwachstellen und bösartige Exploits aufgedeckt, die Hacker einsetzen, um Netzwerke anzugreifen und Abwehrmaßnahmen zu umgehen. Die Bandbreite reicht vom Ausnutzen von Schwachstellen in Programmiersprachen über das Einschleusen von Code in verschiedenen Formaten bis hin zum Abfangen von Daten während der Übertragung. Es gibt eine ganze Reihe von Bedrohungen, aber immer, wenn eine von ihnen erfolgreich ist, gibt es oft eine gemeinsame Komponente in den Anwendungen ihrer Opfer.

Unzureichende Protokollierung und Überwachung ist eine der gefährlichsten Bedingungen, die innerhalb der Verteidigungsstruktur einer Anwendung bestehen können. Wenn diese Schwachstelle oder Bedingung existiert, dann wird fast jeder fortgeschrittene Angriff, der gegen sie durchgeführt wird, letztendlich erfolgreich sein. Eine unzureichende Protokollierung und Überwachung bedeutet, dass Angriffe oder Angriffsversuche für eine sehr lange Zeit nicht entdeckt werden, wenn überhaupt. Das gibt Angreifern im Grunde die Zeit, die sie brauchen, um eine nützliche Schwachstelle zu finden und auszunutzen.

In dieser Folge lernen wir:

• Wie Angreifer unzureichende Protokollierung und Überwachung nutzen können
• Warum unzureichende Protokollierung und Überwachung gefährlich ist
• Techniken, die diese Sicherheitslücke beheben können.

Wie nutzen Angreifer eine unzureichende Protokollierung und Überwachung aus?

Angreifer wissen zunächst nicht, ob ein System ordnungsgemäß überwacht wird oder ob die Protokolldateien auf verdächtige Aktivitäten untersucht werden. Aber es ist leicht genug für sie, das herauszufinden. Was sie manchmal tun, ist, eine Art von unelegantem Brute-Force-Angriff zu starten, vielleicht indem sie eine Benutzerdatenbank nach häufig verwendeten Kennwörtern abfragen. Dann warten sie ein paar Tage und versuchen die gleiche Art von Angriff erneut. Wenn sie beim zweiten Mal nicht daran gehindert werden, dann ist das ein guter Hinweis darauf, dass niemand die Protokolldateien sorgfältig auf verdächtige Aktivitäten überwacht.

Auch wenn es relativ einfach ist, die Verteidigungsmaßnahmen einer Anwendung zu testen und den Grad der aktiven Überwachung zu messen, ist dies keine Voraussetzung für erfolgreiche Angriffe. Sie können ihre Angriffe einfach so starten, dass sie so wenig Lärm wie möglich machen. In den meisten Fällen bedeutet die Kombination aus zu vielen Alarmen, Alarmmüdigkeit, schlechten Sicherheitskonfigurationen oder einfach einer Fülle von ausnutzbaren Schwachstellen, dass sie genügend Zeit haben werden, ihre Ziele zu erreichen, bevor die Verteidiger überhaupt merken, dass sie da sind.

Warum ist unzureichende Protokollierung und Überwachung gefährlich?

Eine unzureichende Protokollierung und Überwachung ist gefährlich, weil sie Angreifern Zeit gibt, nicht nur ihre Angriffe zu starten, sondern auch ihre Ziele zu erreichen, lange bevor Verteidiger eine Reaktion einleiten können. Wie viel Zeit, hängt vom angegriffenen Netzwerk ab, aber verschiedene Gruppen wie das Open Web Application Security Project (OWASP) beziffern die durchschnittliche Reaktionszeit für angegriffene Netzwerke auf 191 Tage oder länger.

Denken Sie mal einen Moment darüber nach. Was würde passieren, wenn Räuber eine Bank überfallen, die Leute die Polizei rufen und diese ein halbes Jahr braucht, um zu reagieren?

Die Räuber wären längst weg, wenn die Polizei eintrifft. In der Tat kann dieselbe Bank noch viele weitere Male ausgeraubt werden, bevor die Polizei überhaupt auf den ersten Vorfall reagiert.

So ist es auch bei der Cybersicherheit. Die meisten der hochkarätigen Sicherheitsverletzungen, von denen man in den Nachrichten hört, waren keine Einbruchsversuche. Oftmals erfährt das betroffene Unternehmen erst von einer Sicherheitsverletzung, nachdem die Angreifer bereits seit Monaten oder sogar Jahren mehr oder weniger volle Kontrolle über die Daten hatten. Dies macht eine unzureichende Protokollierung und Überwachung zu einer der gefährlichsten Situationen, die beim Versuch, gute Cybersicherheit zu praktizieren, auftreten können.

Unzureichende Protokollierung und Überwachung beseitigen

Um eine unzureichende Protokollierung und Überwachung zu verhindern, sind vor allem zwei Dinge erforderlich. Erstens müssen alle Anwendungen mit der Fähigkeit erstellt werden, serverseitige Eingabevalidierungsfehler mit genügend Benutzerkontext zu überwachen und zu protokollieren, damit Sicherheitsteams die Tools und Techniken, wenn nicht sogar die Benutzerkonten, identifizieren können, die Angreifer verwenden. Oder solche Eingaben sollten in einer Sprache wie STIX (Structured Threat Information eXpression) formatiert werden, die von Sicherheitstools schnell verarbeitet werden kann, um entsprechende Warnungen zu erzeugen.

Zweitens reicht es nicht aus, einfach gute Warnmeldungen zu generieren, obwohl das ein Anfang ist. Unternehmen müssen auch Rollen und Verantwortlichkeiten festlegen, damit diese Warnungen zeitnah untersucht werden. Viele erfolgreiche Einbrüche lösten zwar Warnungen in den angegriffenen Netzwerken aus, aber diese Warnungen wurden nicht beachtet, weil es Fragen der Verantwortung gab. Niemand wusste, wessen Aufgabe es war, zu reagieren, oder ging davon aus, dass sich jemand anderes um das Problem kümmerte.

Ein guter Ausgangspunkt für die Zuweisung von Verantwortlichkeiten ist die Annahme eines Notfall- und Wiederherstellungsplans, wie er vom National Institute of Standards and Technology (NIST) in der Sonderveröffentlichung 800-61 empfohlen wird. Es gibt noch weitere Referenzdokumente, einschließlich solcher, die für verschiedene Branchen spezifisch sind, und sie müssen nicht buchstabengetreu befolgt werden. Aber die Erstellung eines Plans, der festlegt, wer innerhalb einer Organisation auf Alarme reagiert und wie er dies zeitnah tut, ist von entscheidender Bedeutung.

Weitere Informationen über unzureichende Protokollierung und Überwachung

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über unzureichende Protokollierung und Überwachung sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Sind Sie bereit, unzureichende Protokollierung und Überwachung zu finden, zu beheben und sofort zu beseitigen? Gehen Sie zu unserer Trainingsarena: [Hier starten]

Die Codierung einer Website oder Anwendung mit der Fähigkeit, nicht validierte Um- und Weiterleitungen zu verarbeiten, kann sowohl für Ihre Benutzer als auch für Ihr Unternehmen extrem gefährlich sein. Dieser häufige Fehler wird häufig von Hackern ausgenutzt, um Phishing-Betrug zu begehen oder um Zugriff auf Seiten und Informationen zu erhalten, die normalerweise gesperrt sind.

Immer wenn eine Webanwendung so konzipiert ist, dass sie Benutzer auf neue Seiten weiterleitet, besteht die Gefahr, dass diese Anfragen manipuliert oder gekapert werden können. Dies kann passieren, wenn es keinen Validierungsprozess gibt, der verhindert, dass Weiterleitungsparameter auf unbeabsichtigte Ziele zeigen.

Die gute Nachricht ist, dass unvalidierte Um- und Weiterleitungen eine der einfacher zu beseitigenden Schwachstellen in Ihrer Umgebung sind. Einmal entfernt, können Sie mit ein paar einfachen Schritten sicherstellen, dass sie in Zukunft nicht mehr generiert werden.

In dieser Folge lernen wir:

• Wie Hacker unvalidierte Redirect- und Forward-Schwachstellen ausnutzen
• Warum das Zulassen von unvalidierten Um- und Weiterleitungen gefährlich sein kann
• Richtlinien und Techniken, die eingesetzt werden können, um dieses Problem zu finden und zu beheben.

Wie nutzen Angreifer nicht validierte Umleitungen und Weiterleitungen aus?

Angreifer müssen zunächst eine Webanwendung finden, die so eingestellt ist, dass Benutzer auf eine bestimmte Seite oder Seiten weitergeleitet werden. Wenn die Zielseite im Code definiert ist, gibt es keine Sicherheitslücke. In Java wäre dies z. B. eine sichere, vordefinierte Möglichkeit, einen Benutzer an einen neuen Ort zu schicken, ohne dass er irgendwelche Aktionen durchführen muss, wie z. B. auf einen Hyperlink klicken.

response.sendRedirect("http://www.knownsafesite.com");

Die Schwachstelle tritt auf, wenn die Website so programmiert ist, dass sie stattdessen Benutzereingaben für die Weiterleitung akzeptiert, oder wenn der Parameter offen gelassen wird, vielleicht um die Informationen aus einer anderen Quelle zu erhalten. Zum Beispiel könnte ein Entwickler den "url'GET-Parameter" verwenden.

response.sendRedirect(request.getParameter("url"));

Dies bietet zwar mehr Flexibilität, schafft aber auch die Schwachstelle der nicht validierten Um- und Weiterleitungen. Hacker können Informationen nach den Schrägstrichen hinzufügen, um eine Weiterleitung zu einer beliebigen Website auszulösen, vielleicht als Teil einer Phishing-E-Mail. Die Benutzer sehen die vertrauenswürdige Domain im ersten Teil eines Links und merken nicht, dass die Website sie möglicherweise auf die Seite des Hackers weiterleitet.

Warum sind unvalidierte Um- und Weiterleitungen so gefährlich?

Die Gefahr, die durch das Zulassen von unvalidierten Um- und Weiterleitungen entsteht, kann erheblich sein. Für Benutzer besteht die größte Gefahr darin, dass sie Opfer von Phishing-Angriffen werden können. Da sie die Top-Level-URL sehen, ist die Wahrscheinlichkeit größer, dass sie einer Phishing-E-Mail oder einer anderen Kommunikation vertrauen und auf einen Link klicken. Und wenn die Seite, auf die sie umgeleitet werden, wie die echte Seite aussieht, kann die Täuschung ziemlich effektiv sein. Sie geben vielleicht ihren Benutzernamen, ihre Kennwörter oder andere Anmeldedaten weiter und ahnen nicht, dass sie manipuliert werden.

Beseitigung der Bedrohung durch ungültige Weiterleitungen und Weiterleitungen

Ungültige Um- und Weiterleitungen entstehen bereits während der Entwicklung einer Anwendung. Sie können im Nachhinein beseitigt werden, aber der einfachste Weg, sie zu eliminieren, besteht darin, Benutzerparameter oder offene Zeichenketten als Teil einer Um- oder Weiterleitungsfunktion gar nicht erst zuzulassen. Definieren Sie stattdessen die URLs, an die Benutzer weitergeleitet werden, genau, um Variablen zu eliminieren und Angreifern den Handlungsspielraum zu nehmen. Besser noch: Ziehen Sie in Erwägung, überhaupt keine Weiterleitungen und Weiterleitungen zu verwenden.

Wenn es absolut keine Möglichkeit gibt, Variablen als Teil einer Weiterleitung oder eines Weiterleitungsprozesses zu vermeiden, dann muss ein Validierungsprozess eingerichtet werden, um sicherzustellen, dass die Weiterleitung zu einem von mehreren gültigen Zielen führt. Schließlich sollten Sie Mapping-Werte anstelle von tatsächlichen URLs verwenden. Hacker werden stattdessen versuchen, URL-Informationen zu verwenden, und werden wahrscheinlich nicht in der Lage sein, das Mapping-Schema zu erraten, selbst wenn sie vermuten, dass eines verwendet wird.

Weitere Informationen zu nicht validierten Um- und Weiterleitungen

Für weitere Lektüre können Sie einen Blick auf die OWASP-Referenzseiten zu nicht validierten Umleitungen und Weiterleitungen werfen. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Kümmern Sie sich ein für alle Mal um unvalidierte Um- und Weiterleitungen. Wenden Sie Ihr neues Wissen an und testen Sie Ihre Fähigkeiten auf unserer gamifizierten Trainingsplattform: [Hier starten]

Code-Injection-Angriffe gehören zu den häufigsten und auch gefährlichsten Angriffen, denen viele Websites und Anwendungen ausgesetzt sind. Sie variieren sowohl in Bezug auf die Raffinesse als auch auf die Gefahr, die von ihnen ausgeht, aber fast jede Website oder Anwendung, die Benutzereingaben akzeptiert, kann anfällig sein. In der Tat ist diese Art von Angriff eine, mit der sich fast jeder Cybersecurity-Verteidiger irgendwann in seiner Karriere auseinandersetzen muss, und das wahrscheinlich mehrmals.

Ein Code-Injection-Angriff kann immer dann erfolgen, wenn eine Anwendung oder Website Eingaben von Benutzern akzeptiert. Dies kann so einfach sein wie die Bereitstellung einer Suchfunktion oder die Aufforderung an einen Benutzer, seine Identifikationsdaten einzugeben. Der Angriff erfolgt, wenn ein böswilliger Benutzer anstelle einer normalen Texteingabe Code in das offene Feld eingibt. Ihr Ziel ist es, den Server dazu zu bringen, die Eingabe für gültigen Code zu halten und dann beliebige Funktionen auszuführen, die der Angreifer wünscht.

Während Code-Injection-Attacken extrem häufig vorkommen, sind auch die verfügbaren Verteidigungsmaßnahmen, mit denen sie gestoppt werden können, entsprechend. In dieser Folge lernen wir:

• Wie sie funktionieren
• Warum sie so gefährlich sind
• Wie Sie Abwehrmaßnahmen ergreifen können, um sie zu stoppen.

Wie verwenden Angreifer Code Injection?

Obwohl sich die spezifischen Details über Code-Injection-Angriffe je nach verwendeter Programmiersprache ändern, kann jede App oder Website anfällig sein, solange sie einem Benutzer die Eingabe von Daten ermöglicht. Code-Injection-Angriffe wurden bereits für SQL, HTML, XML, CSS und jede andere gängige Programmiersprache ausgelöst.

Zunächst muss ein Angreifer verwundbaren Code innerhalb einer Anwendung finden, normalerweise an einer Stelle, an der Benutzer ihre eigenen Eingaben machen können. Dieser Code nimmt zum Beispiel die PHP-Funktion eval() und gibt sie an einen Benutzer weiter, um sie zu ändern, ohne irgendeine Art von Validierung der Rückgabezeichenfolge.

$myvar = "varname";
$x = $_GET[arg];
eval("\$myvar = \$x;");

Ein geschickter Angreifer könnte leicht eine eigene Zeichenkette an die eval-Funktion anhängen und sogar Systembefehle ausführen, wenn er möchte.

/index.php?arg=1; system(id)

Es ist wichtig zu beachten, dass Code-Injection-Angriffe zwar das Senden von Systembefehlen beinhalten können, aber nicht nur darauf beschränkt sind. Tatsächlich sind Hacker bei Code-Injection-Angriffen nur durch die Funktionalität der Sprache selbst begrenzt. In unserem Beispiel könnte ein Angreifer das Zielsystem so programmieren, dass es fast alles tut, was das PHP-Framework erlaubt.

Warum sind Code-Injection-Angriffe so gefährlich?

Code-Injection-Angriffe sind je nach Geschick des Angreifers potenziell extrem gefährlich. Sie können alles tun, was die Programmiersprache zulässt, was sie auf die gleiche Stufe wie die Programmierer der App stellt. Ein Angreifer könnte praktisch seine eigene App schreiben und sie innerhalb der Zielumgebung ausführen lassen.

Auch weniger erfahrene Angreifer können gefährlich sein. Anstatt ihre eigene Anwendung oder Code-Strings zu schreiben, können sie dem Zielsystem einfach befehlen, vorprogrammierte Malware zu akzeptieren und zu installieren. Dies könnte zu einer Verunstaltung der Website, zu Ransomware-Angriffen oder sogar zur Grundlage für eine Phishing-Kampagne werden, die sich gegen die Benutzer der Website richtet.

Meistens werden Code-Injection-Angriffe verwendet, um Dinge wie Benutzerlisten und Passwörter zu stehlen oder um wertvolle Informationen über ein System zu erhalten, das für weitere Kompromittierungen vorgesehen ist. Aber seien Sie gewarnt: Ein geschickter Programmierer kann mit einem Code-Injection-Angriff fast alles erreichen. Deshalb ist es so wichtig, dass jede potenzielle Instanz davon entdeckt und aus Ihrer Umgebung entfernt wird.

Vertrauen Sie niemandem! (Oder zumindest, nicht Benutzer)

Bei der Beseitigung von Schwachstellen, die durch Code-Injection-Angriffe entstehen, sollte man als erstes überall dort nachsehen, wo Benutzereingaben verlangt oder zugelassen werden. Alles, was von einem Benutzer eingegeben wird, ist unter keinen Umständen vertrauenswürdig. Wenn Sie Benutzereingaben ohne Filterung oder Prüfung zulassen, laden Sie Angreifer im Grunde dazu ein, Ihr System oder sogar Ihr Netzwerk mit einem Freischuss zu kompromittieren.

Obwohl es nicht immer möglich ist, ist der beste Weg, Code-Injection-Angriffe zu vereiteln, zu verhindern, dass Funktionen ausgeführt oder Benutzereingaben direkt interpretiert werden. Vielleicht kann man den Benutzern eine Auswahl an statischen Optionen geben, anstatt ihnen freie Hand bei der Eingabe ihrer eigenen Abfragen zu lassen, wobei die Anwendung so programmiert ist, dass sie nur diese begrenzten Auswahlmöglichkeiten als gültig akzeptiert. Das ist vielleicht nicht immer sinnvoll, aber wo es möglich ist, kann es Code-Injektionen verhindern, bevor sie beginnen.

Für Bereiche, in denen Benutzer ihre eigenen Eingaben machen müssen, müssen diese Daten streng kontrolliert werden. Die Annahme, dass alles ein potenzieller Angriff ist, ist ein guter Ansatzpunkt. Die Durchsetzung von Richtlinien mit geringsten Privilegien, wie z. B. Benutzerzugriff nur zum Lesen, sowohl auf der Client- als auch auf der Serverseite, kann die Ausführung des meisten Codes verhindern.

Die andere gute Verteidigung besteht darin, anwendungsweite Filter und Sanitization für alle Benutzereingaben zu implementieren. Entwickler sind sich der Code-Injection-Angriffe schon seit Jahren bewusst, und es gibt Bibliotheken mit bewährten Filtern für jedes Framework und jede Sprache. Wenn Sie diese Filter anwenden, stellen Sie sicher, dass Sie dies nicht nur auf die offensichtlichen Benutzereingabebereiche oder gegen allgemeine Parameter wie Get- und Post-Befehle tun, sondern auch gegen Cookies und HTTP-Header.

Anwenden einer Korrektur für Code Injection

Wenn Sie unnötige Benutzereingabebereiche aus Ihrer Umgebung entfernen, die Prinzipien der geringsten Privilegien durchsetzen und die neuesten Filter- und Bereinigungs-Tools verwenden, um potenzielle Angriffe zu untersuchen und zu erkennen, können Sie diese gefährliche Schwachstelle ausschalten. Die Einstellung, Benutzereingaben niemals zu vertrauen, wird Ihnen auch in Zukunft gute Dienste leisten. Wenn Sie all das tun, können Sie dieser gefährlichen Art von Angriffen einen Schritt voraus sein.

Als weitere Lektüre können Sie einen Blick auf den OWASP-Artikel über Code-Injektion werfen. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Stellen Sie sich der Code-Injektion, genau jetzt. Nehmen Sie die Herausforderung auf unserer gamifizierten Trainingsplattform an: [Hier starten]

Wenn Sie eine Geschäftsanwendung erstellen, sei es für den internen Gebrauch oder die externe Nutzung durch Ihre Kunden, lassen Sie wahrscheinlich nicht jeden Benutzer jede einzelne Funktion ausführen. Wenn Sie das tun, sind Sie möglicherweise anfällig für eine fehlerhafte Zugriffskontrolle.

Lassen Sie uns einen Blick darauf werfen, was eine defekte Zugriffskontrolle ist, warum sie so gefährlich ist und wie man sie beheben kann.

Defekte Zugriffskontrolle verstehen

Eine fehlerhafte Zugriffskontrolle tritt auf, wenn der Anwendungscode nicht über die richtigen Sicherheits- oder Zugriffsprüfungen verfügt. Es kann auch vorkommen, wenn eine Anwendung in irgendeiner Weise falsch konfiguriert ist und den Zugriff auf Funktionen oder Seiten erlaubt, auf die der Benutzer keinen Zugriff haben sollte.

Wenn Sie die Finanzen Ihres Unternehmens verwalten, haben Sie möglicherweise Zugriff darauf, Geld auf bestimmte Konten einzuzahlen oder Geld zwischen den Konten Ihres Unternehmens zu übertragen. Sie sollten jedoch keinen Zugriff haben, um Geld von diesen Konten abzuheben oder Geld auf andere Konten zu überweisen. Wenn die entsprechenden Zugangskontrollen nicht vorhanden sind, können Ihre Mitarbeiter möglicherweise mehr Funktionen als nötig ausführen.

Diese Prüfungen können entweder innerhalb des Codes oder in Konfigurationsdateien durchgeführt werden. So kann es z. B. XML-Konfigurationsdateien geben, die dem Web Application Framework mitteilen, welche Benutzer auf welche Seiten zugreifen dürfen. Dadurch wird sichergestellt, dass Benutzer nur auf die Funktionen zugreifen können, für die sie berechtigt sind.

Warum eine defekte Zugangskontrolle gefährlich ist

Betrachten Sie dieses Beispiel: Ein Angreifer hat erkannt, dass Ihr Code zur Erstellung von Benutzerkonten manipuliert werden kann, sodass der Angreifer mit einer einfachen Post-Anfrage einen Admin-Benutzer erstellen kann. Er kann eine Anfrage mit dem Benutzernamen und dem Kennwort senden und sie dann unterwegs ändern, um die Rolle "admin" als Parameter in die URL oder in den Text der Anfrage aufzunehmen. Der Angreifer meldet sich bei der Anwendung an und erhält sofort Administratorrechte.

Es muss nicht immer ein böswilliger Angreifer sein, der in ein System eindringt. Ohne angemessene Zugriffskontrollen können sensible Informationen, die nicht zwischen Abteilungen ausgetauscht werden sollten, nach außen dringen. Stellen Sie sich vor, jeder Mitarbeiter im Unternehmen könnte Personalabrechnungsdaten oder Finanzdaten sehen. Was würde passieren, wenn jeder Mitarbeiter sehen könnte, dass Entlassungen aufgrund der schlechten finanziellen Situation des Unternehmens bevorstehen? Dies könnte der Moral und dem Ruf Ihres Unternehmens schaden.

Sensible Informationen von Kunden könnten ebenfalls verloren gehen. Unternehmen speichern oft persönliche Informationen von Kunden, die ihre Dienste nutzen. Achten Sie darauf, dass diese nicht versehentlich aufgrund einer fehlenden Zugriffskontrolle preisgegeben werden. Wenn Ihr System beispielsweise Benutzern die Möglichkeit gibt, ihre Gesundheitsdaten anzufordern, haben sie dann auch die Möglichkeit, die Gesundheitsdaten anderer anzufordern und zu sehen? Wenn die URL eine Kunden-ID-Nummer enthält, könnten Angreifer diese Kunden-ID-Nummer immer wieder inkrementieren, bis sie eine finden, die zu einem anderen Kunden passt, und so dessen persönliche Daten preisgeben.

Defeat Broken Access Control

Die rollenbasierte Zugriffskontrolle (RBAC) ist ein sehr effektives Werkzeug zur Implementierung einer soliden Zugriffskontrolle. Diejenigen, die Active Directory verwenden, sind vielleicht mit der Idee vertraut, Gruppen zu erstellen und den Zugriff auf bestimmte Elemente innerhalb der Gruppe zu gewähren, anstatt auf die Einzelperson. Anwendungen arbeiten auf die gleiche Weise, indem sie Rollen verwenden, um zu definieren, wer was sehen darf.

Dies hat zwei Vorteile. Erstens muss eine Funktion nicht geändert werden, wenn jemand die Administratorrolle verlässt. Wenn jemand vorher Administrator war und jetzt nicht mehr sein soll, dann setzen Sie einfach eine neue Person in die Administratorrolle und entfernen die vorherige Person aus der Rolle. Der Code prüft, ob der Benutzer die Administratorrolle hat, anstatt zu prüfen, ob jeder einzelne Benutzer Zugriff auf eine bestimmte Seite oder Funktion hat.

Der zweite Vorteil ist das Vermeiden eines Wartungsalptraums. Eine Zugriffskontrolle, die so granular ist, dass jede Person Assoziationen mit jeder einzelnen möglichen Funktion oder Seite hat, wird mit der Zeit unmöglich zu verwalten sein. Rollen machen die Dinge viel einfacher, weil mehrere Personen zu einer Rolle hinzugefügt werden können. Eine Rolle kann das gesamte Unternehmen umfassen, während eine andere vielleicht nur fünf Personen hat. Dies macht die Verwaltung der Rollen effizienter, da es weniger Rollen zu verwalten gibt. Ein Unternehmen mit 10.000 Mitarbeitern könnte nur 100 Rollen haben statt der 10.000-fachen Anzahl von Funktionen in Ihrer Anwendung. Recherchieren Sie das von Ihnen gewählte Anwendungsframework, um zu sehen, welche Optionen für eine robuste Zugriffskontrolle bestehen.

Es ist außerdem wichtig, eine Zugriffskontrolle auf Funktionsebene zu verwenden. Schützen Sie den Zugriff auf alle Funktionen, indem Sie von den Benutzern verlangen, dass sie bestimmte Zugriffskontrollprüfungen bestehen. Verwenden Sie das Prinzip der geringsten Privilegien, indem Sie den Zugriff standardmäßig verweigern und nur bei Bedarf freigeben. Es kann schwierig sein, sich daran zu erinnern, die Zugriffskontrolle für jede Funktion zu implementieren. Verwenden Sie eine zentrale Komponente zur Verwaltung und Durchsetzung der Zugriffskontrolle.

Schützen Sie Ihre sensiblen Funktionen

Eine unzureichende Zugriffskontrolle kann Ihre Daten und Ihre Anwendung für Angriffe und Ausbeutung weit offen lassen. Kundendaten, die nicht richtig geschützt sind, können zu einer massiven Datenverletzung führen, die Ihrem Ruf und Ihren Einnahmen schadet.

Eine unzureichende Zugriffskontrolle kann auch zu einer Kontoübernahme führen, wenn Angreifer auf Funktionen zugreifen können, auf die sie keinen Zugriff haben sollten. Verwenden Sie eine angemessene Zugriffskontrolle auf Funktionsebene, und Sie schützen Ihre Anwendung vor böswilligen Angreifern und sogar vor versehentlichen Insidern.

Sie denken, dass Sie den Zugang zur Funktionsebene beherrschen? Sie können sich jetzt der Herausforderung stellen, eine defekte Zugangskontrolle zu reparieren: [Hier starten]

"Lose Lippen versenken Schiffe" war eine Redewendung, die in den Vereinigten Staaten während des Zweiten Weltkriegs populär wurde. In Großbritannien hörte man "Careless talk costs lives". Die Hauptaussage des Sprichworts war, dass unvorsichtiges Sprechen über sensible Informationen von Spionen belauscht werden und zu ernsten Konsequenzen führen konnte.

Das gleiche Prinzip gilt für die Erstellung von Webanwendungen. Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann es für Angreifer einfacher sein, in sie einzubrechen.

In diesem Beitrag erfahren Sie, was Informationsaussetzung ist, warum sie gefährlich ist und wie Sie sie verhindern können.

Verstehen der Informationsexposition

Informationsexposition bezieht sich auf Webanwendungen, die interne Informationen für Personen offenlegen, die sie nicht sehen sollten. Es kann sich auch auf die Offenlegung sensibler Kundeninformationen über Protokolldateien oder die Benutzeroberfläche beziehen. In jedem Fall können Angreifer die gefundenen Informationen nutzen, um Ihre Systeme oder Ihre Benutzer anzugreifen.

Oft ist der erste Schritt für einen Angreifer der Versuch, einen Fehler innerhalb Ihrer Anwendung zu erzeugen. Schlechte Fehlerbehandlung und Webanwendungskonfiguration führt zur Offenlegung von Informationen durch Fehlermeldungen. Was passiert, wenn der Angreifer einen Fehler innerhalb Ihrer Anwendung erzeugt? Wenn eine technische Fehlermeldung erscheint, die technische Details wie einen Stack-Trace enthält, haben Sie zu viele Informationen preisgegeben. Diese Details können beinhalten, welche Datenbank Sie verwenden oder welche Version des Anwendungsservers Sie einsetzen.

Die Offenlegung sensibler Informationen kann auf andere Weise erfolgen. Gibt es versteckte Felder in einem Formular, die sensible Informationen enthalten? Angreifer können einfach die Quelle der Seite einsehen und die Werte sehen.

Kurz gesagt: Informationsexposition tritt auf, wenn Informationen, die Ihre Benutzer nur auf einer Need-to-know-Basis kennen sollten, zu leicht zugänglich gemacht werden.

Verstehen Sie, warum die Exposition gegenüber Informationen gefährlich ist

Was kann ein Angreifer mit den von der Anwendung offengelegten Informationen tun? Wenn die Informationen sensibler Natur sind, könnte ein Angreifer Identitäten oder Benutzeranmeldedaten stehlen. Dies könnte zu finanziellen Schäden, Datenschutzverletzungen und behördlichen Bußgeldern führen

Wenn ein Angreifer Fehlermeldungen verwendet, um Informationen über eine Anwendung zu erhalten, könnten diese Informationen in einem zukünftigen Angriff verwendet werden. Tatsächlich gibt es im OWASP Testing Guide einen ganzen Abschnitt über das Sammeln von Informationen.

Der OWASP Testing Guide ermutigt die Verwendung von Suchmaschinen, um Informationen über Ihre Website herauszufinden, die Sie vielleicht nicht beabsichtigen. Sind zum Beispiel Ihre administrativen Seiten für Suchmaschinen zugänglich? Verwenden Sie die Datei robots.txt, um Suchmaschinen mitzuteilen, dass sie bestimmte Seiten nicht indizieren sollen. Gleichzeitig kann die robots.txt-Datei aber auch Informationen preisgeben. Sensible URLs können sich zuweilen in der robots.txt-Datei befinden. Die Angreifer ziehen die Datei herunter und beginnen, einen Teil der Verzeichnisstruktur der Website zu erfahren.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP-Header, Website-Banner und sogar Kommentare in HTML- und JavaScript-Code können Informationen enthalten, die Angreifer nicht sehen sollten. HTTP-Header können Anwendungsserver und Versionsnummern preisgeben. Angreifer können diese Informationen nutzen, um Exploits zu finden, die gegen diese spezifischen Versionen eingesetzt werden können. Vergewissern Sie sich, dass Sie all die verschiedenen Stellen kennen, an denen Angreifer Ihre Informationen finden könnten, und wie Sie sie angemessen verbergen können.

Beseitigen Sie die Informationsaussetzung

Die Offenlegung von Informationen ist oft ein Problem bei der Konfiguration von Webanwendungen. Viele Anwendungsserver geben standardmäßig Stack Traces in Fehlermeldungen zurück. Stellen Sie sicher, dass Sie diese Einstellung für Produktionsanwendungen ändern, um auf eine generische Fehlerseite umzuleiten, während Sie den Fehler zur Fehlerbehebung protokollieren. Detaillierte Fehlermeldungen sollten niemals an den Browser des Benutzers zurückgegeben werden.

Wenn Sie für die Anwendung notwendige Dateien haben, die sensible Informationen enthalten, stellen Sie sicher, dass eine angemessene Zugriffskontrolle gewährleistet, dass nur die Anwendung selbst diese lesen kann. Deaktivieren Sie die Verzeichnisauflistung auf dem Server und verschieben Sie diese Dateien außerhalb des Web-Root-Verzeichnisses. Dies verhindert, dass Angreifer mit dem Browser über einen Directory-Traversal-Angriff zu der Datei navigieren können.

Protokolle können zum Sammeln von Informationen verwendet werden, wenn sie nicht korrekt konfiguriert sind. Wenn ein Fehler auftritt, protokollieren Sie keine sensiblen Informationen wie Passwörter, Sitzungs-Tokens oder persönlich identifizierbare Informationen (PII). Wenn ein Angreifer Zugriff auf Protokolldateien erhalten könnte, würde er eine Fundgrube an sensiblen Informationen finden, die er stehlen könnte. Protokollieren Sie nicht mehr als nötig, was in der Regel eine Kontokennung, eine detaillierte Fehlermeldung und vielleicht die Methode, in der der Fehler aufgetreten ist, oder die durchgeführte Operation ist. Gehen Sie davon aus, dass Protokolldateien nicht geheim sind und Sie nicht in Versuchung kommen werden, sensible Informationen darin zu platzieren.

Versenken Sie Ihre Web-Apps nicht

Hätten Sie wirklich Informationen durchsickern lassen können, während Sie mit einem Freund sprachen, die direkt zum Verlust eines Schlachtschiffs im Zweiten Weltkrieg führten? Vielleicht nicht. Aber warum das Risiko eingehen? Das ist die Lektion des Sprichworts "Lose Lippen versenken Schiffe".

Ebenso gibt es keinen Grund, die internen Abläufe Ihrer Webanwendung der Außenwelt preiszugeben. Es gibt keinen Grund, ganze Kreditkartennummern oder Passwörter einzusehen. Es gibt keinen Grund, PII-Daten in Protokolldateien zu haben. Tun Sie es also nicht. Schauen Sie sich unsere Lernressourcen an, um mehr über die Offenlegung von Informationen zu erfahren.

Behalten Sie die internen Abläufe Ihrer Anwendungen dort, wo sie hingehören. Versenken Sie Ihre Webanwendungen nicht.

Glauben Sie, dass Sie der Informationsaussetzung jetzt Einhalt gebieten können? Stellen Sie sich der Herausforderung, Krieger: [Hier starten]