Vor drei Jahren habe ich zugesehen, wie ein Startup, für das ich beraten habe, in 72 Stunden alles verlor. Nicht aufgrund eines ausgeklügelten Angriffs eines Nationalstaats oder eines Zero-Day-Exploits, der Schlagzeilen machte. Sie verloren ihre gesamte Kundendatenbank, ihren Ruf und letztendlich ihr Geschäft wegen einer einzigen SQL-Injection-Schwachstelle, die ein Junior-Entwickler während eines hastigen Freitags-Deployments eingebracht hatte. Der Angriff fand an einem Montagmorgen statt. Bis Mittwochmittag entwarfen sie Insolvenzunterlagen.
💡 Wichtige Erkenntnisse
- Die Authentifizierungsfalle, die jeden trifft
- Cross-Site Scripting: Die Schwachstelle, die nie stirbt
- SQL-Injection: Die alte Schwachstelle, die immer noch funktioniert
- HTTPS ist nicht mehr optional
Ich bin Sarah Chen und habe die letzten 12 Jahre als Sicherheitsarchitektin in Unternehmen verbracht, die von kleinen Startups bis zu Fortune 500-Unternehmen reichen. Ich habe immer wieder die gleichen vermeidbaren Fehler gesehen, die Unternehmen zerstören. Der frustrierende Teil? Die meisten dieser Katastrophen hätten mit grundlegenden Sicherheitskenntnissen vermieden werden können, die weniger Zeit in Anspruch nehmen als Ihr durchschnittliches JavaScript-Framework.
Hier ist, was dir niemand sagt, wenn du lernst zu programmieren: Sicherheit ist kein fortgeschrittenes Thema, mit dem du dich beschäftigst, nachdem du alles andere gemeistert hast. Es ist grundlegend. Es ist wie das Autofahren zu lernen, ohne zu verstehen, dass rote Lichter Stopp bedeuten. Du magst eine Weile mitkommen, aber irgendwann verursachst du einen katastrophalen Unfall.
Laut dem 2023 Verizon Data Breach Investigations Report betrugen 74 % der Datenverletzungen den menschlichen Faktor, einschließlich Fehler, Missbrauch oder Social Engineering. Aber hier ist der spannende Punkt: Als sie speziell Webanwendungsangriffe analysierten, fanden sie heraus, dass 86 % Schwachstellen ausnutzten, die seit über einem Jahrzehnt dokumentiert und vermeidbar waren. Wir verlieren nicht gegen ausgeklügelte Angreifer. Wir verlieren gegen unsere eigene Ignoranz gegenüber den Grundlagen.
Die Authentifizierungsfalle, die jeden trifft
Ich möchte dir von der Authentifizierung erzählen, denn hier sehe ich, dass Entwickler ihren ersten kritischen Fehler machen. Sie behandeln es wie eine Checkbox-Funktion anstatt als Grundlage ihres gesamten Sicherheitsmodells. Ich habe einmal Code überprüft, bei dem ein Entwickler die Authentifizierung implementiert hatte, indem er prüfte, ob die E-Mail eines Benutzers in einem Cookie vorhanden war. Nicht ein signiertes Cookie. Nicht ein verschlüsseltes Token. Nur eine einfache Text-E-Mail-Adresse, die jeder in den Entwicklertools seines Browsers ändern konnte.
Als ich dies ansprach, sagte der Entwickler: "Aber es funktioniert!" Und das ist das Problem. Sicherheitsanfälligkeiten kündigen sich nicht mit Fehlermeldungen an. Sie funktionieren perfekt, bis jemand sie ausnutzt.
Hier ist, was eine ordnungsgemäße Authentifizierung tatsächlich erfordert. Zunächst musst du den Unterschied zwischen Authentifizierung (wer du bist) und Autorisierung (was du tun darfst) verstehen. Ich habe Produktionssysteme gesehen, bei denen diese Konzepte so durcheinander waren, dass die Behebung eines Sicherheitsproblems drei weitere erzeugte.
Die Passwortspeicherung ist nicht verhandelbar. Du musst einen ordentlichen Passwort-Hash-Algorithmus wie bcrypt, scrypt oder Argon2 verwenden. Nicht SHA-256. Nicht MD5. Auf keinen Fall im Klartext. Ich treffe im Jahr 2026 immer noch auf Datenbanken, in denen Passwörter im Klartext gespeichert sind, und jedes Mal sagt mir der Entwickler, sie "dachten nicht, dass es jemand tatsächlich versuchen würde, sie zu hacken." Das ist, als ob man die Haustür unverschlossen lässt, weil man nicht denkt, dass jemand einen tatsächlich ausrauben würde.
Die Zahlen hier sind erschreckend. Laut dem Bericht des Identity Theft Resource Center 2023 gab es 3.205 Datenkompromisse, die mehr als 353 Millionen Opfer allein in den Vereinigten Staaten betrafen. Als Forscher die kompromittierten Daten analysierten, stellten sie fest, dass in Fällen, in denen die Passwortspeicherungsmethoden offengelegt wurden, 43 % unzureichende Hashing-Methoden oder gar kein Hashing verwendeten.
Das Sitzungsmanagement ist der Punkt, an dem es interessant wird. Du musst kryptografisch sichere, zufällige Sitzungstoken generieren. Die integrierten Zufallszahlengeneratoren in den meisten Sprachen sind nicht kryptografisch sicher. In Node.js willst du crypto.randomBytes(), nicht Math.random(). In Python willst du secrets.token_hex(), nicht random.random(). Ich habe Sitzungstoken gesehen, die mit Zeitstempeln und Benutzer-IDs zusammengefügt wurden. Ein Angreifer kann diese in Sekunden vorhersagen.
Deine Sitzungstoken sollten mindestens 128 Bit Entropie haben. Sie sollten nur über HTTPS übertragen werden. Sie sollten das HttpOnly-Flag gesetzt haben, damit JavaScript nicht auf sie zugreifen kann. Sie sollten das Secure-Flag gesetzt haben, damit sie niemals über unverschlüsselte Verbindungen gesendet werden. Sie sollten das SameSite-Attribut haben, um CSRF-Angriffe zu verhindern. Und sie sollten ablaufen. Ich empfehle 30 Minuten Inaktivität für sensible Anwendungen, vielleicht 24 Stunden für weniger riskante Szenarien.
Cross-Site Scripting: Die Schwachstelle, die nie stirbt
XSS-Angriffe sind wie Kakerlaken. Sie gibt es schon ewig, jeder kennt sie, und doch tauchen sie immer wieder im Produktionscode auf. Die OWASP Top 10 umfasst seit seiner Gründung im Jahr 2003 XSS-Schwachstellen, und auch 2026 ist sie immer noch dort. Das sind 21 Jahre der gleichen vermeidbaren Schwachstelle.
"Sicherheit ist kein fortgeschrittenes Thema, mit dem man sich beschäftigt, nachdem man alles andere gemeistert hat. Es ist grundlegend. Es ist wie das Autofahren zu lernen, ohne zu verstehen, dass rote Lichter Stopp bedeuten."
Ich erinnere mich, dass ich eine Gesundheitsanwendung überprüfte, die die Patientenbemerkungen anzeigte, die von Ärzten eingegeben wurden. Die Entwickler hatten einen Rich-Text-Editor erstellt, der grundlegende Formatierungen erlaubte. Klingt vernünftig, oder? Es sei denn, sie haben diese HTML-Eingabe direkt auf der Seite ohne jegliche Sanitierung gerendert. Ich demonstrierte die Schwachstelle, indem ich eine Patientennotiz eingab, die ein Skript-Tag enthielt. Dieses Skript hätte Sitzungstoken stehlen, medizinische Aufzeichnungen ändern oder Patientendaten exfiltrieren können. Die Entwickler waren schockiert. Sie hatten nie in Betracht gezogen, dass ein Arzt böswillig sein könnte oder dass ein kompromittierter Computer eines Arztes bösartigen Code einfügen könnte.
Hier ist das grundlegende Prinzip: Vertraue niemals Benutzereingaben. Niemals. Nicht von Ärzten, nicht von Administratoren, nicht von deinem CEO. Jede einzelne Datenmenge, die von außerhalb deiner Anwendung kommt, ist potenziell bösartig, bis das Gegenteil bewiesen ist.
Es gibt drei Arten von XSS, die du verstehen musst. Stored XSS ist, wenn schadhafter Code in deiner Datenbank gespeichert wird und jedes Mal ausgeführt wird, wenn jemand diese Daten ansieht. Reflected XSS ist, wenn schadhafter Code in einem URL-Parameter sofort in der Antwort zurückgegeben wird. DOM-basiertes XSS ist, wenn clientseitiges JavaScript Benutzereingaben nimmt und sie ohne angemessene Sanitierung in die Seite einfügt.
Die Lösung ist nicht kompliziert, erfordert jedoch Disziplin. Du musst die Ausgabe kontextabhängig escapen. Wenn du Daten in HTML-Inhalt einfügst, benötigst du HTML-Zeichencodierung. Wenn du Daten in einen JavaScript-String einfügst, benötigst du JavaScript-Entkommentierung. Wenn du Daten in eine URL einfügst, benötigst du URL-Codierung. Wenn du Daten in CSS einfügst, benötigst du CSS-Entkommentierung.
Moderne Frameworks helfen dabei. React, Vue und Angular escapen alle standardmäßig die Ausgabe. Aber sie sind kein Zauber. Wenn du dangerouslySetInnerHTML in React oder v-html in Vue verwendest, umgehst du diesen Schutz. Ich habe gesehen, dass Entwickler diese Funktionen verwenden, weil sie "mussten", HTML zu rendern, ohne zu verstehen, dass sie damit eine XSS-Schwachstelle öffneten.
Content Security Policy ist deine zweite Verteidigungslinie. CSP ist ein HTTP-Header, der dem Browser sagt, welche Inhaltsquellen legitim sind. Du kannst Inline-Skripte vollständig blockieren, einschränken, welche Domains JavaScript laden können, und eine ganze Klasse von XSS-Angriffen verhindern. Laut den Forschungen von Google kann die Implementierung einer strengen CSP etwa 95 % der XSS-Angriffe verhindern. In meiner Erfahrung haben jedoch weniger als 30 % der Anwendungen, die ich überprüfe, irgendeine CSP, und die meisten von ihnen sind so nachgiebig, dass sie im Grunde nutzlos sind.
SQL-Injection: Die alte Schwachstelle, die immer noch funktioniert
SQL-Injection sollte ausgestorben sein. Es wird seit den 1990er Jahren gut verstanden. Bobby Tables ist seit über einem Jahrzehnt ein Meme. Und doch machen laut dem 2023 Bericht über den Stand des Internets von Akamai SQL-Injections 65 % aller Webanwendungsangriffe aus. Warum? Weil es immer noch funktioniert.
| Schwachstellentyp | Risikograd | Schwierigkeitsgrad der Vermeidung | Häufige Ursache |
|---|---|---|---|
| SQL-Injection | Kritisch | Einfach | Unsichere Benutzereingaben in Abfragen |
| Schwache Authentifizierung | Kritisch | Einfach | Schlechte Passwort-Richtlinien, keine MFA |
| XSS (Cross-Site Scripting) | Hoch | Moderat | Unescaped Benutzerinhalt in HTML |
| Gebrochene Zugriffskontrolle | Hoch | Moderat | Fehlende Berechtigungsprüfungen |
| Sicherheitsfehlkonfiguration | Mittel | Einfach | Standard-Einstellungen, exponierte Endpunkte |
Ich habe einmal für ein E-Commerce-Unternehmen beraten, das seit acht Jahren im Geschäft war. Sie hatten Millionen von Transaktionen bearbeitet. Sie hatten ein Team von 15 Entwicklern. Und ihre Suchfunktion war anfällig für SQL-Injection. Der Code sah ungefähr so aus: Sie nahmen den Suchbegriff aus dem URL-Parameter und hängten ihn direkt an eine SQL-Abfrage an. Keine Parametrisierung. Keine Eingangsvalidierung. Nichts.
Als ich die Schwachstelle demonstrierte, ...