Warum sind Sie hier?
Sie wissen, dass Ihre Anwendungen anfällig für alle Arten von Angriffen sind. Insgesamt wird prognostiziert, dass Cyberkriminalität im Jahr 2025 Kosten von 9,5 Billionen US-Dollar verursachen wird, laut Cybersecurity Ventures – das ist eine Verdreifachung gegenüber 2015. Und letztes Jahr machten Webanwendungsangriffe 12 % aller Datenlecks aus, gegenüber 9 % im Vorjahr. Dieser stetige Anstieg, gepaart mit der Tatsache, dass das Versäumnis, Webanwendungen zu sichern, zahlreiche Vorschriften verletzen kann, bedeutet, dass Entwickelnde die Bedrohungen, die sie am stärksten betreffen, besser verstehen wollen.
Wir werden also das Rauschen um gängige Schwachstellen reduzieren und uns auf drei wesentliche Details konzentrieren:
- Das TL;DR, das Sie besser darüber informiert, um welche Art von Angriff es sich handelt.
- Eine prägnante Antwort auf die Frage „Betrifft mich das?“ mit einem klaren Ja oder Nein (✅ oder 🙅) und einer kurzen Erklärung.
- Schnelle Tipps als Antwort auf „Wie kann ich es beheben?“, die keine teuren Tools oder kostspieligen Refactorings erfordern.
1. SQL Injection & NoSQL Injection
TL;DR: Diese klassische Schwachstelle wird durch unbereinigte und unvalidierte Benutzereingaben ermöglicht, die es Angreifern erlaubt, Abfragen direkt gegen Ihre Datenbank auszuführen. Von dort aus können sie Daten extrahieren, Datensätze ändern oder nach Belieben löschen.
Betrifft mich das?
✅ wenn Ihre App zu irgendeinem Zeitpunkt mit einer SQL- oder NoSQL-Datenbank interagiert. Injection-Angriffe gibt es seit Jahrzehnten, und automatisierte Angriffe werden Ihre Endpunkte sofort mit gängigen Exploits sondieren.
🙅 wenn Sie keine dynamischen Inhalte basierend auf Datenbankeinträgen haben. Dies könnte daran liegen, dass Sie vollständig clientseitig arbeiten, einen Static Site Generator (SSG) verwenden oder serverseitiges Rendering mit einer Datenbank durchführen, aber niemals Eingaben von Benutzern akzeptieren.
Wie behebe ich das? Zunächst und vor allem sollten Sie alle Benutzereingaben bereinigen und validieren, um unerwünschte Zeichen oder Zeichenketten zu eliminieren. Nutzen Sie Open-Source-Bibliotheken und Frameworks, die parametrisierte Abfragen ermöglichen, und verketten Sie niemals Benutzereingaben in einer Datenbankabfrage. Wenn Sie Node.js verwenden, ziehen Sie unsere Open-Source-Security-Engine Runtime in Betracht, die Sie autonom vor SQL-/NoSQL-Injection-Angriffen und mehr schützt.
2. Cross-Site-Scripting
TL;DR: XSS ist ein weiterer Injection-Angriff, der einem Angreifer ermöglicht, ein bösartiges Skript an einen anderen zu senden, wodurch potenziell dessen Authentifizierungsdaten oder vertrauliche Daten gesammelt werden können.
Betrifft mich das?
✅ wenn Ihre App Benutzereingaben akzeptiert und diese an anderer Stelle als dynamischen Inhalt ausgibt.
🙅 wenn Sie überhaupt keine Benutzereingaben akzeptieren.
Wie behebe ich das? Wie bei SQL-/NoSQL-Injection-Angriffen sollten Sie Benutzereingaben validieren, wenn Sie diese Eingaben in die href Attribut von Anker-Tags, um sicherzustellen, dass das Protokoll nicht javascriptSeien Sie vorsichtig bei der Verwendung von JavaScript-Methoden wie innerHTML oder Reacts dangerouslySetInnerHTML, der bei der Ausgabe beliebigen Code ausführen kann, der in den String eingebettet ist. Unabhängig von Ihrem Ansatz sollten Sie die HTML-Ausgabe mit Open-Source-Sanitizern wie DOMPurify um nur sauberes, nicht ausführbares HTML an Ihre Benutzer zu senden.
3. Server-Side Request Forgery (SSRF)
TL;DR: SSRF-Angriffe treten auf, wenn ein böswilliger Akteur Ihre App missbraucht, um mit ihrem zugrunde liegenden Netzwerk zu interagieren und sie wie einen Proxy zu betreiben, um zu potenziell anfälligeren oder lukrativeren Diensten zu springen.
Betrifft mich das?
✅ wenn Ihre App mit einem anderen Dienst oder einer API interagiert, die eine spezifische Operation mit Benutzerdaten durchführt – selbst wenn Sie Allow Lists verwendet haben, um den Traffic nur zwischen bekannten und vertrauenswürdigen Endpunkten einzuschränken.🙅 wenn Sie wirklich statisch sind.
Wie behebe ich das? Obwohl ein Regex zur Validierung von IP-Adressen oder Hostnamen ein guter Anfang ist, ist er oft anfällig für Umgehungen wie die Oktal-Kodierung. Zwei zuverlässigere Lösungen sind die Verwendung einer Positivliste und des nativen URL-Parsers Ihrer Plattform, um die Eingabe auf sichere und bekannte Hosts zu beschränken, sowie das Deaktivieren von Weiterleitungen in den Fetch-Anfragen. Je nach Ihrem Framework können Sie auch Open-Source-Projekte – wie ssrf-req-filter für Node.js – frei nutzen, um Anfragen an interne Hosts ordnungsgemäß abzulehnen.
4. Path Traversal
TL;DR: Diese Sicherheitslücke ermöglicht es Angreifern, auf Dateien und Verzeichnisse auf Ihrem Webserver zuzugreifen, indem sie Dateien über ..\/ Sequenzen oder sogar absolute Pfade referenzieren. Mithilfe von raffinierten Taktiken wie der doppelten Kodierung können Angreifer frameworkspezifische Ordner-Datei-Hierarchien oder gängige Dateinamen nutzen, um wertvolle Informationen zu finden.
Betrifft mich das?
✅ Ihre App läuft auf einem Webserver und enthält Referenzen auf das Dateisystem – hier gibt es kein Drumherum.
Wie behebe ich das? Ihr erster Schritt ist es, alle sensiblen Dateien, wie solche, die Umgebungsvariablen oder Secrets enthalten, aus dem Root-Verzeichnis Ihres Webservers zu entfernen und einen Prozess zu etablieren, um weitere Fehler zu vermeiden.
Speichern Sie niemals sensible Dateien, wie solche, die Umgebungsvariablen oder Secrets enthalten, im Root-Verzeichnis Ihres Webservers. Speichern Sie diese Dateien auch nicht in Ordnern, die öffentlich zugänglich sein sollen, wie dem /static und /public Ordner eines Next.js-Projekt. Entfernen Sie schließlich Pfad-Separatoren wie ../ und deren kodierte Varianten aus Benutzereingaben.
Runtime funktioniert auch fantastisch gut für Path Traversal… nur so als Hinweis.
5. XML eXternal Entity (XXE) Injection
TL;DR: XXE-Angriffe nutzen eine Schwachstelle in XML-Parsern aus, die es externen Entitäten, die durch eine Dokumenttypdefinition (DTD) referenziert werden, ermöglicht, ohne Validierung oder Bereinigung abgerufen und verarbeitet zu werden. Art und Schwere des Angriffs werden hauptsächlich durch die Fähigkeiten des Angreifers und etwaige OS-Level-Sicherheits-/Berechtigungen Ihres Infrastrukturanbieters begrenzt.
Betrifft mich das?
✅ wenn Sie XML aus irgendeinem Grund parsen, einschließlich Single-Sign-On-Authentifizierungs-Flows mittels SAML.
🙅 wenn Sie sich in Ihrer App nicht mit XML befassen müssen!
Wie behebe ich das? Deaktivieren Sie die externe DTD-Auflösung in Ihrem XML-Parser. Sie können DTDs wahrscheinlich nicht vollständig ablehnen, da es normal ist, dass einige XML-Payloads diese enthalten – lassen Sie Ihren XML-Parser einfach nichts damit anfangen.
6. Deserialisierung
TL;DR: Angreifer können bösartige Daten über eine in Ihre App integrierte Deserialisierungsfunktion senden (wie unserialize() von node-serialize), um Code remote auszuführen, einen Denial-of-Service-Angriff durchzuführen oder sogar eine Reverse Shell zu erstellen.
Betrifft mich das?
✅ wenn Ihre App Daten direkt aus Benutzerinteraktionen oder über Hintergrundfunktionen/-dienste wie Cookies, HTML-Formulare, APIs von Drittanbietern, Caching und mehr deserialisiert.
🙅 wenn Sie eine vollständig statische App betreiben, die keine der oben genannten Punkte aufweist.
Wie behebe ich das? Vermeiden Sie im Allgemeinen die Deserialisierung von Benutzereingaben (auch bekannt als nicht vertrauenswürdige Daten). Falls unbedingt erforderlich, akzeptieren Sie diese Daten nur von authentifizierten und autorisierten Benutzern, basierend auf vertrauenswürdigen Signaturen, Zertifikaten und Identitätsanbietern.
7. Shell-Injection/Command-Injection
TL;DR: Ihre App leitet Benutzereingaben direkt an die zugrunde liegende Shell des Betriebssystems weiter, auf dem Ihr Webserver und Ihre App ausgeführt werden, was Angreifern ermöglicht, beliebige Befehle auszuführen oder das Dateisystem zu durchsuchen, oft mit ausreichenden Berechtigungen, um Daten zu extrahieren oder auf ein anderes System zu wechseln.
Betrifft mich das?
✅ wenn Ihre App direkt mit dem Dateisystem oder der Shell interagiert, wie zum Beispiel mit einem UNIX-Befehl wie cat.
🙅 wenn Sie bereits eine Framework-API oder -Methode verwenden, um Argumente sicher an den auszuführenden Befehl zu übergeben, oder nicht mit dem Dateisystem/der Shell interagieren müssen, wie z. B. in einem SSG.
Wie behebe ich das? Vermeiden Sie es, Benutzereingaben direkt in Befehle zu übernehmen oder diese direkt aufzurufen. Verwenden Sie stattdessen die API/Methode Ihres Frameworks, wie zum Beispiel child_process.execFile() in Node.js, das es Ihnen ermöglicht, Argumente in einer Liste von Strings zu übergeben. Selbst mit diesem Schutz sollten Sie Ihre Apps immer mit den geringsten Privilegien ausführen, die für die erforderliche Geschäftslogik notwendig sind, um zu verhindern, dass ein Angreifer den Webserver „entkommt“ und auf root-nur Ordner und Dateien.
Und ja, wir sind zurück für eine weitere freundliche Erinnerung, hinzuzufügen Laufzeit zu jedem Node.js-Projekt mit einem Befehl (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) um Ihre App sofort vor gängigen Shell-/Command-Injection-Angriffen zu schützen.
8. Local File Inclusion (LFI)
Kurz gesagt: Bei LFI-Angriffen wird Ihre App dazu gebracht, Dateien auf dem System, auf dem Ihr Webserver läuft, offenzulegen oder auszuführen, was Angreifern ermöglicht, Informationen zu extrahieren oder Code remote auszuführen. Während Path Traversal Angreifern nur das Lesen von Dateien erlaubt, führen LFI-Angriffe diese Dateien innerhalb Ihrer App aus, wodurch Sie einer Vielzahl von Schwachstellen wie Remote Code Execution (RCE) ausgesetzt sind.
Betrifft mich das?
✅ wenn Ihre App den Pfad zu einer Datei als Benutzereingabe verwendet.
🙅 wenn Ihre App nicht erfordert, dass Benutzer Pfade angeben, um eine Aktion abzuschließen.
Wie behebe ich das? Benutzereingaben immer bereinigen, um die oben besprochenen Path-Traversal-Methoden zu verhindern. Wenn Sie Dateien auf dem lokalen Dateisystem einbinden müssen, die über die normalerweise in „sicheren“ Verzeichnissen gefundenen hinausgehen /public oder /static Ordnern, verwenden Sie eine Allowlist für Dateinamen und Speicherorte, die Ihre App lesen und ausführen darf.
9. Prototype Pollution
TL;DR: Dies JavaScript-spezifische Schwachstelle ermöglicht einem Angreifer, die globalen Objekte Ihrer App mithilfe von zu manipulieren __proto__Das neue Objekt wird dann in Ihrer gesamten App vererbt, was ihnen potenziell Zugriff auf vertrauliche Daten verschafft oder ihre Privilegien weiter eskaliert.
Betrifft mich das?
✅ wenn Sie JavaScript verwenden.
🙅 wenn Sie alles außer JavaScript verwenden!
Wie behebe ich das? Beginnen Sie damit, Schlüssel aus Benutzereingaben mithilfe von Allowlists oder einer Open-Source-Hilfsbibliothek zu bereinigen. Sie können Ihren Schutz erweitern, indem Sie Object.freeze() um Änderungen an einem Prototyp zu verhindern oder sogar die Verwendung des --disable-proto=delete Flag angeboten mit Node.js.
10. Offene Weiterleitungen
TL;DR: Bei diesem häufigen Phishing-Vektor erstellen Angreifer eine benutzerdefinierte URL wie https://www.example.com/abc/def?&success=false&redirectURL=https://example.phishing.com um Ihre App dazu zu bringen, ahnungslose Benutzer auf eine bösartige Website umzuleiten. Darüber hinaus können Angreifer Weiterleitungen mit anderen Schwachstellen verketten, um eine noch größere Wirkung zu erzielen, was zu Kontoübernahmen und mehr führt.
Betrifft mich das?
✅ wenn Ihre App Benutzer nach Abschluss einer Aktion auf eine andere Seite/Ansicht umleitet, wie zum Beispiel das Senden an example.app/dashboard nach erfolgreicher Authentifizierung.
🙅 wenn Sie noch immer auf statisch generierte Inhalte setzen.
Wie behebe ich das? Entfernen Sie zunächst parameterbasierte Weiterleitungen aus Ihrer App und ersetzen Sie diese durch feste Weiterleitungen, die auf einer Allowlist vertrauenswürdiger Domains und Pfade basieren, zu denen Sie Benutzer umleiten können, nachdem diese bestimmte Aktionen ausgeführt haben. Dies könnte die Benutzererfahrung geringfügig beeinträchtigen, aber es ist ein sinnvoller Kompromiss, um eine sichere Erfahrung zu bieten, und nicht eine, die dazu führt, dass sie Ihnen die seltsamen Ausgaben auf ihrer Kreditkartenabrechnung anlasten.
Was kommt als Nächstes?
Wenn Sie sich von der Bandbreite der Angriffe und dem gesamten Aufwand, der zu deren Abwehr erforderlich ist, überfordert fühlen, wissen Sie, dass Sie nicht allein sind.
Niemand erwartet von Ihnen, dass Sie all diese Sicherheitsprobleme und möglichen Schwachstellen selbst lösen. SQL-Injection-Angriffe existieren allein schon seit Jahrzehnten, und es werden ständig CVEs in komplexen Apps, Frameworks und Bibliotheken gefunden. Das soll nicht heißen, dass Sie diese Sicherheitsprobleme auf die leichte Schulter nehmen sollten – wenn Ihre App die ✅ für eines dieser Top-10-Sicherheitsprobleme erfüllt, sollten Sie Maßnahmen ergreifen.
Es ist wahrscheinlich, dass Sie entweder Sicherheits-Tools der Enterprise-Klasse (d.h. teuer und komplex) verwenden oder eine Handvoll Open-Source-Projekte zu einer CI/CD-Pipeline oder Git-Commit-Hooks zusammengebastelt haben und auf das Beste hoffen. Dies könnte einige Sicherheitslücken hinterlassen, wie zum Beispiel:
- Wie Ihre App aufgrund suboptimaler Programmierpraktiken, unsicherer Abhängigkeiten und darüber hinaus anfällig sein könnte.
- Wo sich die Schwachstellen am ehesten verbergen, bis hin zu einzelnen LOCs oder Einträgen in Ihrem
package.jsonDatei. - Warum Sie bestimmte Schwachstellen sofort beheben sollten und warum andere eine geringere Priorität haben.
Aikido Security hilft, diese Lücken in 2 einfachen Schritten zu schließen:
1. Scannen Sie Ihren Code mit Aikido
Registrieren Sie sich (kostenlos, dauert 2 Min.) und scannen Sie Ihre Repos. Erhalten Sie eine fokussierte Liste kritischer Schwachstellen basierend auf der tatsächlichen Architektur und Nutzung Ihrer App. Sehen Sie genau, was wichtig ist, erhalten Sie geführte Korrekturen und Benachrichtigungen über neue Probleme in Ihren neuesten Commits.
2. Schützen Sie Ihre Node.js-Apps mit Runtime
Fügen Sie unsere Open-Source-Runtime hinzu, um Injection-, Prototype Pollution- und Path Traversal-Angriffe auf Serverebene zu blockieren – ohne den Overhead von WAFs oder Agents. Runtime sendet auch Echtzeit-Angriffsdaten zurück an Aikido, damit Sie sehen können, was angegriffen wird, und Korrekturen priorisieren können.
Sie sind nun auf dem richtigen Weg und haben ein klareres Bild bezüglich:
- Wie Ihre App auf mehr Arten anfällig ist, als Sie vielleicht einst dachten.
- Wo Sie Ihre Zeit und Aufmerksamkeit konzentrieren sollten, um die kritischsten Probleme zuerst zu beheben.
- Warum Sicherheits- und Schwachstellenscans keine einmalige Anstrengung, sondern ein kontinuierlicher Prozess sind.
Sichern Sie Ihre Software jetzt.
.avif)
