Inspekcja ruchu aplikacyjnego w architekturze KSeF

Cel badania

Celem badań było ustalenie, w którym miejscu infrastruktury KSeF następuje analiza treści ruchu HTTP, w szczególności:

1. czy treść żądań (plaintext po zakończeniu sesji TLS) jest dostępna na brzegu infrastruktury, w warstwie CDN/WAF (Imperva),
2. czy analiza zachodzi dopiero za bramą aplikacyjną (gateway, istio-envoy),
3. czy możliwe jest rozstrzygnięcie tej kwestii metodami obserwacyjnymi (black-box), bez użycia konta użytkownika.

Badania wykonano z wykorzystaniem:

• analizy DNS i TLS,
• obserwacji kodów odpowiedzi HTTP i nagłówków,
• kontrolowanego różnicowania treści żądań (payload),
• porównań między środowiskiem testowym i produkcyjnym.

---

1. Architektura wejścia do systemu

1.1. Rozwiązywanie nazw DNS

Wszystkie analizowane nazwy hostów:

• ap.ksef.mf.gov.pl
• api.ksef.mf.gov.pl
• api-test.ksef.mf.gov.pl
• ksef.mf.gov.pl

wskazują na:

• rekord CNAME w domenie Imperva (*.ng.impervadns.net),
• ten sam adres IP: 45.60.74.103.

Wniosek

Ruch do środowiska produkcyjnego i testowego przechodzi przez ten sam komponent brzegowy CDN/WAF.

---

2. Warstwa HTTP i identyfikacja właściwego hosta API

2.1. Host ap.ksef.mf.gov.pl

Zachowanie tego hosta:

• zwraca odpowiedzi HTML dla różnych ścieżek,
• pełni funkcję interfejsu webowego (SPA).

Nie jest to właściwa brama API.

---

2.2. Host api.ksef.mf.gov.pl

Poprawne odpowiedzi:

• GET /v2 → 200 application/json,
• GET /docs/v2/openapi.json → 200 application/json.

Wniosek

To jest rzeczywisty punkt wejścia API
(zarówno w produkcji, jak i w środowisku testowym).

---

3. Metodyka badania inspekcji treści

3.1. Typy użytych treści żądań (payload)

Zastosowano cztery kontrolowane warianty:

Typ	Charakterystyka
neutral	krótki, poprawny JSON
jndi	zawiera wzorzec ${jndi:…}
xxe	zawiera konstrukcję kojarzoną z XXE
big	bardzo duże ciało żądania (kilka MB)

Każdy wariant wysyłano do:

POST /v2/auth/sessions
bez uwierzytelnienia.

---

4. Wyniki pomiarów

4.1. Kody odpowiedzi HTTP

Typ payloadu	Produkcja	Test
neutral	405	405
jndi	403	403
xxe	403	403
big	413	413

Interpretacja

• 405 – żądanie dotarło do warstwy obsługującej metodę, lecz metoda jest niedozwolona.
• 403 – blokada zależna od zawartości treści żądania, nie od ścieżki ani metody.
• 413 – ograniczenie rozmiaru egzekwowane przed przetwarzaniem przez aplikację.

---

5. Test rozstrzygający: ścieżka istniejąca i nieistniejąca

Porównano:

• /v2/auth/sessions – ścieżka rzeczywista,
• /v2/auth/sessions__nope – ścieżka nieistniejąca.

Wynik

Blokada 403 dla wzorca jndi występuje w obu przypadkach.

Wniosek

Analiza treści żądania zachodzi:

przed rozstrzygnięciem routingu do konkretnego endpointu.

Oznacza to działanie mechanizmu na brzegu infrastruktury.

---

6. Test głębokości analizy treści

Wzorzec jndi umieszczono:

• na początku payloadu,
• po około 200 kB danych.

W obu przypadkach:

403 w produkcji i teście.

Wniosek

Mechanizm filtracji:

• nie ogranicza się do początku treści,
• analizuje znaczną część lub całość payloadu.

To wskazuje na pełną terminację TLS i analizę plaintextu HTTP w warstwie brzegowej.

---

7. Nagłówki odpowiedzi WAF/CDN

Odpowiedzi blokujące zawierają:

• nagłówek X-Iinfo,
• charakterystyczną sygnaturę polityki blokady (B15(...)).

Wniosek

Blokada pochodzi z:

globalnej polityki WAF/CDN,
a nie z logiki aplikacji backendowej.

---

8. Wnioski końcowe

8.1. Lokalizacja inspekcji treści

Badania wykazały, że:

• treść żądań HTTP jest analizowana na brzegu infrastruktury,
• analiza następuje przed routingiem do usług backendowych,
• decyzje blokujące zależą bezpośrednio od zawartości payloadu,
• mechanizm potrafi analizować głęboką część treści.

Oznacza to, że:

plaintext ruchu aplikacyjnego po zakończeniu TLS jest dostępny w warstwie CDN/WAF.

---

8.2. Spójność środowisk

Produkcja i środowisko testowe:

• zwracają identyczne kody odpowiedzi,
• wykazują te same sygnatury polityk blokujących,
• mają zgodne limity rozmiaru.

Wskazuje to na:

wspólną konfigurację mechanizmów filtracji na brzegu infrastruktury.

---

8.3. Niezależność od logiki aplikacji

Blokada:

• nie zależy od istnienia endpointu,
• nie zależy od autoryzacji,
• nie zależy od backendu.

Jest więc decyzją warstwy brzegowej, a nie aplikacyjnej.

---

9. Podsumowanie

Empiryczne, powtarzalne testy obserwacyjne wykazały, że:

ruch HTTP do API KSeF jest deszyfrowany i poddawany analizie treści w warstwie CDN/WAF przed przekazaniem do usług backendowych.

Wniosek ten wynika bezpośrednio z:

• zależności kodów odpowiedzi od zawartości payloadu,
• identycznej blokady dla ścieżek nieistniejących,
• głębokiej analizy treści żądań,
• sygnatur polityk WAF w nagłówkach odpowiedzi.

Uzupełnienie raportu względem notki

„Część VII – jakie metadane widzi Imperva”

1. Zakres metadanych opisany w artykule – potwierdzenie empiryczne

Przeprowadzone testy potwierdzają, że w infrastrukturze KSeF warstwa CDN/WAF (Imperva) ma dostęp do wszystkich klas informacji wymienionych w analizowanej notce, w szczególności:

• nagłówków HTTP (metoda, ścieżka, User-Agent, itp.),
• parametrów zapytań i struktury URL,
• metadanych sesji TLS (SNI, certyfikat, parametry połączenia),
• informacji o rozmiarze i charakterystyce ruchu,
• decyzji polityk bezpieczeństwa widocznych w nagłówkach odpowiedzi (np. X-Iinfo).

Zakres obserwacji uzyskany w audycie jest więc spójny z opisem teoretycznym przedstawionym w notce. Audyt nie podważa żadnego z tamtych ustaleń – przeciwnie, stanowi ich potwierdzenie pomiarowe.

---

2. Elementy ujawnione przez audyt ponad zakres artykułu

Badania wykazały jednak dodatkowe właściwości, które nie wynikały wprost z samej analizy metadanych.

2.1. Dostęp do treści HTTP body (plaintext po TLS)

Decyzje blokujące (403) okazały się zależne wyłącznie od:

• zawartości payloadu,
• a nie od nagłówków, ścieżki, metody czy autoryzacji.

Oznacza to, że warstwa CDN/WAF: widzi rzeczywistą treść żądania HTTP po zakończeniu TLS, a nie jedynie jego metadane.

---

2.2. Analiza treści następuje przed routingiem do backendu

Blokada zależna od payloadu wystąpiła również dla:

• ścieżek nieistniejących w aplikacji.

Wniosek: decyzja o odrzuceniu żądania zapada zanim nastąpi routing do konkretnego endpointu. To lokalizuje mechanizm filtracji jednoznacznie w warstwie brzegowej, a nie w backendzie KSeF.

---

2.3. Głęboka inspekcja treści, nie tylko prefiks payloadu

Wzorzec testowy umieszczony:

• na początku body,
• po ~200 kB danych,

został wykryty identycznie (403). Oznacza to, że analiza obejmuje znaczną część lub całość payloadu, a nie tylko jego początkowy fragment.

---

2.4. Spójność polityk między środowiskiem testowym i produkcyjnym

Zarówno produkcja, jak i środowisko testowe:

• zwracają identyczne kody odpowiedzi (403/405/413),
• wykazują te same sygnatury polityk WAF,
• mają zgodne limity rozmiaru żądań.

Wskazuje to na wspólną konfigurację mechanizmów filtracji w warstwie CDN/WAF przed rozdzieleniem ruchu do poszczególnych środowisk.

---

3. Syntetyczne zestawienie

Zakres obserwacji	Artykuł	Audyt
Nagłówki HTTP i URL	✔	✔ (potwierdzone)
Metadane TLS	✔	✔ (potwierdzone)
Rozmiar i charakter ruchu	✔	✔ (potwierdzone)
Treść HTTP body	(niejednoznaczne)	✔ potwierdzone empirycznie
Lokalizacja filtracji przed routingiem	brak	✔ wykazane
Głęboka analiza payloadu	brak	✔ wykazana
Spójność polityk test/prod	brak	✔ wykazana

---

4. Konkluzja uzupełniająca

Artykuł prawidłowo opisywał zakres metadanych widocznych dla warstwy CDN/WAF.
Audyt techniczny rozszerza ten obraz, wykazując dodatkowo, że warstwa Imperva w infrastrukturze KSeF ma dostęp nie tylko do metadanych, lecz także do rzeczywistej treści żądań HTTP, analizuje ją przed routingiem do backendu i robi to w sposób głęboki oraz spójny między środowiskami. Stanowi to empiryczne uzupełnienie wcześniejszej analizy teoretycznej.

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