Sie wissen, dass Ihre neueste Webanwendung von Natur aus anfällig für alle Arten von Angriffen ist. Sie wissen auch, dass die Anwendungssicherheit nie perfekt sein kann, aber Sie können sie morgen besser machen als gestern.
Das Problem ist, dass Sie entweder Sicherheitstools auf Unternehmensebene (d. h. teure und komplexe Tools) verwenden oder eine Handvoll Open-Source-Projekte zu einer CI/CD-Pipeline oder Git-Commit-Hooks zusammengeschustert haben und auf das Beste hoffen - Ihr Toolkit kann Ihnen nicht helfen, zu sehen:
- Wie Ihre Anwendung aufgrund von nicht idealen Programmierpraktiken, unsicheren Abhängigkeiten und mehr anfällig sein könnte.
- Wo die Schwachstellen höchstwahrscheinlich versteckt sind, bis hin zu einzelnen LOCs oder Einträgen in Ihrem
paket.jsonDatei. - Warum Sie bestimmte Schwachstellen sofort beheben sollten und warum andere weniger wichtig sind.
Aikido wurde entwickelt, um die Sicherheit von Apps für Entwickler relevant und effizient zu machen, die schnell die richtigen Sicherheitskorrekturen anwenden und wieder mit der Auslieferung von Code beginnen müssen. Genau wie bei unserer entwicklerzentrierten Sicherheitsplattform werden wir das Rauschen um häufige Schwachstellen reduzieren und uns auf drei wesentliche Details konzentrieren:
- Die Kurzfassung, die Ihnen gerade genug beibringt, um Angst zu haben ... und die richtigen Schlüsselwörter, um Ihre Bildungssuche fortzusetzen.
- 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 die Frage "Wie kann ich das Problem beheben?", die keine teuren Tools oder kostspieligen Refactors erfordern.
#1: SQL-Injektion && NoSQL-Injektion
TL;DR: Diese klassische Schwachstelle wird durch nicht sanitisierte und nicht validierte Benutzereingaben ermöglicht, die es Angreifern erlauben, Abfragen direkt an Ihrer Datenbank durchzuführen. Von dort aus können sie Daten extrahieren, Datensätze ändern oder nach Belieben löschen und dabei alle anderen von Ihnen eingerichteten Sicherheitsmaßnahmen für die App vollständig außer Kraft setzen.
Hat das Auswirkungen auf mich?
- ✅ wenn Ihre Anwendung an irgendeiner Stelle mit einer SQL- oder NoSQL-Datenbank interagiert. Injection-Angriffe gibt es seit Jahrzehnten, und automatisierte Angriffe werden sofort damit beginnen, Ihre Endpunkte mit gängigen Exploits zu untersuchen.
- 🙅 wenn Sie keine dynamischen Inhalte auf der Grundlage von Datenbankeinträgen haben. Dies könnte daran liegen, dass Sie vollständig clientseitig arbeiten, einen statischen Website-Generator (SSG) verwenden oder serverseitiges Rendering mit einer Datenbank durchführen, aber nie Eingaben von Benutzern akzeptieren.
Wie kann ich das Problem beheben? Zuallererst sollten Sie alle Benutzereingaben bereinigen und validieren, um unerwünschte Zeichen oder Zeichenfolgen zu entfernen. Nutzen Sie Open-Source-Bibliotheken und -Frameworks, die parametrisierte Abfragen ermöglichen, und verketten Sie niemals Benutzereingaben in eine Datenbankabfrage. Wenn Sie Node.js verwenden, sollten Sie unsere Open-Source-Sicherheits-Engine Runtime in Betracht ziehen, die Sie selbstständig vor SQL/NoSQL-Injektionsangriffen und mehr schützt.
#Nr. 2: Cross-Site-Scripting (XSS)
TL;DR: XSS ist ein weiterer Injektionsangriff, der es einem Angreifer ermöglicht, ein bösartiges Skript an eine andere Person zu senden und so möglicherweise deren Authentifizierungsdaten oder vertrauliche Daten zu sammeln.
Hat das Auswirkungen auf mich?
- ✅ wenn Ihre Anwendung Benutzereingaben akzeptiert und diese an anderer Stelle als dynamische Inhalte ausgibt.
- 🙅 wenn Sie überhaupt keine Benutzereingaben akzeptieren.
Wie kann ich es reparieren? Wie bei SQL/NoSQL-Injektionsangriffen sollten Sie Benutzereingaben validieren, wenn Sie diese Eingaben in die href Attribut von Anker-Tags, um sicherzustellen, dass das Protokoll nicht javascript. Seien Sie vorsichtig bei der Verwendung von JavaScript-Methoden wie innerHTML oder Reacts dangerouslySetInnerHTMLdie während der Ausgabe willkürlich jeden in die Zeichenkette eingebetteten Code ausführen kann. 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.
#Nr. 3: Server-seitige Anforderungsfälschung (SSRF)
TL;DR: SSRF-Angriffe finden statt, wenn ein böswilliger Akteur Ihre Anwendung missbraucht, um mit dem zugrundeliegenden Netzwerk zu interagieren und sie wie einen Proxy zu betreiben, um auf potenziell anfälligere oder lukrativere Dienste zuzugreifen.
Hat das Auswirkungen auf mich?
- ✅ wenn Ihre Anwendung eine Schnittstelle zu einem anderen Dienst oder einer API hat, die einen bestimmten Vorgang mit Benutzerdaten durchführt - selbst wenn Sie mithilfe von Zulassen-Listen den Datenverkehr nur zwischen bekannten und vertrauenswürdigen Endpunkten eingeschränkt haben.
- 🙅 wenn Sie wirklich statisch sind.
Wie kann ich das beheben? Ein Regex zur Validierung von IP-Adressen oder Hostnamen ist zwar ein guter Anfang, aber er ist in der Regel anfällig für Umgehungen wie die Oktal-Kodierung. Zwei zuverlässigere Lösungen sind die Verwendung einer Zulassen-Liste und des plattformeigenen URL-Parsers, um die Eingabe auf sichere und bekannte Hosts zu beschränken, sowie die Deaktivierung von Weiterleitungen in den Abrufanforderungen. Abhängig von Ihrem Framework können Sie auch Open-Source-Projekte wie ssrf-req-filter für Node.js nutzen, um Anfragen an interne Hosts abzulehnen.
#4: Pfadüberquerung
TL;DR: Diese Sicherheitslücke ermöglicht es Angreifern, auf Dateien und Verzeichnisse auf Ihrem Webserver zuzugreifen, indem sie auf Dateien mit ../ Sequenzen oder sogar absolute Pfade. Mit hinterhältigen Taktiken wie der doppelten Kodierung können Angreifer rahmenspezifische Datei-Ordner-Hierarchien oder allgemeine Dateinamen nutzen, um wertvolle Informationen zu finden.
Hat das Auswirkungen auf mich?
- ✅. Ihre Anwendung läuft auf einem Webserver und enthält Verweise auf das Dateisystem - hier gibt es keine Umgehungsmöglichkeiten.
Wie kann ich das Problem beheben? Der erste Schritt besteht darin, alle sensiblen Dateien, z. B. solche, die Umgebungsvariablen oder Geheimnisse enthalten, aus dem Stammverzeichnis Ihres Webservers zu entfernen und einen Prozess einzurichten, um weitere Fehler zu vermeiden.
Speichern Sie sensible Dateien, die beispielsweise Umgebungsvariablen oder Geheimnisse enthalten, niemals im Stammverzeichnis Ihres Webservers. Speichern Sie diese Dateien auch nicht in einem öffentlich zugänglichen Ordner, wie dem /statisch und /Öffentlich Mappen eines Next.js-Projekt. Zum Schluss: Abziehen ../ Pfadseparatoren und ihre kodierten Varianten aus Benutzereingaben.
Runtime funktioniert auch phantastisch für die Pfadüberquerung... das nur nebenbei.
#5: XML eXternal Entity (XXE) Injektion
TL;DR: XXE-Angriffe nutzen eine Schwachstelle in XML-Parsern aus, die es externen Entitäten, auf die eine Dokumenttypdefinition (DTD) verweist, ermöglicht, ohne Validierung oder Bereinigung abgerufen und verarbeitet zu werden. Die Art und Schwere des Angriffs wird hauptsächlich durch die Fähigkeiten des Angreifers und die Sicherheitsvorkehrungen auf Betriebssystemebene bzw. die Erlaubnis Ihres Infrastrukturanbieters begrenzt.
Hat das Auswirkungen auf mich?
- ✅ wenn Sie XML aus irgendeinem Grund parsen, einschließlich Single-Sign-On-Authentifizierungsströme mit SAML.
- 🙅 wenn Sie in Ihrer Anwendung nicht mit XML umgehen müssen!
Wie kann ich das Problem beheben? Deaktivieren Sie die externe DTD-Auflösung in Ihrem XML-Parser. Sie können DTDs wahrscheinlich nicht ganz ablehnen, da es normal ist, dass einige XML-Nutzdaten sie enthalten - lassen Sie Ihren XML-Parser einfach nichts mit ihnen anfangen.
#Nr. 6: Deserialisierung
TL;DR: Angreifer können bösartige Daten über eine in Ihrer Anwendung integrierte Deserialisierungsfunktion (wie unserialisieren() von node-serialize), um aus der Ferne Code auszuführen, einen Denial-of-Service auszuführen oder sogar eine Reverse Shell zu erstellen.
Hat das Auswirkungen auf mich?
- ✅ wenn Ihre Anwendung Daten direkt aus der Benutzerinteraktion oder über Hintergrundfunktionen/-dienste wie Cookies, HTML-Formulare, APIs von Drittanbietern, Caching usw. deserialisiert.
- 🙅 wenn Sie eine vollständig statische Anwendung mit keinem der oben genannten Punkte ausführen.
Wie kann ich das beheben? Vermeiden Sie generell die Deserialisierung von Benutzereingaben (auch als nicht vertrauenswürdige Daten bezeichnet). Wenn Sie müssen, akzeptieren Sie nur Daten von authentifizierten und autorisierten Benutzern auf der Grundlage von vertrauenswürdigen Signaturen, Zertifikaten und Identitätsanbietern.
#Nr. 7: Shell-Injektion/Befehlsinjektion
TL;DR: Ihre Anwendung gibt Benutzereingaben direkt an die zugrundeliegende Shell des Betriebssystems weiter, auf dem Ihr Webserver und Ihre Anwendung ausgeführt werden. Dies ermöglicht Angreifern die Ausführung beliebiger Befehle oder die Durchquerung des Dateisystems, oft mit ausreichenden Rechten, um Daten zu extrahieren oder auf ein anderes System zu wechseln.
Hat das Auswirkungen auf mich?
- ✅ wenn Ihre Anwendung direkt mit dem Dateisystem oder der Shell interagiert, z. B. mit einem UNIX-Befehl wie
Katze. - 🙅 wenn Sie bereits eine Framework-API oder -Methode verwenden, um Argumente sicher an den auszuführenden Befehl zu übergeben, oder wenn Sie nicht mit dem Dateisystem/der Shell interagieren müssen, wie z. B. in einer SSG.
Wie kann ich es reparieren? Vermeiden Sie es, Benutzereingaben direkt in Befehle zu übernehmen oder sie direkt aufzurufen. Verwenden Sie stattdessen die API/Methode Ihres Frameworks, wie child_process.execFile() in Node.js, mit dem Sie Argumente in einer Liste von Zeichenketten übergeben können. Selbst mit diesem Schutz sollten Sie Ihre Anwendungen immer mit den geringsten Rechten ausführen, die für die erforderliche Geschäftslogik erforderlich sind, um zu verhindern, dass ein Angreifer dem Webserver "entkommt" und auf die Wurzel-Ordner und Dateien.
Und ja, wir sind wieder da, um eine weitere freundliche Erinnerung hinzuzufügen Laufzeit zu jedem Node.js-Projekt mit einem einzigen Befehl (npm add @aikidosec/runtime || yarn install @aikidosec/runtime), um Ihre Anwendung sofort vor gängigen Shell-/Befehlsinjektionsangriffen zu schützen.
#Nr. 8: Einbindung lokaler Dateien (LFI)
TL;DR: Bei LFI-Angriffen wird Ihre Anwendung dazu gebracht, Dateien auf dem System, auf dem Ihr Webserver läuft, offenzulegen oder auszuführen, wodurch Angreifer Informationen extrahieren oder Code aus der Ferne ausführen können. Während Path Traversal es Angreifern nur ermöglicht, Dateien zu lesen, führen LFI-Angriffe diese Dateien innerhalb Ihrer App aus und öffnen Sie für eine ganze Reihe von App-Sicherheitsschwachstellen wie Remote Code Execution (RCE).
Hat das Auswirkungen auf mich?
- ✅ wenn Ihre Anwendung den Pfad zu einer Datei als Benutzereingabe verwendet.
- 🙅 wenn Ihre Anwendung nicht verlangt, dass die Benutzer Pfade eingeben, um eine Aktion abzuschließen.
Wie kann ich es reparieren? Bereinigen Sie immer die Benutzereingaben, um die oben beschriebenen Methoden zur Pfadumgehung zu verhindern. Wenn Sie Dateien auf dem lokalen Dateisystem einbinden müssen, die nicht typischerweise in "sicheren" /Öffentlich oder /statisch Ordnern verwenden Sie eine Liste mit Dateinamen und Speicherorten, die Ihre Anwendung lesen und ausführen darf.
#Nr. 9: Prototyp der Umweltverschmutzung
TL;DR: Diese JavaScript-spezifische Sicherheitslücke lässt einen Angreifer die globalen Objekte Ihrer Anwendung manipulieren, indem er __proto__. Das neue Objekt wird dann in Ihrer gesamten Anwendung vererbt, wodurch sie möglicherweise Zugriff auf vertrauliche Daten erhalten oder ihre Berechtigungen weiter ausbauen können.
Hat das Auswirkungen auf mich?
- ✅ wenn Sie JavaScript verwenden.
- 🙅 wenn du etwas anderes als JavaScript verwendest!
Wie kann ich es reparieren? Beginnen Sie damit, Schlüssel aus Benutzereingaben mit allowlists oder einer Open-Source-Hilfsbibliothek zu bereinigen. Sie können Ihren Schutz erweitern, indem Sie Objekt.einfrieren() um Änderungen an einem Prototyp zu verhindern, oder sogar mit der --disable-proto=delete Flagge, die mit Node.js angeboten wird.
#10: Offene Weiterleitungen
TL;DR: Bei diesem häufigen Phishing-Vektor erstellen die Angreifer eine benutzerdefinierte URL wie https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com um Ihre Anwendung dazu zu bringen, ahnungslose Nutzer auf eine bösartige Website umzuleiten. Darüber hinaus können Angreifer Umleitungen mit anderen Schwachstellen koppeln, um die Wirkung noch zu verstärken und Konten zu übernehmen und mehr.
Hat das Auswirkungen auf mich?
- ✅ wenn Ihre Anwendung den Benutzer nach Abschluss einer Aktion auf eine andere Seite/Ansicht weiterleitet, z. B. zu
beispiel.app/dashboardnach erfolgreicher Authentifizierung. - 🙅 wenn du immer noch dieses statisch erzeugte Leben lebst.
Wie kann ich das Problem beheben? Entfernen Sie zunächst die parameterbasierten Weiterleitungen aus Ihrer App und ersetzen Sie sie durch feste Weiterleitungen, die auf einer Liste vertrauenswürdiger Domänen und Pfade basieren, zu denen Sie die Nutzer nach bestimmten Aktionen weiterleiten können. Dies könnte das Benutzererlebnis etwas beeinträchtigen, ist aber ein sinnvoller Kompromiss für eine bessere App-Sicherheit und nicht einer, bei dem die Benutzer Ihnen die Schuld für die seltsamen Ausgaben auf ihrer Kreditkartenabrechnung geben.
Wie geht es weiter mit der Sicherheit Ihrer Anwendungen?
Wenn Sie sich angesichts des Ausmaßes der Angriffe und der zum Schutz davor erforderlichen Arbeiten überfordert fühlen, sind Sie nicht allein.
Niemand erwartet von Ihnen, dass Sie all diese Sicherheitsprobleme und möglichen Schwachstellen selbst lösen. Allein SQL-Injection-Angriffe gibt es schon seit Jahrzehnten, und es werden immer noch ständig CVEs in anspruchsvollen Anwendungen, Frameworks und Bibliotheken gefunden. Das soll nicht heißen, dass Sie diese Sicherheitsprobleme mit Vorsicht genießen sollten - wenn Ihr Projekt auf eines der 10 wichtigsten App-Sicherheitsprobleme zutrifft, sollten Sie Maßnahmen ergreifen.
Melden Sie sich zunächst für Aikido an, um sich auf die echten Bedrohungen für die Sicherheit Ihrer App zu konzentrieren. In zwei Minuten und kostenlos können Sie Repositories scannen und erhalten relevante Details sowie geführte Abhilfemaßnahmen für die kritischsten Schwachstellen auf der Grundlage der spezifischen Architektur Ihrer App und der von Ihnen implementierten Features, Funktionen und Hilfsbibliotheken. Mit Aikido können Sie den Umfang auf das Wesentliche reduzieren und intelligente Korrekturen schneller implementieren. Außerdem werden Sie sofort über neue Sicherheitsprobleme informiert, die in Ihren letzten Commits eingeführt wurden.
Als nächstes fügen Sie Runtime, unsere eingebettete Open-Source-Sicherheits-Engine, zu Ihren Node.js-Anwendungen hinzu. Runtime schützt Ihre Anwendungen sofort und autonom gegen verschiedene Injektions-, Prototypverschmutzungs- und Path-Traversal-Angriffe, indem es sie auf Server-Ebene blockiert, jedoch ohne die Kosten und die Komplexität von Web Application Firewalls oder Agent-basierten Application Security Management-Plattformen. Runtime gibt Ihnen die Gewissheit, dass Ihre Anwendung und Ihre Benutzer vor diesen häufigen Sicherheitsproblemen sicher sind, kann aber auch Echtzeitdaten an Aikido zurückmelden, um Ihnen Einblick in aktuelle Angriffsvektoren zu geben und Ihnen bei der Priorisierung von Korrekturmaßnahmen zu helfen.
Jetzt sind Sie auf dem richtigen Weg und haben ein klareres Bild davon:
- Wie Ihre App auf mehr Arten verwundbar ist, als Sie vielleicht einmal gedacht haben.
- Worauf Sie Ihre Zeit und Aufmerksamkeit richten sollten, um die wichtigsten Probleme zuerst zu beheben.
- Warum App-Sicherheit und Schwachstellen-Scans keine einmalige Angelegenheit sind, sondern ein kontinuierlicher Prozess - einer, der mit Aikido viel einfacher ist.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)