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. 1. czy treść żądań (plaintext po zakończeniu sesji TLS) jest dostępna na brzegu infrastruktury, w warstwie CDN/WAF (Imperva),

1. 1. czy analiza zachodzi dopiero za bramą aplikacyjną (gateway, istio-envoy),

1. 1. 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