Warum sind Sie hier?
Sie haben schon von JavaScript SQL-Injection-Angriffen gehört, sind sich aber nicht ganz sicher, wie diese in der Praxis aussehen oder ob Sie sich überhaupt Sorgen machen müssen. Vielleicht versuchen Sie herauszufinden, wie schlimm es wirklich sein könnte.
Kurz gesagt, wenn Sie Anwendungen mit SQL-Datenbanken wie MySQL und PostgreSQL entwickeln, sind Sie gefährdet – Sie sind nicht sicher vor Angriffsmethoden, die Entwickelnde und ihre Datenbanken seit Jahrzehnten plagen. Als Entwickelnde liegt es in Ihrer Verantwortung, Schutzmaßnahmen zu implementieren, die Benutzerdaten schützen und sicherstellen, dass Ihre zugrunde liegende Infrastruktur niemals unbefugt betreten, erkundet oder übernommen wird.
Alle neuen Tools versprechen, Ihnen zu helfen, aber sie machen die Entwicklung nur komplexer.
Sie können einen Object-Relational Mapper (ORM) wie Sequelize und TypeORM hinzufügen, um die Arbeit mit SQL-Datenbanken wie MySQL und PostgreSQL zu vereinfachen, aber diese befreien Sie nicht vollständig vom Risiko. Web Application Firewalls (WAFs) helfen Ihnen, Angriffe auf Netzwerkebene zu blockieren, erfordern jedoch eine teure Infrastruktur und ständige Wartung. Code-Scanner können Ihnen helfen, offensichtliche Schwachstellen zu identifizieren, leisten aber weit weniger für die unbekannten Unbekannten und lauernden Zero-Day-Techniken.
Wir werden Ihnen ein klares Bild davon vermitteln, wie SQL-Injection-Angriffe aussehen, welches Risiko sie bergen und welche Entwicklungsfehler sie ermöglichen. Dann gehen wir noch einen Schritt weiter und führen Sie durch die Installation eines globalen Hotfixes, damit Sie mit Sicherheit wissen, dass Ihre Anwendungen sicher sind.
SQL-Injection-Angriffe: Beispiele und Auswirkungen
Die grundlegendste Definition eines SQL-Injection-Angriffs ist, wenn eine Anwendung unvalidierte und unbereinigte Benutzereingaben zulässt, um Datenbankabfragen auszuführen, wodurch ein Angreifer die SQL-Datenbank lesen, Datensätze ändern oder nach Belieben löschen kann.
Wie üblich veranschaulicht XKCD die Gefahr von SQL besser als die meisten düsteren Szenarien, die wir uns ausdenken könnten:
Wie sieht eine anfällige JavaScript-App aus?
Beginnen wir mit einem einfachen Pseudocode-Beispiel: einer JavaScript-App mit einem Eingabeelement, das Benutzern die Suche in einer Katzendatenbank ermöglicht. Im folgenden JavaScript-Code-Beispiel antwortet die App auf POST-Anfragen auf dem Pfad /cats, um die Benutzereingabe aus dem Request Body zu extrahieren, und verbindet sich mit der Datenbank mit einer Abfrage, um alle Katzen mit einer passenden ID zurückzugeben. Die App zeigt dann die Katze mithilfe der JSON-Antwort an.
app.post("/cats", (request, response) => {
const query = `SELECT * FROM cats WHERE id = ${request.body.id}`;
connection.query(query, (err, rows) => {
if(err) throw err;
response.json({
data: rows
});
});
});
Auch wenn dieses Beispiel für diejenigen, die nicht mit SQL-Injection-Angriffen vertraut sind, harmlos erscheinen mag, ist es eklatant anfällig. Insbesondere versucht die App nicht, Benutzereingaben auf potenziell gefährliche Zeichenfolgen oder Kodierungsmethoden zu validieren oder zu bereinigen, und vercattet Benutzereingaben direkt in die SQL-Abfrage, was Angreifern vielfältige Möglichkeiten bietet, mit gängigen SQL-Injection-Angriffsmethoden anzugreifen, die seit Jahrzehnten existieren.
Beispiel JavaScript SQL-Angriffspayloads
SQL-Injection basiert darauf, Ihre MySQL- oder PostgreSQL-Datenbank dazu zu bringen, Aktionen auszuführen oder mit Daten außerhalb des erwarteten Bereichs zu antworten, aufgrund der Art und Weise, wie Ihre App SQL-Abfragen generiert.
Der 1=1 ist immer wahr Angriff kann die gesamte Tabelle der Katzen mit Tricks wie Apostrophen oder Anführungszeichen zurückgeben, weil 1=1 tatsächlich immer TRUE:
- Der Benutzer gibt ein:
BOBBY TABLES’ OR 1=’1 - Die Datenbank führt die SQL-Abfrage aus:
SELECT * FROM Users WHERE Cat = BOBBY TABLES OR 1=1;
Ähnlich können Angreifer einen = ist immer wahr Angriff nutzen, um alle Katzen zurückzugeben, weil ""="" immer TRUE:
- Der Benutzer gibt ein:
" OR ""=" - Die Datenbank führt die SQL-Abfrage aus:
SELECT * FROM Cats WHERE CatId ="" or ""="";
Angreifer nutzen oft aus, wie Datenbanken Inline-Kommentare verarbeiten, und indem sie Kommentare einfügen (/* … */) in eine Abfrage, können sie ihre Absicht verschleiern oder Filter umgehen.
- Der Benutzer gibt ein:
DR/*hello world*/OP/*sneak attack*/ TABLE Cats; - Die Datenbank führt die SQL-Abfrage aus:
DROP TABLE Cats;
Eine weitere gängige JavaScript SQL-Injection-Strategie ist Query Stacking, die es Angreifern ermöglicht, mit einer harmlosen Zeichenkette zu beginnen, dann ein Semikolon (;) zu verwenden, um diese Anweisung zu beenden und eine weitere mit ihrer Injection zu starten. Angreifer nutzen Query Stacking oft, um ganze Datenbanken mit einem DROP TABLE-Befehl auf einen Schlag zu löschen:
- Der Benutzer gibt ein:
Bobby; DROP TABLE Cats -- - Die App erstellt ihre SQL-Abfrage:
const query = "SELECT * FROM Cats WHERE CatId = " + input; - Die Datenbank führt die SQL-Abfrage aus:
SELECT * FROM Cats WHERE CatId = BOBBY; DROP TABLE Cats;
Was ist mit NoSQL-Injection-Angriffen?
NoSQL-Injection-Angriffe sind gleichermaßen gefährlich für die Sicherheit Ihrer App und Benutzerdaten, betreffen aber nur Tech Stacks, die Datenbanken wie MongoDB verwenden. Der Hauptunterschied liegt im Stil der Angriffe, da SQL- und NoSQL-Abfragen eine völlig einzigartige Syntax verwenden, die nicht von einer Kategorie in die andere übersetzbar ist.
Wenn Sie eine SQL-Datenbank verwenden, sind Sie nicht von NoSQL-Injection-Angriffen bedroht und umgekehrt.
Der grundlegende Weg: alle Ihre SQL-Injection-Schwachstellen manuell beheben
An diesem Punkt sind Sie vielleicht weniger daran interessiert, wie all die möglichen Injection-Tricks aussehen, und mehr daran, wie Sie die Daten in MySQL oder PostgreSQL schützen können.
- Parametrisierte Abfragen verwenden: SQL verfügt über Funktionen, um die Ausführung von Abfragen und Werten zu trennen, wodurch die Datenbank vor Injection-Angriffen geschützt wird. Mit dem obigen JavaScript/Node.js-Beispiel können Sie einen Platzhalter in Ihrer SQL-Abfrage mit einem Fragezeichen (
?). Dieconnection.query()Methode nimmt den Parameter dann als zweites Argument und liefert die gleichen Ergebnisse in einer injectionsicheren Methode.
app.post("/cats", (request, response) => {
const query = `SELECT * FROM Cats WHERE id = ?`;
const value = request.body.id;
connection.query(query, value, (err, rows) => {
if(err) throw err;
response.json({
data: rows
});
});
});
- Benutzereingaben validieren und bereinigen: Während parametrisierte Abfragen dazu beitragen können, Ihre SQL-Datenbank vor Eindringlingen und Angriffen zu schützen, können Sie auch verhindern, dass Benutzer potenziell gefährliche Zeichenketten in Ihre Anwendung eingeben.
Eine Möglichkeit ist, Open-Source-Bibliotheken zur Bereinigung und Validierung zu Ihrer App hinzuzufügen. Zum Beispiel können Sie validator.js im JavaScript-/Node.js-Ökosystem, um zu überprüfen, ob ein Benutzer eine echte E-Mail-Adresse – und keinen SQL-Injection-Angriff – in Ihr Anmeldeformular eingeben möchte.
Sie können auch benutzerdefinierte Regex-basierte Validatoren entwickeln, um ähnliche Aufgaben zu erledigen, aber Sie haben einen enorm zeitaufwändigen und komplexen Weg vor sich, mit Recherche und tonnenweise manuellem Testen. Können Sie außerdem dieses Beispiel-Regex für die E-Mail-Validierung wirklich interpretieren?const re = /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
Dasselbe gilt für die Verhinderung von Strings wie…’ OR 1-’1.Sie können versuchen, all diese Möglichkeiten selbst zu recherchieren und zu schließen, aber Sie würden Ihre Zeit wahrscheinlich lieber mit der Entwicklung neuer Funktionen verbringen.
- WAFs oder agentenbasierte Sicherheitsplattformen bereitstellen: Während diese Lösungen SQL-Angriffe blockieren können, bevor sie Ihre App überhaupt erreichen, oder Sie zumindest in Echtzeit über Angriffe benachrichtigen, sind sie mit einigen Einschränkungen verbunden.
Erstens sind sie oft teuer und erfordern die Einrichtung neuer Infrastruktur on-premise oder in der Cloud, was oft weitaus komplexer ist, als es für Entwickelnde, die einfach nur in Produktion gehen wollen, gedacht war. Zweitens erfordern sie mehr manuelle Wartung, um das Regelsatz zu aktualisieren, was von anderen manuellen Eingriffen bei SQL-Injections ablenkt. Schließlich erhöhen sie oft die Rechenlast oder leiten alle Anfragen zur Analyse über ihre Plattform um, was Latenzzeiten hinzufügt und die Endbenutzererfahrung beeinträchtigt.
Das große Problem ist, dass Möglichkeiten für SQL-Injection-Angriffe wie Unkraut sind – man kann sie mit diesen Tools einmal alle entfernen, aber Sie müssen Ihre gesamte Codebasis ständig überwachen, um sicherzustellen, dass sie nie wieder sprießen.
Ein alternativer Weg zur Lösung von JavaScript SQL-Injection-Angriffen: Aikido Firewall
Aikido Security hat kürzlich Firewall veröffentlicht, eine kostenlose und quelloffene Sicherheits-Engine, die Sie autonom vor SQL-Injection-Angriffen schützt – und noch vielem mehr.
Wenn Sie Node.js nicht verwenden, beachten Sie bitte, dass wir in Zukunft auch andere Sprachen und Frameworks unterstützen werden. Sie können sich jederzeit für unseren Produkt-Newsletter anmelden, um genau zu erfahren, wann Firewall über die JavaScript-Welt hinaus erweitert wird, oder uns eine E-Mail an hello@aikido.dev senden, wenn Sie eine bestimmte Sprache vorschlagen möchten.
Testen einer App, die anfällig für JavaScript SQL-Injection ist
Verwenden wir eine Beispiel-App, die mit dem Open-Source-Repository geliefert wird, um zu zeigen, wie Aikido Firewall funktioniert. Sie benötigen außerdem Docker/Docker Compose, um eine lokale MySQL-Datenbank bereitzustellen.
Beginnen Sie damit, das firewall-node Repository zu forken und diesen Fork auf Ihre lokale Workstation zu klonen.
git clone https://github.com/<YOUR-GITHUB-USERNAME>/firewall-node.gitcd firewall-node
Verwenden Sie Docker, um eine lokale MySQL-Datenbank auf Port 27015 bereitzustellen. Diese docker-compose.yml-Datei erstellt auch s3mock-, MongoDB- und PostgreSQL-Container, da sie erstellt wurde, um dem Aikido-Team zu helfen, zu testen, wie Firewall verschiedene Angriffe blockiert.
docker-compose -f sample-apps/docker-compose.yml up -d
Starten Sie als Nächstes die Beispiel-App:
node sample-apps/express-mysql2/app.js
Öffnen Sie http://localhost:4000 in Ihrem Browser, um die sehr einfache Katzen-App zu testen. Geben Sie im Textbereich einige Katzennamen ein und klicken Sie auf die Schaltfläche Hinzufügen Schaltfläche. Um SQL-Injection zu testen, können Sie entweder auf den Link Injection testen klicken oder Folgendes in den Textbereich eingeben: Kitty'); DELETE FROM cats;-- H und klicken Sie auf Hinzufügen erneut. In jedem Fall ermöglicht die App das Stapeln mehrerer Abfragen mithilfe einiger raffinierter Abfragekommentare, wodurch die gesamte Katzen-Datenbank gelöscht wird.
Wie kommt es dazu? Wie wir bereits gewarnt haben, hängt diese App einfach an jegliche Benutzereingabe am Ende der SQL-Abfrage, was von Natur aus unsicher ist.
const query = `INSERT INTO cats(petname) VALUES ('${name}');`
Die Konsequenzen mögen hier gering sein, doch es ist nicht schwer vorstellbar, wie dieser oft ehrliche Fehler katastrophale Folgen für Ihre Produktionsanwendung haben kann.
Blockieren von JavaScript SQL-Injection mit Aikido Firewall
Sehen wir uns nun an, wie schnell unsere Open-Source-Security-Engine JavaScript SQL-Injection-Angriffe blockiert, ohne jede Datenbankinteraktion in Ihrem Code manuell beheben zu müssen.
Falls Sie noch kein Aikido-Konto haben, fahren Sie fort und kostenlos eines erstellen. Falls Sie bereits eines haben, melden Sie sich an und verbinden Sie Ihr GitHub-Konto. Gewähren Sie Aikido während dieses Prozesses Zugriff, um Ihren Fork des zu lesen firewall-node Projekts zu lesen.
Gehen Sie zum Firewall-Dashboard und klicken Sie auf „Dienst hinzufügen“. Geben Sie Ihrem Dienst einen Namen und wählen Sie erneut Ihren Fork für das firewall-node Projekts zu lesen.
Aikido weist Sie dann an, wie Sie Aikido Firewall installieren und implementieren. Da wir die Beispiel-App verwenden, ist diese Arbeit bereits für Sie erledigt, aber es ist eine hilfreiche Referenz, wie Sie unsere Open-Source-Sicherheits-Engine in alle Ihre Node.js-Apps integrieren würden, die anfällig für JavaScript SQL-Injection-Angriffe sein könnten.
Klicken Sie auf die Schaltfläche Token generieren Schaltfläche, um ein Token zu erstellen, damit Aikido Firewall Informationen über blockierte SQL-Injection-Angriffe sicher an die Aikido-Sicherheitsplattform übermitteln kann. Kopieren Sie das generierte Token, das mit beginnt AIK_RUNTIME… beginnt, und kehren Sie zu Ihrem Terminal zurück, um die Beispiel-App erneut auszuführen, diesmal jedoch mit vollständig aktiviertem Firewall im Blockierungsmodus:
AIKIDO_TOKEN=<YOUR-AIKIDO-TOKEN> AIKIDO_DEBUG=true AIKIDO_BLOCKING=true node sample-apps/express-mysql2/app.js
Öffnen Sie localhost:4000 und rufen Sie erneut den enthaltenen SQL-Injection-Angriff auf. Dieses Mal blockiert Aikido Sie im Browser, gibt Ausgaben in die Protokolle Ihres lokalen Webservers aus und generiert ein neues Ereignis. Klicken Sie darauf, um umfassende Details zum SQL-Injection-Versuch anzuzeigen, einschließlich der Payload und wo Ihre App die gefährliche SQL-Abfrage generiert hat.
Anstatt sich ständig Sorgen um den Schutz Ihrer Apps vor JavaScript SQL-Injection-Angriffen zu machen, sowohl kritischen als auch noch unbekannten, bietet Aikido Firewall umfassende Blockierung und ausgefeilte Observability, die Sie über Angriffsquellen, gängige Payloads und potenzielle Schwachstellen informiert.
Was kommt als Nächstes?
Sie können Aikido Firewall kostenlos in all Ihren Node.js-basierten Anwendungen installieren und implementieren. Unsere quelloffene eingebettete Sicherheits-Engine schützt Ihre Infrastruktur und Benutzerdaten vor JavaScript SQL-Injection-Angriffen, Command Injection, Prototype Pollution, Path Traversal und vielem mehr, das in Kürze folgen wird.
Wir sagen nicht, dass die Firewall Best Practices in der Entwicklung zum Schutz vor SQL-Injection ersetzen sollte, wie die Verwendung parametrisierter Abfragen oder das niemals Vertrauen von Benutzereingaben. Aber wir wissen auch aus eigener Erfahrung, dass keine Entwickelnde perfekt ist. Keine Codebasis ist fehlerfrei, und ehrliche Fehler passieren ständig.
Betrachten Sie die Firewall als einen globalen Hotfix für SQL-Injection. Im Gegensatz zu individuell entwickelten Regex, latenzverursachenden WAFs oder komplexen Security Agents, die ein Vermögen kosten, erledigt sie diese eine Aufgabe außerordentlich gut und mit vernachlässigbarem Einfluss – und das völlig kostenlos.
Wenn Ihnen gefällt, was Sie gesehen haben, schauen Sie sich unsere Roadmap an und geben Sie unserem GitHub-Repository (https://github.com/AikidoSec/firewall-node) einen Stern. ⭐
Sichern Sie Ihre Software jetzt.
