Sicherheit in Webanwendungen: Über die Grundlagen hinaus

Sicherheit ist kein Kästchen, das man ankreuzt und dann vergisst. Es ist eine Denkweise, ein fortlaufender Prozess und eine Verantwortung, die jeder Entwickler trägt. Ein einziger Sicherheitsfehler kann Schäden in Millionenhöhe verursachen, das über Jahre aufgebaute Vertrauen der Benutzer zerstören und sogar Unternehmen auslöschen. Aber Sicherheit muss nicht einschüchternd oder lähmend sein. Mit dem richtigen Wissen und etablierten Praktiken können Sie robuste Anwendungen erstellen, die Ihre Benutzer schützen.

Die moderne Bedrohungslandschaft

Die Welt der Websicherheit hat sich in den letzten Jahren dramatisch verändert. Angreifer sind keine einsamen Hacker mehr in dunklen Kellern – sie sind raffinierte kriminelle Organisationen mit Budgets in Millionenhöhe, Nationalstaaten mit unbegrenzten Ressourcen und automatisierte Bots, die das Internet rund um die Uhr nach Schwachstellen durchsuchen.

Die Kosten eines erfolgreichen Angriffs explodierten. Wir reden hier nicht nur über gestohlene Daten. Im Rahmen der DSGVO und des LGPD](/post/lgpd-startups-compliance-protecao-dados) gibt es massive Bußgelder, die bis zu 4 % des weltweiten Jahresumsatzes eines Unternehmens ausmachen können. Es fallen Kosten für die Benachrichtigung betroffener Benutzer, für forensische Untersuchungen, für die Systemsanierung und für die Kreditüberwachung der Opfer an. Und der zerstörte Ruf verursacht unermessliche Kosten: Benutzer verlieren das Vertrauen und kehren nicht mehr zurück.

Aber auch auf der Verteidigungsseite hat sich das Szenario weiterentwickelt. Wir verfügen über bessere Tools, standardmäßig sicherere Frameworks und verwaltete Dienste, die ganze Klassen von Schwachstellen beseitigen. Cloud-Anbieter investieren Milliarden in die Sicherheit der Infrastruktur. Die Open-Source-Community findet und behebt Schwachstellen schnell. Wenn Sie diese Tools nutzen und Best Practices befolgen, haben Sie eine echte Chance, den Angreifern einen Schritt voraus zu sein.

Die Schwachstellen, die wirklich wichtig sind

OWASP veröffentlicht eine regelmäßig aktualisierte Liste der 10 kritischsten Web-Schwachstellen. Diese Liste ist nicht akademisch – sie basiert auf echten, erfolgreichen Angriffen, die Unternehmen Geld und Daten kosten. Sehen wir uns die wichtigsten an und erfahren, wie Sie sich verteidigen können.

Aufschlüsselung der Zugriffskontrolle

Dies ist aus einem einfachen Grund die größte Sicherheitslücke: Sie kommt unglaublich häufig vor und ist verheerend. Die Grundidee besteht darin, dass Benutzer auf Ressourcen zugreifen können, für die sie keinen Zugriff haben. Bob kann Alices Befehle sehen. Ein normaler Benutzer kann auf administrative Endpunkte zugreifen. Ein Kunde kann Produktpreise ändern, indem er der URL einen Parameter hinzufügt.

Der grundlegende Fehler besteht darin, sich bei Sicherheitsentscheidungen auf Benutzereingaben zu verlassen. „Ich werde diese Admin-Schaltfläche in der Benutzeroberfläche ausblenden“ stellt keine Sicherheit dar – jeder, der die URL kennt, kann darauf zugreifen. „Ich werde sequentielle IDs in die URL einfügen“ ist eine Aufforderung zum Durchlaufen von Ressourcen.

Der Schutz beginnt mit der Berechtigungsprüfung an jedem Endpunkt. Nicht nur in der Benutzeroberfläche, sondern auch im Backend, bei jedem sensiblen Vorgang. Jede Anfrage muss drei Fragen beantworten: Wer stellt diese Anfrage? Sind sie authentifiziert? Dürfen sie diese Aktion speziell für diese bestimmte Ressource ausführen?

Verwenden Sie **nicht erratbare Bezeichner

vel** als UUIDs anstelle von sequentiellen IDs. Implementieren Sie Richtlinien zur geringsten Berechtigung – Benutzer sollten nur über die für ihre Rollen erforderlichen Mindestberechtigungen verfügen. Und testen Sie intensiv: Versuchen Sie, als anderer Benutzer, als nicht authentifizierter Benutzer oder mit geänderten IDs auf Ressourcen zuzugreifen.

Kryptografische Mängel

Sensible Daten geraten ständig ins Leck, weil sie nicht ausreichend geschützt sind. Dazu gehören im Klartext oder mit schwachem Hash gespeicherte Passwörter, unverschlüsselte Kreditkartendaten, vorhersehbare Sitzungstoken und ungeschützte Datenbanksicherungen.

Das Grundprinzip besteht darin, „sensible Daten im Ruhezustand und während der Übertragung“ zu verschlüsseln. HTTPS (TLS) ist für keine Website im öffentlichen Internet optional – moderne Browser markieren HTTP-Websites sogar als „nicht sicher“. Glücklicherweise sind TLS-Zertifikate bei Let's Encrypt kostenlos.

Verwenden Sie für ruhende Daten starke Verschlüsselung. AES-256 für symmetrische Daten. Implementieren Sie niemals Ihre eigene Kryptografie – nutzen Sie etablierte und geprüfte Bibliotheken. Verwenden Sie speziell für Passwörter Hashing-Algorithmen, die für Passwörter entwickelt wurden wie bcrypt, scrypt oder Argon2. Diese sind absichtlich langsam, sodass Brute-Force-Angriffe selbst mit moderner Hardware unpraktisch sind.

Schlüsselverwaltung ist oft das schwache Glied. Verschlüsselungsschlüssel können nicht in Code- oder Konfigurationsdateien im Repository fest codiert werden. Nutzen Sie Geheimverwaltungsdienste wie AWS Secrets Manager, Google Secret Manager oder HashiCorp Vault. Schlüssel regelmäßig wechseln. Verfügen Sie über Verfahren zum Widerruf kompromittierter Schlüssel.

Injektion

SQL-Injection ist immer noch weit verbreitet, da es leicht versehentlich eingeführt werden kann und bei Ausnutzung verheerende Folgen hat. Die Injektionskategorie ist jedoch umfassender – sie umfasst Befehlsinjektion, LDAP-Injektion, NoSQL-Injektion und Vorlageninjektion.

Das gängige Muster besteht darin, Benutzereingaben ohne angemessene Bereinigung zu vertrauen, sodass Angreifer bösartige Befehle einschleusen können. Ein Angreifer kann Ihre gesamte Datenbank extrahieren, Tabellen löschen, Daten ändern oder sogar die Kontrolle über den Server erlangen.

Die primäre Verteidigung sind vorbereitete Anweisungen und parametrisierte Abfragen. Anstatt Zeichenfolgen zum Erstellen von SQL-Abfragen zu verketten, verwenden Sie Platzhalter, die mit Werten gefüllt sind. Die Datenbank behandelt diese Werte als Daten und nicht als Befehle, was eine Injektion unmöglich macht.

Moderne ORMs wie Prisma, TypeORM oder Sequelize tun dies standardmäßig, sodass Sie durch die Verwendung dieser Frameworks in den meisten Fällen bereits geschützt sind. Dennoch müssen Sie bei Bedarf bei Rohabfragen vorsichtig sein.

Eine strenge Eingabevalidierung ist eine weitere Verteidigungslinie. Wenn Sie eine Zahl erwarten, prüfen Sie, ob es sich tatsächlich um eine Zahl handelt. Wenn Sie ein Datum erwarten, überprüfen Sie das Format. Wenn Sie eine Auswahl aus einer vordefinierten Liste erwarten, überprüfen Sie, ob der Wert in dieser Liste enthalten ist. Gehen Sie niemals davon aus, dass Kundendaten sicher oder wohlgeformt sind.

Cross-Site-Scripting (XSS)

XSS ermöglicht es Angreifern, bösartiges JavaScript einzuschleusen, das in den Browsern der Opfer ausgeführt wird. Dies kann Sitzungscookies stehlen, Seiteninhalte ändern, auf Phishing-Seiten umleiten oder Keylogger installieren.

Es gibt drei Haupttypen: gespeichertes XSS (das bösartige Skript wird in der Datenbank gespeichert und jedes Mal ausgeführt, wenn die Seite geladen wird), reflektiertes XSS (das Skript stammt von einem URL-Parameter und wird in der Antwort wiedergegeben) und DOM-basiertes XSS (die Schwachstelle liegt im clientseitigen JavaScript).

Verteidigung beginnt mit Fluchtausgängen. Wenn Sie Benutzerdaten in HTML, JavaScript, CSS oder URLs platzieren, müssen Sie Sonderzeichen für diesen Kontext entsprechend maskieren. Moderne Frameworks wie React erledigen dies in den meisten Fällen automatisch, Sie können XSS jedoch weiterhin mit dangerouslySetInnerHTML oder ähnlichem einführen.

Content Security Policy (CSP) ist eine leistungsstarke zusätzliche Verteidigungslinie. Es handelt sich um einen HTTP-Header, der angibt, welche Schriftarten, Stile, Bilder usw. zulässig sind. Selbst wenn es einem Angreifer gelingt, Code einzuschleusen, kann CSP dessen Ausführung verhindern. Beginnen Sie mit einer restriktiven Politik und öffnen Sie sie nach Bedarf.

Nur HTTP-Cookies für Sitzungstoken verhindern, dass JavaScript auf diese Cookies zugreift, wodurch die Auswirkungen von XSS abgeschwächt werden. Wenn ein Angreifer das Sitzungscookie nicht stehlen kann, ist der Angriff weniger effektiv.

Offenlegung sensibler Daten

Protokolle, Fehlermeldungen, API-Antworten – all das sind Orte, an denen versehentlich vertrauliche Daten preisgegeben werden können. Ein detaillierter Stacktrace in der Produktion kann Codestruktur und Abhängigkeiten aufdecken. SQL-Fehlermeldungen können das Schema von Datenbank offenlegen. Protokolle können Passwörter oder Token enthalten, wenn Sie nicht vorsichtig sind.

Das Prinzip besteht darin, anzunehmen, dass alles, was Sie an den Client senden, von Angreifern gesehen werden kann. Das bedeutet, dass Sie sich niemals auf „Sicherheit durch Unklarheit“ verlassen und Informationen verstecken sollten, in der Hoffnung, dass sie niemand findet. Verwenden Sie echte Authentifizierung und Autorisierung.

Unterschiedliche Fehlermeldungen in der Produktion und in der Entwicklung ist eine bewährte Vorgehensweise. In der Entwicklung benötigen Sie detaillierte Stack-Traces zum Debuggen. In der Produktion sollten Benutzer (und Angreifer) generische Meldungen wie „Es ist ein unerwarteter Fehler aufgetreten“ sehen.

Sorgfältiges Filtern der Protokolle ist unerlässlich. Konfigurieren Sie Ihren Logger so, dass er keine sensiblen Felder wie Passwörter, Token und Kreditkartennummern aufzeichnet. Verwenden Sie Maskierung – protokollieren Sie beispielsweise nur die letzten 4 Ziffern einer Karte.

Robuste Authentifizierung und Autorisierung

Dies sind die Wächter Ihres Systems. Durch die Authentifizierung wird die Identität überprüft (wer Sie sind), durch die Autorisierung werden Berechtigungen überprüft (was Sie tun können). Fehler hier sind katastrophal.

Passwörter und Anmeldeinformationen

Die Forderung nach starken Passwörtern ist ein guter Anfang, aber die korrekte Definition von „starken“ Passwörtern ist wichtig. Willkürliche Regeln wie „Für jedes Zeichen muss ein Typ vorhanden sein“ sind weniger effektiv als die einfache Anforderung einer Mindestlänge von 12 bis 16 Zeichen. Lange, aber einprägsame Passwörter sind besser als komplexe Kurzpasswörter, die Benutzer auf Post-its schreiben.

Speichern Sie Passwörter niemals im Klartext. Verwenden Sie geeignete Hashing-Algorithmen. Bcrypt mit einem Kostenfaktor von mindestens 10 ist ein guter Standard. Das Hashing sollte langsam genug sein, um Brute-Force unpraktisch zu machen, aber nicht so langsam, dass es die Benutzererfahrung beeinträchtigt.

Ratenbegrenzung auf Anmeldeendpunkten verhindert Brute-Force-Angriffe. Nach einigen Fehlversuchen CAPTCHA anfordern oder vorübergehend blockieren. Verwenden Sie einen exponentiellen Backoff – jeder fehlgeschlagene Versuch erhöht die Abklingzeit.

Multi-Faktor-Authentifizierung (MFA) fügt eine wichtige Sicherheitsebene hinzu. Selbst wenn das Passwort geleakt wird, können Angreifer ohne den zweiten Faktor nicht auf das Konto zugreifen. TOTP (Zeitcodes) über Apps wie Google Authenticator oder Authy sind gut. SMS ist besser als nichts, aber anfällig für SIM-Austausch. WebAuthn mit Hardwareschlüsseln (YubiKey) ist der Goldstandard.

Sitzungsverwaltung

Sitzungstoken sind im Wesentlichen Schlüssel für Ihre Anwendung. Wenn ein Angreifer einen gültigen Token stiehlt, kann er sich als Benutzer ausgeben.

Sitzungstokens müssen wirklich zufällig sein und unvorhersehbar. Verwenden Sie kryptografisch sichere Generatoren, nicht Math.random(). Token müssen ausreichende Entropie haben – mindestens 128 Bit werden empfohlen.

Sitzungsablauf vereint Komfort und Sicherheit. Sehr lange Sitzungen stellen ein Risiko dar, wenn der Token durchgesickert ist. Zu kurz frustriert Benutzer. Erwägen Sie die Verwendung von Aktualisierungstoken – kurzlebige Zugriffstoken (15–30 Minuten), die mit langlebigen Aktualisierungstoken erneuert werden, aber eine regelmäßige Neuauthentifizierung erfordern.

Die Ungültigmachung alter Sitzungen, wenn sich der Benutzer abmeldet oder das Passwort ändert, ist von entscheidender Bedeutung. Angreifer sollten nicht in der Lage sein, gestohlene Token zu verwenden, nachdem das Opfer die Kompromittierung bemerkt hat.

OAuth und OpenID Connect

In den meisten Fällen implementieren Sie die Authentifizierung nicht selbst. Nutzen Sie etablierte Anbieter wie Auth0, AWS Cognito, Firebase Auth oder Social Login (Google, GitHub, Microsoft). Diese spezialisierten Dienste verfügen über ganze Teams, die sich der Authentifizierungssicherheit widmen.

Wenn Sie unbedingt implementieren müssen, verwenden Sie etablierte Standards. OAuth 2.0 für die Autorisierung, OpenID Connect für die Authentifizierung. Erfinden Sie nicht Ihr eigenes System – das Feld ist voller subtiler Fallen, die leicht zu übersehen sind.

PKCE (Proof Key for Code Exchange) sollte auch in nicht öffentlichen Anwendungen verwendet werden, um Angriffe auf das Abfangen von Autorisierungscodes zu verhindern. Es ist ein kleiner Mehraufwand, der eine Klasse von Schwachstellen beseitigt.

Tiefenverteidigung

Verlassen Sie sich nicht auf eine einzige Schutzschicht. Gehen Sie davon aus, dass jede Schicht ausfallen kann, und implementieren Sie mehrere unabhängige Schichten.

Web Application Firewall (WAF) filtert schädlichen Datenverkehr, bevor er Ihre Anwendung erreicht. Dienste wie Cloudflare, AWS WAF oder Azure WAF blockieren bekannte Angriffssignaturen

. Es ist kein Ersatz für sicheren Code, aber es ist eine wertvolle zusätzliche Ebene.

Ratenbegrenzung und Drosselung verhindern den Missbrauch von APIs. Begrenzen Sie, wie viele Anfragen ein Benutzer pro Minute/Stunde stellen kann. Dies mildert DDoS, Brute Force und aggressives Scraping.

Überwachung und Warnungen erkennen verdächtiges Verhalten. Viele fehlgeschlagene Anmeldungen von einer IP? Ungewöhnliche Aktivität von einem normalerweise ruhenden Konto? Versuche reguläre Benutzer, auf administrative Endpunkte zuzugreifen? Diese Muster sollten Warnungen und Untersuchungen auslösen.

Vorfallsreaktionsplan stellt sicher, dass Sie wissen, was zu tun ist, wenn (und nicht erst) ein Angriff stattfindet. Wer wird benachrichtigt? Wie isoliert man das System? Wie kommuniziert man mit Benutzern? Wie kann ich aus Backups wiederherstellen? Ein Playbook verkürzt die Reaktionszeit erheblich.

Fazit

Web-Sicherheit ist ein weites und sich ständig weiterentwickelndes Feld. Neue Schwachstellen werden entdeckt, neue Angriffsmuster entstehen, neue Verteidigungsinstrumente werden geschaffen. Sie werden nie alles wissen, aber Sie können solide Prinzipien und Prozesse etablieren, die Ihnen helfen, den meisten Bedrohungen einen Schritt voraus zu sein.

Beginnen Sie mit den Grundlagen: [robuste Authentifizierung, angemessene Zugriffskontrolle, Validierung von Eingaben, maskierte Ausgaben, Verschlüsselung sensibler Daten. Nutzen Sie bewährte Frameworks und Bibliotheken, anstatt das Rad neu zu erfinden. Halten Sie Abhängigkeiten auf dem neuesten Stand. Testen Sie regelmäßig. Kontinuierlich überwachen.

Sicherheit ist kein Projekt, das Sie abschließen – es ist eine fortlaufende Praxis, die Sie in jeden Aspekt der Entwicklung integrieren. Behandeln Sie es mit der Ernsthaftigkeit, die es verdient, denn Ihre Benutzer vertrauen Ihnen ihre Daten an.

Wie gehen Sie in Ihren Projekten mit der Sicherheit um? Haben Sie sich mit Sicherheitsvorfällen befasst? Teilen Sie Ihre Erfahrungen!