Die 10 größten Sicherheitsprobleme von Apps und wie man sich schützt

Sie wissen, dass Ihre neueste Webanwendung von Natur aus anfällig für alle Arten von Angriffen ist. Sie wissen auch, dass App-Sicherheit niemals perfekt sein kann, aber Sie können sie morgen besser machen als sie gestern war.

Das Problem ist, dass, egal ob Sie 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, Ihr Toolkit Ihnen nicht helfen kann, Folgendes zu sehen:

• 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.json Datei.
• Warum Sie bestimmte Schwachstellen sofort beheben sollten und warum andere eine geringere Priorität haben.

Aikido existiert, um App-Sicherheit für Entwickelnde relevant und effizient zu machen, die die richtigen Sicherheits-Fixes schnell anwenden und sich wieder dem Code-Versand widmen müssen. Genau wie auf unserer entwickelnden-zentrierten Sicherheitsplattform werden wir das Rauschen um gängige Schwachstellen reduzieren und uns auf drei wesentliche Details konzentrieren:

• Der TL;DR, der Ihnen gerade genug beibringt, um Angst zu bekommen… und die richtigen Keywords, um Ihre Bildungsrecherche 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 „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 unsanitisierte und unvalidierte Benutzereingaben ermöglicht, was 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, wodurch alle anderen von Ihnen implementierten App-Sicherheitsmaßnahmen vollständig aufgehoben werden.

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, der eine spezifische Operation mit Benutzerdaten durchführt – selbst wenn Sie Allowlists verwendet haben, um den Datenverkehr 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 Angreifern den Zugriff auf Dateien und Verzeichnisse auf Ihrem Webserver, indem sie Dateien referenzieren mit ../ Sequenzen oder sogar absolute Pfade. Mit raffinierten Taktiken wie Double Encoding können Angreifer framework-spezifische 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 Verweise 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 ../ Pfadtrennzeichen 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 ein 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)

TL;DR: LFI-Angriffe beinhalten das Austricksen Ihrer App, um 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 ermöglicht, führen LFI-Angriffe diese Dateien innerhalb Ihrer App aus, wodurch Sie einer langen Liste von App-Sicherheitslücken 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 von Dateinamen und Speicherorten, 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=true&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 Positivliste vertrauenswürdiger Domains und Pfade basieren, zu denen Sie Benutzer nach bestimmten Aktionen umleiten können. Dies könnte die Benutzererfahrung geringfügig beeinträchtigen, ist aber ein sinnvoller Kompromiss für eine bessere App-Sicherheit und nicht einer, der dazu führt, dass sie Ihnen die seltsamen Ausgaben auf ihrer Kreditkartenabrechnung anlasten.

Wie geht es weiter mit Ihrer App-Sicherheit?

Wenn Sie sich von der Vielzahl 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, all diese Sicherheitsprobleme und möglichen Schwachstellen selbst zu lösen. SQL-Injection-Angriffe existieren allein schon seit Jahrzehnten, und es werden ständig CVEs in komplexen Anwendungen, Frameworks und Bibliotheken gefunden. Das soll nicht heißen, dass Sie diese Sicherheitsprobleme auf die leichte Schulter nehmen sollten – wenn Ihr Projekt die ✅ für eines dieser Top-10-App-Sicherheitsprobleme erfüllt, sollten Sie Maßnahmen ergreifen.

Zuerst, melden Sie sich bei Aikido an, um sich auf die echten Bedrohungen Ihrer App-Sicherheit zu konzentrieren. In zwei Minuten und kostenlos können Sie Repositories scannen und relevante Details sowie geführte Behebungen für die kritischsten Schwachstellen erhalten, basierend auf der spezifischen Architektur Ihrer App und den von Ihnen implementierten Features, Funktionen und Hilfsbibliotheken. Mit Aikido reduzieren Sie den Umfang auf das Wesentliche, implementieren intelligente Fixes schneller und werden sofort über neue Sicherheitsprobleme informiert, die in Ihren neuesten Commits eingeführt wurden.

Fügen Sie als Nächstes Runtime, unsere Open-Source Embedded Security Engine, zu Ihren Node.js-Anwendungen hinzu. Runtime schützt Ihre Anwendungen sofort und autonom vor verschiedenen Injection-, Prototype Pollution- und Path Traversal-Angriffen, indem es diese auf Server-Ebene blockiert, jedoch ohne die Kosten und Komplexität von Anwendungs-Firewalls oder Agent-basierten Application Security Management Plattformen. Runtime gibt Ihnen die Gewissheit, dass Ihre Anwendung und Ihre Nutzer vor diesen gängigen Sicherheitsproblemen sicher sind, kann aber auch Echtzeitdaten an Aikido zurücksenden, um Ihnen Einblicke in aktuelle Angriffsvektoren zu geben und Ihnen bei der Priorisierung von Korrekturen zu helfen.

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 darauf konzentrieren sollten, die kritischsten Probleme zuerst zu beheben.
• Warum App-Sicherheit und Schwachstellen-Scanning keine einmalige Anstrengung, sondern ein kontinuierlicher Prozess ist – einer, der mit Aikido erheblich einfacher wird.