EN

Unsicheres Design

In diesem Artikel:

Bei der Entwicklung von Anwendungen wird Entwicklern empfohlen, sichere Entwurfsmuster, eine sorgfältig geplante Bedrohungsmodellierung und Referenzarchitekturen zu verwenden, die die Anwendung frei von Sicherheitslücken halten.

Das Fehlen wirksamer Sicherheitskontrollen in der Entwurfsphase führt häufig dazu, dass eine Anwendung für viele Schwachstellen anfällig ist, die als unsichere Entwurfsschwachstellen bezeichnet werden. In diesem Artikel werden unsichere Entwurfsschwachstellen, mögliche Auswirkungen und Abhilfestrategien erörtert.

Was ist unsicheres Design?

Unsicheres Design umfasst verschiedene Risiken, die sich aus der Nichtbeachtung bewährter Design- und Architekturpraktiken ergeben, und zwar bereits in der Planungsphase vor der eigentlichen Implementierung. An dieser Stelle sei kurz darauf hingewiesen, dass sich ein unsicheres Design von einer unsicheren Implementierung unterscheidet, und dass eine nahezu perfekte Implementierung Mängel, die aus einem unsicheren Design resultieren, nicht verhindern kann. 

Die Schwachstelle „Unsicheres Design“ ist zwar neu in der OWASP-Top-10-Liste, steht aber auf Platz vier der Liste für 2021, da die Risikominderung in der Designphase als grundlegend für die Sicherheitspraktiken von „Shift Left“ angesehen wird.

Was sind unsichere Konstruktionsschwachstellen?

Unsichere Designschwachstellen entstehen, wenn Entwickler, Qualitätssicherungs- und/oder Sicherheitsteams es versäumen, Bedrohungen während der Codeentwurfsphase zu antizipieren und zu bewerten. Diese Schwachstellen sind auch eine Folge der Nichtbeachtung bewährter Sicherheitspraktiken beim Entwurf einer Anwendung. Da sich die Bedrohungslandschaft ständig weiterentwickelt, ist eine konsistente Bedrohungsmodellierung erforderlich, um bekannte Angriffsmethoden zu verhindern. Ohne ein sicheres Design ist es schwierig, architektonische Schwachstellen zu erkennen und zu beheben, wie z. B.:

Ungeschützte Speicherung von Anmeldeinformationen

Beim Entwurf einer Anwendung ignorieren die Entwicklungsteams häufig die bewährten Verfahren zur Verwaltung von Geheimnissen und zur Zugriffskontrolle, was zu Sicherheitsschwachstellen führt. Infolgedessen wird das System häufig durch schädliche Kennwortverwaltungspraktiken kompromittiert, z. B. durch die Speicherung von Benutzerkennwörtern als Klartext in Anwendungseigenschaften, Konfigurationsdateien oder im Speicher. 

Designfehler in der Identitäts- und Zugriffsverwaltung für die Zertifikatserstellung ermöglichen ebenfalls den Zugriff auf vertrauliche Informationen. Solche Anwendungssicherheitslücken würden es Angreifern ermöglichen, legitime Benutzerkonten anzunehmen und unbefugten Zugriff auf passwortgeschützte Ressourcen zu erhalten, um das System tiefergehend auszunutzen.

Verstöße gegen die Vertrauensgrenze

Eine Vertrauensgrenze ist eine Schnittstelle in einem Programm, die den sicheren Austausch von Daten oder Befehlen zwischen zwei Entitäten ermöglicht. Dazu gehören Bereiche der Anwendung, die unkontrollierte externe Eingaben wie HTTP-Anfragen, Netzwerk-Sockets und Dateiuploads akzeptieren. Verletzungen der Vertrauensgrenze treten auf, wenn die Schnittstelle sowohl vertrauenswürdige als auch nicht vertrauenswürdige Dateneingaben in demselben Datenspeicher akzeptiert und speichert. 

Entwickler versäumen es oft, zwischen vertrauenswürdigen und nicht vertrauenswürdigen Quellen zu unterscheiden, wodurch der Austausch von bösartigen Daten und Befehlen ermöglicht wird. Darüber hinaus kann auch das Backend der Anwendung den unsicheren Austausch von Daten über die Vertrauensgrenze hinweg zulassen, wenn die Anwendung nicht über einen sorgfältig eingesetzten Mechanismus zur Eingabevalidierung verfügt.

Generierung von Fehlermeldungen mit sensiblen Informationen

Die meisten modernen Anwendungen sind so konzipiert, dass sie Fehlerzustände erkennen und Diagnosemeldungen erzeugen, die den Benutzer über den Fehler und mögliche Abhilfemaßnahmen informieren. Oft sind diese Fehlermeldungen sehr ausführlich und enthalten sensible Informationen wie Benutzerkennung, Kennwort, die Anwendungsumgebung oder andere zugehörige Daten, auf die ein Angreifer zugreifen kann. Der Angreifer kann die offengelegten Daten nutzen, um andere Angriffe wie Pfadumgehung und SQL-Injection-Angriffe zu starten.

Unsachgemäße Isolierung oder Kompartimentierung

Diese Schwachstelle tritt auf, wenn die Anwendung Entitäten mit unterschiedlichen Rechten, Privilegien und Zugriffsberechtigungen nicht wirksam trennt, was zu einer lückenhaften Zugriffskontrolle führt. Angenommen, die Entwickler schaffen es nicht, die Umgebungen eines Produkts erfolgreich zu trennen. In diesem Fall kann sich ein Angreifer Zugang zu einer der Umgebungen verschaffen und den Angriff auf andere Umgebungen ausweiten. Infolgedessen führt eine unsachgemäße Isolierung von Prozessen, Ressourcen und Schwachstellen in Anwendungsfunktionen zu einem riesigen Angriffsradius.

Durch unsichere Designs resultierende Angriffe vermeiden
Präventionsguide

Leitfaden zur Vermeidung von unsicheren Designangriffen

Lernen Sie, wie Sie unsichere Design-Angriffe erkennen und verhindern können.

Download

Wie lassen sich unsichere Design-Schwachstellen verhindern?

Die Vorbeugung von Schwachstellen im Design beginnt in der Regel mit der Durchsetzung einer „Linksverschiebung“ des Sicherheitsdenkens, die eine Erstellung von Geschäftsrisikoprofilen bereits zu Beginn des SDLC erfordert. Einige gängige Ansätze zur Vorbeugung von Schwachstellen in der Entwicklung sind:

Einrichten eines sicheren Entwicklungslebenszyklus

In der Phase des Anwendungsentwurfs sollten die Entwicklungsteams eine faktische Entwurfsmethodik und etablierte Entwurfsmuster anwenden. Jedes Teammitglied sollte Zugang zu Sicherheitstools, getesteten Komponentenbibliotheken und Bedrohungsmodellen haben, um das Sicherheitsrisiko der eigenen Anwendung zu verringern. Die Sicherheitsteams sollten zu Beginn des Entwicklungszyklus einbezogen und während der gesamten Entwicklungs-, Integrations- und Bereitstellungsphase konsultiert werden.

Kontinuierliche Unit- und Integrationstests einrichten

Die Entwickler sollten automatisierte Sicherheitstests für einzelne Funktionen und Methoden innerhalb der in der Anwendung verwendeten Module, Komponenten und Klassen einrichten. Skizzierte Testpläne sollten Teil des Entwurfs und der Freigabe des Produkts sein, um in jeder Phase des SDLC eine luftdichte Sicherheit zu gewährleisten.

Durchsetzung eines detaillierten Anforderungs- und Ressourcenmanagements

In den ersten Planungsphasen der Anwendungsentwicklung sollten die Produktmanager die technischen und geschäftlichen Anforderungen des Kunden erfassen und bewerten, einschließlich der Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit der Anwendungslogik und der Daten. Auf dieser Grundlage sollten die Entwicklerteams die optimale Trennung von Mandanten und die Exposition der einzelnen Komponenten innerhalb der Anwendung festlegen. Der Produktionsplan sollte auch die Verwaltung aller Entwicklungsaktivitäten auf Mandantenbasis umfassen, um eine sichere Verwaltung der Zugriffsrechte durchzusetzen.

Implementierung der Trennung von System- und Netzwerkebene

Unternehmen sollten den Schutz- und Gefährdungsbedarf der Anwendung ermitteln, um die geeignete Trennungsebene auf der System- oder Netzwerkebene zu implementieren. Durch die Partitionierung der Anwendung in modulare Subsysteme oder virtuelle Netzwerke ist es einfacher, den Zugriff auf bestimmte Daten und Ressourcen zu beschränken. Dadurch wird es für Hacker schwieriger, ihren Zugriffsbereich im Falle eines Angriffs zu erweitern.

Auswirkungen von unsicherem Design

Die Folgen von Angriffen auf Schwachstellen in unsicheren Designs hängen vom Umfang des Angriffs, den offengelegten Daten und der Dauer des Angriffs bis zur Entdeckung ab. Zu den möglichen Auswirkungen eines erfolgreichen Angriffs gehören

Beispiele für unsichere Design-Schwachstellen

Beispiele für Angriffsszenarien, die ein unsicheres Design ausnutzen, sind:

Ausführliche Fehlermeldung, die zu Pfadumgehung führt

Fehlermeldungen, die detaillierte Informationen zurückgeben, können Angreifer zu Dateien führen, die wertvolle Informationen enthalten. Angreifer können auf die Dateien und Verzeichnisse mit Hilfe von Pfadumgehungstechniken zugreifen und so eine weitere Kompromittierung ermöglichen. Der folgende Codeschnipsel zeigt einen PHP-Datenbankfehler, der die Systemstruktur für böswillige Benutzer offenlegt:

try {
openDbConnection();
}
//print exception message that includes exception message and configuration file location 
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';
}

Aus der obigen Fehlermeldung geht hervor, dass der böswillige Benutzer auf Mysql_config_location zugreifen und sich die Anmeldeinformationen für den Zugriff auf die Datenbank beschaffen oder die Konfigurationsdatei durch eine böswillige Datei ersetzen kann.

Injektion als Verletzung der Vertrauensgrenze

In einer Anwendung, die eine SQL-Datenbank ohne angemessene Validierung verwendet, kann ein Angreifer bösartigen Code einschleusen, um Daten aus der Datenbank abzurufen. Angenommen, eine Autovermietungs-Website verwendet die folgende URL für Kunden, die einen Geländewagen mieten möchten:

https://darwin-cars.com/vehicles?category=SUV

Wenn Sie auf den Link klicken, wird die Anwendung angewiesen, eine Abfrage zu erstellen, um Details zu den entsprechenden Fahrzeugen aus der Datenbank abzurufen, wie unten dargestellt:

SELECT * FROM vehicles WHERE type = ‘SUV’ AND registered=1

Diese Abfrage fordert das Backend auf, alle Details aus der Fahrzeugtabelle zurückzugeben, wobei die Kategorie SUV ist und der Wert der Spalte registriert 1 ist. Die Einschränkung registriert=1 wird verwendet, um vorhandene Fahrzeuge auszublenden, die nicht registriert wurden.

Da der Benutzer keine URL-Validierung durchführt, kann der böswillige Benutzer eine URL wie die folgende konstruieren:

https://darwin-cars.com/vehicles?category=SUV‘-

Damit wird die folgende Abfrage an die Datenbank gesendet:

SELECT * FROM vehicles WHERE type= ‘SUV’--’ AND registered = 1

Die –Zeichen stehen in SQL für den Beginn eines Kommentars, so dass der Server den Rest der Abfrage als Kommentar interpretiert. Indem der Angreifer den Teil „registered= 1“ der Abfrage auskommentiert, zwingt er den Server, Details zu allen Fahrzeugen der Kategorie SUV zurückzugeben, auch zu den nicht registrierten.

Wie Crashtest Security helfen kann, unsichere Designs zu verhindern

Die Crashtest Security Suite enthält umfassende Funktionen zur Sicherung von Anwendungen während des gesamten SDLC. Diese beinhalten:

Automatisierte Penetrationstests

Crashtest Security bietet ein automatisiertes Penetrationstest-Tool, das kontinuierliche Tests in allen Phasen des Anwendungsentwicklungsprozesses ermöglicht. Dies hilft bei der effizienten Modellierung von Bedrohungen, während die Angriffsflächen der Anwendung reduziert und drohende Bedrohungen abgeschwächt werden.

Kontinuierliches Schwachstellen-Scanning

Die Plattform umfasst Schwachstellen-Scanner für die meisten bekannten Angriffsvektoren, um Unternehmen bei der Beseitigung von Sicherheitslücken zu unterstützen, die in der Entwurfs- und Planungsphase übersehen wurden.

Sicherheitsbeurteilungen, Berichte und Benchmarks

Der Schwachstellen-Scanner von Crashtest Security bietet umsetzbare Berichte nach einer gründlichen Bewertung der Anwendung durch Benchmarking mit den OWASP Top 10. Die Berichte enthalten auch Empfehlungen für ein sicheres Entwurfsmuster und eine Anwendungsarchitektur zur Verbesserung der Sicherheitshygiene

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit https://example.com
Wir scannen derzeit https://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 06/12/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.