Remote Code Execution, Cross-Site Scripting und Denial-of-Service-Schwachstellen machen zwei Drittel aller bekannten Schwachstellen im .NET-Ökosystem aus

Willkommen zu unserem neuen Sicherheitsbericht: Einblicke in die Open-Source-Sicherheit im .NET-Ökosystem. Der Bericht besteht aus drei Beiträgen:

• Einblicke in die Open-Source-Sicherheit im .NET-Ökosystem

• Im .NET-Ökosystem sind 75 % der 20 häufigsten Schwachstellen als kritisch eingestuft

• Remote Code Execution, Cross-Site Scripting und Denial-of-Service-Schwachstellen machen zwei Drittel aller bekannten Schwachstellen im .NET-Ökosystem aus

Unser liebevoll gestalteter PDF-Bericht enthält all diese Informationen und mehr an einem Ort und kann kostenlos heruntergeladen werden!

Was verrät uns Snyk über die Sicherheit im .NET-Ökosystem?

Nachdem wir uns die am häufigsten auftretenden Schwachstellen angesehen haben, werfen wir nun einen umfassenderen Blick auf das .NET-Ökosystem. Welche Arten von Schwachstellen kommen dort häufig vor? Zeigt sich der Trend zu Schwachstellen mit hohem Schweregrad auch, wenn wir das Ökosystem als Ganzes betrachten?

Arten von Schwachstellen

Die folgende Tabelle zeigt die Arten von Schwachstellen, die im .NET-Ökosystem jeweils mindestens ein Prozent aller Schwachstellen ausmachen. Sie enthält die Anzahl der unterschiedlichen Schwachstellen eines bestimmten Typs in der Schwachstellendatenbank von Snyk sowie deren prozentualen Anteil. Trotz der großen Vielfalt machen nur drei Schwachstellentypen den Großteil der gefundenen Schwachstellen aus. Schwachstellen durch Remote Code Execution (RCE), Cross-Site Scripting (XSS) und Denial of Service (DoS) machen zwei Drittel aller .NET-Schwachstellen in der Schwachstellendatenbank von Snyk aus.

Schwachstellen durch Remote Code Execution (RCE), Cross-Site Scripting (XSS) und Denial of Service (DoS) machen zwei Drittel aller .NET-Schwachstellen in der Schwachstellendatenbank von Snyk aus.

Schwachstellen im Fokus

Dieser Abschnitt bietet einen praktischen Überblick für alle, die mehr über die drei häufigsten Schwachstellentypen im .NET-Ökosystem erfahren möchten.

Remote Code Execution

Remote Code Execution bezeichnet eine Schwachstelle, die es einem Angreifer ermöglicht, beliebige Befehle oder Code in Ihrer Anwendung auszuführen. Die Codeausführung kann über ein Netzwerk erfolgen und ist daher nicht an einen bestimmten geografischen Standort gebunden. Eine damit verwandte Sicherheitslücke ist die Befehlseinschleusung.

Cross-Site Scripting

Ein Cross-Site-Scripting-Angriff liegt vor, wenn ein Angreifer eine legitime webbasierte Anwendung oder Website dazu bringt, eine Anfrage so zu akzeptieren, als stamme sie aus einer vertrauenswürdigen Quelle. Dazu wird der Kontext der Webanwendung verlassen. Anschließend gibt die Webanwendung diese Daten zusammen mit anderen vertrauenswürdigen dynamischen Inhalten an ihre Nutzer aus, ohne sie zu überprüfen.

Denial of Service

Denial of Service bezeichnet eine Gruppe von Angriffen, die allesamt darauf abzielen, ein System für die vorgesehenen, legitimen Nutzer unzugänglich zu machen. Im Gegensatz zu anderen Schwachstellen zielen DoS-Angriffe in der Regel nicht darauf ab, die Sicherheit zu durchbrechen. Vielmehr sollen Websites und Dienste für echte Nutzer nicht verfügbar sein, was zu Ausfallzeiten führt.

Bekannte .NET-Schwachstellen haben häufig einen hohen Schweregrad

Bei unserer früheren Betrachtung der 20 am häufigsten auftretenden Schwachstellen haben wir festgestellt, dass die meisten einen hohen Schweregrad aufwiesen. Gilt dieser Trend auch für alle .NET-Schwachstellen in der Snyk-Datenbank? Ja! Schwachstellen mit hohem Schweregrad machen 70,7 % aller Schwachstellen aus. Schwachstellen mit mittlerem Schweregrad bilden mit 26,9 % den zweitgrößten Anteil. Nur 2,4 % der .NET-Schwachstellen in der Snyk-Datenbank gelten als niedrig eingestuft.

Schwachstellen mit hohem Schweregrad machen 70,7 % aller Schwachstellen aus. Schwachstellen mit mittlerem Schweregrad bilden mit 26,9 % den zweitgrößten Anteil.

Das mag ein düsteres Bild der .NET-Sicherheit zeichnen. Der Anteil der Schwachstellen mit hohem Schweregrad ist beträchtlich. Zum Zeitpunkt der Erstellung dieses Berichts gab es jedoch für jede Schwachstelle, die Snyk bei einem Abhängigkeitsscan gefunden hat, eine verfügbare Behebung. Wir können zwar nicht mit 100-prozentiger Sicherheit sagen, warum das so ist, möglicherweise liegt es aber teilweise an der Unterstützung, die das .NET-Ökosystem von Microsoft erhält.

Zum Zeitpunkt der Erstellung dieses Berichts gab es für jede Schwachstelle, die Snyk bei einem Abhängigkeitsscan gefunden hat, eine verfügbare Behebung.

Sicherheit im Fokus: Schwachstellen beheben

Doch was bedeutet es eigentlich, eine Schwachstelle zu beheben? Dieser Abschnitt gibt Ihnen einen kurzen Überblick über den Prozess.

Upgrade

Wird eine Schwachstelle gefunden, nehmen die Projektbetreuer in der Regel eine Behebung in eine zukünftige Version auf, sofern dies möglich ist. Wie lange das dauert, kann jedoch stark variieren. Wenn Sie Ihre Versionen auf dem neuesten Stand halten, können Sie Sicherheitslücken in der Regel frühzeitig erkennen. Manchmal ist es schwierig, eine Abhängigkeit zu aktualisieren. Das kann daran liegen, dass Abhängigkeiten miteinander und mit Ihrem Code interagieren.

Direkte und indirekte Abhängigkeiten

Schwachstellen in direkten Abhängigkeiten lassen sich in der Regel unkompliziert beheben: Aktualisieren Sie die Abhängigkeit auf die Mindestversion, die den Fix enthält. Um Schwachstellen in indirekten Abhängigkeiten zu beheben, sind zwei Dinge erforderlich: eine Version der indirekten Abhängigkeit mit einem Fix und eine Version der direkten Abhängigkeit, die diese korrigierte Version verwendet. Sind beide Voraussetzungen erfüllt, lässt sich das Problem beheben, indem Sie die zugehörige direkte Abhängigkeit auf eine Version aktualisieren, die die korrigierte Version der indirekten Abhängigkeit nutzt. Ist auf Ebene der direkten Abhängigkeit kein Fix verfügbar, können Entwickler die indirekte Abhängigkeit aktualisieren, um das Problem zu beheben. Dadurch können jedoch Kompatibilitätsprobleme zwischen den Abhängigkeiten entstehen.

Fazit

Im .NET-Ökosystem gibt es nur wenige Schwachstellen pro Paket, doch diese haben häufig einen hohen Schweregrad. Das bedeutet, dass vermutlich weniger Zeit für die Behebung der Probleme erforderlich ist (geringerer Aufwand), während Sie zugleich potenziell gefährliche Sicherheitsprobleme angehen (hoher Nutzen). Anders gesagt: Wenn Sie bekannte Schwachstellen in den verwendeten .NET-Paketen beheben, ergreifen Sie eine Sicherheitsmaßnahme mit hoher Rendite. Unser Ziel bei Snyk ist es, Menschen dabei zu unterstützen, Open Source zu nutzen und sicher zu bleiben. Dazu gehört auch, Tools zu entwickeln, mit denen bekannte Schwachstellen in Abhängigkeiten gefunden und automatisch behoben werden können. Ebenso wichtig ist es jedoch, neue Schwachstellen zu identifizieren und verantwortungsvoll offenzulegen. Im .NET-Ökosystem gibt es derzeit keine zentrale Stelle, um Schwachstellen in Open-Source-Bibliotheken zu melden. Snyk ist eine CVE Numbering Authority (CNA). Das bedeutet, dass wir neuen Schwachstellen eine CVE-Nummer zuweisen können (eine Art ID für eine Schwachstelle) und sie in relevante Datenbanken aufnehmen. Als CNA kann Snyk Sie dabei unterstützen, Schwachstellen verantwortungsvoll zu melden. Weitere Informationen zu diesem Prozess finden Sie hier: https://snyk.io/vulnerability-disclosure.

Vielen Dank!

Vielen Dank, dass Sie unseren neuen Bericht zur .NET-Sicherheit gelesen haben. Wir hoffen, er hat Ihnen gefallen. Wir möchten Sie dabei unterstützen, Open Source zu nutzen und sicher zu bleiben. Freuen Sie sich daher auf weitere Ressourcen dieser Art. Denken Sie daran: Sie können den vollständigen Bericht kostenlos herunterladen.

Laden Sie den Bericht zu Einblicke in die Open-Source-Sicherheit im .NET-Ökosystem herunter.