20. März 2020

• Security
• Java · Spring Boot
• Praxisbeispiele

Webanwendungen absichern – die häufigsten Schwachstellen und wie man sie behebt

Die durchschnittliche Webanwendung enthält 33 Sicherheitslücken – sechs davon kritisch.¹ Bei 19 % der getesteten Anwendungen hätten Angreifer die vollständige Systemkontrolle erlangen können. Dieser Artikel zeigt, wo die häufigsten Einfallstore liegen, warum sie so verbreitet sind, und wie man sie mit konkretem Java-Code schließt.

Das Problem mit dem Sicherheits-Blindspot

„Unsere Anwendung ist sicher – wir haben HTTPS." Dieser Satz ist keine Karikatur, sondern wird in technischen Gesprächen erstaunlich häufig geäußert. HTTPS schützt die Übertragung – nicht die Anwendungslogik. SQL Injections, Cross-Site-Scripting und schwache Authentifizierungsmechanismen funktionieren über HTTPS genauso zuverlässig wie ohne.

Das Paradoxe: Die häufigsten Schwachstellen sind gut dokumentiert, seit Jahrzehnten bekannt und trotzdem allgegenwärtig. Nicht weil Entwickler schlechte Arbeit leisten, sondern weil Security unter Zeitdruck als nachgelagerte Aufgabe behandelt wird – bis etwas schiefgeht.

Was die Daten sagen

Das Open Web Application Security Project (OWASP) veröffentlicht seit 2003 eine Rangliste der kritischsten Schwachstellen in Webanwendungen. Die Top 10 sind kein akademisches Konstrukt – sie spiegeln wider, was Angreifer in der Praxis tatsächlich ausnutzen. Wer diese zehn Kategorien versteht, schließt die häufigsten Einfallstore.

SQL Injection: Die älteste Lücke mit dem größten Schaden

SQL Injections zählen seit über zwei Jahrzehnten zu den gefährlichsten Schwachstellen – und sind trotzdem heute noch in produktiven Systemen zu finden. Das Prinzip ist simpel: Nutzereingaben werden ungeprüft in SQL-Statements eingebaut. Ein Angreifer, der das weiß, kann die Datenbanklogik von außen kontrollieren.

Ein klassisches Beispiel: eine Login-Methode, die Benutzername und Passwort direkt in eine SQL-Query konkateniert.

public boolean isValidLogin(String username, String password) throws SQLException {
    try (Connection con = dataSource.getConnection();
            Statement stmt = con.createStatement()) {

        String sql = "SELECT * FROM USER WHERE username = '" + username
                            + "' AND password = '" + password + "'";
        ResultSet rs = stmt.executeQuery(sql);
        return rs.next();
    }
}

Gibt ein Angreifer als Benutzername a' OR 'b'='b ein, sieht die resultierende Query so aus:

SELECT *
FROM USER
WHERE username = 'a' OR 'b'='b'
AND password = 'a' OR 'b'='b'

Da 'b' = 'b' immer wahr ist, gibt die Query alle Nutzer zurück – die Authentifizierung ist vollständig umgangen. Fortgeschrittene Angriffe gehen weiter: Tabellenstrukturen auslesen, Daten manipulieren, im schlechtesten Fall Betriebssystembefehle ausführen.

Die Lösung ist bekannt und seit Java 1.1 verfügbar: PreparedStatements. Statement und Parameter werden separat an die Datenbank übergeben – Nutzereingaben können niemals Teil der ausführbaren SQL-Logik werden.

public boolean isValidLogin(String username, String password) throws SQLException {
    String sql = "SELECT * FROM USER WHERE username = ? AND password = ?";
    try (Connection con = dataSource.getConnection();
            PreparedStatement stmt = con.prepareStatement(sql)) {

        stmt.setString(1, username);   // Index startet bei 1
        stmt.setString(2, password);
        ResultSet rs = stmt.executeQuery();
        return rs.next();
    }
}

Sensitive Data Exposure: Was nach außen dringt

Die überwiegende Mehrheit aller Webanwendungen verarbeitet sensible Nutzerdaten – und schützt sie nicht ausreichend. OWASP nennt diese Kategorie in der aktuellen Top-10-Liste (2021) treffender: Cryptographic Failures. Das ist präziser: Das Problem ist nicht immer fehlende Verschlüsselung, sondern häufig falsch angewendete.

Broken Authentication: Wer kommt rein?

Schwache Authentifizierung ist in der OWASP-Statistik für 28 % der Fälle durch fehlende Zugriffsrestriktionen verursacht – gefolgt von fest einprogrammierten Passwörtern mit 22 %.² Beides sind keine komplexen Angriffsvektoren. Es sind Konfigurationsfehler, die sich verhindern lassen.

Cross-Site-Scripting (XSS): Eigener Code in fremden Seiten

Mit 77 % Vorkommen ist XSS die am weitesten verbreitete Schwachstelle in Webanwendungen.² Das Prinzip: Nutzereingaben werden ungefiltert in die HTML-Ausgabe übernommen – ein Angreifer kann damit JavaScript in den Browser eines anderen Nutzers einschleusen.

Es gibt zwei Hauptvarianten. Beim Reflected XSS wird Schadcode über URL-Parameter direkt auf die Seite gespiegelt – Angreifer versenden präparierte Links, oft über URL-Shortener verschleiert. Kritischer ist Persistent XSS: Schadcode wird in der Datenbank gespeichert und bei jedem Seitenaufruf ausgeliefert – potenziell an alle Nutzer gleichzeitig.

Wie man die eigene Anwendung prüft

Manuelle Code-Reviews sind unersetzlich – aber nicht allein ausreichend. Eine Kombination aus statischer und dynamischer Analyse deckt systematisch ab, was Reviews übersehen.

Was das für Java-Projekte konkret bedeutet

Sicherheit ist keine nachgelagerte Aufgabe – sie ist eine Architekturentscheidung, die von Tag eins mitgedacht werden muss. Für den Java/Spring-Stack bedeutet das in der Praxis:

Fazit

Die beunruhigendste Erkenntnis aus den Daten ist nicht, dass Schwachstellen existieren – sondern dass es sich bei den häufigsten um bekannte, dokumentierte und seit Jahren lösbare Probleme handelt. SQL Injection wurde 1998 erstmals systematisch beschrieben. XSS ist seit 2000 in der OWASP-Liste. Broken Authentication seit der ersten Ausgabe 2003.

Die richtigen Werkzeuge sind verfügbar: PreparedStatements, bcrypt, Spring Security, OWASP ZAP, SonarQube. Sie einzusetzen erfordert kein spezialisiertes Security-Wissen – es erfordert die Entscheidung, Sicherheit nicht als optionales Feature zu behandeln, sondern als Teil der Definition of Done.

1. Positive Technologies, „Web Application Vulnerabilities Statistics 2019", PT Security, 2019. Durchschnittlich 33 Schwachstellen pro Anwendung, 6 davon kritisch; 19 % ermöglichten vollständige Systemübernahme.
2. OWASP, „OWASP Top 10 – 2017", Open Web Application Security Project, 2017. XSS-Vorkommen 77 %; fehlende Zugriffsrestriktionen bei Broken Authentication 28 %, Hardcoded Credentials 22 %.
3. BSI, „IT-Grundschutz-Kataloge: G 4.35 – Unsichere kryptographische Algorithmen", Bundesamt für Sicherheit in der Informationstechnik. DES, 3DES, MD5, SHA-1 und RSA unter 2048 Bit als unsicher klassifiziert.
4. OWASP, „OWASP Top 10 – 2021", Open Web Application Security Project, 2021. Aktuellste Ausgabe; „Sensitive Data Exposure" umbenannt zu „Cryptographic Failures".