Q1: Co JPCERT/CC wskazał jako główne przyczyny niedawnych japońskich wycieków danych? A1: JPCERT/CC powiązał wzrost wycieków danych z nadużywaniem mobilnych API aplikacji oraz znanymi lukami w oprogramowaniu, w tym wykorzystywanym błędem SQL injection w Metabase. Q2: Czym jest SQL injection i jak powoduje wyciek danych? A2: SQL injection ma miejsce, gdy aplikacja przekazuje dane wejściowe dostarczone przez użytkownika do zapytania do bazy danych bez odpowiedniego sprawdzenia ich, co pozwala atakującym stworzyć dane wejściowe zmieniające zapytanie i odczytać dane, których nigdy nie powinni zobaczyć. Q3: Czym jest nadużywanie mobilnego API i jak prowadzi do wycieków danych? A3: Nadużywanie mobilnego API ma miejsce, gdy API nie weryfikuje należycie, kto pyta lub co może pobrać, pozwalając komuś wysyłać żądania bezpośrednio do niego i wyciągać dane masowo. Q4: Czyim obowiązkiem jest naprawienie tych luk? A4: Słabość leży po stronie organizacji obsługującej usługę, a łatanie znanych luk i zaostrzenie kontroli dostępu do API należy do obowiązków operatora, nie klienta. Q5: Co mogą zrobić pojedynczy użytkownicy, aby się chronić? A5: Użytkownicy mają niewiele do bezpośredniej konfiguracji, ale mogą wypatrywać oznak, że usługa została dotknięta, takich jak e-maile z powiadomieniami, nieoczekiwane wiadomości o resecie hasła lub phishing odwołujący się do szczegółów, które powinna znać tylko ta firma. ---END---
Japoński narodowy zespół reagowania na incydenty komputerowe, JPCERT/CC, powiązał niedawny wzrost wycieków danych z witryn internetowych z dwiema głównymi przyczynami: nadużywaniem mobilnych API aplikacji oraz znanymi lukami w oprogramowaniu, w tym wykorzystywanym błędem SQL injection w Metabase. Ta historia to użyteczne przypomnienie, że japońskie wycieki danych z witryn i słabości mobilnych API to zwykle problemy po stronie serwera, w systemach, których użytkownicy nie widzą i nie kontrolują. ## Co JPCERT/CC odkrył za japońskimi wyciekami danych Zgodnie z raportem, JPCERT/CC łączy niedawny wzrost wycieków danych w Japonii z nadużywaniem mobilnych API aplikacji oraz z lukami, które były już publicznie znane. Jednym z wymienionych przykładów jest błąd SQL injection w Metabase, który został wykorzystany przez atakujących. Wspólnym wątkiem jest to, że nie są to egzotyczne ataki. Znane luki i słabo chronione interfejsy to punkty wejścia. Podsumowanie materiału źródłowego nie wiąże wycieków z niczym, co zrobili pojedynczy użytkownicy, i to ma znaczenie dla sposobu, w jaki czytelnicy powinni myśleć o ryzyku: dane osobowe zostały ujawnione przez usługi, które je przechowywały. ## Jak SQL injection i ujawnione mobilne API powodują wyciek danych osobowych Ta historia opiera się na dwóch terminach technicznych, więc warto je jasno zdefiniować. **SQL injection** ma miejsce, gdy aplikacja przekazuje dane wejściowe dostarczone przez użytkownika do zapytania do bazy danych bez odpowiedniego sprawdzenia ich. Atakujący może stworzyć dane wejściowe, które zmieniają zapytanie, co może pozwolić mu odczytać dane, których nigdy nie powinien zobaczyć. Metabase to narzędzie do analityki danych, które łączy się z bazami danych, więc luka w nim może postawić bazowe rekordy w zasięgu ręki. **Nadużywanie mobilnego API** to inna droga do podobnego rezultatu. Aplikacja mobilna komunikuje się z serwerami firmy przez API. Jeśli to API nie weryfikuje należycie, kto pyta, ani co może pobrać, ktoś może wysyłać żądania bezpośrednio do niego, poza aplikacją, i wyciągać dane masowo. Aplikacja na twoim telefonie może wyglądać zupełnie normalnie, podczas gdy serwer za nią wydaje więcej, niż powinien. W obu przypadkach słabość leży po stronie organizacji obsługującej usługę. Łatanie znanych luk i zaostrzenie kontroli dostępu do API to rozwiązania, a jedno i drugie należy do obowiązków operatora, nie klienta. ## Co japońscy użytkownicy i usługi powinni teraz sprawdzić Dla organizacji nacisk raportu na znane luki wskazuje na podstawową listę kontrolną: - Potwierdź, że każde wdrożenie Metabase jest zaktualizowane do wersji, która usuwa wykorzystywany błąd SQL injection. - Przejrzyj mobilne API aplikacji, aby upewnić się, że każde żądanie jest uwierzytelniane, a użytkownicy mogą pobierać wyłącznie własne rekordy. - Traktuj publicznie ujawnione podatności jako pilne, ponieważ atakujący już ich używają. Dla pojedynczych użytkowników niewiele można skonfigurować bezpośrednio, ale można wypatrywać oznak, że używana usługa została dotknięta: e-maile z powiadomieniami, nieoczekiwane wiadomości o resecie hasła lub phishing odwołujący się do szczegółów, które powinna znać tylko ta firma. ## Jak ograniczyć swoje narażenie po wycieku Warto powiedzieć wprost jedną rzecz: VPN tego nie naprawia. VPN szyfruje ruch między twoim urządzeniem a [serwerem VPN](/en/glossary/vpn-server) i maskuje twój adres IP, co jest przydatne dla prywatności w niezaufanych sieciach. Nie robi nic w związku z luką w bazie danych lub API, które przechowują twoje informacje. Jeśli usługa ujawni twoje rekordy, droga, którą dane tam trafiły, nie ma znaczenia dla sposobu, w jaki zostały ujawnione. Pomaga natomiast ograniczenie szkód, gdy dojdzie do wycieku: - **Używaj unikalnego hasła do każdego konta.** Jeśli jedna usługa zostanie naruszona, atakujący nie mogą ponownie użyć tych samych danych logowania gdzie indziej. Menedżer haseł czyni to praktycznym. - **Włącz monitorowanie wycieków.** Wiele przeglądarek, menedżerów haseł i niezależnych usług powiadomi cię, gdy twój e-mail pojawi się w znanym wycieku. - **Udostępniaj aplikacjom mniej danych.** Pola, których nigdy nie podałeś, nie mogą zostać ujawnione. Pomijaj opcjonalne szczegóły i używaj osobnego adresu e-mail dla usług o niższym zaufaniu. - **Włącz uwierzytelnianie wieloskładnikowe**, gdzie jest oferowane, aby sam ujawniony identyfikator i hasło nie wystarczyły. - **Zachowaj ostrożność wobec nieoczekiwanych wiadomości.** Ujawnione dane kontaktowe często napędzają ukierunkowany phishing. ## Co to oznacza dla ciebie Ustalenia JPCERT/CC wzmacniają przekonanie, że twoje narażenie w dużym stopniu zależy od tego, jak dobrze firmy, którym ufasz, utrzymują swoje systemy. Nie możesz załatać ich serwerów, ale możesz zmniejszyć to, co jest na szali. Zakładaj, że część twoich danych prędzej czy później zostanie gdzieś ujawniona, i upewnij się, że to ujawnienie nie odblokuje twoich innych kont. Po niedawny przykład tego, jak wygląda ujawnienie na dużą skalę w Japonii, zobacz nasze omówienie [naruszenia KDDI, które ujawniło 12,2 mln e-maili klientów w Japonii](/en/kddi-breach-exposes-12-2m-customer-emails-in-japan). Same adresy e-mail mogą wydawać się drobne, ale to dokładnie ten rodzaj danych, który napędza kampanie phishingowe. ## Najważniejsze wnioski Japońskie wycieki danych z witryn powiązane z nadużywaniem mobilnych API i niezałatanym oprogramowaniem to problem po stronie usługi, którego VPN nie rozwiąże. Używaj unikalnych haseł, włącz monitorowanie wycieków, włącz uwierzytelnianie wieloskładnikowe i przekazuj aplikacjom tylko te dane, których naprawdę potrzebują. Te nawyki nie powstrzymają naruszenia, ale mogą powstrzymać je przed staniem się znacznie większym problemem dla ciebie.
 i maskuje twój adres IP, co jest przydatne dla prywatności w niezaufanych sieciach. Nie robi nic w związku z luką w bazie danych lub API, które przechowują twoje informacje. Jeśli usługa ujawni twoje rekordy, droga, którą dane tam trafiły, nie ma znaczenia dla sposobu, w jaki zostały ujawnione.
Pomaga natomiast ograniczenie szkód, gdy dojdzie do wycieku:
- **Używaj unikalnego hasła do każdego konta.** Jeśli jedna usługa zostanie naruszona, atakujący nie mogą ponownie użyć tych samych danych logowania gdzie indziej. Menedżer haseł czyni to praktycznym.
- **Włącz monitorowanie wycieków.** Wiele przeglądarek, menedżerów haseł i niezależnych usług powiadomi cię, gdy twój e-mail pojawi się w znanym wycieku.
- **Udostępniaj aplikacjom mniej danych.** Pola, których nigdy nie podałeś, nie mogą zostać ujawnione. Pomijaj opcjonalne szczegóły i używaj osobnego adresu e-mail dla usług o niższym zaufaniu.
- **Włącz uwierzytelnianie wieloskładnikowe**, gdzie jest oferowane, aby sam ujawniony identyfikator i hasło nie wystarczyły.
- **Zachowaj ostrożność wobec nieoczekiwanych wiadomości.** Ujawnione dane kontaktowe często napędzają ukierunkowany phishing.
## Co to oznacza dla ciebie
Ustalenia JPCERT/CC wzmacniają przekonanie, że twoje narażenie w dużym stopniu zależy od tego, jak dobrze firmy, którym ufasz, utrzymują swoje systemy. Nie możesz załatać ich serwerów, ale możesz zmniejszyć to, co jest na szali. Zakładaj, że część twoich danych prędzej czy później zostanie gdzieś ujawniona, i upewnij się, że to ujawnienie nie odblokuje twoich innych kont.
Po niedawny przykład tego, jak wygląda ujawnienie na dużą skalę w Japonii, zobacz nasze omówienie [naruszenia KDDI, które ujawniło 12,2 mln e-maili klientów w Japonii](/en/kddi-breach-exposes-12-2m-customer-emails-in-japan). Same adresy e-mail mogą wydawać się drobne, ale to dokładnie ten rodzaj danych, który napędza kampanie phishingowe.
## Najważniejsze wnioski
Japońskie wycieki danych z witryn powiązane z nadużywaniem mobilnych API i niezałatanym oprogramowaniem to problem po stronie usługi, którego VPN nie rozwiąże. Używaj unikalnych haseł, włącz monitorowanie wycieków, włącz uwierzytelnianie wieloskładnikowe i przekazuj aplikacjom tylko te dane, których naprawdę potrzebują. Te nawyki nie powstrzymają naruszenia, ale mogą powstrzymać je przed staniem się znacznie większym problemem dla ciebie.](/api/img?p=articles%2F7955%2Fimage-0.jpg&w=1200)
// FAQ
Co JPCERT/CC wskazał jako główne przyczyny niedawnych japońskich wycieków danych?
JPCERT/CC powiązał wzrost wycieków danych z nadużywaniem mobilnych API aplikacji oraz znanymi lukami w oprogramowaniu, w tym wykorzystywanym błędem SQL injection w Metabase.
Czym jest SQL injection i jak powoduje wyciek danych?
SQL injection ma miejsce, gdy aplikacja przekazuje dane wejściowe dostarczone przez użytkownika do zapytania do bazy danych bez odpowiedniego sprawdzenia ich, co pozwala atakującym stworzyć dane wejściowe zmieniające zapytanie i odczytać dane, których nigdy nie powinni zobaczyć.
Czym jest nadużywanie mobilnego API i jak prowadzi do wycieków danych?
Nadużywanie mobilnego API ma miejsce, gdy API nie weryfikuje należycie, kto pyta lub co może pobrać, pozwalając komuś wysyłać żądania bezpośrednio do niego i wyciągać dane masowo.
Czyim obowiązkiem jest naprawienie tych luk?
Słabość leży po stronie organizacji obsługującej usługę, a łatanie znanych luk i zaostrzenie kontroli dostępu do API należy do obowiązków operatora, nie klienta.
Co mogą zrobić pojedynczy użytkownicy, aby się chronić?
Użytkownicy mają niewiele do bezpośredniej konfiguracji, ale mogą wypatrywać oznak, że usługa została dotknięta, takich jak e-maile z powiadomieniami, nieoczekiwane wiadomości o resecie hasła lub phishing odwołujący się do szczegółów, które powinna znać tylko ta firma.



