Zajęcia

01.03.2026r. – 3 bloki, obecny.

​_

1. Gdzie zgłaszać incydenty?

W Polsce funkcjonują trzy główne zespoły poziomu krajowego (CSIRT – Computer Security Incident Response Team):

A. CERT Polska (CSIRT NASK) – Dla obywateli i firm

To najważniejszy punkt kontaktu dla większości osób. Obsługują incydenty dotyczące osób prywatnych, małych i średnich firm oraz operatorów usług kluczowych.

Strona do zgłoszeń: incydent.cert.pl

Co zgłaszać: Ataki na strony www, phishing (fałszywe panele logowania), malware, wycieki danych.

B. CSIRT GOV (Agencja Bezpieczeństwa Wewnętrznego) – Dla administracji

Jeśli incydent dotyczy aplikacji webowej należącej do administracji rządowej (np. strony ministerstwa, systemy e-PUAP, gov.pl).

Strona: csirt.gov.pl

C. CSIRT MON (Wojsko Polskie) – Dla resortu obrony

Dotyczy tylko infrastruktury związanej z Ministerstwem Obrony Narodowej.

D.Właściciel aplikacji (Programy Bug Bounty / Responsible Disclosure)

Zanim zgłosisz incydent do organów państwowych (jeśli np. znalazłeś lukę bezpieczeństwa, a nie jesteś ofiarą ataku), sprawdź, czy firma posiada politykę Responsible Disclosure.

Poszukaj pliku /.well-known/security.txt na domenie aplikacji (np. example.com/.well-known/security.txt). Tam znajdziesz instrukcję, jak bezpiecznie poinformować twórców o błędzie.

E. Urząd Ochrony Danych Osobowych (UODO)

Jeśli incydent w aplikacji webowej doprowadził do wycieku danych osobowych (Twoich lub Twoich klientów), administrator danych ma obowiązek zgłosić to do UODO w ciągu 72 godzin.

Strona: uodo.gov.pl

F. Policja / Prokuratura
Jak zgłosić incydent? (Krok po kroku)

Skuteczne zgłoszenie powinno zawierać jak najwięcej konkretów technicznych. Oto co przygotować:

Adres URL: Dokładny link do aplikacji lub podstrony, której dotyczy problem.

Opis zdarzenia: Co się stało? (np. strona przestała działać, pojawił się komunikat o okupie, dane użytkowników są widoczne dla wszystkich).

Czas zdarzenia: Kiedy zauważyłeś incydent (data i godzina).

Dowody (bardzo ważne):

Zrzuty ekranu (screenshots): Pokaż błąd, podejrzany formularz lub komunikat.

Logi serwera: Jeśli jesteś właścicielem aplikacji, dołącz logi (np. z serwera Apache/Nginx).

Nagłówki HTTP / Payload: Jeśli jesteś specjalistą i znalazłeś lukę, opisz metodę (np. błąd typu XSS lub SQL Injection).

Twoje dane kontaktowe: Aby eksperci z CERT mogli dopytać o szczegóły.

infrastructure as a service

software as service
​_

1. Cel zajęć
   Celem zajęć było wprowadzenie studentów do przedmiotu „Bezpieczeństwo aplikacji webowych”, omówienie zasad i karty przedmiotu, a także zapoznanie z procesem wyboru i zakupu domeny oraz hostingu web dla WordPress, wraz z początkową inicjacją zakupionego środowiska hostingowego.
2. Wprowadzenie do Bezpieczeństwa Aplikacji Webowych
   Podczas pierwszego bloku zajęć, szczegółowo omówiono cele przedmiotu „Bezpieczeństwo aplikacji webowych”, jego harmonogram oraz kryteria zaliczenia. Przedstawiono również kartę przedmiotu, wskazując na kluczowe zagadnienia, które będą poruszane w trakcie semestru, ze szczególnym uwzględnieniem identyfikacji zagrożeń i metod ich zapobiegania w kontekście aplikacji webowych.
3. Wybór i zakup domeny oraz hostingu web dla WordPress
   W tej części zajęć studenci zapoznali się z praktycznymi aspektami wyboru i zakupu domeny internetowej oraz odpowiedniego pakietu hostingowego, zoptymalizowanego pod system WordPress. Omówiono szereg czynników decydujących o wyborze, takich jak:
   • Kryteria wyboru domeny: dostępność, rozszerzenie (np. .pl, .com), intuicyjność i łatwość zapamiętania. Wybrana została domena MyUniversity.pl
   • Kryteria wyboru hostingu: typ hostingu (np. hosting współdzielony), parametry techniczne serwera (np. wersja PHP, limit transferu danych, pojemność dysku SSD), lokalizacja serwera, wsparcie techniczne, stosunek ceny do oferowanych usług oraz funkcje bezpieczeństwa.
     Przedstawiono również przykładowe oferty rynkowe i wskazówki dotyczące procesu zakupu.
4. Początkowe zainicjowanie zakupionego hostingu
   Ostatni blok zajęć poświęcono na demonstrację i omówie​_infrastructure as a service software as service
   ​_ nie pierwszych kroków po zakupie us​_infrastructure as a service software as service
   ​_ ługi hostingowej. Zaprezentowano proces logowania do panelu administracyjnego hostingu (LH.pl) oraz przedstawiono jego podstawowe funkcje. Skupiono się na:
   • Lokalizacji i zrozumieniu struktury katalogów serwera (np. public_html).
   • Omówieniu zarządzania wersją PHP dostępną dla domeny.
   • Wstępnym zapoznaniu się z narzędziami do zarządzania plikami oraz potencjalnymi opcjami konfiguracji baz danych, stanowiącymi fundament pod przyszłą instalację WordPressa.
5. Wnioski
   Wszystkie założone na dzień 01.03.2026 cele zajęć zostały osiągnięte. Studenci otrzymali kompleksowe wprowadzenie do przedmiotu „Bezpieczeństwo aplikacji webowych”, zdobyli wiedzę na temat świadomego wyboru i zakupu domeny oraz hostingu, a także poznali podstawowe kroki inicjalizacji środowiska serwerowego. Stanowi to solidną bazę do dalszych prac praktycznych z zakresu tworzenia i zabezpieczania witryn internetowych opartych na systemie WordPress.

15.03.2026r. – 1 blok, obecny.

Konfiguracja środowiska serwerowego i instalacja systemu WordPress

1. Cel zajęć

Celem zajęć było przygotowanie środowiska hostingowego pod wielostanowiskową pracę studentów, konfiguracja subdomen, kont FTP oraz instalacja i wstępna konfiguracja systemu zarządzania treścią WordPress wraz z wykorzystaniem multimediów generowanych przez sztuczną inteligencję.

2. Parametry techniczne serwera

Podczas prac wykorzystano serwer o następującej specyfikacji:

• Adres hosta: serwer425538.lh.pl
• Wersja PHP: 8.4 (najnowsza stabilna wersja zapewniająca wysoką wydajność)
• Separacja katalogów: Włączona (zapewnia bezpieczeństwo pomiędzy poszczególnymi stronami)
• Multipoczta: Włączona

3. Konfiguracja kont FTP i struktury katalogów

W ramach panelu administracyjnego utworzono 6 kont FTP. Główne konto administratora ma dostęp do pełnej struktury, natomiast konta studenckie zostały ograniczone do dedykowanych im katalogów wewnątrz ścieżki

/public_html/

.

Wykaz utworzonych kont i przypisanych ścieżek:

1. serwer425538 – konto główne (pełny dostęp).
2. serwer425538_2384 →/public_html/2384.myuniversity.pl
3. serwer425538_4174 →/public_html/4174.myuniversity.pl
4. serwer425538_4175 →/public_html/4175.myuniversity.pl
5. serwer425538_4177 →/public_html/4177.myuniversity.pl
6. serwer425538_4183 →/public_html/4183.myuniversity.pl

4. Zarządzanie domenami i subdomenami

Skonfigurowano łącznie 6 witryn WWW. Główna domena projektu to

myuniversity.pl

. Dla poszczególnych użytkowników (studentów) przygotowano subdomeny odpowiadające ich numerom identyfikacyjnym:

• 2384.myuniversity.pl
• 4174.myuniversity.pl
• 4175.myuniversity.pl
• 4177.myuniversity.pl
• 4183.myuniversity.pl

Status SSL: Obecnie strony wyświetlają komunikat o braku certyfikatu SSL. Wynika to z faktu, że rekordy DNS są w trakcie propagacji (rozpowszechniania w sieci). Certyfikaty zostaną wdrożone niezwłocznie po zakończeniu tego procesu.

5. Instalacja systemu WordPress i treści AI

Na skonfigurowanym środowisku przeprowadzono instalację systemu WordPress.

• Wdrożenie: Postawiono przykładową stronę demonstracyjną.
• Multimedia: W celu wypełnienia strony treścią, wykorzystano narzędzia sztucznej inteligencji (AI) do wygenerowania unikalnych obrazów i grafik, które zostały zaimplementowane w bibliotece mediów WordPressa.

6. Wnioski

Wszystkie założone cele zostały zrealizowane. Serwer został poprawnie przygotowany do pracy grupowej, a separacja kont FTP zapewnia bezpieczeństwo danych poszczególnych użytkowników. Środowisko jest gotowe do dalszego rozwoju treści i projektowania layoutów stron w systemie CMS.

29.03.2026r. – 3 bloki, obecny.

1 blok. Omówienie panelu administracyjnego i incydent bezpieczeństwa

W pierwszym bloku zajęć przeprowadzono szczegółowe omówienie panelu administracyjnego, prezentując studentom założone wcześniej strony internetowe. Studenci mieli okazję zapoznać się z interfejsem zarządzania swoimi witrynami, w tym z dostępem do plików, baz danych oraz podstawowymi ustawieniami WordPressa. Kluczowym elementem tej części zajęć było również omówienie incydentu bezpieczeństwa, który miał miejsce na wspólnym serwerze. Przedstawiono naturę incydentu, jego potencjalne konsekwencje oraz podjęte kroki w celu jego rozwiązania i zapobiegania podobnym sytuacjom w przyszłości. Podkreślono znaczenie regularnych aktualizacji, silnych haseł oraz monitorowania aktywności na serwerze jako podstawowych elementów utrzymania bezpieczeństwa aplikacji webowych.

2 blok. Prezentacja o phototrollingu i stron studentów

Drugi blok zajęć rozpoczął się prezentacją poświęconą zjawisku phototrollingu. Omówiono jego definicję, przykłady oraz wpływ na wizerunek i bezpieczeństwo w sieci, zwracając uwagę na aspekty etyczne i prawne związane z manipulacją obrazem w internecie. Następnie studenci zaprezentowali swoje strony internetowe, które zostały wcześniej zainstalowane i wstępnie skonfigurowane w systemie WordPress. Każdy student przedstawił swoją witrynę, omawiając wybrane elementy projektu, zastosowane rozwiązania oraz napotkane wyzwania. Była to okazja do wymiany doświadczeń i konstruktywnej krytyki.

3 blok. Główne cele cyfrowe UE, wnioski ze sprawozdania 2025 oraz bezpieczeństwo stron GOV.PL

W ramach trzeciego bloku zajęć przedstawiono i omówiono główne cele cyfrowe Unii Europejskiej do 2030 roku, które obejmują:

• Społeczeństwo wykwalifikowane cyfrowo: Dążenie do tego, aby przynajmniej 80% osób w wieku 16-74 lat posiadało podstawowe umiejętności cyfrowe, a w UE zatrudnionych było co najmniej 20 milionów specjalistów ICT, z większym udziałem kobiet.
• Bezpieczne i zrównoważone infrastruktury cyfrowe: Zapewnienie wszystkim użytkownikom końcowym dostępu do sieci gigabitowej oraz ultraszybkiej sieci bezprzewodowej (przynajmniej 5G) we wszystkich obszarach zaludnionych. Celem jest również, aby produkcja najnowocześniejszych półprzewodników w UE stanowiła co najmniej 20% wartości produkcji światowej, powstało 10 000 neutralnych dla klimatu węzłów brzegowych, a do 2025 roku UE dysponowała pierwszym komputerem z przyspieszeniem kwantowym.
• Transformacja cyfrowa przedsiębiorstw: Zakłada się, że co najmniej 75% przedsiębiorstw unijnych będzie korzystać z chmury obliczeniowej, dużych zbiorów danych lub sztucznej inteligencji; ponad 90% MŚP osiągnie podstawowy poziom wykorzystania technologii cyfrowych, a liczba „jednorożców” ma się co najmniej podwoić.
• Cyfryzacja usług publicznych: Celem jest, aby 100% kluczowych usług publicznych było dostępnych online dla obywateli i przedsiębiorstw, 100% obywateli miało dostęp do elektronicznej dokumentacji medycznej oraz do środków identyfikacji elektronicznej (eID) uznawanych w całej UE.

Omówiono również główne wnioski ze sprawozdania z 2025 roku, które wskazują na:

• Infrastrukturę cyfrową: Powolny rozwój sieci światłowodowych i samodzielnych sieci 5G.
• Cyfryzację przedsiębiorstw: Poprawę wykorzystania sztucznej inteligencji, chmury obliczeniowej i dużych zbiorów danych przez przedsiębiorstwa, ale z koniecznością przyspieszenia tego procesu.
• Umiejętności cyfrowe: Fakt, że tylko 55,6% Europejczyków posiada podstawowe umiejętności cyfrowe oraz ciągły brak zaawansowanych specjalistów ICT, zwłaszcza kobiet.
• Cyfryzację usług publicznych: Stałe postępy w cyfryzacji kluczowych usług publicznych, jednak z zauważalnym wykorzystaniem dostawców spoza UE w znacznej części rządowej infrastruktury cyfrowej.

W kontekście bezpieczeństwa aplikacji webowych, przedstawiono informacje o zabezpieczeniach SSL stron internetowych domen GOV.PL, podkreślając ich znaczenie dla ochrony danych użytkowników i zapewnienia wiarygodności serwisów publicznych. Przeprowadzono również testowanie e-usług na wybranych stronach, takich jak:

• http://karty.apgw.gov.pl:4200/jcw-powierzchniowe
• http://bazaoos.gdos.gov.pl/web/guest/home
• http://bip.warszawa.sko.gov.pl/
• http://www.dzielautracone.gov.pl/katalog-strat-wojennych
• http://www.hcv.pzh.gov.pl/Page/o-hcv
• https://www.podatki.gov.pl/
• https://www.zus.pl/ezus/logowanie
• https://www.gov.pl/web/mobywatel
• https://pz.gov.pl/dt/login/login?urlt=3a3o8gku5o5vwc7cu68b
• https://www.e-sad.gov.pl/
  Celem testowania było praktyczne zapoznanie się z działaniem i zabezpieczeniami różnych serwisów publicznych.

​_

infrastructure as a service

software as service
​_

1. Logowanie do intranetu bez ssl: Pierwsza część obrazu przedstawia formularz logowania do intranetu, zawierający pola „Login” i „Password”. Zgodnie z informacją w zapytaniu, ta strona jest niezabezpieczona. Brak widocznych wskaźników bezpieczeństwa, takich jak ikona kłódki czy protokół HTTPS w adresie URL, sugeruje, że dane wprowadzane w tym formularzu mogą być przesyłane w sposób niezaszyfrowany.

1. Bezpieczeństwo strony www.gov.pl i logowanie do usług: Druga część obrazu, dotycząca strony www.gov.pl, wyraźnie wskazuje na bezpieczne połączenie. Panel bezpieczeństwa informuje: „Połączenie jest bezpieczne” oraz „Certyfikat jest ważny Wystawiony dla: Ministerstwo Cyfryzacji [PL]”. Oznacza to, że strona korzysta z protokołu SSL/TLS, co zapewnia szyfrowanie przesyłanych danych. Poniżej przedstawiono różne metody logowania do usług, w tym „Aplikacja mObywatel”, „Bankowość elektroniczna”, „E-dowód”, „Profil zaufany” oraz „Use eID”, które są bezpiecznymi metodami uwierzytelniania.

1. On-Premises (Lokalnie)

• Opis: W modelu On-Premises cała infrastruktura IT jest zarządzana i utrzymywana przez użytkownika (firmę) we własnym centrum danych. Obejmuje to zarówno sprzęt (serwery, pamięć masową, sieć), jak i oprogramowanie (wirtualizacja, system operacyjny, środowisko uruchomieniowe, aplikacje i dane).
• Zarządzanie:
  • Ty zarządzasz: Wszystkimi warstwami – od sie​_infrastructure as a service software as service
    ​_ ci, przez pamię​_ć masową, serwery, wirtualizację, system operacyjny, oprogramowanie pośredniczące (middleware), środowisko uruchomieniowe (runtime), dane, aż po aplikacje.
• Różnice: Jest to model, w którym użytkownik ma największą kontrolę, ale jednocześnie ponosi pełną odpowiedzialność i koszty związane z zakupem, utrzymaniem i zarządzaniem całą infrastrukturą.

​2. Infrastructure as a Service (IaaS)

​_

infrastructure as a service

software as service
​_

• Opis: W modelu IaaS dostawca chmury udostępnia podstawową infrastr​_ukturę obliczeniową, taką jak wirtualne maszyny, pamięć masowa i sieć. Użytkownik ma kontrolę nad systemem operacyjnym, środowiskiem uruchomieniowym, aplikacjami i danymi.
• Zarządzanie:
  • Ty zarządzasz: Aplikacjami, danymi, środowiskiem uruchomieniowym (runtime), oprogramowaniem pośredniczącym (middleware) i systemem operacyjnym (O/S).
  • Inni zarządzają (dostawca): Wirtualizacją, serwerami, pamięcią masową (storage) i siecią (networking).
  •  
• Różnice: W porównaniu do On-Premises, IaaS odciąża użytkownika od zarządzania fizycznym sprzętem i wirtualizacją, oferując większą elastyczność i skalowalność. Użytkownik nadal ma jednak dużą kontrolę nad środowiskiem oprogramowania.

3. Platform as a Service (PaaS)

• Opis: PaaS to model, w którym dostawca chmury udostępnia środowisko do tworzenia, uruchamiania i zarządzania aplikacjami. Obejmuje to system operacyjny, środowisko uruchomieniowe, oprogramowanie pośredniczące i bazową infrastrukturę. Użytkownik koncentruje się wyłącznie na swoich aplikacjach i danych.
• Zarządzanie:
  • Ty zarządzasz: Aplikacjami i danymi.
  • ​_infrastructure as a service software as service
    ​_ Inni zarządzają (dostawca): Środowiskiem uruchomieniowym (runtime), oprogramowaniem pośredniczącym (middleware), systemem operacyjnym (O/S), wirtualizacją, serwerami, pamięcią masową (storage) i siecią (networking).
• Różnice: PaaS idzie o krok dalej niż IaaS, zwalniając użytkownika z zarządzania systemem operacyjnym i środowiskiem uruchomieniowym. Jest to idealne rozwiązanie dla deweloperów, którzy chcą skupić się na kodowaniu, a nie na zarządzaniu infrastrukturą.

​4. Software as a Service (SaaS)

• Opis: SaaS to model, w którym dostawca chmury hostuje i zarządza całą aplikacją, udostępniając ją użytkownikom końcowym przez internet. Użytkownik korzysta z gotowego oprogramowania, nie martwiąc się o żadne aspekty infrastruktury czy platformy.
• Zarządzanie:
  • Inni zarządzają (dostawca): Wszystkimi warstwami – od sieci, przez pamięć masową, serwery, wirtualizację, system operacyjny, oprogramowanie pośredniczące, środowisko uruchomieniowe, dane, aż po aplikacje.
• Różnice: W modelu SaaS użytkownik ma najmniejszą kontrolę nad infrastrukturą i oprogramowaniem, ale jednocześnie ponosi najmniejszą odpowiedzialność za ich utrzymanie. Jest to model „plug-and-play”, gdzie dostawca zajmuje się wszystkim, a klient jedynie korzysta z usługi (np. Gmail, Salesforce).

Podsumowując różnice:

• On-Premises: Pełna kontrola i pełna odpowiedzialność użytkownika.
• IaaS: Użytkownik zarządza warstwami oprogramowania (od O/S w górę), dostawca zarządza infrastrukturą fizyczną i wirtualizacją.
• PaaS: Użytkownik zarządza tylko aplikacjami i danymi, dostawca zarządza całą plat​_formą i infrastrukturą.
• SaaS: Dostawca zarządza wszystkim, użytkownik korzysta z gotowej aplikacji.

W miarę przechodzenia od On-Premises do SaaS, zakres odpowiedzialności użytkownika maleje, a odpowiedzialność dostawcy rośnie, co przekłada się na mniejszą kontrolę, ale i mniejsze obciążenie operacyjne dla klienta.

1. Gdzie zgłaszać incydenty?

W Polsce funkcjonują trzy główne zespoły poziomu krajowego (CSIRT – Computer Security Incident Response Team):

A. CERT Polska (CSIRT NASK) – Dla obywateli i firm

To najważniejszy punkt kontaktu dla większości osób. Obsługują incydenty dotyczące osób prywatnych, małych i średnich firm oraz operatorów usług kluczowych.

• Strona do zgłoszeń: incydent.cert.pl
• Co zgłaszać: Ataki na strony www, phishing (fałszywe panele logowania), malware, wycieki danych.

B. CSIRT GOV (Agencja Bezpieczeństwa Wewnętrznego) – Dla administracji

Jeśli incydent dotyczy aplikacji webowej należącej do administracji rządowej (np. strony ministerstwa, systemy e-PUAP, gov.pl).

• Strona: csirt.gov.pl

C. CSIRT MON (Wojsko Polskie) – Dla resortu obrony

Dotyczy tylko infrastruktury związanej z Ministerstwem Obrony Narodowej.

D.Właściciel aplikacji (Programy Bug Bounty / Responsible Disclosure)

Zanim zgłosisz incydent do organów państwowych (jeśli np. znalazłeś lukę bezpieczeństwa, a nie jesteś ofiarą ataku), sprawdź, czy firma posiada politykę Responsible Disclosure.

• Poszukaj pliku /.well-known/security.txt na domenie aplikacji (np. example.com/.well-known/security.txt). Tam znajdziesz instrukcję, jak bezpiecznie poinformować twórców o błędzie.

E. Urząd Ochrony Danych Osobowych (UODO)

Jeśli incydent w aplikacji webowej doprowadził do wycieku danych osobow

1. Gdzie zgłaszać incydenty?

W Polsce funkcjonują trzy główne zespoły poziomu krajowego (CSIRT – Computer Security Incident Response Team):

A. CERT Polska (CSIRT NASK) – Dla obywateli i firm

To najważniejszy punkt kontaktu dla większości osób. Obsługują incydenty dotyczące osób prywatnych, małych i średnich firm oraz operatorów usług kluczowych.

Strona do zgłoszeń: incydent.cert.pl

Co zgłaszać: Ataki na strony www, phishing (fałszywe panele logowania), malware, wycieki danych.

B. CSIRT GOV (Agencja Bezpieczeństwa Wewnętrznego) – Dla administracji

Jeśli incydent dotyczy aplikacji webowej należącej do administracji rządowej (np. strony ministerstwa, systemy e-PUAP, gov.pl).

Strona: csirt.gov.pl

C. CSIRT MON (Wojsko Polskie) – Dla resortu obrony

Dotyczy tylko infrastruktury związanej z Ministerstwem Obrony Narodowej.

D.Właściciel aplikacji (Programy Bug Bounty / Responsible Disclosure)

Zanim zgłosisz incydent do organów państwowych (jeśli np. znalazłeś lukę bezpieczeństwa, a nie jesteś ofiarą ataku), sprawdź, czy firma posiada politykę Responsible Disclosure.

Poszukaj pliku /.well-known/security.txt na domenie aplikacji (np. example.com/.well-known/security.txt). Tam znajdziesz instrukcję, jak bezpiecznie poinformować twórców o błędzie.

E. Urząd Ochrony Danych Osobowych (UODO)

Jeśli incydent w aplikacji webowej doprowadził do wycieku danych osobowych (Twoich lub Twoich klientów), administrator danych ma obowiązek zgłosić to do UODO w ciągu 72 godzin.

Strona: uodo.gov.pl

F. Policja / Prokuratura
Jak zgłosić incydent? (Krok po kroku)

Skuteczne zgłoszenie powinno zawierać jak najwięcej konkretów technicznych. Oto co przygotować:

Adres URL: Dokładny link do aplikacji lub podstrony, której dotyczy problem.

Opis zdarzenia: Co się stało? (np. strona przestała działać, pojawił się komunikat o okupie, dane użytkowników są widoczne dla wszystkich).

Czas zdarzenia: Kiedy zauważyłeś incydent (data i godzina).

Dowody (bardzo ważne):

Zrzuty ekranu (screenshots): Pokaż błąd, podejrzany formularz lub komunikat.

Logi serwera: Jeśli jesteś właścicielem aplikacji, dołącz logi (np. z serwera Apache/Nginx).

Nagłówki HTTP / Payload: Jeśli jesteś specjalistą i znalazłeś lukę, opisz metodę (np. błąd typu XSS lub SQL Injection).

Twoje dane kontaktowe: Aby eksperci z CERT mogli dopytać o szczegóły.

ych (Twoich lub Twoich klientów), administrator danych ma obowiązek zgłosić to do UODO w ciągu 72 godzin.

• Strona: uodo.gov.pl

F. Policja / Prokuratura

Jak zgłosić incydent? (Krok po kroku)

Skuteczne zgłoszenie powinno zawierać jak najwięcej konkretów technicznych. Oto co przygotować:

1. Adres URL: Dokładny link do aplikacji lub podstrony, której dotyczy problem.
2. Opis zdarzenia: Co się stało? (np. strona przestała działać, pojawił się komunikat o okupie, dane użytkowników są widoczne dla wszystkich).
3. Czas zdarzenia: Kiedy zauważyłeś incydent (data i godzina).
4. Dowody (bardzo ważne):
   • Zrzuty ekranu (screenshots): Pokaż błąd, podejrzany formularz lub komunikat.
   • Logi serwera: Jeśli jesteś właścicielem aplikacji, dołącz logi (np. z serwera Apache/Nginx).
   • Nagłówki HTTP / Payload: Jeśli jesteś specjalistą i znalazłeś lukę, opisz metodę (np. błąd typu XSS lub SQL Injection).
5. Twoje dane kontaktowe: Aby eksperci z CERT mogli dopytać o szczegóły.

Kary z Dyrektywy NIS2 (Cyberbezpieczeństwo)

Od 2024/2025 roku w Polsce kluczowa jest ustawa o Krajowym Systemie Cyberbezpieczeństwa (wdrażająca NIS2). Tutaj kary są nakładane nie za wyciek danych osobowych, ale za brak odporności infrastruktury.

• Kogo dotyczy: Energetyka, transport, bankowość, ochrona zdrowia, produkcja żywności, a nawet gospodarowanie odpadami.
• Kary:
  • Dla podmiotów kluczowych: do 10 mln EUR lub 2% globalnego obrotu.
  • Dla podmiotów ważnych: do 7 mln EUR lub 1,4% globalnego obrotu.
• Za co? Za brak wdrożenia zarządzania ryzykiem, brak audytów, brak zgłaszania incydentów (nawet tych, które nie skończyły się wyciekiem danych, a jedynie przestojem systemu).

Phototrolling

Zidentyfikowane podmioty

1. Kancelaria Prawna: Depicta Legal (działająca wcześniej pod nazwą Fechner Legal)[2][3].
   Jest to niemiecka kancelaria z siedzibą w Berlinie, prowadzona przez adwokata Roberta Fechnera[2][3]. Kancelaria ta specjalizuje się w masowym wysyłaniu przedsądowych wezwań do zapłaty (niem. Abmahnung) za naruszenia praw autorskich do zdjęć w internecie[3].
2. Firma z Warszawy obsługująca serwery i monitoring: PhotoClaim Sp. z o.o.[3][4]
   Spółka zarejestrowana w Warszawie (z siedzibą przy ul. Wąchockiej)[4]. Posiada systemy informatyczne i serwery, które nieustannie (24/7) skanują internet przy pomocy zaawansowanych algorytmów rozpoznawania obrazu, poszukując zdjęć wykorzystanych bez licencji, odpowiedniego podpisu autora lub wykraczających poza dozwolony użytek[1]. (W dokumentacji dowodowej czasem pojawia się również powiązana niemiecka spółka RightsPilot UG[5]).
3. Fotograf i właściciel firmy z Warszawy: Nico Trinkhaus[1][6].
   Niemiecki fotograf, podróżnik i przedsiębiorca. Jest założycielem oraz prezesem zarządu warszawskiej spółki PhotoClaim[1][6]. Sam jest autorem tysięcy atrakcyjnych zdjęć (udostępnianych m.in. na jego platformie Sumfinity)[7][8]. To właśnie jego prace (obok prac kilku innych współpracujących fotografów, takich jak Jean Claude Castor czy Anna Neetzel) są bardzo często przedmiotem prowadzonych roszczeń[2][3].

---

Mechanizm działania (Phototrolling)

Proceder jest wysoce zautomatyzowany i opiera się na specyficznej luce informacyjnej po stronie właścicieli stron internetowych oraz na wykorzystaniu rygorystycznego niemieckiego prawa autorskiego. Składa się on z następujących kroków:

1. „Zarzucenie przynęty” (Publikacja zdjęć)
Fotograf (Nico Trinkhaus lub inni powiązani z nim twórcy) publikuje w sieci bardzo atrakcyjne wizualnie zdjęcia (często o tematyce podróżniczej, architektonicznej, biznesowej)[3][7]. Zdjęcia te łatwo pozycjonują się w wyszukiwarce Google Images. Niekiedy udostępniane są na licencjach, które wymagają bardzo specyficznego, trudnego technicznie sposobu przypisania autorstwa (np. wymóg umieszczenia aktywnego linku dokładnie w określonym miejscu) – w przypadku najmniejszego błędu licencja staje się nieważna.

2. Zautomatyzowany monitoring i zbieranie dowodów
Boty i serwery należące do PhotoClaim przeczesują internet[1]. Kiedy oprogramowanie zidentyfikuje zdjęcie na blogu, stronie firmowej, a nawet w mediach społecznościowych, automatycznie zabezpieczany jest dowód[9]. Wykonywane są zrzuty ekranu, archiwizowany jest kod źródłowy strony i zapisywana dokładna data publikacji[9].

3. Agresywne wezwanie do zapłaty (Copyright Infringement Notice)
Zebrane „dowody” przekazywane są do berlińskiej kancelarii Depicta Legal (Robert Fechner), która wysyła do właściciela strony mailowe lub listowne wezwanie do zapłaty[9]. Pismo to ma bardzo formalny, zastraszający ton. Zawiera m.in.:

• Zarzut nielegalnego użycia utworu i naruszenia praw osobistych (np. brak podpisu autora)[2][9].
• Bardzo krótki termin na odpowiedź (często tylko kilka dni)[10].

4. Żądania finansowe i prawne
W wezwaniu od Depicta Legal znajdują się zwykle dwa kluczowe żądania:

• Wysoka opłata (Odszkodowanie): Kancelaria nie żąda rynkowej wartości zdjęcia (często wynoszącej kilkanaście złotych na stockach), lecz opiera swoje roszczenia na niemieckich, branżowych tabelach MFM (Mittelstandsgemeinschaft Foto-Marketing)[11]. Kwoty te wynoszą najczęściej od kilkuset do nawet kilku tysięcy euro (np. 1500 – 5000 EUR)[2][5]. Do tego doliczane są koszty pracy prawnika (często drugie tyle) oraz koszty dokumentacji dowodowej[5].
• Deklaracja Zaniechania (Unterlassungserklärung): Jest to gotowy druk nakazujący natychmiastowe usunięcie zdjęcia i zaniechanie jego publikacji w przyszłości[3][10]. Dokument ten, jeśli zostanie podpisany bez modyfikacji, stanowi w świetle niemieckiego prawa dożywotnią umowę, przewidującą drakońskie kary umowne (np. 5000 EUR) za każde kolejne pojawienie się zdjęcia[3][10] (nawet jeśli zostało ono w pamięci cache wyszukiwarki czy na starym serwerze pocztowym).

5. Zastraszanie sądem zagranicznym
Jeśli ofiara nie zapłaci, kancelaria Depicta Legal potrafi kierować sprawy do sądów – najczęściej do sądu krajowego w Berlinie (Landgericht Berlin), argumentując to transgranicznym charakterem naruszenia z racji na niemieckie obywatelstwo/rezydencję fotografa[5]. Sądy te znane są z orzekania na korzyść twórców. Koszty procesu dla przedsiębiorcy z Polski są na ogół niewspółmiernie wysokie do samej wartości zdjęcia[5][12]. Czasami podmioty te wykorzystują również Europejskie Postępowanie w Sprawach Drobnych Roszczeń[1].

Jak środowisko prawnicze radzi sobie z tym zjawiskiem?

Eksperci od prawa własności intelektualnej i prawnicy reprezentujący poszkodowanych (ofiary trollingu) odradzają samodzielny kontakt z kancelarią Depicta Legal[3]. Głównym zaleceniem jest:

• Nigdy nie podpisywać załączonej deklaracji zaniechania (Unterlassungserklärung) w jej pierwotnej formie, lecz dostarczyć prawnikowi do zmodyfikowania (tzw. modifizierte Unterlassungserklärung)[3][10].
• Nie płacić od razu całej kwoty – roszczenia bywają celowo zawyżane, a doświadczeni adwokaci potrafią znacząco zbić te stawki podczas negocjacji ugody[2][3].
• Natychmiastowo i trwale usunąć sporne zdjęcie z serwerów i pamięci cache[5].