CSRF in der mobilen Entwicklung: Wesen, Angriffsarten und Schutzmethoden

Was ist ein CSRF-Angriff?

CSRF (Cross-Site Request Forgery) ist ein Angriff, bei dem ein Angreifer eine gefälschte Anfrage erstellt und den Browser des Opfers zwingt, sie an einen Zielserver zu senden. Der Server führt die Anfrage aus, weil er gültige Cookie-Anmeldeinformationen aus der aktuellen Sitzung des Benutzers erhält. Der Angriff ist möglich, weil der Browser automatisch Cookies zu jeder Anfrage an die Zieldomain hinzufügt, unabhängig davon, von welcher Seite die Anfrage gesendet wurde. Der Benutzer sieht möglicherweise nicht einmal die Seite des Angreifers — es reicht aus, ein verstecktes <img>, <form> oder <iframe> mit einer bösartigen URL zu laden. CSRF stiehlt keine Daten direkt — der Angriff führt Aktionen im Namen des Opfers aus (zustandsändernde Operationen), wie Geld überweisen, Passwörter ändern oder Konten löschen.

Welche Operationen sind am anfälligsten?

CSRF-Angriffe zielen ausschließlich auf zustandsändernde Operationen ab — GET-Anfragen mit Nebenwirkungen, POST, PUT und DELETE. Zum Beispiel eine Anfrage zur Änderung der E-Mail-Adresse in einem persönlichen Konto: wenn der Server die Anfrage ohne Überprüfung ihrer Herkunft annimmt, kann der Angreifer seine eigene E-Mail-Adresse einsetzen und ein Passwort-Reset einleiten. Der Angriff ist besonders gefährlich für Bankensysteme, Administrationspanels und soziale Netzwerke, wo eine einzige Aktion schwerwiegende Folgen hat. APIs mobiler Anwendungen, die Cookies zur Authentifizierung verwenden, sind ebenfalls anfällig für CSRF, wenn sie keine zusätzlichen Überprüfungen durchführen.

Wer ist gefährdet?

Jede Webanwendung und API, bei der die Authentifizierung auf Cookies basiert und der Server die Herkunft der Anfrage nicht überprüft, ist gefährdet. Mobile Anwendungen, die WebView für die Authentifizierung über Webformulare verwenden, sind ebenfalls gefährdet: die Browserkomponente sendet automatisch Cookies, und der Angreifer kann eine bösartige Anfrage durch Hintergrundladen einschleusen. Laut HackerOne (2025) stehen etwa 12% aller Schwachstellenmeldungen in Webanwendungen im Zusammenhang mit fehlendem CSRF-Schutz.

Was macht CSRF gefährlich?

Das Hauptmerkmal von CSRF ist seine Unsichtbarkeit für das Opfer. Der Benutzer bemerkt möglicherweise nicht einmal, dass ein Angriff stattgefunden hat: die gefälschte Anfrage wird im Hintergrund ausgeführt, und die Anwendungsoberfläche zeigt keine Anzeichen einer Kompromittierung. Der einzige Weg, CSRF zu erkennen, ist die Überwachung von Serverprotokollen oder das Feststellen plötzlicher Änderungen im Konto. Darüber hinaus lässt sich CSRF leicht mit anderen Schwachstellen kombinieren, wie XSS oder offenen Weiterleitungen, was den Schaden vervielfacht.

Wie funktioniert ein CSRF-Angriff?

Ein CSRF-Angriff erfordert drei Bedingungen: das Opfer ist auf der Zielseite authentifiziert, der Server verwendet Cookie-Authentifizierung, und die Anfrage des Angreifers ist auf eine Aktions-URL gerichtet. Der Angreifer erstellt eine HTML-Seite mit einem Formular, Skript oder Bild, dessen src-Attribut auf die Ziel-URL verweist. Der Browser des Opfers lädt diese Seite und sendet automatisch eine Anfrage zusammen mit dem aktuellen Sitzungscookie an den Server. Der Server erhält gültige Cookies, überprüft die Quelle der Anfrage nicht und führt die Operation aus.

<!-- Beispiel eines CSRF-Angriffs über ein verstecktes Formular -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Nach dem Laden der Seite sendet das Skript sofort das Formular ab. Der Browser hängt das Sitzungscookie des Benutzers an die POST-Anfrage an bank.example.com an. Der Server der Bank überprüft das Cookie, bestätigt, dass der Benutzer authentifiziert ist, und führt die Überweisung auf das Konto des Angreifers aus. Das Opfer sieht eine leere oder legitime Seite, aber das Geld ist bereits weg.

Die Rolle des Browsers bei CSRF

Ein Hauptmerkmal des HTTP-Protokolls ist das Fehlen einer integrierten Überprüfung der Anfragenquelle. Der Browser fügt Cookies zur Anfrage hinzu, wenn die Anfragedomain mit der Cookiedomain übereinstimmt. Der Angreifer muss den Inhalt des Cookies nicht kennen — der Browser macht dies automatisch. Die Same-Origin-Policy schützt nicht vor CSRF, da der Angriff auf den Server abzielt, nicht auf das Lesen der Antwort. Mechanismen wie CORS sind ebenfalls machtlos: CSRF-Anfragen müssen in der Regel keine Antwort lesen, um Schaden zu verursachen.

Hauptarten von CSRF-Angriffen

CSRF-Angriffe werden nach der Methode der Zustellung der bösartigen Anfrage klassifiziert. Jede Art verwendet ein anderes HTML-Element zum Senden der Anfrage, aber alle verlassen sich auf das automatische Senden von Cookies durch den Browser. Die Wahl der Methode hängt von den Zielen des Angreifers ab: GET-basierte Angriffe erfordern weniger Code, POST-basierte Angriffe umgehen einige Schutzmaßnahmen zuverlässiger, und XMLHttpRequest-basierte Angriffe ermöglichen die Manipulation von Headern.

GET-basierter CSRF

Die einfachste Methode: der Angreifer platziert ein <img> auf einer Seite mit einer URL, die Anfrageparameter enthält. Der Browser lädt das Bild und sendet eine GET-Anfrage an den Server. Zum Beispiel <img src="https://api.example.com/delete?postId=123" /> löscht einen Datensatz, wenn der Server DELETE über GET verarbeitet. Trotz der offensichtlichen Gefahr verwenden einige APIs immer noch GET für Lösch- oder Aktualisierungsvorgänge.

POST-basierter CSRF

Wenn der Server nur POST-Anfragen akzeptiert, erstellt der Angreifer ein verstecktes Formular mit der POST-Methode und sendet es automatisch über JavaScript ab. Das Formular wird nicht auf dem Bildschirm angezeigt (alle <input> haben type="hidden"), und autofocus + .submit() wird ohne Benutzerklick ausgelöst. POST-basierte Angriffe funktionieren nicht, wenn der Server den Content-Type-Header überprüft, aber die meisten APIs akzeptieren das Standardformat application/x-www-form-urlencoded.

XHR-basierter CSRF (mit CORS)

XMLHttpRequest oder Fetch API ermöglichen das Senden von Anfragen mit beliebigen Headern. Wenn der Server CORS zu weit gefasst konfiguriert hat (Access-Control-Allow-Origin: *), kann der Angreifer jede beliebige Anfrage senden und die Antwort lesen. Für einen CSRF-Angriff ist das Lesen der Antwort jedoch nicht erforderlich — es reicht aus, die Aktion auszuführen. Moderne Browser senden vor nicht standardmäßigen Anfragen eine Preflight-Anfrage OPTIONS, die XHR-basierten CSRF blockieren kann, wenn der Server richtig konfiguriert ist.

CSRF in mobilen Anwendungen

Mobile Anwendungen sind weniger anfällig für CSRF als Websites, da native Apps selten Cookie-Authentifizierung verwenden. Stattdessen verwenden mobile APIs häufiger Tokens im Authorization-Header (Bearer-Tokens, JWT). Es gibt jedoch Szenarien, in denen ein CSRF-Angriff möglich ist: WebView mit Web-Login, hybride Anwendungen und APIs mit cookie-basierten Sitzungen. Laut TechCrunch (2025) unterstützen etwa 18% der öffentlichen mobilen App-APIs immer noch Sitzungscookies.

CSRF über WebView

Viele Apps öffnen Webseiten in WebView — OAuth-Autorisierung, Zahlungsformulare, Inhaltsanzeige. WebView ist ein vollwertiger Browser innerhalb der App, der Sitzungscookies speichert. Wenn ein Angreifer einen Weg findet, seine URL in WebView zu laden (über eine offene Weiterleitung oder einen Deep Link), kann er einen CSRF-Angriff genau wie in einem normalen Browser ausführen. Schutz — Verwenden Sie Chrome Custom Tabs oder SFSafariViewController anstelle von WebView für kritische Vorgänge.

CSRF in APIs mit JWT-Authentifizierung

JWT-Tokens werden normalerweise im localStorage oder im Arbeitsspeicher der App gespeichert und nicht automatisch gesendet — der Entwickler fügt explizit den Authorization-Header zu jeder Anfrage hinzu. Dies macht einen klassischen CSRF-Angriff unmöglich. Wenn die App JWT jedoch in einem Cookie speichert (selten, aber möglich), kehrt das Risiko zurück. Zusätzlicher Schutz — Binden Sie JWT über den Claim azp oder aud an einen bestimmten Anfragen-Ursprung, was die Verwendung des Tokens auf einer anderen Domain verhindert.

// Beispiel einer serverseitigen CSRF-Token-Überprüfung in Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// CSRF-Token-Generierung beim Login
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Schutzmethoden gegen CSRF

Moderner CSRF-Schutz basiert auf drei Ebenen: serverseitige CSRF-Tokens, das SameSite-Attribut für Cookies und die Überprüfung des Origin-Headers. Die Kombination dieser Methoden bietet Schutz vor 99% der CSRF-Angriffe, ohne die Benutzererfahrung wesentlich zu beeinträchtigen. Die Wahl des Ansatzes hängt von der Anwendungsarchitektur ab: eine Website benötigt möglicherweise nur SameSite=Lax, während eine mobile App-API Tokens in Headern benötigt.

CSRF-Tokens (Synchronisator)

Die Standardmethode: der Server generiert einen eindeutigen Token, bindet ihn an die Sitzung des Benutzers und sendet ihn an den Client. Der Client fügt den Token in jede zustandsändernde Anfrage ein (in einem versteckten Formularfeld oder im X-CSRF-Token-Header). Der Server vergleicht den empfangenen Token mit dem in der Sitzung gespeicherten. Der Token muss kryptographisch stark, zufällig, mindestens 32 Byte lang sein und sich mit jeder Sitzung oder Operation ändern. Die Lebensdauer des Tokens sollte einige Stunden nicht überschreiten.

SameSite Cookie

Das SameSite-Attribut für Cookies schränkt das Senden von Cookies bei domainübergreifenden Anfragen ein. Der Wert Lax erlaubt Cookies nur für navigationsbezogene GET-Anfragen der obersten Ebene — ausreichend für die meisten Websites. Strict blockiert Cookies für alle domainübergreifenden Anfragen, einschließlich Navigation: der Benutzer muss sich erneut authentifizieren, wenn er von einer anderen Seite kommt. Laut Chrome Platform Status (2026) ist SameSite=Lax in allen modernen Browsern standardmäßig aktiviert, was die Anzahl der CSRF-Angriffe um 67% reduziert hat.

Überprüfung von Origin und Referer

Der Server kann die Origin- oder Referer-Header eingehender Anfragen überprüfen. Wenn die Anfrage von einer anderen Domain kommt, wird sie blockiert. Origin ist zuverlässiger als Referer, da es in POST-Anfragen immer vorhanden ist und nicht durch Browserrichtlinien deaktiviert werden kann. Implementierung: eine Whitelist erlaubter Ursprünge, Vergleich mit dem aktuellen Header-Wert. Diese Methode ist effektiv, aber schwierig bei mobilen Apps, wo Origin-Header fehlen oder gefälscht sein können.

// Beispiel einer CSRF-Token-Überprüfung in Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Eine Methode, die keine serverseitige Token-Speicherung erfordert: der Server setzt ein Cookie mit einem zufälligen Wert, der Client liest den Wert aus dem Cookie und sendet ihn in einem Header oder Anforderungstext zurück. Der Server vergleicht beide Werte. Wenn der Angreifer das Cookie nicht lesen kann (Same-Origin-Policy), kann er den Token nicht fälschen. Diese Methode ist einfacher zu implementieren als der Synchronisator, erfordert aber HTTPS, um das Cookie vor Abfangen zu schützen.

• CSRF-Tokens — der Goldstandard: zuverlässig, zeitgeprüft, von allen Frameworks unterstützt
• SameSite=Lax — minimaler Schutz für Web-Apps: kostenlos, automatisch, kein Code erforderlich
• Origin-Überprüfung — eine zusätzliche Ebene: blockiert Angriffe vor der Token-Überprüfung
• Double Submit — für REST-APIs ohne serverseitige Sitzungen: effektiv über HTTPS
• Benutzerdefinierte Header — X-Requested-With: XMLHttpRequest blockiert einfache CSRF-Formulare

Unterschied zwischen CSRF und XSS

CSRF und XSS sind verschiedene Angriffsarten, die oft verwechselt werden. CSRF nutzt das Vertrauen des Servers in den Browser des Benutzers aus: der Server führt den Befehl des Angreifers aus, weil die Anfrage mit gültigen Cookies kommt. XSS nutzt das Vertrauen des Browsers in den Inhalt des Servers aus: der Browser führt ein Skript aus, das der Angreifer in die Seite eingeschleust hat. CSRF erfordert kein Einschleusen von Code auf der Zielseite — es reicht aus, eine Anfrage von einer anderen Domain zu senden. XSS hingegen erfordert, einen Weg zu finden, JavaScript in den HTML-Code der Seite einzuschleusen. Allerdings kann XSS den CSRF-Schutz umgehen: das eingeschleuste Skript liest den CSRF-Token von der Seite und sendet ihn zusammen mit der Anfrage.

Das Verständnis des Unterschieds zwischen CSRF und XSS ist entscheidend für den Aufbau eines mehrschichtigen Schutzes. CSRF-Tokens schützen nicht vor XSS, und CSP (Content Security Policy) schützt nicht vor CSRF. Nur eine Kombination von Methoden gewährleistet die Sicherheit der Anwendung gegen beide Angriffsarten. In mobilen Apps mit WebView verdoppeln sich die Risiken, daher wird Entwicklern empfohlen, mindestens CSRF-Tokens für API-Anfragen und Content Security Policy für Webinhalte anzuwenden.