Anatomia ryzyk wielotenantowej platformy biletowej do obsługi atrakcji turystycznych - case study na przykładzie Orientarium Zoo Łódź

TL;DR. 3 kwietnia 2026 r. redakcja Signal Dadalo Media przeprowadziła kontrolowany test zakupu biletu do Orientarium Zoo Łódź przez platformę BASE - wielotenantową SaaS sprzedaży biletów obsługującą (wg deklaracji operatora) ponad 50 obiektów: ogrody zoologiczne, aquaparki, stacje narciarskie, obiekty UNESCO, hotele i instytucje publiczne. Materiał poniżej jest rozszerzoną wersją zawiadomienia złożonego do UODO 23 kwietnia 2026 r. - 18 dni temu. W tym czasie ORIENTARIUM przebudowało koszyk i zmodyfikowało komunikację o partnerach oraz procedurze płatności (analiza payloadów po modyfikacjach jeszcze trwa). Serwer nadal pozostaje w strefie zarządzanej przez Oracle (DynDNS, homelinux.net), więc twardy rdzeń architektoniczny jest niezmieniony.

Cztery grzechy główne

1. Infrastruktura domenowa DynDNS o niskim zaufaniu (homelinux.net, strefa Oracle Dyn - usługa typu Dynamic DNS / Remote Access dla urządzeń domowych).
2. Skrajnie nieaktualne oprogramowanie serwerowe - nginx/1.10.3 na Ubuntu 16.04, którego standardowe wsparcie zakończyło się w 2021 r., a ESM wygasło w kwietniu 2026.
3. Krytycznie błędna konfiguracja CORS - Access-Control-Allow-Origin: * w połączeniu z Access-Control-Allow-Credentials: true, sprzeczne ze specyfikacją W3C/WHATWG Fetch.
4. Przesyłanie danych osobowych w parametrach URL (GET) - adres e-mail klienta jako CustomerEmail w query stringu przekierowania do operatora płatności.

W typowym audycie bezpieczeństwa lub zgodności z RODO ten układ otrzymałby ocenę negatywną z rekomendacją natychmiastowej migracji na bezpieczniejszą architekturę.

I. STAN FAKTYCZNY

3 kwietnia 2026 r. redakcja podjęła czynności weryfikacyjne dotyczące architektury sprzedaży biletów elektronicznych w platformie BASE, wykorzystując jako przykład proces zakupu biletu wstępu do Orientarium Zoo Łódź. Test przeprowadzono w warunkach kontrolowanych - w przeglądarce w trybie prywatnym, bez cache’u i wcześniej zapisanych ciasteczek - z wykorzystaniem tożsamości redakcyjnej (adres e-mail: redakcja@dadalo.pl). Celem była weryfikacja zachowania platformy w typowym scenariuszu zakupowym oraz udokumentowanie sposobu przetwarzania danych osobowych w toku tego procesu.

Zebrano kompletną dokumentację techniczną:

• łańcuch przekierowań HTTP z surowymi nagłówkami odpowiedzi serwerów,
• odtwarzalne zapytania curl odwzorowujące przepływ zakupu,
• pełną konfigurację CORS zwracaną na żądania preflight OPTIONS,
• rozpoznanie DNS dla wszystkich domen w łańcuchu,
• ciasteczka ustawiane w toku procesu zakupu,
• żądania do systemów analitycznych aktywnych na stronie bramki płatniczej,
• nagłówki SMTP wiadomości e-mail wygenerowanej przez system po transakcji.

Całość materiału technicznego znajduje się w sekcji V (Załączniki).

I.1. Architektura systemu sprzedaży - komponent zewnętrzny osadzany na stronie Administratora

Strona orientarium.lodz.pl/bilety nie hostuje panelu sprzedażowego we własnej infrastrukturze. Formularz zakupowy jest komponentem webowym (web component) osadzanym z zewnętrznego systemu działającego pod domeną sklep.homelinux.net. Dane osobowe wprowadzane przez użytkownika - imię, nazwisko, adres e-mail, numer telefonu - trafiają bezpośrednio na serwer pod adresem IP 185.204.217.182, a nie do infrastruktury Administratora.

Model ten jest przez operatora platformy opisywany publicznie jako standardowy tryb wdrożenia. Na stronie basesystem.pl/modul-sprzedazy-online BASE deklaruje: „Panel sprzedaży online można umieścić wewnątrz własnej strony WWW po uprzednim skonfigurowaniu biletów, grafik i skonfigurowaniu akcentów kolorystycznych", wskazując dalej: „Aby dokonać zakupu wystarczy wybrać bilety, potwierdzić zamówienie podając imię, nazwisko i adres mailowy, a następnie opłacić zamówienie online".

Komunikacja przeglądarki z backendem odbywa się przez endpointy API identyfikowane unikalnymi GUID-ami na poziomie ścieżki URL:

POST https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add
POST https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/order

Ciąg f5ff01a4311c42a68af6f4d9780290d2 jest identyfikatorem tenanta (GUID) konkretnego klienta platformy - w opisanym przypadku Orientarium Zoo Łódź. Struktura endpointu potwierdza wielotenantowy charakter systemu: identyczna infrastruktura obsługuje wielu administratorów danych pod różnymi identyfikatorami.

I.2. Ekspozycja adresu e-mail klienta w parametrze URL - naruszenie główne

Po złożeniu zamówienia i kliknięciu przycisku „Kupuję i płacę" serwer sklep.homelinux.net generuje przekierowanie HTTP, kierujące przeglądarkę użytkownika do operatora płatności. Przechwycone w sposób odtwarzalny nagłówki odpowiedzi serwera:

1
2
3
4
5
6
7

HTTP/1.1 302 Found
Server: nginx/1.10.3 (Ubuntu)
Location: https://pay.bm.pl/payment?ServiceID=103573
  &OrderID=7a31bf54b0434ed8827c2669eb01505c
  &Amount=80.00
  &CustomerEmail=redakcja@dadalo.pl
  &Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027

Adres e-mail klienta - parametr CustomerEmail - jest przekazywany w query stringu adresu URL (metoda GET), w formie jawnej. Adres e-mail w URL jest eksponowany w następujących kontekstach przetwarzania:

• w pasku adresu przeglądarki - widoczny dla osób postronnych mających wgląd w ekran;
• w historii przeglądarki - zapisywany trwale i synchronizowany między urządzeniami przez mechanizmy Chrome Sync, Firefox Sync itp.;
• w logach dostępowych serwerów (access logs) - zarówno sklep.homelinux.net, jak i pay.bm.pl, a następnie pay.autopay.eu standardowo rejestrują pełny URL (włącznie z query stringiem) w logach, o ile administratorzy tych systemów nie wdrożyli dedykowanej filtracji;
• w nagłówku HTTP Referer - kolejne żądania HTTP mogą przekazać URL zawierający dane osobowe do systemów trzecich;
• w systemach analitycznych aktywnych na bramce płatniczej - Matomo (piwik.blue.pl) oraz Google Analytics, jak opisano w sekcji I.9.

Standardy branżowe - w tym zalecenia OWASP w zakresie „Use of Sensitive Information in URL Query Parameters" (CWE-598) oraz materiały edukacyjne samego operatora płatności Autopay - jednoznacznie wskazują, że dane osobowe powinny być przekazywane w ciele żądania POST lub kanałem serwer-serwer, a nigdy w query stringu adresu URL.

Opisany wzorzec przetwarzania nie jest indywidualną pomyłką konfiguracyjną, lecz systemowym rozwiązaniem w integracji BASE ↔ pay.bm.pl. Wskazuje na to zarówno struktura parametrów URL (zawierająca kryptograficzny Hash obliczany po stronie serwera BASE na podstawie parametrów, w tym CustomerEmail), jak i konsekwentne występowanie parametru w każdym z kolejnych testów.

I.3. Przestarzała infrastruktura serwerowa - nginx 1.10.3 na Ubuntu 16.04

Serwer obsługujący platformę BASE odpowiada nagłówkiem:

Server: nginx/1.10.3 (Ubuntu)

Nginx w wersji 1.10.3 został wydany 31 stycznia 2017 roku. Gałąź 1.10 upstream zakończyła wsparcie w 2017 roku. Pakiet ten pochodzi z dystrybucji Ubuntu 16.04 LTS (Xenial Xerus), której:

• standardowe wsparcie bezpieczeństwa Canonical zakończyło się w kwietniu 2021 roku (pięć lat przed datą audytu);
• rozszerzone wsparcie (Extended Security Maintenance, ESM) - dostępne jako płatna subskrypcja w ramach Ubuntu Pro - trwa do końca kwietnia 2026 roku, czyli wygasa w ciągu najbliższych dni.

Oznacza to, że infrastruktura przetwarzająca dane osobowe klientów kilkudziesięciu obiektów użyteczności publicznej oraz obsługująca inicjację płatności o wartości milionowej w skali roku:

• przez ostatnie pięć lat otrzymywała jedynie aktualizacje bezpieczeństwa wąsko ograniczone do CVE o wysokim i krytycznym stopniu ryzyka (w ramach ESM), pod warunkiem posiadania przez operatora aktywnej, płatnej subskrypcji Ubuntu Pro;
• w ciągu najbliższych dni przestanie otrzymywać jakiekolwiek aktualizacje od producenta systemu operacyjnego, o ile operator nie nabędzie dodatkowej subskrypcji „Legacy" Ubuntu Pro;
• od lat nie otrzymuje aktualizacji od upstream’u nginx (gałąź 1.10 zakończyła cykl życia w 2017 r.);
• nie zapewnia wsparcia dla aktualnych standardów protokołu TLS ani nowszych mechanizmów ochrony protokołu HTTP/2.

Migracja do wspieranej wersji dystrybucji systemu operacyjnego jest procesem rutynowym, dostępnym dla każdego profesjonalnego operatora infrastruktury IT.

I.4. Błędna konfiguracja CORS - sprzeczność ze specyfikacją W3C

Serwer API sklepu odpowiada na żądanie preflight (OPTIONS) następującymi nagłówkami:

1
2
3
4
5
6
7
8

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,
  X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,
  Expires,Pragma
Access-Control-Max-Age: 1728000

Jednoczesne wystąpienie Access-Control-Allow-Origin: * (wildcard) oraz Access-Control-Allow-Credentials: true jest konfiguracją sprzeczną ze specyfikacją CORS (W3C / WHATWG Fetch Standard - sekcja dotycząca credentialed requests). Specyfikacja jednoznacznie stanowi, że gdy flaga credentials jest ustawiona na true, wartość Access-Control-Allow-Origin musi wskazywać konkretne źródło, a nie wildcard. Standardowe implementacje przeglądarek wprawdzie zablokują takie żądania na poziomie klienta, jednak sama deklaracja serwera o akceptacji uwierzytelnionych żądań z dowolnego źródła świadczy o braku przeglądu bezpieczeństwa oraz sygnalizuje, że serwer został skonfigurowany w sposób niezgodny z podstawowymi standardami bezpieczeństwa webowego.

Dla porównania: system analityczny Matomo działający pod domeną piwik.blue.pl (wykorzystywany na bramce pay.autopay.eu) stosuje precyzyjne ograniczenie Access-Control-Allow-Origin: https://pay.autopay.eu. Operator systemu biletowego BASE nie stosuje żadnego ograniczenia źródła.

I.5. Domena produkcyjna w strefie zarządzanej przez Oracle Corporation - homelinux.net

System przetwarzający dane osobowe klientów oraz obsługujący inicjację płatności działa pod subdomeną sklep.homelinux.net. Strefa homelinux.net jest domeną dynamicznego DNS oferowaną przez Dyn - podmiot, który w 2016 r. został przejęty przez Oracle Corporation. Potwierdza to rozpoznanie DNS wykonane 21 kwietnia 2026 r.:

$ dig SOA homelinux.net
→ ns1.dyndns.org. hostmaster.dyndns.org. 2126617188 10800 1800 604800 1800

Strefa homelinux.net znajduje się na oficjalnej liście domen dynamicznego DNS Oracle/Dyn (publikacja: help.dyn.com/list-of-dyn-dns-pro-remote-access-domain-names.html), obok domen takich jak is-a-chef.com, is-a-geek.com, homeunix.com czy homeip.net. Zgodnie z oficjalnym opisem usługi Oracle Dyn Dynamic DNS, jej zastosowanie to „remotely accessing files from home computers, monitoring security systems, and accessing home…" - zdalny dostęp do urządzeń domowych (NAS, kamera monitoringu, router, serwer hobbystyczny). Z publicznego opisu usługi Oracle Dyn wynika, że ma ona charakter rozwiązania typu Dynamic DNS / Remote Access, przeznaczonego do wiązania zmiennego adresu IP z urządzeniami i usługami takimi jak router, kamera, DVR, termostat, komputer, pamięć plikowa czy serwer gier.

Istotne jest przy tym, że BASE nie występuje jako podmiot zarządzający strefą homelinux.net, lecz jako użytkownik subdomeny funkcjonującej w ramach infrastruktury Oracle Dyn, co potwierdzają ustalenia DNS oraz opis tej usługi. Oznacza to, że operator nie sprawuje decydującej kontroli nad serwerami autorytatywnymi tej strefy, parametrami jej delegacji ani polityką utrzymania samej strefy przez dostawcę usługi. Dla adresu sklep.homelinux.net nie występuje odrębna rejestracja WHOIS, ponieważ rejestracja dotyczy domeny homelinux.net, a nie jej subdomen.

W konsekwencji warstwa DNS, z której faktycznie świadczone są usługi przetwarzania danych osobowych i inicjacji płatności, pozostaje osadzona w zewnętrznej strefie, nad którą operator nie wykonuje pełnej kontroli administracyjnej. Ma to znaczenie nie tylko z punktu widzenia bieżącego zarządzania infrastrukturą, lecz również z perspektywy ciągłości działania oraz przewidywalności warunków świadczenia usługi przez podmiot trzeci.

Dodatkowy kontekst: BASE posługuje się równolegle własną domeną basesystem.pl, co uzasadnia pytanie, czy przyjęty model adresacji był rozwiązaniem właściwie zaprojektowanym dla środowiska produkcyjnego tej skali.

I.6. Brak segmentacji infrastruktury, DMARC p=none oraz ryzyko phishingu

Po teście zakupu na adres testowy redakcja@dadalo.pl przyszła wiadomość e-mail od nadawcy wyświetlanego jako „ZOO Łódź" - z adresu rzeczywistego noreply@basesystem.pl. Analiza nagłówków SMTP ujawnia:

Received: from [127.0.0.1] (unknown [185.204.217.182])
(Authenticated sender: noreply@basesystem.pl)
by ewok.endor.pl (Postfix) with ESMTPSA id...

Analiza pełnych nagłówków SMTP wiadomości transakcyjnej wskazuje, że finalne doręczenie wiadomości do odbiorcy nastąpiło przez serwer ewok.endor.pl (91.194.229.47), natomiast host 185.204.217.182, powiązany z infrastrukturą sklep.homelinux.net, uwierzytelnił się do tego serwera jako klient SMTP z identyfikatorem noreply@basesystem.pl.

Oznacza to, że warstwa aplikacyjna odpowiedzialna za obsługę sklepu uczestniczy bezpośrednio w generowaniu i uwierzytelnionym nadaniu korespondencji transakcyjnej, a więc kompromitacja tego hosta może przełożyć się na możliwość nadużycia kanału wysyłkowego lub mechanizmu SMTP używanego do kontaktu z klientami.

Nagłówki nie pozwalają jednak twierdzić wprost, że ta sama maszyna samodzielnie doręcza pocztę odbiorcom albo przechowuje pełną historię wysłanych wiadomości, ponieważ w procesie uczestniczy odrębny relay pocztowy.

Zastosowano co najwyżej częściową segmentację, która nie odcina hosta aplikacyjnego od uwierzytelnionego nadania SMTP.

Dodatkowym elementem obniżającym poziom ochrony jest polityka DMARC domeny basesystem.pl, ustawiona na p=none. Oznacza to, że serwery pocztowe odbiorców nie podejmują żadnych działań blokujących wobec sfałszowanych wiadomości podszywających się pod basesystem.pl. W połączeniu z faktem, że:

• treść maili transakcyjnych jest prosta do odtworzenia (imię, nazwisko, adres e-mail, nazwa biletu, kwota);
• nadawca wyświetlany (friendly name) może być dowolnie ustawiany na nazwę znaną odbiorcy („ZOO Łódź");
• odbiorca nie spodziewa się maila z domeny basesystem.pl, nieujawniającej się w żadnym momencie procesu zakupowego;
• system nie oferuje wysyłki z domeny brandowanej (white-label), tj. z subdomeny Administratora (np. no-reply@orientarium.lodz.pl), co jest powszechnie uznawaną dobrą praktyką w profesjonalnych systemach biletowych,

tworzy to wektor ataku phishingowego o wysokiej wiarygodności. Znane są udokumentowane ataki wykorzystujące dokładnie taki zestaw informacji (numer zamówienia, nazwa obiektu, kwota, imię i nazwisko klienta) na klientów systemów rezerwacyjnych. Ostatnio taki atak miał miejsce na klientów systemu KWhotel.

I.7. Niestabilność procesu inicjacji płatności

W trakcie przechwytywania ruchu HTTP zaobserwowano, że pierwsza próba inicjacji przekierowania do bramki płatniczej zakończyła się kodem odpowiedzi HTTP 500 Internal Server Error:

1
2
3
4
5
6
7

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, private
date: Fri, 03 Apr 2026 10:02:23 GMT
Set-Cookie: XSRF-TOKEN=[...]
Set-Cookie: base_system_session=[...]

Mimo błędu wewnętrznego serwer kontynuował procesowanie transakcji (ustawiając cookies sesji i finalnie generując kolejne przekierowanie). Zachowanie takie sugeruje brak właściwej obsługi błędów w ścieżce krytycznej procesu płatności. Tworzy ryzyko niekontrolowanego wycieku danych do logów błędów serwera (np. stack traces zawierające wartości zmiennych, w tym dane osobowe klienta), a także utrudnia audyt następczy - w logach występują zdarzenia bez jasnego mapowania na stan przetwarzania.

I.8. Ciasteczka bez flagi Secure

Ciasteczka ustawiane przez serwer sklep.homelinux.net nie zawierają flagi Secure:

1
2

Set-Cookie: XSRF-TOKEN=[...]; expires=[...]; Max-Age=7200; path=/
Set-Cookie: base_system_session=[...]; expires=[...]; Max-Age=7200; path=/; httponly

Ciastko XSRF-TOKEN nie posiada ani flagi Secure, ani HttpOnly. Ciastko base_system_session posiada wyłącznie HttpOnly. Brak flagi Secure oznacza, że w przypadku wystąpienia niezabezpieczonego kanału komunikacji (np. degradacja do HTTP, błąd w łańcuchu certyfikatów) ciasteczka mogą zostać przekazane w formie niezaszyfrowanej. Dla sesji zawierających identyfikatory przetwarzania danych osobowych klienta jest to uchybienie podstawowym standardom bezpieczeństwa webowego. Może to też wynikać z przestarzałego i nieaktualizowanego oprogramowania serwerowego.

I.9. Analityka i nagrywanie sesji użytkownika na stronie bramki płatniczej

Po przejściu łańcucha przekierowań użytkownik trafia na stronę pay.autopay.eu/web/payment/start/{GUID}, gdzie wybiera metodę płatności. Na tej stronie aktywne są systemy analityczne rejestrujące zachowanie użytkownika:

Matomo (piwik.blue.pl, idsite=47) - w trakcie testu zarejestrowano sześć żądań do tej domeny, w tym:

• załadowanie skryptu piwik.js;
• rejestrację wyświetlenia strony z pełnym URL bramki jako parametrem url;
• aktywację modułu HeatmapSessionRecording (/plugins/HeatmapSessionRecording/configs.php?idsite=47&trackerid=Zn1V3x) - nagrywanie sesji użytkownika, rejestrujące ruchy myszy, kliknięcia i scrollowanie;
• aktywację modułu AB Testing (e_c=abtesting&e_a=SimpleABTest);
• aktywację modułu Ecommerce tracking (_pkp=80&_pks=2&_pkn=ECOMMERCE) z informacją o wartości transakcji.

Google Analytics - żądanie POST do www.google-analytics.com/mp/collect?measurement_id=G-CFLZGNHGSQ - śledzenie za pośrednictwem Measurement Protocol.

Nagrywanie sesji użytkownika (HeatmapSessionRecording) na stronie, na której użytkownik wybiera metodę płatności i wprowadza dane karty płatniczej, stanowi praktykę wysokiego ryzyka. Niezależnie od mechanizmów maskowania wdrożonych po stronie operatora, sam fakt rejestracji interakcji użytkownika w czasie rzeczywistym - w połączeniu z możliwością trafienia do nagłówka Referer URL zawierającego CustomerEmail w poprzednim kroku łańcucha - budzi poważne wątpliwości co do zakresu i podstawy prawnej przetwarzania.

I.10. Wielotenantowa platforma obsługująca kilkadziesiąt podmiotów - skala wzorca wdrożeniowego

Opisane ustalenia techniczne nie dotyczą pojedynczego, lokalnego wdrożenia. BASE jest platformą SaaS wielokrotnego użytku. Na stronie basesystem.pl/realizacje operator publicznie wymienia ponad 50 obiektów korzystających z platformy. Lista wymieniona jest sektorowo wyłącznie jako wskazanie skali wzorca wdrożeniowego, który - jeśli ustalenia techniczne opisane w sekcjach I.2–I.9 są systemowe (a ich charakter to sugeruje) - dotyka potencjalnie wszystkich administratorów danych korzystających z tej samej infrastruktury:

Parki rozrywki, Ogrody zoologiczne, Aquaparki i baseny, Stacje narciarskie, Obiekty UNESCO i kultury, Hotele i SPA, Instytucje publiczne, Lodowiska.

Redakcja nie weryfikowała wdrożeń na stronach wymienionych podmiotów ze względów prawnych oraz braku możliwości rzetelnej i szybkiej weryfikacji - nie przedstawiamy pełnej listy firm. Tym bardziej, że lista realizacji na stronie wykonawcy może być nieaktualna (np. EnergyLandia używa comarchesklep.pl do obsługi sprzedaży biletów online). Wskazujemy jednak, że wszystkie te podmioty mogą korzystać z tego samego serwera (IP 185.204.217.182), tej samej wersji oprogramowania, tej samej konfiguracji CORS oraz tego samego modelu przekazywania danych do operatora płatności - co sugeruje, że zaobserwowane uchybienia mogą mieć charakter powtarzalnego wzorca wdrożeniowego o charakterze ogólnopolskim.

I.11. Niezgodność Regulaminu sprzedaży i Polityki plików cookies z faktycznym stanem przetwarzania

Redakcja przeanalizowała Regulamin sprzedaży elektronicznych biletów wstępu do Orientarium Zoo Łódź (dostępny na orientarium.lodz.pl/bilety) oraz Politykę plików cookies serwisu orientarium.lodz.pl (dostępną na tej samej stronie). Dokumenty te wykazują istotne niezgodności z faktycznym stanem przetwarzania danych osobowych, ustalonym w sekcjach I.1–I.9:

(a) Brak informacji o podmiocie przetwarzającym BASE. Regulamin w pkt V.6 deklaruje kategorie odbiorców danych w sposób następujący: „podmioty dostarczające i wspierające systemy teleinformatyczne, podmioty świadczące dla Administratora usługi np. księgowe, prawnicze, podmiot świadczący usługi płatności online". Kategoria „podmioty dostarczające i wspierające systemy teleinformatyczne" jest tak ogólna, że nie pozwala osobie, której dane dotyczą, zidentyfikować konkretnego procesora. Ani Regulamin, ani Polityka cookies nie wymieniają operatora BASE (basesystem.pl) oraz domeny sklep.homelinux.net, mimo że to właśnie ten podmiot i ta domena są faktycznymi odbiorcami danych osobowych klienta w chwili wypełnienia formularza zakupowego.

(b) Nieaktualna nazwa operatora płatności. Regulamin w pkt III.9 wskazuje operatora płatności jako „Blue Media S.A. z siedzibą w Sopocie". Spółka ta w 2022 r. zmieniła firmę na „Autopay S.A." Regulamin nie został zaktualizowany. Choć samo to uchybienie ma charakter informacyjny, świadczy o braku bieżącej weryfikacji dokumentacji RODO przez Administratora.

(c) Deklaracja braku zautomatyzowanego przetwarzania sprzeczna z faktycznym stanem. Regulamin w pkt V.9 deklaruje wprost: „Informujemy, że dane Klienta nie będą przetwarzane w sposób zautomatyzowany w tym profilowania." Tymczasem - jak wykazano w sekcji I.9 - na stronie bramki płatniczej pay.autopay.eu, do której klient jest przekierowywany, aktywne są systemy Matomo z modułami HeatmapSessionRecording (nagrywanie sesji) i AB Testing, a także Google Analytics. Są to formy zautomatyzowanej rejestracji i analizy zachowań użytkownika. Deklaracja Administratora wprowadza zatem osobę, której dane dotyczą, w błąd co do faktycznego zakresu przetwarzania.

(d) Brak informacji o systemach analitycznych w łańcuchu zakupu. Polityka plików cookies wymienia partnerów Administratora w zakresie plików cookies zewnętrznych (Facebook, LinkedIn, Twitter, YouTube, Google Analytics). Nie wymienia natomiast ani piwik.blue.pl (Matomo operatora płatności aktywne w toku procesu zakupu), ani jakiegokolwiek śledzenia związanego z domeną sklep.homelinux.net. Osoba, której dane dotyczą, nie otrzymuje tym samym pełnej informacji o systemach, w kontekście których jej zachowanie jest rejestrowane w toku procesu zakupu biletu.

(e) Ogólność deklaracji o odbiorcach zewnętrznych. Regulamin w pkt V.10 deklaruje: „Dane osobowe nie będą przekazywane do państwa trzeciego ani innym podmiotom z wyjątkiem tych, które są uprawnione do ich uzyskiwania na podstawie przepisów obowiązującego prawa." Deklaracja ta nie uwzględnia faktu, że dane klienta w toku inicjacji płatności są przekazywane w adresie URL do domeny pay.bm.pl, a następnie do pay.autopay.eu, gdzie są rejestrowane przez systemy Matomo i Google Analytics (ten ostatni z przepływem danych do Google LLC w USA - państwie trzecim w rozumieniu RODO).

I.12. Karta Łodzianina - klasyczny input validation failure w odrębnym mechanizmie zakupowym

Niezależnie od opisanego wyżej standardowego procesu zakupu biletów, w serwisie funkcjonuje odrębny mechanizm obsługi biletów powiązanych z kartami lojalnościowymi (w tym Kartą Łodzianina wdrożoną przez QB sp. z o.o. z Gdyni). Mechanizm ten wykorzystuje osobny formularz weryfikacji uprawnienia do ulgi, w ramach którego użytkownik podaje numer karty oraz kod PIN, a następnie inicjuje sprawdzenie uprawnienia przez zewnętrzny backend działający pod adresem sklep.homelinux.net.

W toku weryfikacji tego mechanizmu stwierdzono brak skutecznej walidacji długości danych wejściowych w polu numeru karty oraz brak sanityzacji znaków specjalnych - a więc podręcznikowy input validation failure z katalogu OWASP Top 10 (kategoria „Insecure Design" / „Injection"). Endpoint:

POST /api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/useService

umożliwiał przesłanie wartości pola card o rozmiarze dalece przekraczającym racjonalny format numeru karty, ze znakami specjalnymi - co może doprowadzić do zakłócenia działania formularza weryfikacyjnego i wskazuje na brak elementarnych ograniczeń wejścia po stronie aplikacji i/lub backendu. Na zrzutach ekranu (Załącznik R) widoczny jest brak ograniczenia długości danych w polu numeru karty oraz akceptacja przez system ciągu o długości » 1000 znaków, co potwierdza brak podstawowej sanityzacji i walidacji wejścia.

Dlaczego to ważne:

• mechanizm weryfikacji uprawnienia do ulgi jest realizowany przez tę samą infrastrukturę BASE (sklep.homelinux.net), która pośredniczy również w pozostałych operacjach zakupu biletów i przetwarzaniu danych użytkowników;
• brak podstawowych mechanizmów walidacji wejścia w odrębnym kanale obsługi ulg i kart lojalnościowych wskazuje na istotne braki w projektowaniu oraz zabezpieczeniu tego rozwiązania, mogące stanowić potencjalny wektor ataku na infrastrukturę i przetwarzane w niej dane osobowe;
• charakter uchybienia (brak walidacji długości i sanityzacji wejścia) zalicza się do podstawowych klas ryzyk bezpieczeństwa aplikacji webowych identyfikowanych w wytycznych OWASP i ENISA jako wymagających obowiązkowej kontroli na etapie projektowania.

Pod formularzem weryfikacji uprawnienia widnieje komunikat: „W przypadku pytań związanych z ofertą prosimy o kontakt pod adresem bok@zoo.lodz.pl. System sprzedaży biletów dostarcza BASE System". Zestawienie tego komunikatu z rzeczywistym przepływem żądań do sklep.homelinux.net potwierdza, że operacja sprawdzania uprawnienia do ulgi nie odbywa się wyłącznie w infrastrukturze Administratora, lecz z udziałem zewnętrznego serwera pośredniczącego.

Test został przeprowadzony wyłącznie z użyciem standardowej funkcjonalności formularza dostępnego publicznie, na tożsamości testowej redakcji (redakcja@dadalo.pl), bez użycia jakichkolwiek narzędzi do automatyzacji, bez próby iniekcji kodu, bez naruszania integralności systemu ani omijania mechanizmów uwierzytelniania. Działanie polegało na wprowadzeniu w polu numeru karty ciągu znaków o długości przekraczającej racjonalny format, co system zaakceptował, ujawniając brak walidacji wejścia. Nie nastąpiło żadne zakłócenie funkcjonowania systemu ani dostęp do nieuprawnionych danych.

V. ZAŁĄCZNIKI TECHNICZNE

Dokumentacja zebrana podczas kontrolowanego testu zakupu przeprowadzonego 3 kwietnia 2026 r. (ID audytu evidence_20260403_1149).

Załącznik A - redirect_chain.json

Zarejestrowany łańcuch przekierowań HTTP z URL zawierającym parametr CustomerEmail:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

[
  {
    "url": "https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c",
    "status": 302,
    "location": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027"
  },
  {
    "url": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027",
    "status": 303,
    "location": "https://pay.autopay.eu/web/payment/start/768a3653b0da481699fe1e6c496eeeeb"
  }
]

Załącznik B - redirect_chain_raw_headers.txt

Surowe nagłówki HTTP z odpowiedzi serwerów, w tym zarejestrowany kod HTTP 500 Internal Server Error:

=== Payment Redirect Chain Capture ===
Timestamp: 2026-04-03T10:02:23Z
Order GUID: 7a31bf54b0434ed8827c2669eb01505c
Initial URL: https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c
=======================================

--- Step 1: Payment Init (sklep.homelinux.net) ---
HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Cache-Control: no-cache, private
date: Fri, 03 Apr 2026 10:02:23 GMT
Set-Cookie: XSRF-TOKEN=eyJpdiI6Ing5c09DWUZpbUJ2eFF1bXpzMU5ISHc9PSIsInZhbHVlIjoieDBZVHdlQzlLaWJnQWtXMGloRFJsaWk1TFF2bnpnL2lKQ0I1dnZVMktEUkxYZUh1V3c1S2J6UlJiYzFQdVdkVXBQS09UemowNDBPcmtoSDNQbnZBRVMrSndzdTJPajRDRm0yR1NUMkQxcXJ1VGFkN2lDWDVHaFBucld6THE0NXMiLCJtYWMiOiI3ODIwY2Y0YzQ1NmQ0MWNkOTAyODcwYmI5NjMyNWVlOWE1NTc1OGNmODQ0ZDFkYjNlNDhlMGI3MGMyZTk0YzVkIn0%3D; expires=Fri, 03-Apr-2026 12:02:23 GMT; Max-Age=7200; path=/
Set-Cookie: base_system_session=eyJpdiI6IklobzNJNE5xTzU3WWZJQThRTmRmbmc9PSIsInZhbHVlIjoieTRFTU16WlBzeXNVblJ2WU4rei9VWnpPdjJUZDBYMzgzQ1VRdXRDMEk3R3ppVGJ5bmhRcndMNGV1VTVlRk05cGtRZUlyZGkwTWwwMXlXVm1COHNwTWNHeG9kdFZ3NjF1MjZhRmdQL242bVJrZzZhRlpoU2ZPbkFMSjdzeU9xYm8iLCJtYWMiOiI3MDdmN2YyMDRiMDg4YmZlOGU5OGFmNTY3ODdhZDQwYjYzMDYxNDVhZjVlZDVhMzc2ZTI2ZTM3MmNkZWFmZjBhIn0%3D; expires=Fri, 03-Apr-2026 12:02:23 GMT; Max-Age=7200; path=/; httponly

Załącznik C - redirect_chain_curl.json

Odtwarzalna wersja łańcucha przekierowań w formie zapytań curl:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "capture_timestamp": "2026-04-03T10:02:23Z",
  "order_guid": "7a31bf54b0434ed8827c2669eb01505c",
  "redirect_chain": [
    {
      "step": 1,
      "url": "https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c",
      "status": "302",
      "location": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027",
      "server": "nginx/1.10.3 (Ubuntu)",
      "description": "Payment init on sklep.homelinux.net - 302 redirect exposes CustomerEmail in URL"
    },
    {
      "step": 2,
      "url": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027",
      "status": "303",
      "location": "https://pay.autopay.eu/web/payment/start/768a3653b0da481699fe1e6c496eeeeb",
      "description": "Payment gateway redirect (pay.bm.pl → pay.autopay.eu)"
    },
    {
      "step": 3,
      "url": "https://pay.autopay.eu/web/payment/start/768a3653b0da481699fe1e6c496eeeeb",
      "status": "200",
      "location": null,
      "description": "Autopay payment page (STOP - do not proceed with payment)"
    }
  ],
  "pii_in_url": true,
  "customer_email_extracted": "redakcja@dadalo.pl"
}

Załącznik D - cors_check.txt

Odpowiedź serwera na żądanie preflight OPTIONS potwierdzająca konfigurację CORS wildcard + credentials:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

HTTP/1.1 204 No Content
Server: nginx/1.10.3 (Ubuntu)
Date: Fri, 03 Apr 2026 10:02:26 GMT
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,Expires,Pragma
Access-Control-Max-Age: 1728000
Content-Type: text/plain charset=UTF-8
Content-Length: 0

Załącznik E - api_calls.json

Zapis wywołań API ze wskazaniem wersji nginx w nagłówkach odpowiedzi:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

[
  {
    "direction": "request",
    "method": "OPTIONS",
    "url": "https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add",
    "headers": {
      "Origin": "https://orientarium.lodz.pl",
      "Access-Control-Request-Method": "POST"
    },
    "timestamp": "2026-04-03T10:02:26Z"
  },
  {
    "direction": "response",
    "method": "OPTIONS",
    "url": "https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add",
    "status": 204,
    "server": "nginx/1.10.3 (Ubuntu)",
    "cors_origin": "*",
    "cors_credentials": "true",
    "findings": [
      "CORS wildcard origin (*) - accepts any origin",
      "CORS credentials (true) combined with wildcard - spec violation",
      "nginx/1.10.3 (Ubuntu) - released January 2017, EOL, multiple known CVEs"
    ]
  },
  {
    "direction": "response",
    "method": "GET",
    "url": "https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c",
    "status": 302,
    "server": "nginx/1.10.3 (Ubuntu)",
    "findings": [
      "302 redirect exposes CustomerEmail in URL query string - PRIMARY EVIDENCE",
      "XSRF-TOKEN cookie set WITHOUT Secure flag",
      "base_system_session cookie set WITHOUT Secure flag, has httponly only"
    ]
  }
]

Załącznik F - cookies.json

Ciasteczka ustawiane w łańcuchu zakupu i płatności (w tym brak flagi Secure):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "pay.autopay.eu": {
    "layout": "light",
    "_pk_id.47.1dc5": "c3d4b4d5c6760351.1775210441.",
    "_pk_ses.47.1dc5": "1",
    "lang": "PL"
  },
  "sklep.homelinux.net": {
    "XSRF-TOKEN": "eyJpdiI6Ing5c09DWUZpbUJ2eFF1bXpzMU5ISHc9PSIs...",
    "base_system_session": "eyJpdiI6IklobzNJNE5xTzU3WWZJQThRTmRmbmc9PSIs..."
  },
  "assets.secure.checkout.visa.com": {
    "_cfuvid": "mOY9m4UFlc6aHLeSgh.yyamFrgSqFLAu4ecMH6YDXs0-1775210441910-0.0.1.1-604800000"
  }
}

Załącznik G - dns_resolution.txt

Rozpoznanie DNS dla wszystkich domen w łańcuchu, w tym SOA homelinux.net wskazujące na zarządzanie strefą przez Oracle/Dyn oraz informacja o certyfikacie TLS sklep.homelinux.net:

=== DNS Resolution Report ===
Timestamp: 2026-04-21T19:22:10Z
==============================

--- sklep.homelinux.net ---
# dig +short sklep.homelinux.net
185.204.217.182

--- orientarium.lodz.pl ---
# dig +short orientarium.lodz.pl
49.12.241.238
# dig NS orientarium.lodz.pl
dns.home.pl.
dns2.home.pl.
dns3.home.pl.
# dig -x 49.12.241.238 (reverse DNS)
static.238.241.12.49.clients.your-server.de.

--- pay.bm.pl ---
# dig +short pay.bm.pl
195.187.130.220
# dig -x 195.187.130.220 (reverse DNS)
h220.blue.pl.

--- pay.autopay.eu ---
# dig +short pay.autopay.eu
195.187.130.220
# dig -x 195.187.130.220 (reverse DNS)
h220.blue.pl.

--- piwik.blue.pl ---
# dig +short piwik.blue.pl
k8s-servicesexternal-1dcca797e8-1429967.eu-west-1.elb.amazonaws.com.
3.248.18.229
63.32.37.232
54.171.230.184

=== DynDNS check for homelinux.net ===
# dig SOA homelinux.net
ns1.dyndns.org. hostmaster.dyndns.org. 2126617188 10800 1800 604800 1800

=== TLS Certificate: sklep.homelinux.net ===
subject=CN=sklep.homelinux.net
issuer=C=US, O=Let's Encrypt, CN=R13
notBefore=Mar 30 06:52:26 2026 GMT
notAfter=Jun 28 06:52:25 2026 GMT
serial=06C33635D303101CA1C536B42E7A1F933D2D

=== Server headers: sklep.homelinux.net ===
HTTP/1.1 302 Found
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Cache-Control: no-cache, private
Date: Tue, 21 Apr 2026 19:22:11 GMT
Location: https://sklep.homelinux.net/login

Załącznik H - matomo_requests.json

Żądania do systemów analitycznych (piwik.blue.pl oraz Google Analytics) aktywnych na bramce płatniczej, w tym aktywacja modułu HeatmapSessionRecording:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

[
  {
    "url": "https://piwik.blue.pl/piwik.js",
    "method": "GET",
    "referer": "https://pay.autopay.eu/"
  },
  {
    "url": "https://piwik.blue.pl/piwik.php?action_name=pay.autopay.eu%2FBramka%20p%C5%82atnicza%20-%20Autopay&idsite=47&rec=1&r=066307&h=12&m=0&s=41&url=https%3A%2F%2Fpay.autopay.eu%2Fweb%2Fpayment%2Fstart%2F768a3653b0da481699fe1e6c496eeeeb",
    "method": "POST",
    "referer": "https://pay.autopay.eu/",
    "notes": "Main page view tracking"
  },
  {
    "url": "https://piwik.blue.pl/plugins/HeatmapSessionRecording/configs.php?idsite=47&trackerid=Zn1V3x&url=https%3A%2F%2Fpay.autopay.eu%2Fweb%2Fpayment%2Fstart%2F768a3653b0da481699fe1e6c496eeeeb",
    "method": "GET",
    "referer": "https://pay.autopay.eu/",
    "notes": "Heatmap and Session Recording Active"
  },
  {
    "url": "https://piwik.blue.pl/piwik.php?e_c=abtesting&e_a=SimpleABTest&e_n=NO_SUBMIT&ca=1&idsite=47...",
    "method": "POST",
    "referer": "https://pay.autopay.eu/",
    "notes": "AB Testing tracking"
  },
  {
    "url": "https://piwik.blue.pl/piwik.php?action_name=pay.autopay.eu%2FBramka%20p%C5%82atnicza%20-%20Autopay...&_pkp=80&_pks=2&_pkn=ECOMMERCE...",
    "method": "POST",
    "referer": "https://pay.autopay.eu/",
    "notes": "Ecommerce tracking for 80 PLN"
  },
  {
    "url": "https://www.google-analytics.com/mp/collect?measurement_id=G-CFLZGNHGSQ",
    "method": "POST",
    "referer": "https://pay.autopay.eu/"
  }
]

Załącznik I - summary.json

Techniczne podsumowanie audytu z kluczowymi parametrami (ServiceID, OrderID, GUID tenanta, IP serwera, wersja nginx, konfiguracja CORS):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "test_timestamp": "2026-04-21T21:24:45.459103",
  "test_identity_email": "redakcja@dadalo.pl",
  "pii_exposed_in_url": true,
  "pay_bm_url_params": {
    "ServiceID": "103573",
    "OrderID": "7a31bf54b0434ed8827c2669eb01505c",
    "Amount": "80.00",
    "CustomerEmail": "redakcja@dadalo.pl",
    "Hash": "f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027"
  },
  "service_id": "103573",
  "redirect_chain_length": 2,
  "matomo_analysis": {
    "matomo_count": 6,
    "pii_in_referer": false,
    "cross_tenant_refs": []
  },
  "cors_wildcard_detected": true,
  "cors_credentials_with_wildcard": true,
  "server_version": "nginx/1.10.3 (Ubuntu)",
  "tenant_guid": "f5ff01a4311c42a68af6f4d9780290d2",
  "sklep_homelinux_ip": "185.204.217.182",
  "infrastructure_findings": {
    "eol_server": true,
    "dyndns_domain": true,
    "cors_misconfiguration": true,
    "cookie_flag_issues": 0
  }
}

Załącznik J - recon.json

Rozpoznanie struktury formularza zakupowego i elementów UI osadzanego komponentu BASE:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "embedding_model": "Web Component (sklep.homelinux.net)",
  "form_fields": {
    "email": "input[placeholder='Adres e-mail *']",
    "first_name": "input[placeholder='Imię *']",
    "last_name": "input[placeholder='Nazwisko *']",
    "phone": "input[placeholder='Telefon *']"
  },
  "buttons": {
    "add_to_cart": "div:has-text('Dodaj do koszyka')",
    "go_to_checkout": "button:has-text('Przejdź do kasy')",
    "accept_terms": "label:has-text('Zapoznałem się z Regulaminem')",
    "pay": "div:has-text('Kupuję i płacę')"
  },
  "observations": {
    "cart_location": "Right-side panel (visible after adding item)",
    "checkout_trigger": "Right-side panel form replaces cart view.",
    "shadow_dom": "Likely used as it is a web component from homelinux.net"
  }
}

Załącznik L - Nagłówki SMTP

Wiadomość e-mail od noreply@basesystem.pl potwierdzająca tożsamość nadawczego adresu IP oraz politykę DMARC p=none:

Return-Path: <noreply@basesystem.pl>
Authentication-Results: mail.protonmail.ch; dkim=pass (Good 1024 bit rsa-sha256 signature) header.d=basesystem.pl
Authentication-Results: mail.protonmail.ch; dmarc=pass (p=none dis=none) header.from=basesystem.pl
Authentication-Results: mail.protonmail.ch; spf=pass smtp.mailfrom=basesystem.pl

Received: from [127.0.0.1] (unknown [185.204.217.182])
    (Authenticated sender: noreply@basesystem.pl)
    by ewok.endor.pl (Postfix) with ESMTPSA id C806E202028F
    for <redakcja@dadalo.pl>; Fri, 3 Apr 2026 12:00:56 +0200 (CEST)

Received: from ewok.endor.pl (ewok.endor.pl [91.194.229.47])
    by mailinzur1020.protonmail.ch (Postfix) with ESMTPS id 4fnDkn3YmPz9vNQ5
    for <redakcja@dadalo.pl>; Fri, 3 Apr 2026 10:01:05 +0000 (UTC)

Message-Id: <99a1f65733393982d2a7331b70df08de@swift.generated>
Date: Fri, 03 Apr 2026 12:00:55 +0200
Subject: =?utf-8?Q?Potwierdzenie_z=C5=82o=C5=BCenia_zam=C3=B3wienia.?=
From: =?utf-8?B?Wk9PIMWBw7Nkxbo=?= <noreply@basesystem.pl>
Reply-To: =?utf-8?Q?ZOO_=C5=81=C3=B3d=C5=BA_<faktury@zoo.lodz.pl>?=

Pozostałe załączniki

• Załącznik M - zarchiwizowany zrzut strony basesystem.pl/modul-sprzedazy-online z publiczną deklaracją operatora o sposobie przetwarzania danych klientów: https://archiv.dadalo.pl/archive/1776884876.012425/index.html
• Załącznik N - zarchiwizowany zrzut strony basesystem.pl/realizacje z listą publicznie deklarowanych klientów platformy: https://archiv.dadalo.pl/archive/1776945609.60861/index.html
• Załącznik O - Regulamin sprzedaży elektronicznych biletów wstępu do Orientarium Zoo Łódź (obowiązujący, pobrany ze strony orientarium.lodz.pl/bilety): https://archiv.dadalo.pl/archive/1776884876.012425/index.html
• Załącznik P - Polityka plików cookies serwisu orientarium.lodz.pl (obowiązująca): https://archiv.dadalo.pl/archive/1772740908.024841/index.html
• Załącznik R - zrzut ekranu zakupu biletu z karty łodzianina, dokumentujący brak walidacji długości pola card.

Załącznik S - Weryfikacja punktowa na dzień publikacji

Wykonana 10 maja 2026 r., 00:37 CEST (22:37 UTC, 9 maja). Trzy odtwarzalne zapytania potwierdzające utrzymanie kluczowych ustaleń infrastrukturalnych z 3 kwietnia 2026 r.

$ curl -sI https://sklep.homelinux.net/ | grep -i server
Server: nginx/1.10.3 (Ubuntu)

$ curl -s -X OPTIONS \
    https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add \
    -H "Origin: https://orientarium.lodz.pl" \
    -H "Access-Control-Request-Method: POST" \
    -D - -o /dev/null
HTTP/1.1 204 No Content
Server: nginx/1.10.3 (Ubuntu)
Date: Sat, 09 May 2026 22:37:35 GMT
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,
  If-Modified-Since,Cache-Control,Content-Type,Authorization,Expires,Pragma
Access-Control-Max-Age: 1728000
Content-Type: text/plain charset=UTF-8

$ dig SOA homelinux.net
homelinux.net. 86400 IN SOA ns1.dyndns.org. hostmaster.dyndns.org.
  2126648047 10800 1800 604800 1800

Wnioski:

• I.3 - Server: nginx/1.10.3 (Ubuntu) bez zmian. Oprogramowanie serwerowe wydane w styczniu 2017 r., z zakończonym wsparciem upstream i wygasającym ESM Ubuntu, pozostaje w produkcji.
• I.4 - endpoint API tenanta Orientarium (GUID f5ff01a4311c42a68af6f4d9780290d2) zwraca preflight 204 No Content z konfiguracją Access-Control-Allow-Origin: * w połączeniu z Access-Control-Allow-Credentials: true. Konfiguracja sprzeczna z W3C / WHATWG Fetch Standard niezmieniona.
• I.5 - strefa homelinux.net pozostaje pod autorytetem ns1.dyndns.org. Numer seryjny strefy zmienił się z 2126617188 (21 kwietnia) na 2126648047 (10 maja), co świadczy o aktywnym utrzymaniu strefy przez Dyn, ale nie o zmianie operatora ani warstwy adresacyjnej.

GUID tenanta f5ff01a4311c42a68af6f4d9780290d2 pozostaje aktywny - endpoint zakupu nie został przeniesiony przy modyfikacjach interfejsu.

Wszystkie testy zostały przeprowadzone z użyciem tożsamości testowej redakcji (adres e-mail: redakcja@dadalo.pl). Żadne dane rzeczywistych użytkowników systemu nie zostały pozyskane ani przetworzone w trakcie audytu. Materiał dowodowy został zgromadzony w sposób odtwarzalny (odtwarzalne zapytania curl, surowe nagłówki HTTP, rozpoznanie DNS) i może zostać niezależnie zweryfikowany.

Postscriptum: stan na 11 maja 2026 r.

Od momentu złożenia zawiadomienia do UODO (23 kwietnia 2026 r.) upłynęło 18 dni - równe dwa tygodnie i cztery dni. W tym czasie ORIENTARIUM przebudowało koszyk i zmodyfikowało komunikację dotyczącą partnerów oraz sposobu procedowania płatności w warstwie informacyjnej serwisu.

Punktowa weryfikacja curl przeprowadzona 10 maja 2026 r. o godz. 00:37 CEST (Załącznik S) potwierdza, że rdzeń architektoniczny zarejestrowany 3 kwietnia pozostaje niezmieniony:

• I.3 (oprogramowanie serwerowe) - serwer odpowiada nadal nagłówkiem Server: nginx/1.10.3 (Ubuntu);
• I.4 (konfiguracja CORS) - preflight OPTIONS na endpoint API tenanta Orientarium (GUID f5ff01a4311c42a68af6f4d9780290d2) zwraca nadal Access-Control-Allow-Origin: * w połączeniu z Access-Control-Allow-Credentials: true, w sprzeczności ze specyfikacją WHATWG Fetch;
• I.5 (strefa DNS) - dig SOA homelinux.net zwraca nadal ns1.dyndns.org. hostmaster.dyndns.org. jako autorytet strefy.

Tym samym modyfikacje wprowadzone po 23 kwietnia ograniczają się do warstwy interfejsu użytkownika i komunikacji informacyjnej. Cztery grzechy główne wskazane w leadzie - infrastruktura DynDNS, EOL-owe oprogramowanie serwerowe, błędna konfiguracja CORS oraz przekazywanie danych osobowych w parametrach URL do operatora płatności - pozostają w mocy w dniu publikacji.

Pełna analiza payloadów po przebudowie koszyka, ze szczególnym uwzględnieniem tego, czy zachowano przekazywanie CustomerEmail w query stringu przekierowania do bramki płatniczej (sekcja I.2), stanowi przedmiot odrębnego follow-upu.

Materiał jest rozszerzoną wersją zawiadomienia złożonego do Prezesa UODO w trybie sygnalizacji systemowej - niezależnie od korespondencji prowadzonej w odrębnej sprawie ekosystemu cyfrowego Miasta Łodzi (sygnatura DKN.5101.148.2026).

Zgłaszanie nieprawidłowości w serwisie BIP spółki miejskiej

Po odkryciu tylu potencjalnych nieprawidłowości chciałem skorzystać z linka w stopce na stronie Orinetarium o poważnej nazwie ZGŁASZANIE NIEPRAWIDŁOWOŚCI. Po kliknięciu jesteśmy przekierowani na stronę Biuletynu Informacji Publicznej niestety na stronę błędu 404, czyli strona nie istnieje. Kurtyna.