Die häufigsten Probleme, die wir in der IT-Sicherheit sehen

Die meisten Produkte, die Sie kaufen, sind auf Netzwerk- und Endpunktsicherheit ausgerichtet. Diese sind nicht sehr wirksam gegen Schwachstellen in Webanwendungen. In diesem Beitrag beleuchten wir daher die häufigsten Probleme, die wir bei unserer Arbeit sehen, von schwachen Netzwerken bis hin zur Benutzeraufzählung. Das Verständnis dieser Herausforderungen ist nicht nur für IT-Experten wichtig, sondern auch für Einzelpersonen und Organisationen, die ihre Sicherheitslage in einer zunehmend vernetzten Welt verbessern möchten.

Schlechte Passwörter

Wenn Sie eine Anwendung verwenden, werden Sie als Erstes auf eine Art Authentifizierung stoßen. Dies ist normalerweise eine Kombination aus Benutzername und Passwort. Und natürlich unterscheiden sich die Anforderungen von Site zu Site stark. Es ist recht üblich, dass Groß- und Kleinbuchstaben sowie möglicherweise einige Zahlen und Sonderzeichen erforderlich sind. Die Länge ist ebenfalls ein wichtiger Faktor. Eine gute Richtlinie ist, das Passwort lang genug zu halten, um Brute-Force-Angriffe zu verhindern, und komplex genug, damit es nicht in einem Wörterbuch auftaucht. Eine gute, empfohlene Länge ist MINDESTENS 10 Zeichen. Vorzugsweise viel mehr.

Wir sind auf zahlreiche Anwendungen gestoßen, bei denen die einzige Anforderung eine Länge von sechs Zeichen war. Ein Passwort wie „111111“ wäre also vollkommen akzeptabel. Selbst ein einfacher Computer würde eine kurze Zeit brauchen, um einen Hash dieses Passworts zu knacken. Ganz zu schweigen davon, dass es wahrscheinlich in einem Wörterbuch steht, sodass auch Brute-Force-Angriffe durchaus möglich wären. Weitere Informationen dazu, wie Passwörter geknackt werden, finden Sie hier.

Fehlende starke SSL-Implementierung

SSL Labs ist ein praktisches Tool zur Bewertung des aktuellen Status der SSL-Implementierung. Es ist schnell, einfach zu verwenden und umfassend. Es gibt auch das Tool SSL Checker, eine vereinfachte Version, die für Laien leichter zu verstehen ist. Es bietet außerdem die zusätzliche Möglichkeit, SSL-Sicherheitsheader zu überprüfen. Wir werden jetzt nicht auf alle Details zur SSL/TLS-Implementierung eingehen, das würde mindestens mehrere weitere Seiten in diesem Beitrag erfordern. Wir müssen also mit einem separaten Beitrag darüber zurückkommen. Wenn Sie jetzt mehr wissen möchten, gibt es ein weiteres praktisches Tool. Sie nennen es Google; wir glauben, dass es langsam ankommt! Oder kontaktieren Sie uns einfach und wir sorgen dafür, dass Sie die richtigen Informationen erhalten.

Benutzeraufzählung

Es gibt mehrere gängige Möglichkeiten, mit denen Anwendungen gültige Benutzer aufzählen können. Eine der gängigsten und einfachsten Möglichkeiten ist die Anmeldefunktion. Ein Beispiel: Sie melden sich bei einer Anwendung an. Wenn Sie den richtigen Namen eingeben, aber das Passwort verwechseln, lautet die Antwort „Das Passwort ist falsch“. Dies ist ein Hinweis darauf, dass der Benutzer ein gültiger Benutzer ist. Wenn Sie einen anderen Benutzernamen (der nicht gültig ist) ausprobieren und die Antwort „Kein gültiger Benutzer“ lautet, können Sie nun leicht feststellen, dass der erste Benutzer tatsächlich ein gültiger Benutzer war.

Für einen Angreifer wäre dies eine gute Gelegenheit, Benutzer der Anwendung mit Brute Force anzugreifen. Denn die Anwendung wird antworten und Sie darüber informieren, ob der Benutzer gültig ist oder nicht.

XSS/HTML/SQL-Injection

Das größte Problem der Jahre 2017 und 2018 waren Injections verschiedener Art. Was kann also injiziert werden? SQL-Abfragen, Betriebssystembefehle, HTML-Inhalte, ganze Seiten mit Inhalten und Skripten. Wo kann man das injizieren? Überall dort, wo eine Benutzereingabe erforderlich ist oder Benutzer Daten ändern können, z. B. in einem Textfeld, einem Benutzernamen-/Passwortfeld, Suchfunktionen, Feedback- und Kommentarfeldern, URLs usw.

Uneingeschränkter Dateiupload

Hochgeladene Dateien können schwerwiegende Auswirkungen auf die Anwendung sowie das Dateisystem haben. Es ist oft zu beobachten, dass es keine Filter dafür gibt, welche Arten von Dateierweiterungen hochgeladen werden können. Wenn nur ein oder zwei Dateitypen benötigt werden, sollten alle anderen auf der schwarzen Liste stehen.

Stellen Sie sich eine in PHP geschriebene Anwendung vor, bei der der Benutzer ein Profilbild hochladen kann. Sie würden annehmen, dass diese Funktion nur das Hochladen von Bilddateien (JPG und PNG) zulässt. Aber auch andere Dateiformate dürfen hochgeladen werden. Da wir es in diesem Fall mit PHP zu tun haben (und PHP direkt mit dem Betriebssystem interagieren kann), laden wir einen lustigen PHP-Code hoch, der uns eine direkte Kommunikation mit dem Dateisystem des Servers selbst ermöglicht. Dies kann zu noch fantastischeren Dingen führen, wie z. B. der Gefährdung von Informationen und möglicherweise auch zu einem weiteren Eindringen in das Netzwerk.

Defekte Zugriffskontrollen (Sicherheit durch Verschleierung)

Dies geschieht, wenn nicht die richtigen Prüfungen für die gesamte Sitemap durchgeführt werden. Dadurch kann ein Benutzer auf Informationen zugreifen, die seine Benutzerberechtigungen nicht zulassen sollten (oder die völlig ohne Authentifizierung sind). Stellen Sie sich vor, Sie durchsuchen Ihre Zeiterfassungsanwendung mit Ihrem Konto mit niedrigen Berechtigungen. Das Einzige, was Sie davon abhält, Ihren eigenen Zeitbericht zu genehmigen, sind im Grunde kosmetische Dinge. Die Genehmigungsschaltfläche ist für Ihr Konto nicht sichtbar, sondern nur für die Administratoren der Anwendung. Wenn Sie die Anforderungsdaten kennen würden, könnten Sie den Zeitbericht tatsächlich selbst genehmigen.

In dieser Anwendung haben Sie und Ihr Unternehmen einige interne Dokumente gespeichert, die vertrauliche Informationen enthalten. Sie greifen auf eines der PDFs zu und laden es authentifiziert herunter. Wenn Sie sich von der Anwendung abmelden und dann dieselbe URL für dieses Dokument aufrufen und die Datei zugänglich ist, wäre dies erneut ein Beweis für fehlerhafte Zugriffskontrollen.

Schwache Benutzer-/Gruppensegmentierung (Least Privilege Practice)

Es wäre schön, in einer Welt zu leben, in der alle gleich sind. Aber wenn es um IT geht, ist dies ein absolutes No-Go, aber dennoch eine sehr gängige Sache. Alle Konten einer Anwendung oder eines Netzwerks haben die gleichen Berechtigungen, was Chaos mit sich bringt, insbesondere wenn diese Anmeldeinformationen von einem Angreifer kompromittiert werden. Dies bedeutet mehr oder weniger, dem Angreifer die Schlüssel zum Königreich zu geben, und wird allgemein als „schlechte Idee“ bezeichnet. Hier muss gefragt werden, ob Janice aus der Buchhaltung tatsächlich Zugriff auf die streng geheimen Dokumente benötigt, die für Leann und Kurt bestimmt sind? Benutzerrollen sollten nach dem Prinzip der geringsten Privilegien zugewiesen werden. Was Sie nicht wissen müssen, sollten Sie einfach nicht wissen oder keinen Zugriff darauf haben.

Schlechtes Patch-Management / End-of-Life-Management

Ein gutes Beispiel für dieses Problem ist der WannaCry/EternalBlue-Ausbruch am 12. Mai 2017. Infrastrukturen auf der ganzen Welt waren von dieser Sicherheitslücke betroffen, die Server und Computer von Unternehmen unterschiedlicher Größe wurden mit einem Cryptolocker infiziert. Laut IBM X-Force wurde in 150 Ländern allein durch den WannaCry-Vorfall ein Gesamtschaden von über 8 Milliarden Dollar gemeldet. Ich denke, das spricht für sich: Wenn Sie Ihre eigenen Daten und Server verwalten, können Sie kontrollieren, wann und was Sie patchen. Bei einem Drittanbieter haben Sie keine Ahnung, was er tut. Deshalb ist dies eine gute Frage an jeden Drittanbieter, den Sie in Betracht ziehen.

Schwache Netzwerk-/Datenbanksegmentierung

Wir hatten Fälle, in denen uns gesagt wurde, dass das Netzwerk oder die Datenbank richtig segmentiert ist, zumindest laut den Leuten, mit denen wir gesprochen haben. Als wir uns später bei ihnen meldeten, haben wir bewiesen, dass dies nicht der Fall ist. Anwendungen, bei denen die Vorproduktionsversion und die Produktionsversion auf demselben Server gespeichert sind wie die „richtig segmentierte“ Datenbank. Die tatsächliche Segmentierung der Datenbank bestand tatsächlich nur darin, dass es sich um zwei separate Zweige in derselben Datenbank handelte. Das bedeutete, dass die in der Vorproduktionsanwendung gefundene SQL-Injection auch zu einer vollständigen Kompromittierung der Produktionsdatenbank führte. Dies wurde auch bei Multi-Tenant-Systemen beobachtet, bei denen die Daten mehrerer Unternehmen alle in derselben Datenbank gespeichert sind.

Wenn Sie mehr über die häufigsten Angriffe erfahren und wissen möchten, wie Sie Sicherheit in den Entwicklungsprozess integrieren können, nehmen Sie unbedingt an unserem Webinar im September teil, in dem wir uns mit diesen Schlüsselbereichen befassen. Registrieren Sie sich unten.