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]

Was ist die eine Sache, die alle Anwendungen haben? Komponenten, auch bekannt als Abhängigkeiten oder Bibliotheken. Es gibt nur sehr wenig Code auf der Welt, der nicht irgendwann von anderem Code abhängt. Sie beginnen sogar mit einem Berg von Abhängigkeiten ab dem Zeitpunkt, an dem Sie die Anwendung erstellen!

Da alle Anwendungen Komponenten verwenden, von denen Sie die meisten nicht geschrieben haben, können Schwachstellen in den von Ihnen verwendeten Komponenten zu Verbindlichkeiten werden. Lassen Sie uns besprechen, was die Verwendung von Komponenten mit bekannten Schwachstellen bedeutet, wie gefährlich sie ist und wie man sie beheben kann.

Die Verwendung von Komponenten mit bekannten Schwachstellen verstehen

Jede komplexe Software hat Schwachstellen. Das liegt in der Natur der Sache. Ihre Komponenten werden also nie 100 % sicher sein. Wenn jedoch Schwachstellen in Komponenten gefunden werden, wissen Sie dann davon? Sind Sie darauf vorbereitet?

Probleme treten am häufigsten auf, wenn Komponenten über ihre Nutzungsdauer hinaus verwendet werden oder nachdem Sicherheitslücken gefunden wurden. Die meisten Komponenten und Bibliotheken veröffentlichen Patches für Sicherheitslücken zur gleichen Zeit oder früher als die Schwachstelle bekannt gegeben wird. Wenn Sicherheitslücken in Komponenten entdeckt und bekannt gegeben werden, ist es daher von größter Bedeutung, die Komponenten so schnell wie möglich zu aktualisieren. Lassen Sie anfällige Software nicht in der Produktion.

Komponenten können aus verschiedenen Quellen stammen. Manchmal kaufen Sie Produkte von Drittanbietern, die sich direkt in Ihren benutzerdefinierten Code integrieren. Diese Komponenten werden zu einem Teil Ihres Codes und arbeiten auf der gleichen Berechtigungsebene. Eine weitere Quelle sind Open-Source-Projekte, die auf Websites wie GitHub gehostet werden. Offene Quellen können gefährlich sein, da nicht alle Open-Source-Bibliotheken sorgfältig geprüft oder auf Schwachstellen untersucht worden sind.

Angreifer nutzen die Informationen über Sicherheitslücken in Komponenten zu ihrem Vorteil. Da die Schwachstellen öffentlich bekannt gegeben werden, wissen Angreifer zur gleichen Zeit wie Sie von den Schwachstellen. Angreifer verfügen auch über Techniken, mit denen sie herausfinden können, welche Komponenten Sie verwenden. Sobald sie diese Informationen kennen, wissen sie, wie sie Ihre Anwendung angreifen können, wenn sie nicht gepatcht ist.

Wissen, warum anfällige Komponenten gefährlich sind

Wenn Sie nach einem Beweis dafür suchen, wie gefährlich die Verwendung von Komponenten mit bekannten Schwachstellen ist, suchen Sie nicht weiter als die Equifax-Verletzung von 2017.

Im Juli 2017 entdeckte Equifax, eine US-amerikanische Kreditauskunftei, eine massive Datenpanne, durch die die persönlichen Daten von über 147 Millionen Menschen bekannt wurden. Der Umfang und die Auswirkungen dieser Datenpanne sind beispiellos. Kürzlich wurden Nachrichten über die laxen Sicherheitspraktiken von Equifax bekannt.

Eine dieser laxen Praktiken war das Patch-Management. Equifax hatte keine gute Patch-Management-Praxis, was bedeutete, dass ihre Komponenten eine ganze Weile nicht gepatcht wurden. Dies war die direkte Ursache für die Sicherheitsverletzung.

Die Website von Equifax verwendete das Apache Struts-Webframework. Einige Monate bevor sich die Angreifer in das Netzwerk hackten, wurde eine Schwachstelle im Struts-Framework gefunden, Apache Struts CVE-2017-5638. Equifax hat die Sicherheitslücke jedoch nicht gepatcht. Die Angreifer nutzten diese Schwachstelle, um sich Zugang zum Netzwerk von Equifax zu verschaffen. Von dort aus verschafften sie sich Zugang zu einer Fundgrube persönlicher Daten.

Viele Websites basieren auf Web-Frameworks, die nicht vom Unternehmen selbst geschrieben wurden. Dies ist gängige Praxis, da es ein zu großes Unterfangen wäre, alle notwendigen Funktionen von Grund auf neu einzubauen. Die starke Abhängigkeit von einem Framework kann Sie jedoch für Sicherheitslücken öffnen. Werden Sie nicht das nächste Equifax.

So schützen Sie sich vor gefährdeten Komponenten

Es gibt kein Patentrezept zum Schutz vor der Verwendung anfälliger Komponenten. Es gibt jedoch Richtlinien und Kontrollen, mit denen Sie das Risiko verringern können, dass anfällige Komponenten zur Kompromittierung Ihrer Systeme verwendet werden.

Sie müssen wissen, welche Komponenten und welche Version der einzelnen Komponenten Sie zum Erstellen Ihrer Anwendungen verwenden. Tools zur Verwaltung von Abhängigkeiten, wie z. B. Dependency Check von OWASP, helfen Ihnen, die von Ihnen verwendeten Abhängigkeiten in den Griff zu bekommen. Dependency Check sagt Ihnen auch, ob eine dieser Komponenten eine öffentlich bekannte Schwachstelle aufweist.

Eine Patch-Management-Methodik ist ebenfalls unerlässlich. Wenn Schwachstellen entdeckt werden, muss ein System vorhanden sein, mit dem die Patches reibungslos heruntergeladen, getestet und für die Produktion freigegeben werden können. Wenn Sie Ihre Software gepatcht halten, verhindern Sie, dass Monate alte Schwachstellen von Angreifern ausgenutzt werden.

Schließlich sollten Sie über Richtlinien verfügen, die die Verwendung von Open-Source- und Drittanbieter-Komponenten regeln. Entwickler mögen keinen bürokratischen Aufwand, und das ist auch verständlich. Es muss jedoch einen Prüfprozess für Code geben, der nicht von Ihrem Unternehmen geschrieben wurde. Er muss nicht schwergewichtig sein, ist aber ein Muss, um zu verhindern, dass unbekannte Komponenten verwendet werden. Zumindest muss ein Inventar der verwendeten Komponenten aktuell gehalten werden.

Lassen Sie sich nicht von der Drittanbieter-Wanze anstecken

Komponenten werden Schwachstellen haben. Ihre Geschäftsanwendungen werden Komponenten verwenden, ob von einem Anbieter oder aus einer Open-Source-Bibliothek. Das bedeutet nicht, dass Ihr Unternehmen anfällig für Angriffe sein muss.

Auch wenn Angreifer zur gleichen Zeit wie Sie wissen, welche Schwachstellen existieren, werden Patches in der Regel zur gleichen Zeit wie die öffentlichen Ankündigungen zur Verfügung gestellt. Informieren Sie sich also unbedingt darüber, was Ihre Anwendung verwendet. Wissen Sie, was verwundbar ist. Halten Sie Ihre Komponenten gepatcht!

Sind Sie bereit, einige verwundbare Komponenten zu entdecken (und zu besiegen)? Begeben Sie sich in die Arena und nehmen Sie den Kampf auf: [Hier starten]

Ursprünglich veröffentlicht auf dem DevSecCon-Blog.

Da ich auf beiden Seiten des Zauns gestanden habe, kenne ich nur zu gut die Spannungen, die zwischen dem Entwicklungsteam und den AppSec-Spezialisten entstehen können, wenn es um die Einhaltung von Best Practices in Sachen Sicherheit geht.

Es ist schwierig, denn am Ende des Tages ist die oberste Priorität eines Entwicklers die Bereitstellung von Softwarefunktionen. Sie müssen schön und funktional sein und die Leistungsfähigkeit der Anwendung demonstrieren. Mit den heutzutage üblichen agilen Entwicklungspraktiken müssen diese Funktionen innerhalb strenger Fristen fertiggestellt werden... und die Sicherheit steht selten ganz oben auf der Liste der Bedenken, wenn so viel anderes auf dem Spiel steht.

Sicherheit wird als Domäne des AppSec-Teams angesehen, das die wenig beneidenswerte Aufgabe hat, Code zu scannen (oder schlimmer noch: ihn manuell, Zeile für Zeile, zu überprüfen) und dem Entwicklungsteam mitzuteilen, dass ihr Code unsicher oder sogar völlig unbrauchbar ist. Sie sind die Stöpsel im Dreck, die ihre gute Arbeit zerpflücken, Innovationen aufhalten und den Entwicklern allgemein Kopfschmerzen bereiten. Am Ende des Tages sind viele Sicherheitsprobleme recht einfach zu beheben " vielleicht kann eine einzige Codezeile eine verwundbare Hintertür in Minutenschnelle verstärken.

Aber, hier ist das Problem. Da "Sicherheit" so sehr ein Synonym für eine negative Erfahrung ist, beschäftigen sich Entwickler einfach nicht so intensiv damit, wie sie es sollten. Diese einzeiligen Fixes passieren nicht: Schließlich stoßen die AppSec-Leute immer wieder auf die gleichen Probleme. Es muss ziemlich verrückt für sie sein, immer noch auf SQL-Injection-Fehler hinzuweisen, mehr als zwanzig Jahre nachdem wir sie zum ersten Mal entdeckt haben (und ihren anschließenden Fix).

Was wir bisher getan haben, funktioniert nicht annähernd so effektiv, wie wir gehofft hatten. Wir müssen uns darauf konzentrieren, die Brücke zwischen Entwicklern und AppSec-Spezialisten zu reparieren und eine positive Sicherheitskultur anzustreben, in der Entwicklern die Werkzeuge und Schulungen an die Hand gegeben werden, um in diesem Bereich wirklich etwas bewirken zu können.

Wer weiß? Vielleicht verlieben sie sich sogar darin, so wie ich es tat!

Positive Sicherheit ist der schnellste und einfachste Weg zur Verbesserung der Anwendungssicherheit

ity " und nein, es ist kein Hokuspokus über immaterielle Ergebnisse. Es ist eine absolut wichtige Zutat im Erfolgsrezept der sicheren Codierung.

Entwickler halten den Schlüssel zur Verbesserung der Sicherheit von Beginn der Produktion an in der Hand, indem sie von vornherein sicheren Code schreiben. Durch die Schaffung einer positiven Sicherheitskultur und die Begeisterung der Entwickler für die Anwendungssicherheit können häufige Schwachstellen ausgemerzt werden, bevor sie es überhaupt zu einem Scan oder einer manuellen Codeprüfung im AppSec-Land schaffen.

Es ist dreißigmal teurer, Schwachstellen in bereits implementiertem Code zu beheben. Daher ist die Suche nach einer Schulung, die die Stärken der Entwickler nutzt, das Interesse aufrecht erhält und tatsächlich funktioniert, ein großer Schritt zur zukünftigen Kostenreduzierung bei der Identifizierung und Behebung dieser wiederkehrenden Schwachstellen.

Positive, entwicklerorientierte Initiativen fördern die richtige Sicherheitskultur.

Wenn alle mit den Best Practices für Sicherheit auf einer Wellenlänge liegen, ist eine positive Sicherheitskultur ein glückliches, vitales Nebenprodukt.

Positive, skalierbare, entwicklerorientierte Initiativen fördern die richtige Sicherheitskultur. Es ist wichtig, die problemlösenden und kreativen Köpfe der Entwickler anzusprechen, um sie für sich zu gewinnen und sicherzustellen, dass neue Mitarbeiter sich schnell mit den Sicherheitserwartungen des Teams vertraut machen können. Nehmen Sie Kontakt auf, um einen Überblick über die Entwicklung der Beziehung zwischen Entwicklern und Sicherheit zu erhalten und um Ideen für die Einführung eines erfolgreichen Security Awareness-Programms in Ihrem Unternehmen zu erhalten.

In diesem Blog werden wir eines der häufigsten Probleme behandeln, mit denen Organisationen konfrontiert sind, die entweder Websites betreiben oder Mitarbeitern den Fernzugriff auf Computerressourcen erlauben - was so ziemlich jeder ist. Und ja, Sie haben wahrscheinlich erraten, dass wir über Authentifizierung sprechen werden.

Wenn sich ein Hacker einfach als Administrator mit einem gültigen Benutzernamen und Kennwort bei einem System anmelden kann, ist es nicht notwendig, fortschrittliche Techniken zur Bekämpfung der Netzwerkabwehr einzusetzen. Das System öffnet einfach die Tür und lässt den Angreifer hinein. Schlimmer noch: Wenn der Angreifer nichts allzu Ausgefallenes tut, ist es fast unmöglich, seine Anwesenheit zu entdecken, da die meisten Verteidigungssysteme ihn einfach als gültigen Benutzer oder Administrator ansehen, der seine Arbeit macht.

Die Kategorie der Authentifizierungsschwachstellen ist recht umfangreich, aber wir gehen auf die häufigsten Probleme ein, die dazu neigen, versehentlich in die Anmeldeprozesse der Benutzer eingebettet zu werden. Indem Sie diese Löcher stopfen, können Sie die große Mehrheit der Authentifizierungsprobleme in Ihrem Unternehmen beseitigen.

In dieser Folge lernen wir:

• Wie einige gängige Authentifizierungsschwachstellen ausgenutzt werden
• Warum sie so gefährlich sind
• Welche Richtlinien und Techniken zur Beseitigung von Authentifizierungsschwachstellen eingesetzt werden können.

Wie nutzen Angreifer Authentifizierungsschwachstellen aus?

Es gibt eine ganze Reihe von Sicherheitslücken bei der Authentifizierung, die sich in ein Authentifizierungssystem einschleichen können, so dass Hacker jede davon ein wenig anders ausnutzen. Lassen Sie uns zunächst die häufigsten Schwachstellen durchgehen und dann anhand von Beispielen zeigen, wie ein paar davon ausgenutzt werden könnten.

Zu den häufigsten Schwachstellen bei der Authentifizierung gehören:

• Schwache oder unzureichende Passwortrichtlinien haben,
• Unbegrenzte Anmeldeversuche zulassen,
• Weitergabe von Informationen über fehlgeschlagene Anmeldungen an einen Angreifer,
• Senden von Anmeldedaten über unsichere Kanäle,
• Schwaches Hashing von Passwörtern,
• Und mit einem unsicheren Passwort-Wiederherstellungsprozess.

Eine schwache Passwortrichtlinie ist wahrscheinlich die häufigste Schwachstelle. Wenn Benutzer Passwörter ohne Einschränkungen erstellen dürfen, werden viel zu viele von ihnen leicht zu erratende Passwörter verwenden. Jedes Jahr veröffentlichen verschiedene Computer-Nachrichtenorganisationen eine Liste der am häufigsten verwendeten Kennwörter, und "123456" und "password" sind immer unter den ersten fünf. Es gibt aber auch andere. Administratoren verwenden sehr gerne "Gott". Diese sind zwar alle entweder witzig oder leicht zu merken, aber auch sehr leicht zu erraten. Hacker kennen die gängigsten Kennwörter und versuchen sie zuerst, wenn sie versuchen, in ein System einzudringen. Wenn diese Art von Kennwörtern in Ihrer Organisation erlaubt ist, werden auch Sie irgendwann geknackt werden.

Eine weniger offensichtliche, aber dennoch gefährliche Schwachstelle ist die Rückmeldung an einen Benutzer über eine fehlgeschlagene Anmeldung. Das ist schlecht, denn wenn Sie eine Meldung zurückgeben, wenn ein Benutzername nicht existiert, und eine andere, wenn ein Benutzername existiert, aber das Passwort falsch ist, können Angreifer gültige Benutzer auf einem System ausfindig machen und sich auf das Erraten von Passwörtern nur für diese Benutzernamen konzentrieren. Wenn dies mit der Authentifizierungsschwachstelle kombiniert wird, die unbegrenztes Erraten von Passwörtern erlaubt, würde es Angreifern ermöglichen, Wörterbuchangriffe gegen alle gültigen Benutzer auszuführen, die sie gefunden haben, was sie ziemlich schnell in ein System bringen könnte, wenn das Passwort leicht zu erraten ist.

Warum sind Authentifizierungsschwachstellen so gefährlich?

Es gibt eine klassische Geschichte aus dem amerikanischen Wilden Westen über einen paranoiden Siedler, der an seiner Haustür dreifache Schlösser anbrachte, seine Fenster mit Brettern verbarrikadierte und mit vielen Gewehren in Reichweite schlief. Am nächsten Morgen wurde er tot aufgefunden. Seine Angreifer waren an ihn herangekommen, weil er vergessen hatte, die Hintertür zu verschließen. Mit Authentifizierungsschwachstellen verhält es sich ähnlich. Es spielt wirklich keine Rolle, welche Art von Überwachungstools oder proaktiven Kontrollen Sie einsetzen oder wie viele Experten Sie beschäftigen, wenn ein Angreifer einen gültigen Benutzernamen und ein Passwort verwenden kann, um in Ihr Netzwerk einzudringen.

Wenn der Angreifer erst einmal drin ist, gibt es nur sehr wenige Einschränkungen, was er tun kann. Solange er im Rahmen seiner Benutzerrechte agiert, die ziemlich umfangreich sein können, wenn er ein Administratorkonto kompromittiert hat, ist die Chance sehr gering, dass er rechtzeitig erwischt wird, um ernsthafte Probleme zu verhindern. Das macht die Klasse der Authentifizierungsschwachstellen zu einer der gefährlichsten Schwachstellen auf jedem System.

Beseitigung von Schwachstellen bei der Authentifizierung

Eine der besten Möglichkeiten, um Authentifizierungsschwachstellen in einem Netzwerk zu beseitigen, sind gute, global durchgesetzte Passwortrichtlinien. Benutzer, sogar Administratoren, sollten nicht nur keine Passwörter wie "password" verwenden, sondern auch gezwungen werden, ein Maß an Komplexität hinzuzufügen, das es für einen Angreifer unmöglich macht, einen Angriff mit einem Wörterbuch oder allgemeinen Phrasen durchzuführen. Sie können Ihre eigenen Regeln für die Erstellung von Passwörtern basierend auf der Wichtigkeit des zu schützenden Systems aufstellen. Auf diese Weise wird es für Angreifer viel schwieriger, Passwörter zu erraten oder zu erzwingen.

Sie sollten auch die Anzahl der fehlgeschlagenen Anmeldeversuche begrenzen, so dass der Benutzer gesperrt wird, wenn ein falsches Passwort mehr als, sagen wir, drei Mal eingegeben wird. Die Sperre kann temporär sein, da schon eine Verzögerung von wenigen Minuten die Fortsetzung automatischer Wörterbuchangriffe verhindert. Oder sie kann dauerhaft sein, es sei denn, das Konto wird von einem Administrator entsperrt. In jedem Fall sollte das Sicherheitspersonal alarmiert werden, wenn eine solche Sperrung auftritt, damit es die Situation überwachen kann.

Eine weitere gute Möglichkeit, Angreifer am Sammeln von Informationen zu hindern, besteht darin, eine generische Meldung zu erstellen, wenn entweder ein falscher Benutzername oder ein falsches Passwort eingegeben wird. Sie sollte für beide Fälle gleich sein, damit Hacker nicht wissen, ob sie abgewiesen wurden, weil ein Benutzer nicht existiert oder weil sie das falsche Passwort haben.

Authentifizierungsschwachstellen gehören zu den häufigsten und gefährlichsten auf den meisten Systemen. Aber sie sind auch relativ leicht zu finden und zu beseitigen.

Weitere Informationen über Sicherheitslücken bei der Authentifizierung

Für weitere Lektüre können Sie einen Blick auf den OWASP-Authentifizierungs-Spickzettel 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 .

Treten Sie vor und stellen Sie sich einer Sicherheitslücke bei der Authentifizierung in der Plattform Secure Code Warrior : [Hier starten]

Stellen Sie sich vor, Sie gehen zur Tür einer alten Flüsterkneipe oder eines Underground-Clubs. Das kleine Loch in der Tür gleitet auf und ein stämmiger Türsteher fragt nach dem Passwort. Der potenzielle Besucher kennt das Passwort nicht und rät es. Es ist falsch, also lässt der Türsteher ihn nicht hinein.

Das ist das, was normalerweise passieren würde. Nun stellen Sie sich vor, dass der Besucher, der das falsche Passwort erraten hat, es sofort noch einmal versucht, sich irrt und ihm erneut der Zugang verweigert wird. Dann stellen Sie sich vor, dass der potenzielle Besucher das Wörterbuch öffnet und anfängt, Wörter vorzulesen, beginnend mit etwas wie "Erdferkel" und fortfahrend, jedes einzelne mögliche Wort zu versuchen.

Höchstwahrscheinlich würde der Türsteher diese Art von Aktivität nicht zulassen, aber Websites und Anwendungen mit unzureichendem Automatisierungsschutz tun genau das. Sie lassen es zu, dass Benutzer immer wieder Passwörter ausprobieren, sogar unter Verwendung von Automatisierungstechniken, bis sie schließlich über das richtige Schlagwort stolpern.

In dieser Folge lernen wir:

• Wie Angreifer unzureichenden Automatisierungsschutz ausnutzen
• Warum Anwendungen mit unzureichender Anti-Automatisierung gefährlich sind
• Techniken, die diese Sicherheitslücke beheben können.

Wie nutzen Angreifer eine unzureichende Anti-Automation aus?

Der Einsatz von Automatisierungs- oder wörterbuchähnlichen Angriffen, wie sie unser imaginärer Speakeasy-Besucher durchgeführt hat, ist in der Cybersicherheit nicht neu. Tatsächlich waren diese Brute-Force-Angriffe einige der ersten Hackertechniken, die jemals eingesetzt wurden. Und da Computer immer schneller wurden, wurden sie auch immer effizienter. Ein schneller Computer kann ein ganzes Wörterbuch in nur wenigen Minuten durchlaufen, je nach Geschwindigkeit der Verbindung zwischen dem Angriffsrechner und dem Zielsystem.

Diese Art von automatisierten Angriffen war der Grund, warum Anti-Automatisierungssoftware und -techniken entwickelt wurden. Sie gibt Anwendungen die Möglichkeit, festzustellen, ob die von einem Benutzer durchgeführten Aktionen außerhalb der Normen des typischen menschlichen Verhaltens liegen.

Wenn eine Anwendung keine ausreichenden Anti-Automatisierungsprüfungen hat, können Angreifer einfach so lange Passwörter erraten, bis sie eine Übereinstimmung finden. Oder sie verwenden Automatisierungssoftware, um andere Dinge zu tun, wie z. B. Spam-Kommentare in Website-Foren.

Warum ist unzureichende Anti-Automatisierung gefährlich?

Es kann gefährlich sein, böswilligen Benutzern zu erlauben, Automatisierung einzusetzen, um zu versuchen, die Sicherheit zu umgehen. Der Grund dafür, dass sich Angriffe vom Typ "Automatisierung" seit den Anfängen der Computertechnik bis heute gehalten haben, ist, dass sie sehr effektiv sein können. Wenn Sie einem Automatisierungsprogramm unbegrenzt viel Zeit geben, um Passwörter ohne Konsequenzen für ein falsches Erraten einzureichen, wird es schließlich das richtige finden.

Wenn sie in einem Forum verwendet werden, können Wellen von offensichtlich geskripteten Kommentaren gültige Benutzer frustrieren oder sogar wie eine Art Denial-of-Service-Attacke wirken, indem sie Systemressourcen verschwenden. Automatisiertes Posten könnte auch als Werkzeug für einen Phishing- oder anderen Angriff verwendet werden, um die Köder so vielen Menschen wie möglich zu präsentieren.

Behebung unzureichender Anti-Automatisierungsprobleme

Um das Problem der unzureichenden Anti-Automatisierung zu beheben, müssen alle Anwendungen in die Lage versetzt werden, festzustellen, ob die durchgeführten Aktionen von einem Menschen oder einer Automatisierungssoftware ausgeführt werden. Eine der populärsten und am weitesten verbreiteten Techniken ist der Completely Automated Public Turing test to tell Computers and Humans Apart, oder CAPTCHA.

Das CAPTCHA ist im Grunde ein Turing-Test, der erstmals 1950 von dem Informatiker Alan Turing vorgeschlagen wurde und mit dem menschliches und Computerverhalten getrennt und identifiziert werden kann. Moderne CAPTCHAs stellen Probleme dar, die Menschen leicht lösen können, mit denen Computer aber Schwierigkeiten haben oder die sie einfach nicht lösen können. Ein beliebtes Beispiel ist ein Foto, das durch ein Raster getrennt ist und den Benutzer auffordert, alle Sektoren zu identifizieren, auf denen ein bestimmtes Element zu sehen ist, z. B. eine Blume oder ein Gesicht. Der Computer kann nicht verstehen, wonach er gefragt wird, und kann daher nicht einmal versuchen, das Bild zu scannen. Selbst wenn er es könnte, ist die Bilderkennung für die meisten Programme, die nicht speziell dafür entwickelt wurden, nicht möglich.

Andere Beispiele für CAPTCHAs sind das Anzeigen von verschwommenem Text, das Stellen einer einfachen Logikfrage oder sogar das laute Abspielen der Frage. Die Implementierung einer CAPTCHA-Herausforderung an kritischen Stellen in einer Anwendung, wie z. B. bei der Abfrage eines Passworts, kann Automatisierungsprogramme in ihren Bahnen stoppen.

Es ist auch möglich, Automatisierungsprogramme zu stoppen, indem man einfach die Anzahl der falschen Ratschläge von derselben Quelle begrenzt. Wenn zu viele falsche Schätzungen eingesendet werden, kann das Konto vorübergehend gesperrt werden, wodurch das Automatisierungsprogramm über den Punkt der Nützlichkeit hinaus verzögert wird, oder es könnte sogar ein menschlicher Administrator erforderlich sein, um es zu entsperren. Auf diese Weise sollten Schwachstellen in der Automatisierung innerhalb einer Anwendung vermieden werden.

Mehr Informationen über Insufficient Anti-Automation

Zur weiteren Lektüre können Sie einen Blick darauf werfen, was OWASP über unzureichende Anti-Automatisierung 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 einer Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Sind Sie bereit, eine unzureichende Anti-Automatisierung zu finden und zu beheben, jetzt? Testen Sie Ihre Fähigkeiten in unserer Spiel-Arena: [Hier starten]

Im Gegensatz zu den meisten anderen Schwachstellen, die wir in dieser Share & Learn-Reihe behandelt haben, sind Probleme mit der Geschäftslogik nicht direkt mit Codierungsfehlern verbunden. Obwohl Codierungsprobleme Teil des Problems sein können, sind Geschäftslogikfehler am häufigsten das Ergebnis von Designfehlern oder falschen logischen Annahmen bei der ersten Erstellung einer App.

Probleme mit der Geschäftslogik können auftreten, wenn ein Benutzer bei der Verwendung einer Anwendung eine unerwartete Aktion ausführt. Das kann fast alles sein - von der unerwarteten Stornierung einer Bestellung über die zu häufige Anwendung eines Gutscheincodes bis hin zum einfachen Überspringen eines erwarteten Schritts und einer Aktion, die die Anwendung nicht zu bewältigen weiß. Für das Ausnutzen von Fehlern in der Geschäftslogik ist nicht einmal eine Schulung erforderlich, sondern nur ein böswilliger Benutzer mit einem wissbegierigen Geist, der bereit ist, über den Tellerrand zu schauen.

In dieser Folge lernen wir:

• Wie Angreifer Schwachstellen in der Geschäftslogik ausnutzen
• Warum Anwendungen mit Fehlern in der Geschäftslogik gefährlich sind
• Techniken, die Fehler in der Geschäftslogik verhindern können.

Wie nutzen Angreifer Probleme in der Geschäftslogik aus?

Im Gegensatz zu den meisten Exploits können wir nicht auf bestimmte Code-Strings hinweisen, die diese Schwachstelle verursachen könnten. Stattdessen kommt es darauf an, dass Benutzer Aktionen ausführen, die nicht vorhergesehen wurden und mit denen die Programme nicht umgehen können. Nehmen wir als Beispiel an, dass eine Bankanwendung es Benutzern ermöglicht, Geld auf andere Konten zu überweisen. Doch anstatt Geld zu überweisen, versucht ein böswilliger Benutzer, einen negativen Betrag auf ein anderes Konto zu überweisen. Wie wird die Bankanwendung reagieren? Wird sie abstürzen? Wird sie die Überweisung verweigern? Oder schickt sie vielleicht sogar Geld an den Benutzer zurück, der die Überweisung initiiert hat, um den negativen Betrag auszugleichen?

E-Commerce-Websites sind besonders, wenn auch nicht ausschließlich, anfällig für Fehler in der Geschäftslogik, da sie für die Interaktion mit vielen Benutzern konzipiert sind und viele Komponenten haben. Benutzer, die Bestellungen unerwartet stornieren, versuchen, einzelne Gutscheine mehrfach anzuwenden, oder sogar ihre Einkaufswagen überladen, können Anwendungen vor Bedingungen stellen, die nicht vorhergesehen wurden. Es gibt wirklich keine Möglichkeit zu wissen, wie ein Programm reagieren wird, wenn es mit einer unbekannten Situation konfrontiert wird. Im besten Fall wird eine Fehlermeldung generiert, aber es gibt keine Garantie dafür, dass eine App nicht eine noch schlimmere Aktion durchführt, wie z. B. das kostenlose Anbieten von Waren.

Warum sind Business-Logik-Probleme gefährlich?

Probleme in der Geschäftslogik können extrem gefährlich sein, weil sie von jedem ausgenutzt werden können, sogar von jemandem, der keine Programmier- oder Hackerausbildung hat. Es erfordert wirklich nur Experimentierfreude und Zeit, herumzuklicken und zu versuchen, Fehler in der Art und Weise zu finden, wie eine Anwendung reagieren soll. Und sobald ein böswilliger Benutzer eine Schwachstelle in der Geschäftslogik einer Website entdeckt, können Sie darauf wetten, dass er sie so weit wie möglich ausnutzen wird.

Die größte Gefahr ist normalerweise finanzieller Natur, wenn ein Benutzer 20 Großbildfernseher kauft, ohne dafür zu bezahlen, oder etwas Ähnliches. Aber Fehler in der Geschäftslogik können auch andere Probleme verursachen. Wenn z. B. die Kennwortfunktion, die eine Website schützt, nicht weiß, was zu tun ist, wenn ein Benutzer ständig auf "Abbrechen" drückt, könnte sie ihn den Anmeldevorgang ganz umgehen lassen.

Es gibt wirklich keine Möglichkeit, vorherzusehen, wie viel Schaden ein Problem mit der Geschäftslogik anrichten könnte. Oft kommt der erste Hinweis auf ein Problem lange nachdem die Benutzer es ausgenutzt haben.

Probleme mit der Geschäftslogik beheben

Leider hilft der Einsatz gängiger Tools wie Schwachstellen-Scanner nicht dabei, Probleme mit der Geschäftslogik zu identifizieren oder zu beheben, da sich das Testen auf Probleme mit der Geschäftslogik nicht einfach automatisieren lässt. Der beste Weg, sie zu vermeiden, ist die Implementierung einer guten Planung, Fehlerbehandlung und Prüfung für negative Testfälle während der Entwicklung einer Anwendung. Dies erfordert zunächst einen klar definierten Satz von Geschäftsregeln, der alle möglichen und gewünschten Aktionen enthält, die eine Anwendung ausführen soll.

Eine der besten Möglichkeiten, um zu verhindern, dass sich Fehler in der Geschäftslogik einschleichen, besteht darin, ein Flussdiagramm zu erstellen, das alle möglichen Wege aufzeigt, auf denen Daten und Transaktionen innerhalb einer Anwendung fließen sollen. Dazu gehört die Modellierung des Verhaltens für jede Instanz, in der ein Benutzer eine Auswahl treffen oder Daten eingeben kann. Überprüfen Sie ständig, ob die möglichen Aktionen im Flussdiagramm mit den Funktionen im Geschäftsregelplan übereinstimmen.

Verwenden Sie schließlich die Bedrohungsmodellierung, um Schwachstellen in der Geschäftslogik während der Entwurfs-, Implementierungs- und Testphasen zu identifizieren. Erstellen Sie als Ausfallsicherung eine Aktion, die das Programm ausführen soll, wenn es auf eine Situation stößt, die nicht ausdrücklich vorhergesehen wurde. Dies könnte so einfach sein wie die Verweigerung der Aktion und die Benachrichtigung eines Administrators über das aufgetretene Problem.

Weitere Informationen zu Business Logic Problems

Für weitere Lektüre können Sie einen Blick auf die OWASP-Seiten zu Problemen mit der Geschäftslogik 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 .

Sind Sie bereit, jetzt Schwachstellen in der Geschäftslogik zu suchen und zu beseitigen? Gehen Sie auf die Plattform und testen Sie Ihre Fähigkeiten: [Hier starten]

Heutzutage ist es üblich, dass Websites und Anwendungen den Benutzern erlauben, Feedback, Terminerinnerungen und verschiedene andere Informationen über eine Anwendung per E-Mail zu senden. Normalerweise ist dieser Vorgang ziemlich harmlos, und die meisten Leute denken nicht einmal über ein potenzielles Sicherheitsrisiko nach.

Wie jedes andere Designelement, das Benutzereingaben zulässt, können jedoch auch diese scheinbar unbedeutenden Funktionen, wenn sie nicht richtig konfiguriert sind, von böswilligen Benutzern für schändliche Zwecke manipuliert werden. Es genügt, dem Benutzer die Möglichkeit zu geben, Code in das Eingabefeld einzugeben, der dann fälschlicherweise vom Server verarbeitet wird. Plötzlich kann eine E-Mail-Anwendung zur Waffe werden.

In dieser Folge lernen wir:

• Wie Angreifer eine E-Mail-Header-Injection auslösen können
• Warum E-Mail-Header-Injektionen gefährlich sind
• Techniken, die diese Sicherheitslücke beheben können.

Wie lösen Angreifer eine E-Mail-Header-Injection aus?

Obwohl es nicht oft als programmierbar angesehen wird, können die meisten E-Mail-Kontaktanwendungen oder Funktionen, die in Websites oder Anwendungen eingebaut sind, Eingaben akzeptieren, die die Art der Abfrage ändern. Dies geschieht normalerweise automatisch durch den Server, nachdem ein Benutzer seine Informationen, wie z. B. seine E-Mail-Adresse, in das Vertragsfeld eingegeben hat. Das Programm konfiguriert dann die Nachricht, fügt die entsprechenden Empfänger hinzu und sendet die Nachricht über seinen Standard-E-Mail-Server.

Eine typische E-Mail-POST-Anfrage könnte wie folgt aussehen:

POST /contact.php HTTP/1.1
Host: www.example.com

Und generieren Sie Code, der so aussieht, nachdem ein Benutzer seine Informationen eingegeben hat:

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

Das Problem tritt auf, wenn Hacker beginnen, Code in den Prozess zu injizieren, anstatt nur ihre Kontaktdaten. Dies ist einem Angriff vom Typ SQL-Injection nicht unähnlich, richtet sich aber gegen die E-Mail-Anwendung. Ein Beispiel für eine manipulierte Abfrage, die stattdessen Spam aus Ihrer Anwendung an einen gezielten Benutzer senden würde, könnte so aussehen:

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed Nachricht

Warum ist Email Header Injection gefährlich?

Abhängig von der Geschicklichkeit des böswilligen Benutzers und seinen Absichten können E-Mail-Header-Injection-Angriffe in Bezug auf den Schweregrad von einfach nur lästig bis hochgefährlich reichen. Am unteren Ende der Schweregradskala könnten sie in der Lage sein, ihre Kontaktinformationen in das BCC-Feld einer ausgehenden Nachricht einzufügen, die an ein geheimes oder nicht bekannt gegebenes Postfach innerhalb Ihres Unternehmens gesendet wurde, und sie so einem Hacker zu offenbaren.

Noch bedenklicher ist, dass es ihnen erlauben könnte, Ihren E-Mail-Server vollständig zu kontrollieren, um Spam-, Phishing- oder andere Angriffs-E-Mails von Ihrer Organisation aus zu versenden. Sie bräuchten nicht zu versuchen, die Tatsache vorzutäuschen, dass die E-Mail von Ihren internen Servern kommt, da sie tatsächlich von dort stammen würde. Und wenn Sie diese Aktivitäten nicht überwachen, können sie den Prozess sogar automatisieren und Hunderte oder Tausende von E-Mails über die Server Ihres Unternehmens versenden, und zwar so, dass es so aussieht, als würden Sie diese Aktivitäten tatsächlich veranlassen.

Eliminierung des E-Mail-Header-Injection-Problems

Wie bei SQL-Injection und anderen Angriffen dieser Art liegt der Schlüssel zum Ausschluss der Möglichkeit, dass ein böswilliger Benutzer eine E-Mail-Header-Schwachstelle ausnutzt, darin, den Benutzereingaben niemals zu vertrauen. Wenn ein Benutzer in der Lage ist, Informationen einzugeben, selbst wenn es sich um einen scheinbar trivialen Vorgang wie die Eingabe seiner E-Mail-Adresse handelt, müssen Sie vom Schlimmsten ausgehen. Oder zumindest davon ausgehen, dass das Schlimmste möglich ist.

Die Eingabevalidierung sollte für alle Parameter durchgeführt werden, auch beim Hinzufügen einer E-Mail-Kontaktmöglichkeit zu einer App oder Website. Whitelisting kann verwendet werden, um gezielt Prozesse und Felder zu aktivieren, die Sie als gültig erachten, während alles andere verweigert wird. Die meisten Frameworks verfügen über Bibliotheken, die dabei helfen können, Funktionen nur auf die benötigten zu beschränken. Auf diese Weise wird verhindert, dass Code oder Befehle, die von böswilligen Benutzern eingegeben werden, von Ihren Servern erkannt und verarbeitet werden.

Weitere Informationen über E-Mail-Header-Injektionen

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über E-Mail-Header-Injektionen sagt. 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-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, eine E-Mail-Injection zu finden und zu beheben? Gehen Sie auf die Plattform und testen Sie Ihre Fähigkeiten: [Hier starten]