Japanski nacionalni tim za odgovor na računalne incidente, JPCERT/CC, povezao je nedavni porast curenja podataka s weba s dva glavna uzroka: zloupotrebom API-ja mobilnih aplikacija i poznatim softverskim ranjivostima, uključujući iskorišteni bug SQL injekcije u Metabaseu. Priča je koristan podsjetnik da su curenja podataka s weba u Japanu i slabosti mobilnih API-ja obično problemi na strani poslužitelja, u sustavima koje korisnici ne mogu vidjeti niti kontrolirati. ## Što je JPCERT/CC otkrio iza curenja podataka u Japanu Prema izvješću, JPCERT/CC povezuje nedavni porast curenja podataka u Japanu sa zloupotrebom API-ja mobilnih aplikacija i ranjivostima koje su već bile javno poznate. Jedan od navedenih primjera je ranjivost SQL injekcije u Metabaseu koju su napadači iskoristili. Zajednička nit je da se ne radi o egzotičnim napadima. Poznate ranjivosti i slabo zaštićena sučelja ulazne su točke. Sažetak izvornog materijala ne povezuje curenja s bilo čime što su pojedinačni korisnici učinili, a to je važno za to kako čitatelji trebaju razmišljati o riziku: osobne podatke izložile su usluge koje su ih čuvale. ## Kako SQL injekcija i izloženi mobilni API-ji cure osobne podatke Dva tehnička pojma pokreću ovu priču, pa ih je korisno jednostavno definirati. **SQL injekcija** događa se kada aplikacija prosljeđuje korisnički unos u upit baze podataka bez odgovarajuće provjere. Napadač može osmisliti unos koji mijenja upit, što mu može omogućiti čitanje podataka koje nikada ne bi smio vidjeti. Metabase je alat za analitiku podataka koji se povezuje s bazama podataka, pa ranjivost u njemu može staviti temeljne zapise na dohvat ruke. **Zloupotreba mobilnog API-ja** drugi je put do sličnog rezultata. Mobilna aplikacija komunicira s poslužiteljima tvrtke putem API-ja. Ako taj API ne provjerava ispravno tko pita, ili što smije dohvatiti, netko može slati zahtjeve izravno na njega, izvan aplikacije, i povući podatke u velikim količinama. Aplikacija na vašem telefonu može izgledati savršeno normalno dok poslužitelj iza nje dijeli više nego što bi trebao. U oba slučaja slabost se nalazi kod organizacije koja upravlja uslugom. Krpanje poznatih ranjivosti i pojačavanje kontrola pristupa API-ju su rješenja, a oboje je posao operatera, ne korisnika. ## Što bi japanski korisnici i usluge trebali provjeriti sada Za organizacije, naglasak izvješća na poznatim ranjivostima upućuje na osnovni popis za provjeru: - Potvrdite da je svaka Metabase instalacija ažurirana na verziju koja rješava iskorišteni bug SQL injekcije. - Pregledajte API-je mobilnih aplikacija kako biste bili sigurni da je svaki zahtjev autentificiran i da korisnici mogu dohvatiti samo vlastite zapise. - Tretirajte javno objavljene ranjivosti kao hitne, jer ih napadači već koriste. Za pojedinačne korisnike, malo je toga što se može izravno konfigurirati, ali možete paziti na znakove da je usluga koju koristite pogođena: obavijesti e-poštom, neočekivane poruke o ponovnom postavljanju lozinke ili phishing koji spominje pojedinosti koje bi trebala znati samo ta tvrtka. ## Kako ograničiti svoju izloženost nakon curenja Vrijedi biti izravan oko jedne stvari: VPN ovo ne rješava. VPN šifrira promet između vašeg uređaja i [VPN poslužitelja](/en/glossary/vpn-server) i maskira vašu IP adresu, što je korisno za privatnost na nepouzdanim mrežama. Ne čini ništa u vezi s ranjivošću u bazi podataka ili API-ju koji čuva vaše informacije. Ako usluga procuri vaše zapise, put kojim su podaci stigli tamo nije relevantan za to kako su izloženi. Ono što pomaže jest ograničavanje štete kada do curenja dođe: - **Koristite jedinstvenu lozinku za svaki račun.** Ako jedna usluga bude probijena, napadači ne mogu ponovno upotrijebiti iste vjerodajnice drugdje. Upravitelj lozinkama to čini praktičnim. - **Uključite praćenje curenja podataka.** Mnogi preglednici, upravitelji lozinkama i neovisne usluge upozorit će vas kada se vaša e-adresa pojavi u poznatom curenju. - **Dijelite manje podataka s aplikacijama.** Polja koja nikada niste pružili ne mogu procuriti. Preskočite neobavezne pojedinosti i koristite zasebnu e-adresu za usluge s nižim povjerenjem. - **Omogućite višefaktorsku autentifikaciju** gdje je ponuđena, tako da procurjela lozinka sama po sebi nije dovoljna. - **Budite oprezni s neočekivanim porukama.** Procurjeli podaci za kontakt često potiču ciljani phishing. ## Što to znači za vas Nalazi JPCERT/CC-a potvrđuju da vaša izloženost uvelike ovisi o tome koliko dobro tvrtke kojima vjerujete održavaju svoje sustave. Ne možete krpati njihove poslužitelje, ali možete smanjiti ono što je na kocki. Pretpostavite da će neki od vaših podataka na kraju negdje biti izloženi i pobrinite se da ta izloženost ne otključa vaše druge račune. Za nedavni primjer kako izgleda izloženost velikih razmjera u Japanu, pogledajte našu reportažu o [KDDI proboju koji je izložio 12,2 milijuna e-adresa korisnika u Japanu](/en/kddi-breach-exposes-12-2m-customer-emails-in-japan). Same e-adrese mogu se činiti beznačajnima, ali upravo su to vrsta podataka koja pokreće phishing kampanje. ## Ključni zaključci Curenja podataka s weba u Japanu povezana sa zloupotrebom mobilnih API-ja i nezakrpanim softverom problem su na strani usluge i VPN ih neće riješiti. Koristite jedinstvene lozinke, omogućite praćenje curenja podataka, uključite višefaktorsku autentifikaciju i dajte aplikacijama samo podatke koji su im uistinu potrebni. Te navike neće zaustaviti proboj, ali mogu spriječiti da jedan postane mnogo veći problem za vas.