Die häufigsten Probleme die wir im IT-Security sehen

Fehlende starke SSL-Implementierung 

Ein raffiniertes Tool zur Bewertung des aktuellen Stands der SSL-Implementierung,SSL Labs  is quick, easy to use, and comprehensive. There is also the tool  SSL Checker eine vereinfachte Version, die auch für Nichttechniker leicht verständlich ist. Sie bietet auch den zusätzlichen Vorbehalt der Überprüfung der SSL-Sicherheits-Header. Wir werden jetzt nicht auf alle Details der SSL/TLS-Implementierung eingehen, das würde mindestens mehrere Seiten dieses Beitrags erfordern. Wir werden also in einem separaten Beitrag darauf zurückkommen. Wenn Sie jetzt wirklich mehr wissen wollen, dann gibt es ein anderes schickes Tool. Sie nennen es Google; wir glauben, dass es sich langsam durchsetzt! Oder kontaktieren Sie uns und wir werden dafür sorgen, dass Sie die richtigen Informationen erhalten. 

User enumeration 

Es gibt mehrere gängige Methoden, mit denen Anwendungen die gültigen Benutzer aufzählen. Eine der häufigsten und einfachsten ist die Login-Funktion. Ein Beispiel: Sie wollen sich bei einer Anwendung anmelden. Wenn Sie den richtigen Namen eingeben, sich aber beim Passwort vertippen und die Antwort lautet: "Das Passwort ist falsch". Dies ist ein Hinweis darauf, dass der Benutzer ein gültiger Benutzer ist. Wenn Sie es mit einem anderen Benutzernamen versuchen (der nicht gültig ist) und die Antwort lautet: "Kein gültiger Benutzer", können Sie jetzt leicht feststellen, dass der erste Benutzer tatsächlich ein gültiger Benutzer war. 

 Für einen Angreifer wäre dies eine gute Gelegenheit, die Benutzer der Anwendung mit roher Gewalt zu erpressen. Denn die Anwendung antwortet und informiert Sie, ob der Benutzer gültig ist oder nicht. 

XSS/HTML/SQL Injection 

Das Thema Nummer eins der Jahre 2017 und 2018 waren Injektionen verschiedener Art. Was kann also injiziert werden? SQL-Abfragen, Betriebssystembefehle, HTML-Inhalte, ganze Seiten mit Inhalten und Skripten. Wo würde jemand diese injizieren? Überall dort, wo eine Benutzereingabe erforderlich ist oder Benutzer Daten ändern können, z. B. in Textfeldern, Feldern für Benutzernamen und Kennwort, Suchfunktionen, Feedback- und Kommentarfeldern, URLs usw... 

Unbeschränktes File Upload 

Hochgeladene Dateien können sowohl für die Anwendung als auch für das Dateisystem schwerwiegende Folgen haben. Häufig wird festgestellt, dass es keine Filter für die Arten von Dateierweiterungen gibt, die hochgeladen werden können. Wenn nur ein oder zwei Dateitypen benötigt werden, sollten alle anderen auf die schwarze Liste gesetzt werden. 

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. Es können aber auch andere Dateiformate hochgeladen werden. Da wir es in diesem Fall mit PHP zu tun haben (und PHP kann direkt mit dem Betriebssystem interagieren), 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 Kompromittierung von Informationen und dem möglichen Eindringen in das Netz 

Broken Access Controls (Security by Obscurity) 

Dies geschieht, wenn die gesamte Sitemap nicht ordnungsgemäß überprüft wird. Auf diese Weise kann ein Benutzer auf Informationen zugreifen, die seine Berechtigungen nicht zulassen sollten (oder völlig unauthentifiziert). Stellen Sie sich vor, Sie durchsuchen Ihre Zeitberichtsanwendung mit Ihrem niedrig privilegierten Konto, und das einzige, was Sie davon abhält, Ihren eigenen Zeitbericht zu genehmigen, ist im Grunde nur Kosmetik. Die Genehmigungsschaltfläche ist für Ihr Konto nicht sichtbar, sondern nur für die Administratoren der Anwendung. Wenn Sie die Antragsdaten kennen würden, könnten Sie den Zeitbericht selbst genehmigen. 

In dieser Anwendung haben Sie und Ihr Unternehmen einige interne Dokumente gespeichert, die sozusagen sensible Informationen enthalten. Sie greifen auf eines der PDF-Dokumente zu und laden es herunter, wobei Sie sich authentifizieren. Wenn Sie sich aus der Anwendung abmelden und dann auf dieselbe URL für dieses Dokument zugreifen und die Datei zugänglich ist, wäre das wieder ein Beweis für eine unzureichende Zugangskontrolle.

Weak User/Group segmentation (Least Privilege Practice) 

Flache Benutzer-/Gruppenberechtigungen. Es wäre schön, in einer Welt zu leben, in der alle gleich sind. In der IT ist dies jedoch ein absolutes No-Go, aber dennoch sehr verbreitet. Alle Konten einer Anwendung oder eines Netzwerks haben die gleichen Berechtigungen, was zu einem Chaos führt, vor allem, wenn diese Anmeldeinformationen von einem Angreifer missbraucht werden. Damit wird dem Angreifer mehr oder weniger der Schlüssel zum Königreich in die Hand gegeben, was gemeinhin als "schlechte Idee" bezeichnet wird. Hier stellt sich die Frage: Braucht Janice aus der Buchhaltung tatsächlich Zugang zu den streng geheimen Dokumenten, die für Leann und Kurt bestimmt sind? Benutzerrollen sollten nach dem Prinzip der geringsten Privilegien vergeben werden: Was man nicht wissen muss, sollte man einfach nicht wissen und keinen Zugang dazu haben.  

Bad patch management / End of life management 

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

Weak Network/Database segmentation 

Es gab Fälle, in denen uns gesagt wurde, dass das Netz oder die Datenbank ordnungsgemäß segmentiert ist, zumindest nach Aussage der Personen, mit denen wir gesprochen haben. Als wir uns einige Zeit später wieder bei ihnen melden, haben wir festgestellt, dass dies nicht der Fall ist. Anwendungen, bei denen die Vorproduktionsversion und die Produktionsversion auf demselben Server gespeichert sind wie die "ordnungsgemäß segmentierte" Datenbank. Die tatsächliche Segmentierung der Datenbank bestand in Wirklichkeit nur darin, dass es sich um zwei getrennte Zweige in derselben Datenbank handelte. Das bedeutete, dass die SQL-Injektion, die in der Vorproduktionsanwendung gefunden wurde, auch zu einer vollständigen Kompromittierung der Produktionsdatenbank führte. Dies wurde auch bei mandantenfähigen Systemen beobachtet, bei denen die Daten mehrerer Unternehmen alle in derselben Datenbank gespeichert sind.  

Wenn Sie mehr über die häufigsten Angriffe und die Integration von Sicherheitsaspekten in den Entwicklungsprozess erfahren möchten, sollten Sie an unserem Webinar im September teilnehmen, in dem wir diese Schlüsselbereiche näher beleuchten. Registrieren Sie sich unten.