
Sicherheitsfehler
Sicherheitsfehlkonfiguration ist so etwas wie ein Überbegriff, der häufig auftretende Sicherheitslücken abdeckt, die eher auf die Konfigurationseinstellungen einer Anwendung als auf schlechten Code zurückzuführen sind. Es handelt sich um ein weitreichendes Thema, das stark von Faktoren wie Ihrem Technologie-Stack abhängt.
Oft scheint die Behebung dieser Probleme einfach zu sein, wie das Ändern einer Konfigurationsdatei oder sogar einer einzelnen Codezeile, aber die Auswirkungen und Folgen dieser Sicherheitsanfälligkeiten können schwerwiegend sein.
Schauen wir uns einige der folgenden Kategorien an.
Kategorien
Web-Server
Eine klassische Fehlkonfiguration auf Webservern ist die Aktivierung von Directory Listing.
Die Aktivierung der Verzeichnisliste hat zwar oft nur geringe bis gar keine direkten Auswirkungen, macht es einem Angreifer jedoch leicht, andere Fehler zu entdecken, die möglicherweise ebenfalls vorhanden sind. Dies können Dinge wie absichtlich versteckte Seiten, Sicherungsdateien und andere ähnliche Elemente sein.
Es ist erwähnenswert, dass all diese Dinge selbst ebenfalls von Natur aus schlechte Praktiken sind und als Sicherheit im Dunkeln gelten.
Die Verzeichnisauflistung ist einfach zu deaktivieren und bietet eine tiefgreifende Abwehr, da es für einen Angreifer teurer ist, den Host aufzulisten, um potenzielle Angriffsvektoren gegen ihn zu finden.
Frameworks
Debug-Modus
Die meisten Frameworks bieten einen „Debug“ -Modus für Entwickler. In diesem Modus werden unter anderem normalerweise Stacktrace-Details angezeigt, wenn eine unbehandelte Ausnahme auftritt. Einige Frameworks zeigen Ihnen neben dem Stacktrace sogar Codefragmente. Dies kann bei der Entwicklung äußerst hilfreich sein, kann Angreifern aber auch viele Informationen liefern, auf die sie eigentlich keinen Zugriff haben sollten.
Überwachung von Endpunkten
Viele Frameworks verfügen auch über eine Reihe von Endpunkten, die aktiviert werden können, sodass die Anwendung überwacht werden kann, unabhängig davon, ob sich diese in einer Produktions- oder Test-/Entwicklungsumgebung befindet.
Dazu können gehören:
- Metriken (Prometheus)
- Protokolle
- Informationen zur Umgebung
- Pfad-/URL-Zuordnungen
Diese Information ist zwar nicht meistens Da es sensibel ist, kann es dennoch Details liefern, die potenziellen Angreifern helfen, Ihre Anwendung besser zu verstehen. Natürlich können Ihre Umgebung oder Ihre Protokolle tatsächlich enthalten vertrauliche Informationen, daher ist es wichtig, darauf zu achten, was sichtbar und nutzbar sein könnte, wenn neugierige Blicke darauf stoßen.
Der Unterschied zwischen Produktions- und Nichtproduktionsumgebungen
Benutzer machen häufig den Fehler, die Richtlinien wie das Deaktivieren der Verzeichnisliste, des Debug-Modus und der Debug-Endpunkte in Entwicklungs- und Testumgebungen nicht zu befolgen, und zwar nur in Produktionsumgebungen. Der Grund dafür ist, dass diese Systeme, die keine Produktionssysteme sind, zum Testen gedacht sind und es wichtig ist, die durch diese Funktionen bereitgestellten Informationen zu erhalten.
Diese Mentalität ist jedoch fehlgeleitet. Angreifer sind immer noch in der Lage, Informationen von Systemen anderer Anbieter zu untersuchen und an Dritte weiterzugeben. Anschließend nutzen sie die vom Testsystem gesammelten Informationen, um dann Ihr Produktionssystem anzugreifen. Es ist auch nicht ungewöhnlich, dass Unternehmen Kopien ihrer Produktionsdatenbank in Testsystemen verwenden, was das Risiko noch weiter erhöht.
XXE
Eine Art von Sicherheitsfehlkonfiguration, die sehr schwerwiegend ist, sind XML External Entities (XXE).
Dies tritt auf, wenn Sie aus nicht vertrauenswürdigen Quellen mit aktivierter Entitätsauflösung analysieren, was in der Vergangenheit der Fall war. XXE kann unter anderem zum willkürlichen Lesen von Dateien und zur serverseitigen Fälschung von Anfragen führen.
Schauen Sie sich das folgende Beispiel an, um weitere Informationen und insbesondere ein einfaches Beispiel dafür zu erhalten.