This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Germany/Projekte/Top 10 fuer Entwickler-2013/A5-Sicherheitsrelevante Fehlkonfiguration

From OWASP
Jump to: navigation, search
← A4-Unsichere direkte Objektreferenzen
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

A6-Verlust der Vertraulichkeit sensibler Daten →
A5 Sicherheitsrelevante Fehlkonfiguration


Bedrohungsquellen
Angriffsvektoren
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
Anwendungs-
spezifisch
Ausnutzbarkeit
EINFACH
Verbreitung
HÄUFIG
Auffindbarkeit
EINFACH
Auswirkung
MITTEL
Anwendungs-/
Geschäftsspezifisch
Nicht authentifizierte Angreifer sowie authentifizierte Nutzer könnten versuchen, Zugangsdaten anderer zu stehlen. In Betracht kommen außerdem Innentäter, die ihre Handlungen verschleiern wollen. Angreifer benutzen Standardkonten, inaktive Seiten, ungepatchte Fehler, ungeschützte Dateien und Verzeichnisse etc., um unautorisierten Zugang zum oder Kenntnis über das Zielsystem zu erlangen. Sicherheitsrelevante Fehlkonfiguration kann auf jeder Ebene der Anwendung, inkl. Plattform, Web- und Anwendungsserver, oder Datenbank vorkommen. Die Zusammenarbeit zwischen Entwicklern und Administratoren ist wichtig, um eine sichere Konfiguration aller Ebenen zu gewährleisten. Automatisierte Scanner können oft fehlende Sicherheitspatches, Fehlkonfigurationen, Standardkonten, nicht benötigte Dienste, usw. erkennen. Diese Fehler geben Angreifern häufig unautorisierten Zugriff auf Systemdaten oder -funktionalitäten.
Manchmal führen sie zur kompletten Kompromittierung des Zielsystems.

Ein System könnte unbemerkt kompromittiert werden. Alle Daten könnten gestohlen oder nach und nach verändert werden.

Hohe Wiederherstellungskosten können entstehen.
Mögliche Angriffsszenarien

Szenario 1: Die Administratorkonsole mit Standardkonto wurde automatisch installiert und nicht entfernt. Angreifer entdecken dies, melden sich über das Standardkonto an und kapern das System.

Szenario 2: Directory Listings wurden nicht deaktiviert. Angreifer nutzen dies, um in den Besitz aller Dateien zu kommen. Sie laden alle existierenden Java-Klassen herunter, dekompilieren diese und entdecken einen schwerwiegenden Fehler in der Zugriffskontrolle.

Szenario 3: Die Konfiguration des Anwendungsservers erlaubt es, Stack Traces an Benutzer zurückzugeben. Dadurch können potentielle Fehler im Backend offengelegt werden. Angreifer nutzen zusätzliche Informationen in Fehlermeldungen aus.

Szenario 4: Der Applikationsserver wird mit Beispielapplikationen ausgeliefert, die auf dem Produktivsystem nicht entfernt wurden. Diese Beispielapplikationen besitzen bekannte Sicherheitsschwachstellen, die Angreifer ausnutzen können um den Server zu kompromittieren.

Wie kann ich 'Sicherheitsrelevante Fehlkonfiguration' verhindern?

Alle folgenden Empfehlungen sollten berücksichtigt werden:

  1. Ein wiederholbarer Härtungsprozess, der eine schnelle und einfache Verteilung einer neuen, abgesicherten Umgebung erlaubt. Entwicklungs-, QA-, und Produktionsumgebungen sollten identisch konfiguriert sein (mit unterschiedlichen Passwörtern pro Umgebung). Der Prozess sollte automatisiert sein, um den nötigen Aufwand bei Erstellung einer neuen, sicheren Umgebung zu minimieren.
  2. Ein Prozess, der zeitnah neuentwickelte Softwareupdates auf allen ausgerollten Umgebungen ermöglicht. Davon sind auch alle Bibliotheken und Komponenten betroffen (siehe A9).
  3. Eine robuste Anwendungsarchitektur, mit effektiver und sicherer Trennung und Absicherung einzelner Komponenten.
  4. Periodisch durchgeführte Tests und Audits helfen zukünftige Fehlkonfigurationen oder fehlende Patches zu erkennen und zu vermeiden.
Verteidigungs-Option 1 gegen 'Sicherheitsrelevante Fehlkonfiguration':

Bitte setzen Sie die oben genannten Empfehlungen auf allen Ebenen von der Anwendung, den Libraries, der Middleware bis hin zur IT-Infrastruktur um.

speziell für PHP:

In der Datei php.ini bietet PHP Konfigurationsmöglichkeiten für Umgebungsvariablen an. Hier kann bspw. bestimmt werden, ob ein Cookie nur bei HTTP-Abfragen oder auch durch JavaScript ausgelesen werden darf. Zur Laufzeit können die Parameter ebenfalls über die Funktion ini_set() gesetzt werden. Das PHP-Projekt Psecio (siehe https://github.com/psecio/iniscan/) bietet ein Werkzeug zur Überprüfung der php.ini an, mit welchem Schwachstellen in der Konfigurationsdatei aufgedeckt werden können.

Wichtige Parameter sind dabei u.a.:

  • open_basedir "/var/www/project" ; Ggf. auch /tmp erlauben, Einstellung bevorzugt in der Webserver-Konfiguration vornehmen
  • session.cookie_secure=On
  • session.use_only_cookies=On
  • session.cookie_httponly=On
  • allow_url_fopen=Off
Verteidigungs-Option 2 gegen 'Sicherheitsrelevante Fehlkonfiguration':

ModSecurity

Die Benutzung einer Webfirewall wie modsecurity, welches sich als Modul in den Webserver einbindet, ist empfehlenswert. Zentrale Komponente sind die "corerules", in welchen zwischen Warnungen und Fehlern unterschieden wird. In der Konfiguration des Webservers kann angegeben werden, welche Aktion bei einem Regelverstoß durchgeführt werden soll. Verstößt eine Anfrage gegen hinterlegte Regeln, kann die Ausführung der Anfrage gestoppt oder der Regelverstoß protokolliert werden.

Referenzen

OWASP

Weitere Informationen unter ASVS requirements area for Security Configuration (V12)

Andere

← A4-Unsichere direkte Objektreferenzen
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

A6-Verlust der Vertraulichkeit sensibler Daten →

© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png