Informacje Lokalne

Krok 1 — potwierdzenie obecności warstwy Imperva przed backendem KSeF

Komenda

curl.exe -vk https://api.ksef.mf.gov.pl/v2/rate-limits -o NUL

Wynik (fragment nagłówków HTTP)

HTTP/1.1 401 Unauthorized
Server: Kestrel
X-CDN: Imperva
Set-Cookie: visid_incap_...
Set-Cookie: incap_ses_...

Opis techniczny

Nagłówek X-CDN: Imperva oraz ciasteczka visid_incap_* i incap_ses_* są charakterystyczne dla reverse-proxy WAF Imperva. Odpowiedź HTTP została wygenerowana po zakończeniu sesji TLS na tej warstwie.

Wniosek

Połączenie TLS kończy się na infrastrukturze Imperva, która ma techniczną możliwość:

• odszyfrowania całego ruchu HTTP,
• analizy nagłówków i treści odpowiedzi,
• logowania pełnych odpowiedzi aplikacyjnych.

---

Krok 2 — potwierdzenie, że API KSeF zwraca dane aplikacyjne w formacie JSON

Komenda

curl.exe -vk https://api.ksef.mf.gov.pl/v2/auth/challenge

Wynik

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-CDN: Imperva

Treść odpowiedzi:

{
  "challenge": "20260214-CR-...",
  "timestamp": "2026-02-14T19:24:11.5838134+00:00",
  "timestampMs": 1771097051583
}

Opis techniczny

Odpowiedź:

• została przekazana przez Imperva (nagłówek X-CDN),
• zawiera czytelny JSON w plaintext,
• nie jest objęta dodatkowym szyfrowaniem aplikacyjnym.

Wniosek

Imperva ma pełny wgląd w:

• identyfikatory operacji,
• znaczniki czasu,
• strukturę odpowiedzi API.

---

Krok 3 — potwierdzenie widoczności statusów operacji uwierzytelniania

Komenda

curl.exe -vk -H "Authorization: Bearer <authenticationToken>" `
  https://api.ksef.mf.gov.pl/v2/auth/<referenceNumber>

Wynik

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-CDN: Imperva

Treść:

{
  "startDate": "2026-02-14T19:47:26.7106241+00:00",
  "authenticationMethod": "Token",
  "authenticationMethodInfo": {
    "category": "Token",
    "code": "token.ksef",
    "displayName": "Token KSeF"
  },
  "status": {
    "code": 450,
    "description": "Uwierzytelnianie zakończone niepowodzeniem...",
    "details": ["Invalid token encoding."]
  }
}

Opis techniczny

Odpowiedź:

• przechodzi przez Imperva w postaci odszyfrowanej,
• zawiera szczegółowe dane operacyjne w JSON,
• nie jest szyfrowana na poziomie aplikacyjnym.

Wniosek

Imperva widzi w plaintext:

• metodę uwierzytelniania,
• status operacji,
• szczegóły błędów,
• znaczniki czasu.

---

Krok 4 — potwierdzenie, że metadane biznesowe są zwracane w JSON (model API)

Komenda

$spec.components.schemas.InvoiceMetadata | ConvertTo-Json -Depth 20

Wynik (fragment schematu)

Schemat metadanych obejmuje pola:

• NIP sprzedawcy
• identyfikator nabywcy
• nazwy podmiotów
• kwoty netto, VAT i brutto
• walutę
• numer faktury
• daty operacyjne
• typ faktury

Opis techniczny

Ponieważ:

1. API zwraca dane w jawnej strukturze JSON,
2. TLS jest terminowany na Imperva,
3. brak jest dodatkowego szyfrowania pól metadanych,

to wszystkie pola modelu odpowiedzi są czytelne dla warstwy WAF.

Wniosek

Każdy endpoint zwracający metadane faktur w JSON:

• ujawnia je w plaintext po stronie Imperva,
• umożliwia analizę przepływów gospodarczych bez dostępu do XML faktury.

---

Krok 5 — logiczna konsekwencja architektury TLS termination

Obserwacje potwierdzone w audycie

1. TLS kończy się na Imperva.
2. Imperva przekazuje do klienta odszyfrowane odpowiedzi HTTP.
3. API KSeF zwraca metadane w jawnych strukturach JSON.

Wniosek końcowy (techniczny, niepublicystyczny)

Warstwa Imperva ma techniczną możliwość odczytu wszystkich danych, które:

• znajdują się w nagłówkach HTTP,
• znajdują się w treści odpowiedzi JSON,
• nie są dodatkowo szyfrowane aplikacyjnie przed wysłaniem.

Dotyczy to w szczególności:

• identyfikatorów podmiotów (NIP, VAT UE),
• nazw kontrahentów,
• kwot transakcji,
• dat i numerów faktur,
• statusów operacji systemowych.

Grzegorz GPS Świderski
Kanał Blogera GPS
GPS i Przyjaciele
X.GPS65