Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Aplikacje religijne i serwisy społecznościowe przetwarzają dane osobowe, które z pozoru mogą wydawać się mało wrażliwe, ale w praktyce stanowią cenny materiał dla cyberprzestępców. Gdy w interfejsie API zabraknie prawidłowej kontroli dostępu, nawet prosty mechanizm odczytu rekordów może doprowadzić do masowego ujawnienia informacji o użytkownikach.
Taki scenariusz dotyczył oficjalnej aplikacji modlitewnej „Click to Pray”, powiązanej z watykańską siecią modlitewną. Problem miał wynikać z błędnej autoryzacji, która pozwalała odczytywać dane użytkowników na podstawie przewidywalnych identyfikatorów kont.
W skrócie
Incydent dotyczył publicznie dostępnego endpointu API, który bez wymogu właściwej autoryzacji zwracał dane przypisane do kolejnych identyfikatorów użytkowników. W efekcie możliwe było zautomatyzowane pobieranie rekordów na dużą skalę.
- skala incydentu miała obejmować ponad 700 tys. rekordów,
- ujawnione dane mogły zawierać imiona, nazwiska i adresy e-mail,
- widoczne były również informacje o kraju, statusie konta i rolach,
- podatność wpisuje się w klasę IDOR oraz szerszy problem Broken Access Control.
Kontekst / historia
„Click to Pray” to oficjalna aplikacja modlitewna dostępna dla użytkowników mobilnych i webowych. Platforma służy do publikacji modlitw, intencji oraz treści religijnych kierowanych do odbiorców z wielu krajów.
Według opisu incydentu podatność została wykryta przez niezależnego badacza bezpieczeństwa. Nie chodziło o skomplikowany atak wykorzystujący zaawansowane techniki, lecz o klasyczny błąd logiki biznesowej, w którym aplikacja nie sprawdzała poprawnie, czy użytkownik ma prawo odczytać konkretny rekord danych.
To ważny przykład dlatego, że podobne błędy od lat należą do najpoważniejszych problemów bezpieczeństwa aplikacji. Kontrola dostępu pozostaje jednym z najczęściej zawodzących elementów nowoczesnych systemów webowych i API.
Analiza techniczna
Rdzeniem problemu była podatność typu Insecure Direct Object Reference. W takim scenariuszu aplikacja udostępnia zasób na podstawie identyfikatora obiektu, ale nie weryfikuje, czy żądający rzeczywiście powinien mieć do niego dostęp.
Jeżeli identyfikatory użytkowników są sekwencyjne, atakujący może bardzo łatwo odgadywać kolejne wartości i odpytywać API automatycznie. Taka enumeracja nie wymaga łamania haseł, omijania wieloskładnikowego uwierzytelniania ani wykorzystania błędów pamięci. Wystarcza znajomość schematu żądania i brak autoryzacji na poziomie obiektu.
W opisywanym przypadku odpowiedzi API miały zawierać dane zapisane jawnym tekstem, w tym nazwy kont, adresy e-mail, kraj pochodzenia oraz metadane dotyczące statusu konta. Szczególnie niebezpieczne są informacje o rolach i poziomach uprawnień, ponieważ zwiększają wartość wycieku dla napastników planujących dalsze działania.
Incydent dobrze pokazuje różnicę między uwierzytelnieniem a autoryzacją. To, że aplikacja poprawnie obsługuje logowanie, nie oznacza jeszcze, że właściwie ogranicza dostęp do konkretnych danych. Brak kontroli „kto może zobaczyć który rekord” tworzy jedynie pozór bezpieczeństwa.
Konsekwencje / ryzyko
Najbardziej bezpośrednim skutkiem jest naruszenie poufności danych osobowych. Nawet jeśli wyciek nie obejmuje haseł czy danych płatniczych, zestaw informacji takich jak imię, nazwisko, e-mail, kraj oraz status konta ma dużą wartość dla przestępców.
- umożliwia prowadzenie kampanii phishingowych i spear phishingowych,
- ułatwia podszywanie się pod organizację religijną lub administratorów,
- pozwala profilować użytkowników według kraju i przynależności do wspólnoty,
- zwiększa ryzyko ataków socjotechnicznych opartych na zaufaniu,
- może pomóc w identyfikacji kont personelu i prób dalszej kompromitacji zaplecza organizacyjnego.
Poza skutkami operacyjnymi pojawia się także wymiar reputacyjny i zgodności. Podmiot obsługujący setki tysięcy użytkowników staje się faktycznym opiekunem danych, niezależnie od charakteru działalności. Oznacza to konieczność utrzymywania dojrzałych procesów bezpieczeństwa, monitorowania API i reagowania na zgłoszenia o podatnościach.
Rekomendacje
Dla operatorów aplikacji najważniejsze są działania naprawcze na poziomie architektury, kodu i procesu wytwórczego.
- wdrożenie autoryzacji na poziomie obiektu dla każdego endpointu API,
- pełny przegląd logiki dostępu do danych użytkowników i kont uprzywilejowanych,
- testy bezpieczeństwa API pod kątem IDOR, BOLA i Broken Access Control,
- minimalizacja danych zwracanych przez API zgodnie z zasadą need-to-know,
- monitorowanie nietypowej enumeracji rekordów oraz wdrożenie alertowania,
- segmentacja ról i ograniczenie widoczności metadanych administracyjnych,
- stosowanie zasad privacy by design i data minimization,
- uruchomienie jawnego procesu zgłaszania błędów przez badaczy bezpieczeństwa.
Użytkownicy mają mniejszy wpływ na bezpieczeństwo samej platformy, ale mogą ograniczać skutki podobnych incydentów.
- korzystanie z aliasów e-mail zamiast głównego adresu,
- podawanie wyłącznie minimalnego zakresu danych przy rejestracji,
- stosowanie unikalnych haseł i menedżera haseł,
- zwiększona ostrożność wobec wiadomości dotyczących darowizn, modlitw i pilnych aktualizacji konta,
- monitorowanie skrzynki pocztowej pod kątem ukierunkowanych prób phishingu.
Podsumowanie
Przypadek aplikacji „Click to Pray” pokazuje, że poważny incydent bezpieczeństwa może wynikać nie z zaawansowanego exploita, lecz z podstawowego błędu autoryzacji w API. Podatności IDOR pozostają groźne właśnie dlatego, że są łatwe do przeoczenia podczas rozwoju aplikacji, a jednocześnie proste do wykorzystania przez atakującego.
Dla branży cyberbezpieczeństwa to kolejne potwierdzenie, że kontrola dostępu musi być testowana równie rygorystycznie jak logowanie, szyfrowanie i zarządzanie sesją. Jeżeli aplikacja przetwarza dane osobowe na dużą skalę, brak takich mechanizmów szybko przekształca błąd programistyczny w pełnoprawny incydent bezpieczeństwa.
Źródła
- Dark Reading — https://www.darkreading.com/vulnerabilities-threats/vatican-official-prayer-app-leaks-700k-pii
- OWASP Foundation — Insecure Direct Object Reference (IDOR) — https://owasp.org/www-community/attacks/insecure_direct_object_reference
- OWASP Top 10:2025 — Broken Access Control — https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
- Apple Support — Create and manage Hide My Email addresses in Settings on iPhone — https://support.apple.com/en-mide/guide/iphone/iphcb02e76f7/ios
- Pontifical Commission of Vatican City State — General Regulation on the Protection of Personal Data — https://www.vaticanstate.va/en/news/566-pontifical-commission-of-vatican-city-state-promulgates-general-regulation-on-the-protection-of-personal-data.html