Web Security Basics Every Developer Must Know — txt1.ai

Von Marcus Chen, Senior Security Engineer bei einem Fortune-500-Fintech-Unternehmen mit 12 Jahren Erfahrung in der Härtung von Webanwendungen, die über 2 Milliarden Dollar an täglichen Transaktionen abwickeln

Vor drei Jahren sah ich einen Junior-Entwickler um 16:47 Uhr an einem Freitag Code in die Produktion pushen. Um 18:15 Uhr leuchtete unser Sicherheitsoperationszentrum wie ein Weihnachtsbaum. Eine SQL-Injektionsanfälligkeit in einer scheinbar harmlosen Suchfunktion hatte 340.000 Kundenakten offengelegt. Der Vorfall kostete uns 4,2 Millionen Dollar für die Behebung, regulatorische Geldstrafen und verlorenes Geschäft. Der Entwickler? Ein brillanter Ingenieur, der einfach nicht wusste, was er über Websicherheit nicht wusste.

Dieser Vorfall änderte, wie ich Sicherheitsbildung angehe. Ich stellte fest, dass die meisten Entwickler nicht rücksichtslos sind – sie arbeiten einfach in einem Wissensvakuum. Informatikstudiengänge verbringen vielleicht zwei Wochen mit Sicherheit, wenn Sie Glück haben. Bootcamps überspringen es oft ganz. Dennoch wird von uns erwartet, dass wir Festungen bauen, während wir nur verstehen, wie man Ziegel stapelt.

Ich habe das letzte Jahrzehnt in den Schützengräben der Websicherheit verbracht, vom Penetrationstest bis zum Aufbau von Sicherheitsframeworks, die von Teams mit über 200 Entwicklern verwendet werden. Ich habe gesehen, wie Angriffe von groben Skript-Kiddie-Versuchen zu ausgeklügelten Operationen von Nationalstaaten evolvierten. Und ich habe gelernt, dass die Grundlagen – die Basics, die jeder Entwickler verinnerlichen muss – sich nicht so sehr geändert haben, wie Sie vielleicht denken. Beherrschen Sie diese Kernprinzipien, und Sie werden 90 % der Verwundbarkeiten verhindern, die ich jeden Tag im Produktionscode sehe.

Angriffsfläche verstehen: Was Sie wirklich schützen

Wenn ich Entwickler frage, was sie schützen, höre ich normalerweise "Benutzerdaten" oder "die Datenbank." Das ist nicht falsch, aber es ist unvollständig. Ihre Angriffsfläche ist jeder einzelne Punkt, an dem Ihre Anwendung Eingaben akzeptiert, Daten verarbeitet oder mit externen Systemen interagiert. Es ist das Anmeldeformular, ja, aber es ist auch der API-Endpunkt, den Sie nur für interne Zwecke geschrieben haben, die Datei-Upload-Funktion im Admin-Panel und sogar die Fehlermeldungen, die Sie den Benutzern anzeigen.

Lassen Sie mich Ihnen ein konkretes Beispiel aus meiner eigenen Erfahrung geben. Wir hatten einen internen API-Endpunkt, der JSON-Payloads für massenhafte Benutzeraktualisierungen akzeptierte. Er war „nur intern“ – keine Authentifizierung erforderlich, da er nur von unserem VPN zugänglich war. Es sei denn, jemand hat einen Reverse-Proxy falsch konfiguriert, und plötzlich war dieser Endpunkt ungefähr 18 Stunden lang dem Internet ausgesetzt, bevor wir ihn entdeckten. In diesen 18 Stunden hatten automatisierte Scanner ihn bereits gefunden und 2.847 verschiedene Angriffsvektoren ausprobiert.

Die Angriffsfläche umfasst jede Abhängigkeit in Ihrer package.json oder requirements.txt. Als die Log4Shell-Anfälligkeit im Dezember 2021 bekannt wurde, verbrachte ich 72 aufeinanderfolgende Stunden damit, Teams zu helfen, betroffene Systeme zu identifizieren und zu patchen. Die Verwundbarkeit befand sich nicht in dem Code, den wir geschrieben hatten – sie war in einer Logging-Bibliothek, die eine Abhängigkeit einer Abhängigkeit einer Abhängigkeit war. Ihre Angriffsfläche erstreckt sich über Ihren gesamten Abhängigkeitsbaum, der für eine typische Node.js-Anwendung mehr als 800 Pakete umfassen kann.

Denken Sie an die Vertrauensgrenzen Ihrer Anwendung. Wo gelangt untrusted Daten in Ihr System? Jedes Formularfeld, jeder URL-Parameter, jeder HTTP-Header, jedes Cookie, jeder API-Anforderungskörper. Wenn es nicht aus dem Speicher Ihres Servers kommt, ist es untrusted. Ich habe gesehen, wie Entwickler sorgfältig Formulareingaben validieren, aber URL-Parameter völlig ignorieren oder POST-Daten bereinigen, während sie GET-Parameter weit offen lassen. Angreifer interessieren sich nicht für Ihr mentales Modell darüber, was „validiert werden sollte“ – sie prüfen alles.

Ihre Angriffsfläche umfasst auch zeitbasierte Verwundbarkeiten. Dieser Passwort-Zurücksetzen-Token, den Sie generieren? Wenn er vorhersagbar oder nicht abläuft, ist er ein Angriffsvektor. Sitzungsidentifikatoren, API-Schlüssel, temporäre Dateinamen – alles, was ein Angreifer erraten oder brute-forcen könnte, wenn er genügend Zeit hat. Ich fand einmal ein System, in dem Passwort-Zurücksetzen-Token einfach aufeinanderfolgende ganze Zahlen waren. Ein Angreifer konnte eine Zurücksetzung für sein eigenes Konto anfordern, Token 45231 sehen und dann die Token 45230, 45229, 45228 versuchen, um die Passwörter anderer Benutzer zurückzusetzen.

Eingangsvalidierung: Ihre erste Verteidigungslinie

Wenn ich ein Prinzip jedem Entwickler auf die Stirn tätowieren könnte, wäre es folgendes: vertrauen Sie niemals Benutzereingaben. Weder die Eingaben Ihrer mobilen App. Noch die Eingaben der API Ihres „vertrauenswürdigen“ Partners. Nicht einmal die Eingaben Ihres eigenen Frontend-JavaScripts. Alles, was eine Vertrauensgrenze überschreitet, muss validiert, bereinigt und als potenziell bösartig behandelt werden, bis das Gegenteil bewiesen ist.

Die gefährlichsten Verwundbarkeiten sind nicht die, die Hacker finden – es sind die, von denen Entwickler nicht wissen, dass sie in ihrem Code vorhanden sind, bis es zu spät ist.

Ich sehe Entwickler immer wieder dieselbe Fehler machen: Sie validieren Eingaben im Frontend und gehen davon aus, dass das ausreicht. Hier ist die Realität – ich kann Ihre Frontend-Validierung in etwa 15 Sekunden mit den Entwicklerwerkzeugen des Browsers oder einem einfachen curl-Befehl umgehen. Frontend-Validierung dient der Benutzererfahrung, nicht der Sicherheit. Echte Validierung erfolgt auf dem Server, jedes Mal, ohne Ausnahmen.

Effektive Eingangsvalidierung hat drei Komponenten: Typprüfung, Formatvalidierung und Validierung der Geschäftslogik. Die Typprüfung stellt sicher, dass ein Feld, das eine Zahl erwartet, tatsächlich eine Zahl erhält, nicht einen String mit SQL-Injektionsversuchen. Die Formatvalidierung verwendet Erlaubenlisten (nicht Leugnungslisten), um sicherzustellen, dass die Daten erwarteten Mustern entsprechen. Wenn Sie eine E-Mail-Adresse erwarten, validieren Sie mit einem geeigneten E-Mail-RegEx. Wenn Sie eine US-Telefonnummer erwarten, validieren Sie das Format ausdrücklich.

Die Validierung der Geschäftslogik ist der Punkt, an dem die meisten Entwickler aufhören zu denken. Nur weil etwas technisch gültig ist, bedeutet das nicht, dass es im Kontext Ihrer Anwendung sinnvoll ist. Ich habe einmal Code überprüft, bei dem ein Warenkorb negative Mengen erlaubte. Der Entwickler hatte validiert, dass die Eingabe eine ganze Zahl war, aber nie überprüft, ob sie positiv war. Ein Angreifer konnte -100 Artikel „kaufen“ und stattdessen eine Gutschrift erhalten, anstatt belastet zu werden. Die Behebung war trivial, aber das Übersehen kostete das Unternehmen 23.000 Dollar, bevor es entdeckt wurde.

Hier ist mein praktischer Ansatz: Definieren Sie strenge Schemata für jede Eingabe, die Ihre Anwendung akzeptiert. Verwenden Sie Validierungsbibliotheken wie Joi für Node.js, Pydantic für Python oder integrierte Validierung in Frameworks wie Laravel oder Django. Diese Bibliotheken ermöglichen es Ihnen, genau zu deklarieren, wie gültige Eingaben aussehen, und sie lehnen alles andere standardmäßig ab. Wenn die Validierung fehlschlägt, protokollieren Sie es. Wiederholte Validierungsfehler von derselben IP-Adresse oder Benutzerkonto können ein Hinweis auf einen laufenden Angriff sein.

Ein weiterer kritischer Punkt: Validieren Sie auf jeder Ebene. Wenn Daten von Ihrer API zu einem Hintergrundjob zu einer Datenbank fließen, validieren Sie bei jedem Schritt. Ich habe Angriffe gesehen, die die Lücke zwischen der API-Validierung und der Verarbeitung von Hintergrundjobs ausnutzten. Die API validierte Eingaben korrekt, aber der Hintergrundjob setzte voraus, dass die Daten sicher waren, weil sie aus der Datenbank kamen. Ein Angreifer, der direkt in die Datenbank schreiben konnte (durch eine separate Verwundbarkeit), konnte alle Validierungen umgehen.

Authentifizierung und Autorisierung: Wer und was Sie kennen

Authentifizierung beantwortet die Frage „Wer sind Sie?“ Autorisierung beantwortet die Frage „Was dürfen Sie tun?“ Diese beiden Konzepte zu verwechseln oder sie schlecht zu implementieren, schafft einige der am meisten ausnutzbaren Verwundbarkeiten, die ich antreffe. Ich habe Systeme gesehen, die eine rocksolide Authentifizierung hatten, die es jedem authentifizierten Benutzer erlaubte, auf die Daten eines anderen Benutzers zuzugreifen, weil die Autorisierung nachträglich bedacht wurde.