Einige Statistiken von Pentester es Labor 2018-2020

Seit einigen Jahren sammle ich Statistiken aus den Ergebnissen ihrer Computersicherheitsforschung. Ich beschloss, sie ein wenig zu teilen. Hier finden Sie einen Beispielbericht über den Penetrationstest – Bericht. In einer großen Anzahl von Interviews mit Penetrationstetern höre ich die Frage: "Hat sich die Sicherheit von Internet-Apps im Laufe der Jahre verbessert?" Meiner Meinung nach – ja, aber nur dort, wo es irgendwie durch die Regulierung an der Basis erzwungen wird. Helfen Penetrationstests, die Sicherheit zu verbessern? – auf jeden Fall!

Um welche Daten geht es

In den letzten 2 Jahren konnte ich mehr als 100 Penetrationstests, Sicherheitsaudits, Analysen und Retests durchführen. Es waren verschiedene Apps für verschiedene Kunden. Die überwiegende Mehrheit waren Web-Apps. Wenn eine App zum ersten Mal getestet wurde, wurde fast immer ein Fehler mit der Einstufung der Bedrohung als kritisch oder hoch gefunden. Für Uneingeweihte führt die Nutzung dieser Art von Verwundbarkeit dazu, dass die vollständige Kontrolle über die Anwendung (häufig auch der Server) übernommen wird oder dass auf sensible Daten zugegriffen werden kann.

Statistiken nach Verwundbarkeitsklassifizierung sehen wie folgt aus:

Statistiken Penetrationstests
* Instanzen einer bestimmten Anfälligkeit für Anwendungen, keine Anzahl von Instanzen einer bestimmten Anfälligkeit in der Anwendung (z. B. 7 verschiedene XSS in einer Anwendung werden als 1 kritischer Fehlertyp gezählt)
Statistiken Penetrationstests in Prozent

Die seit Jahren fortschreitende Erkennung so großer Sicherheitsfehler in Anwendungen deutet meiner Meinung nach darauf hin, dass zu wenig Sicherheitszeit in einem frühen Stadium der Softwareentwicklung aufgewendet wird. Ich beziehe mich hier auf die Ausbildung von Entwicklern, die Neigung zur Sicherheit, während sie bereits Softwarearchitektur konstruieren und Bedrohungen modellieren. Ohne diese anhaltende Verwundbarkeit werden sie in der Endphase der Softwareentwicklung erwischt werden (die gleichen Reparaturkosten sind hoch) oder schlimmer noch, nur in Produktionsumgebungen von diesen weniger ethischen Hackern ;).

Die am häufigsten gefundenen Anfälligkeiten aufgrund des Typs

Lassen Sie es auf die nächsten Statistiken lehnen. Diesmal die am häufigsten gefundenen Arten von Anfälligkeiten.

TOP 12 Pentester
* Instanzen einer bestimmten Anfälligkeit für Anwendungen, keine Anzahl von Instanzen einer bestimmten Anfälligkeit in der Anwendung (z. B. 7 verschiedene XSS in einer Anwendung werden als 1 kritischer Fehlertyp gezählt)
TOP 12 Pentester

Mit verschiedenen Farben habe ich versucht, die typische Klassifizierung des Risikos einer bestimmten Anfälligkeit zu markieren (natürlich vereinfacht, in der Praxis hängt sie von vielen Faktoren ab). Nacheinander sieht es so aus: kastanienbraun – kritisch, rot – hoch, orange – mittel, grün- niedrig.

Zuallererst können Sie hier feststellen, dass XSSy die am häufigsten gefundene Art von Anfälligkeit von denen sind, die am meisten bekannt sind. Überraschend ist mir, dass sie seit etwa 30 Jahren bekannt ist. Darüber hinaus ist es vielleicht die bekannteste Klasse von Sicherheitsfehlern. Daher sollte ihr Auftreten bereits selten sein.

Nacheinander werden die Mitautorisierungsanfälligkeiten, d. h. der richtige Prozess, um zu überprüfen, ob der Benutzer berechtigt ist, einen bestimmten Vorgang auszuführen, rangieren. Das Problem zeigt sich insbesondere bei Anwendungen mit erweiterten APIs.

Wenn Man sich die Statistiken auf die häufigsten Fehler anschaut, steht die Offenlegung von Informationen an erster Stelle, die nicht öffentlich zugänglich sein sollten. Beachten Sie, dass die erste Phase des Hackens der App Die Aufklärung ist. Jede redundante Information, die scheinbar tribal erscheinen mag, könnte sich letztlich als entscheidend für einen effektiven Angriff erweisen.

Dann gibt es nicht-generische Fehlermeldungen in der Liste. Wie bisher zeigen sie oft zu viele sensible Daten, z. B. über die verwendeten Technologien.

An dritter Stelle steht ein Problem, das meiner Meinung nach in den kommenden Jahren in der Statistik an die Spitze vorrücken wird. Es handelt sich um technologische Schulden und die damit verbundene Verwendung von Komponenten mit bekannten Verwundbarkeiten. Aus meiner Sicht, heute es Anwendungen sind sozusagen aus vielen kleinen Pads und Abhängigkeitsketten gefaltet. Dadurch stellt sich fast täglich heraus, dass eine kleine Komponente bereits veraltet ist. Die Erholung seiner Version beinhaltet oft die Überarbeitung von Teilen der Anwendung (zumindest bekomme ich solche Informationen von Entwicklern 😉 ), und dieser Prozess verbraucht leider eine Menge Ressourcen.

OWASP Top 10 vs Top 12 Pentester

Die Aufschlüsselung der am häufigsten von mir festgestellten Anfälligkeiten mit der OWASP Top 10 Liste sieht wie folgt aus:

OWASP Top 10 vs Top 12 Pentester

Es ist schwer, meine "Funde" 1 zu 1 auf der OWASPa-Liste zu kartieren. Wir werden hier kein Spiegelbild von "Broken Authentication" finden. Dies liegt einfach daran, dass das Brutforsieren von Konten am häufigsten außerhalb des Anwendungsbereichs meiner Tests liegt (und andere Fehler, die unter diesen Punkt fallen, sind nicht ganz oben auf meiner Liste). Suchen Sie auch vergeblich nach einem Verweis auf XXE. Mit meinen Beobachtungen passieren Fehler dieser Klasse immer seltener. Ich denke, es ist damit verbunden, dass die Frameworks verantwortlich für die Verarbeitung von XMLy standardmäßig nicht mehr erlauben, externe Entitäten zu verwenden. Die obige Zusammenstellung zeigt jedoch, dass die Top 10 OWASP-Liste nicht nur eine trockene Theorie ist und sich in der Praxis widerspiegelt. Auf diese Weise sollten Sie es nutzen, ebenso wie alle Kenntnisse, die das Open Web Application Security Projectvermittelt.

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Speichere in deinen Favoriten diesen permalink.

Podziel się swoją opinią na temat artykułu