Ataki na API i WebSockets

API i WebSockets są powszechnie stosowane w nowoczesnych aplikacjach webowych. Ich podatności mogą prowadzić do wycieku danych, eskalacji uprawnień i przejęcia sesji użytkowników.

---

Testowanie API REST i GraphQL

API REST i GraphQL często posiadają błędy związane z uwierzytelnianiem, autoryzacją oraz niewłaściwą walidacją danych wejściowych.

1️⃣ Wykrywanie API w aplikacji

1. Sprawdzenie dokumentacji API (np. swagger.json lub graphql/schema):

curl -s https://example.com/swagger.json
curl -s https://example.com/graphql/schema

2. Analiza ruchu HTTP w Burp Suite lub mitmproxy.

---

2️⃣ Ataki na API REST

2.1 IDOR w API

Niektóre API pozwalają na dostęp do zasobów innych użytkowników poprzez manipulację parametrami:

GET /api/user/123/profile

Jeśli zmiana 123 na 124 zwraca dane innego użytkownika, API jest podatne na IDOR.

2.2 Brak ograniczeń w żądaniach (Rate Limiting Bypass)

Niektóre API nie ograniczają liczby żądań, co umożliwia ataki brute-force. Hydra wymaga wskazania modułu i wzorca odpowiedzi (nie przyjmuje samego URL-a):

hydra -L users.txt -P passwords.txt example.com \
  https-post-form "/api/login:username=^USER^&password=^PASS^:F=invalid credentials"

Dla API zwracających JSON często wygodniej użyć ffuf z parametrem -d:

ffuf -u https://example.com/api/login -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"FUZZ"}' \
  -w passwords.txt -mc 200

Rozwiązanie: Ograniczenie liczby prób logowania i użycie CAPTCHA.

2.3 Ataki na nagłówki API (JWT Manipulation)

Tokeny JWT mogą być zmanipulowane, jeśli używają słabego klucza.

jwt_tool mytoken.jwt -d

Atakujący może podmienić nagłówek JWT:

{
  "alg": "none",
  "typ": "JWT"
}

Jeśli serwer akceptuje niepodpisane tokeny, można przejąć konto użytkownika.

---

3️⃣ Ataki na GraphQL

GraphQL pozwala na dynamiczne zapytania, co może prowadzić do nieautoryzowanego dostępu do danych.

3.1 Wykrywanie GraphQL

Sprawdzenie endpointu:

curl -X POST https://example.com/graphql -d '{"query":"{__schema{types{name}}}"}'

Jeśli zwróci schemat API, aplikacja jest podatna na nadmierne ujawnianie danych.

🧭 Zasada: samoopisująca się usługa opisuje się też napastnikowi — a kanały samoopisu to rodzeństwo. Introspekcja (__schema/__type) to odpowiednik wręczenia pliku OpenAPI/Swagger. Problem w tym, że wyłączenie introspekcji nie zamyka pozostałych kanałów: field suggestions („Did you mean title?”) odtwarzają schemat po literówkach (narzędzie Clairvoyance robi to niemal w całości), a gadatliwe błędy i extensions.tracing zdradzają zapytania SQL, ścieżki i czasy. Ten sam schemat bywa też dostępny innym transportem — introspekcja wyłączona po HTTP potrafiła przechodzić po WebSocket. Przy przeglądzie pytaj o cały zbiór: skoro wyłączam introspekcję, to czy field suggestions, tryb debug i tracing też są wyłączone na produkcji? — Aleks, Farhi, Black Hat GraphQL, s. 66, 145–160, 262

3.2 Atak DoS na GraphQL (Deep Query Attack)

Zapytania mogą przeciążać serwer:

query {
  user(id: "123") {
    friends {
      friends {
        friends {
          name
        }
      }
    }
  }
}

Rozwiązanie: Ograniczenie głębokości zapytań i wprowadzenie limitów.

🧭 Zasada: w GraphQL to klient komponuje koszt zapytania. Napastnikowi nie trzeba wykonać kodu — wystarczy narzucić koszt: kształt zapytania (głębokość, rozgałęzienie, parametr limit) ustala klient, a ścieżka /graphql jest jedna, więc po samym URL-u o koszcie nic nie wywnioskujesz. Dlatego limit głębokości i „limit per zapytanie” to nie limit kosztu — wiele zapytań równoległych, każde tuż pod progiem, przechodzi (ta sama pułapka co z liczeniem żądań HTTP, gdy serwer płaci za operacje wewnątrz żądania). Skuteczna obrona liczy koszt (wagi @cost sumowane do MAX_COST, analiza statyczna przed wykonaniem lub dynamiczna po rozwiązaniu) i prowadzi budżet per sesja/IP (credit-based), który wymaga trwałego stanu. Przy autoskalowaniu atak na dostępność zamienia się w atak na budżet (denial of wallet) — stąd limity wydatków i alerty kosztowe. — Aleks, Farhi, Black Hat GraphQL, s. 102, 121, 128–132; Haro Peralta, Secure APIs, s. 109–112

3.3 Brak kontroli uprawnień w GraphQL

Jeśli GraphQL nie wymaga autoryzacji dla pewnych operacji:

query { allUsers { id, email, password } }

To oznacza, że dowolny użytkownik może pobrać dane wszystkich kont.

---

Ataki na WebSockets

WebSockets umożliwiają dwukierunkową komunikację w czasie rzeczywistym, ale ich brak walidacji może prowadzić do ataków.

4️⃣ Przechwytywanie i manipulacja WebSockets

Przechwycenie ruchu w Burp Suite:

1. Przejdź do zakładki WebSockets history.
2. Przechwyć i zmodyfikuj wiadomość WebSocket.
3. Wysłanie zmienionych danych może ujawnić podatność.

4.1 IDOR w WebSockets

Podobnie jak w API REST, jeśli WebSocket pozwala na zmianę ID użytkownika:

{"action":"getUser","id":"123"}

Zmiana 123 na 124 może ujawnić dane innego użytkownika.

4.2 WebSocket Injection

Niektóre aplikacje nie walidują poprawnie wejścia:

{"action":"sendMessage","message":"<script>alert('XSS')</script>"}

Jeśli wiadomość jest wyświetlana bez sanitacji, możliwy jest atak XSS.

4.3 Brak kontroli autoryzacji w WebSockets

Jeśli WebSocket nie sprawdza autoryzacji użytkownika, można wykonywać operacje jako inny użytkownik:

{"action":"transferFunds","amount":10000,"to":"hacker"}

Rozwiązanie: Każda wiadomość WebSocket powinna być podpisana tokenem JWT.

---

Jak zabezpieczyć API i WebSockets?

✅ Ogranicz uprawnienia użytkowników i stosuj weryfikację ID w API. ✅ Waliduj dane wejściowe i nie dopuszczaj do manipulacji tokenami JWT. ✅ Monitoruj ruch API pod kątem nietypowych żądań i prób brute-force. ✅ Stosuj uwierzytelnianie dla WebSockets i sprawdzaj sesję użytkownika. ✅ Wprowadź limity zapytań dla GraphQL i WebSockets.

---

API i WebSockets są kluczowymi elementami aplikacji webowych, ale ich podatności mogą prowadzić do poważnych ataków. Kolejnym krokiem będzie Testowanie aplikacji w chmurze (AWS, Azure, GCP)!