CSRF w rozwoju mobilnym: istota, rodzaje ataków i metody ochrony

Czym jest atak CSRF?

CSRF (Cross-Site Request Forgery) to atak, w którym osoba atakująca tworzy sfałszowane żądanie i zmusza przeglądarkę ofiary do wysłania go na docelowy serwer. Serwer wykonuje żądanie, ponieważ otrzymuje ważne cookie-credentials bieżącej sesji użytkownika. Atak jest możliwy, ponieważ przeglądarka automatycznie dodaje ciasteczka do każdego żądania na docelową domenę, niezależnie od tego, z której strony zostało wysłane żądanie. Użytkownik mógł nawet nie widzieć strony osoby atakującej — wystarczy załadować ukryty <img>, <form> lub <iframe> ze złośliwym URL. CSRF nie kradnie danych bezpośrednio — atak wykonuje działania w imieniu ofiary (state-changing operations), takie jak przelew pieniędzy, zmiana hasła lub usunięcie konta.

Które operacje są najbardziej podatne?

Ataki CSRF są skierowane wyłącznie na operacje zmieniające stan — żądania GET z efektami ubocznymi, POST, PUT i DELETE. Na przykład żądanie zmiany adresu email w panelu użytkownika: jeśli serwer przyjmuje żądanie bez weryfikacji źródła, osoba atakująca może podstawić swój email i zainicjować reset hasła. Atak jest szczególnie niebezpieczny dla systemów bankowych, paneli administracyjnych i sieci społecznościowych, gdzie jedna czynność pociąga za sobą poważne konsekwencje. API aplikacji mobilnych wykorzystujące ciasteczka do uwierzytelniania również są podatne na CSRF, jeśli nie stosują dodatkowych zabezpieczeń.

Kto jest zagrożony?

Na atak narażone są wszystkie aplikacje webowe i API, w których uwierzytelnianie opiera się na cookie, a serwer nie sprawdza źródła żądania. Aplikacje mobilne używające WebView do autoryzacji przez formularze internetowe również są podatne: komponent przeglądarki automatycznie wysyła ciasteczka, a osoba atakująca może wstrzyknąć złośliwe żądanie poprzez ładowanie w tle. Według HackerOne (2025), około 12% wszystkich raportów o podatnościach w aplikacjach webowych dotyczy braku ochrony przed CSRF.

Co sprawia, że CSRF jest niebezpieczne?

Główna cecha CSRF to niewidoczność dla ofiary. Użytkownik może nawet nie podejrzewać, że atak miał miejsce: sfałszowane żądanie jest wykonywane w tle, a interfejs aplikacji nie wykazuje oznak włamania. Jedynym sposobem wykrycia CSRF jest monitorowanie logów serwera lub nagłe zmiany na koncie. Ponadto CSRF łatwo łączy się z innymi podatnościami, takimi jak XSS czy otwarte przekierowania, co wielokrotnie zwiększa szkody.

Jak działa atak CSRF?

Atak CSRF składa się z trzech niezbędnych warunków: ofiara jest zalogowana na docelowej stronie, serwer używa uwierzytelniania cookie, a żądanie osoby atakującej jest skierowane na URL akcji. Osoba atakująca tworzy stronę HTML z formularzem, skryptem lub obrazem, którego atrybut src wskazuje na docelowy URL. Przeglądarka ofiary ładuje tę stronę i automatycznie wysyła żądanie na serwer wraz z ciasteczkami bieżącej sesji. Serwer otrzymuje ważne ciasteczka, nie sprawdza źródła żądania i wykonuje operację.

<!-- Przykład ataku CSRF przez ukryty formularz -->
<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>

Po załadowaniu strony skrypt natychmiast wysyła formularz. Przeglądarka dołącza ciasteczka sesji użytkownika do żądania POST na bank.example.com. Serwer banku sprawdza ciasteczka, potwierdza uwierzytelnienie użytkownika i wykonuje przelew na konto osoby atakującej. Ofiara widzi pustą lub legalną stronę, a pieniądze zostały już przelane.

Rola przeglądarki w CSRF

Kluczową cechą protokołu HTTP jest brak wbudowanej weryfikacji źródła żądania. Przeglądarka dodaje ciasteczka do żądania, jeśli domena żądania pokrywa się z domeną ciasteczka. Osoba atakująca nie musi znać zawartości ciasteczka — przeglądarka robi to automatycznie. Same-origin policy nie chroni przed CSRF, ponieważ atak jest skierowany na serwer, a nie na odczyt odpowiedzi. Mechanizmy takie jak CORS również są nieskuteczne: żądania CSRF zazwyczaj nie wymagają odczytu odpowiedzi, aby wyrządzić szkodę.

Główne typy ataków CSRF

Ataki CSRF klasyfikuje się według sposobu dostarczania złośliwego żądania. Każdy typ używa innego elementu HTML do wysłania żądania, ale wszystkie opierają się na automatycznym wysyłaniu cookie przez przeglądarkę. Wybór metody zależy od celów atakującego: ataki GET-based wymagają mniej kodu, POST-based skuteczniej omijają niektóre zabezpieczenia, a XMLHttpRequest-based pozwalają manipulować nagłówkami.

GET-based CSRF

Najprostsza metoda: osoba atakująca umieszcza na stronie <img> z URL zawierającym parametry żądania. Przeglądarka ładuje obraz i wysyła żądanie GET na serwer. Na przykład <img src="https://api.example.com/delete?postId=123" /> usuwa wpis, jeśli serwer obsługuje DELETE przez GET. Pomimo oczywistego zagrożenia, niektóre API nadal używają GET do operacji usuwania lub aktualizacji.

POST-based CSRF

Jeśli serwer przyjmuje tylko żądania POST, osoba atakująca tworzy ukryty formularz z metodą POST i automatycznie wysyła go przez JavaScript. Formularz nie jest wyświetlany na ekranie (wszystkie <input> mają type="hidden"), a autofocus + .submit() działa bez kliknięcia użytkownika. Ataki POST-based nie działają, jeśli serwer sprawdza nagłówek Content-Type, ale większość API akceptuje standardowy application/x-www-form-urlencoded.

XHR-based CSRF (z CORS)

XMLHttpRequest lub Fetch API pozwalają wysyłać żądania z dowolnymi nagłówkami. Jeśli serwer skonfigurował CORS zbyt szeroko (Access-Control-Allow-Origin: *), osoba atakująca może wysłać dowolne żądanie i odczytać odpowiedź. Jednak do ataku CSRF odczyt odpowiedzi nie jest konieczny — wystarczy wykonanie działania. Nowoczesne przeglądarki wysyłają żądanie preflight OPTIONS przed niestandardowymi żądaniami, co może zablokować XHR-based CSRF, jeśli serwer jest poprawnie skonfigurowany.

CSRF w aplikacjach mobilnych

Aplikacje mobilne są mniej podatne na CSRF niż strony internetowe, ponieważ aplikacje natywne rzadko używają uwierzytelniania cookie. Zamiast tego mobilne API częściej stosują tokeny w nagłówku Authorization (Bearer-tokeny, JWT). Istnieją jednak scenariusze, w których atak CSRF jest możliwy: WebView z logowaniem internetowym, aplikacje hybrydowe i API z sesjami opartymi na cookie. Według TechCrunch (2025), około 18% publicznych API aplikacji mobilnych nadal obsługuje ciasteczka sesyjne.

CSRF przez WebView

Wiele aplikacji otwiera strony internetowe w WebView — autoryzację przez OAuth, formularze płatności, przeglądanie treści. WebView to pełnoprawna przeglądarka wewnątrz aplikacji, która przechowuje ciasteczka sesyjne. Jeśli osoba atakująca znajdzie sposób na załadowanie swojego URL w WebView (poprzez otwarte przekierowanie lub Deep Link), może przeprowadzić atak CSRF dokładnie tak samo, jak w zwykłej przeglądarce. Ochrona — używanie Chrome Custom Tabs lub SFSafariViewController zamiast WebView dla krytycznych operacji.

CSRF w API z uwierzytelnianiem JWT

Tokeny JWT są zwykle przechowywane w localStorage lub w pamięci aplikacji i nie są wysyłane automatycznie — programista jawnie dodaje nagłówek Authorization do każdego żądania. To sprawia, że klasyczny atak CSRF jest niemożliwy. Jednak jeśli aplikacja przechowuje JWT w cookie (co jest rzadkie, ale się zdarza), ryzyko powraca. Dodatkową ochroną jest powiązanie JWT z konkretnym origin żądania poprzez claim azp lub aud, co zapobiega użyciu tokena na innej domenie.

// Przykład serwerowej walidacji tokena CSRF w 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();
};

// Generowanie tokena CSRF przy logowaniu
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Metody ochrony przed CSRF

Nowoczesna ochrona przed CSRF opiera się na trzech poziomach: serwerowe tokeny CSRF, atrybut SameSite dla cookie i weryfikacja nagłówka Origin. Połączenie tych metod zapewnia ochronę przed 99% ataków CSRF bez znaczącego wpływu na UX. Wybór konkretnego podejścia zależy od architektury aplikacji: strona internetowa może użyć SameSite=Lax, API aplikacji mobilnej wymaga tokenów w nagłówkach.

Tokeny CSRF (synchronizator)

Standardowa metoda: serwer generuje unikalny token, wiąże go z sesją użytkownika i przekazuje klientowi. Klient dołącza token do każdego żądania zmieniającego stan (w ukrytym polu formularza lub nagłówku X-CSRF-Token). Serwer porównuje otrzymany token z zapisanym w sesji. Token musi być kryptograficznie bezpieczny, losowy, o długości co najmniej 32 bajtów i zmieniać się przy każdej sesji lub operacji. Okres życia tokena — nie więcej niż kilka godzin.

SameSite Cookie

Atrybut SameSite dla ciasteczek ogranicza wysyłanie cookie przy żądaniach cross-domain. Wartość Lax zezwala na wysyłanie cookie tylko dla nawigacyjnych żądań GET najwyższego poziomu — to wystarcza dla większości stron. Strict blokuje cookie dla wszystkich żądań cross-domain, w tym nawigacji: użytkownik będzie musiał zalogować się ponownie po przejściu z innej strony. Według Chrome Platform Status (2026), SameSite=Lax jest domyślnie włączony we wszystkich nowoczesnych przeglądarkach, co zmniejszyło liczbę ataków CSRF o 67%.

Weryfikacja Origin i Referer

Serwer może sprawdzać nagłówki Origin lub Referer przychodzącego żądania. Jeśli żądanie pochodzi z innej domeny — jest blokowane. Origin jest bardziej niezawodny niż Referer, ponieważ zawsze jest obecny w żądaniach POST i nie jest wyłączany przez polityki przeglądarki. Implementacja: biała lista dozwolonych originów, porównanie z bieżącą wartością nagłówka. Metoda jest skuteczna, ale skomplikowana w przypadku aplikacji mobilnych, gdzie nagłówki Origin mogą być nieobecne lub fałszowane.

// Przykład walidacji tokena CSRF w 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

Metoda niewymagająca przechowywania tokena na serwerze: serwer ustawia cookie z losową wartością, klient odczytuje wartość z cookie i wysyła ją z powrotem w nagłówku lub treści żądania. Serwer porównuje obie wartości. Jeśli osoba atakująca nie może odczytać cookie (Same-origin policy), nie będzie w stanie sfałszować tokena. Metoda jest łatwiejsza we wdrożeniu niż synchronizator, ale wymaga HTTPS do ochrony cookie przed przechwyceniem.

• Tokeny CSRF — złoty standard: niezawodne, sprawdzone w czasie, obsługiwane przez wszystkie frameworki
• SameSite=Lax — minimalna ochrona dla aplikacji webowych: bezpłatna, automatyczna, niewymagająca kodu
• Weryfikacja Origin — dodatkowy poziom: blokuje ataki przed weryfikacją tokena
• Double Submit — dla REST API bez sesji po stronie serwera: skuteczny na HTTPS
• Niestandardowe nagłówki — X-Requested-With: XMLHttpRequest blokuje proste formularze CSRF

Różnica między CSRF a XSS

CSRF i XSS to różne typy ataków, które często są mylone. CSRF wykorzystuje zaufanie serwera do przeglądarki użytkownika: serwer wykonuje polecenie osoby atakującej, ponieważ żądanie przychodzi z ważnymi ciasteczkami. XSS wykorzystuje zaufanie przeglądarki do treści serwera: przeglądarka wykonuje skrypt wstrzyknięty przez osobę atakującą na stronę. CSRF nie wymaga wstrzyknięcia kodu na docelowej stronie — wystarczy wysłać żądanie z innej domeny. XSS natomiast wymaga znalezienia sposobu na wstrzyknięcie swojego JavaScript do kodu HTML strony. Ponadto XSS może ominąć ochronę CSRF: wstrzyknięty skrypt odczytuje token CSRF ze strony i wysyła go razem z żądaniem.

Zrozumienie różnicy między CSRF a XSS jest krytycznie ważne dla budowania wielopoziomowej ochrony. Tokeny CSRF nie chronią przed XSS, a CSP (Content Security Policy) nie chroni przed CSRF. Tylko połączenie metod zapewnia bezpieczeństwo aplikacji przed oboma typami ataków. W aplikacjach mobilnych z WebView ryzyko się podwaja, dlatego programistom zaleca się stosowanie co najmniej tokenów CSRF dla żądań API oraz Content Security Policy dla treści internetowych.