
Falsche Sicherheitseinstellungen
Eine fehlerhafte Sicherheitskonfiguration ist ein allgemeiner Begriff, der häufige Schwachstellen umfasst, die aufgrund der Konfigurationseinstellungen einer Anwendung und nicht aufgrund von fehlerhaftem Code auftreten. Es handelt sich um ein sehr umfangreiches Thema, das in hohem Maße von Faktoren wie der verfügbaren Technologie abhängt.
Oftmals scheint die Behebung dieser Probleme einfach zu sein, beispielsweise durch Ändern einer Konfigurationsdatei oder sogar einer einzigen Codezeile, doch die Auswirkungen und Folgen dieser Schwachstellen können schwerwiegend sein.
Werfen wir einen Blick auf einige der folgenden Kategorien.
Kategorien
Webserver
Ein klassischer Konfigurationsfehler bei Webservern ist die Aktivierung der Verzeichnisliste.
Die Aktivierung der Verzeichnisliste hat zwar in der Regel nur geringe oder gar keine direkten Auswirkungen, erleichtert es einem Angreifer jedoch, andere Fehler zu entdecken, die ebenfalls vorhanden sein könnten. Dabei kann es sich um absichtlich versteckte Seiten, Sicherungsdateien und ähnliche Elemente handeln.
Es ist anzumerken, dass all diese Dinge an sich auch intrinsisch schlechte Praktiken sind und als Sicherheit durch Verschleierung gelten.
Die Liste der Verzeichnisse lässt sich ganz einfach deaktivieren und macht die Verteidigung noch besser, weil es für Angreifer teurer wird, den Host zu durchsuchen, um mögliche Angriffspunkte zu finden.
Marcos
Modus zur Fehlerbehebung
Die meisten Frameworks bieten einen „Debugging“-Modus für Entwickler. Dieser Modus zeigt unter anderem häufig die Details des Stacktrace an, wenn eine unkontrollierte Ausnahme auftritt. Einige Frameworks zeigen sogar Codefragmente zusammen mit dem Stacktrace an. Dies kann während der Entwicklung sehr hilfreich sein, aber auch Angreifern 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 zur Überwachung der Anwendung aktiviert werden können, sei es in einer Produktionsumgebung oder in einer Test-/Entwicklungsumgebung.
Diese können Folgendes umfassen:
- Metriken (Prometheus)
- Registros
- Informationen zur Umgebung
- Routen-/URL-Mappings
Auch wenn diese Informationen in der Regel nicht sensibel sind, können sie dennoch Details enthalten, die potenziellen Angreifern helfen, Ihre Anwendung besser zu verstehen. Natürlich können Ihre Umgebung oder Ihre Protokolle tatsächlich vertrauliche Informationen enthalten. Daher ist es wichtig zu bedenken, was gesehen und verwendet werden könnte, wenn neugierige Blicke darauf fallen.
Die Unterscheidung zwischen Produktionsumgebungen und Nicht-Produktionsumgebungen
Menschen begehen häufig den Fehler, Richtlinien nicht zu befolgen, wie beispielsweise das Deaktivieren der Verzeichnisliste, des Debug-Modus und der Debug-Endpunkte in Entwicklungs- und Testumgebungen, und tun dies nur in Produktionsumgebungen. Der Grund dafür ist, dass diese Nicht-Produktionssysteme für Testzwecke konzipiert sind und es wichtig ist, die von diesen Funktionen bereitgestellten Informationen zu erhalten.
Diese Denkweise ist jedoch falsch. Angreifer können weiterhin Informationen aus Nicht-Produktionssystemen recherchieren und weitergeben und dann die im Testsystem gesammelten Informationen nutzen, um 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 sehr schwerwiegende Art von Sicherheitsfehlern sind externe XML-Entitäten (XXE).
Dies geschieht, wenn Sie nicht vertrauenswürdige Quellen mit aktivierter Entitätsauflösung analysieren, wie es in der Vergangenheit der Fall war. XXE kann unter anderem zum willkürlichen Lesen von Dateien und zur Fälschung von Anfragen auf Serverseite führen.
Weitere Details und ein einfaches Beispiel hierfür finden Sie im folgenden Beispiel.