Prieš porą metų vienas klientas paprašė "greito saugumo audito" savo aplikacijai. Per valandą radau hardcoded API raktą, kuris leido pasiekti visų 50,000 vartotojų asmens duomenis. Raktas buvo aplikacijos kode nuo pat paleidimo dienos - 8 mėnesiai be jokios apsaugos.
Tai ne išimtis - tai norma. 75% mobiliųjų aplikacijų turi bent vieną rimtą saugumo spragą. Bet štai kas baisiausia: dauguma verslo savininkų apie tai nesužino, kol nėra per vėlu. Šiame straipsnyje pasidalinsiu tuo, ką išmokau per daugelį saugumo auditų - nuo OWASP Top 10 iki praktinių apsaugos strategijų, kurias galite įgyvendinti jau šiandien.
Kodėl Turėtumėte Jaudintis? (Skaičiai)
Realybė, Kurios Nenori Girdėti
IBM tyrimai rodo: vidutiniškai praeina 197 dienos, kol įmonė sužino apie duomenų nutekėjimą. Dar 69 dienos - kol jį sustabdo. Tai beveik 9 mėnesiai, per kuriuos įsilaužėliai gali daryti ką nori su jūsų duomenimis. Pagalvokite - jei šiandien kas nors įsilaužė, sužinotumėte tik kitų metų rugpjūtį.
10 Dažniausių Klaidų, Kurias Matau Audituose
OWASP Mobile Top 10 - tai standartinis sąrašas, kurį naudoju kiekviename audite. Bet sausas sąrašas nepaaiškina, kodėl šios klaidos tokios dažnos. Štai ką matau praktikoje:
M1: Hardcoded Raktai ir Slaptažodžiai
Tai #1 problema, kurią randu. Programuotojai development metu įrašo API raktą tiesiai į kodą "laikinai" - ir pamiršta. Žmogus su Jadx (nemokamas Android dekompiliatorius) per 5 minutes ištrauks viską. Mačiau production aplikacijas su AWS raktais, Firebase secrets, net admin slaptažodžiais tiesiog kode.
M2: Atviras Duomenų Saugojimas
SharedPreferences Android, UserDefaults iOS - tai NE saugios vietos jautriems duomenims. Bet vis dar matau aplikacijas, saugančias ten access tokenus, PIN kodus, net mokėjimo informaciją. Jei telefonas rootintas/jailbreakintas - viskas pasiekiama per minutę.
M3: "123456" Vis Dar Veikia
Slaptažodžių politika - tai ne tik "8 simboliai ir skaičius". Matau aplikacijas be rate limiting (galima bandyti slaptažodžius be galo), be account lockout, su sesijomis, kurios niekada nebaigiasi. O apie MFA - daugelis net negalvoja, nors tai vienas efektyviausių apsaugos būdų.
M4: Kai Vartotojo Įvestis Tampa Ginklu
SQL injection 2025 metais? Taip, vis dar egzistuoja. Ypač SQLite duomenų bazėse mobiliosiose aplikacijose. XSS per WebView - irgi klasika. Taisyklė paprasta: NIEKADA nepasitikėkite vartotojo įvestimi, net jei "tai tik mobili aplikacija".
M5: HTTP Vietoj HTTPS
Atrodytų akivaizdu, bet vis dar randu. Ypač su third-party SDK, kurie "tyliai" siunčia duomenis per HTTP. Arba aplikacijos, kurios priima bet kokį SSL sertifikatą (įskaitant suklastotą). Viešas WiFi + tokia aplikacija = visi jūsų duomenys matomi.
M6: Nepakankama Privatumo Kontrolė
Per didelis asmens duomenų rinkimas, trūksta sutikimo mechanizmų, nesilaikoma GDPR reikalavimų.
M7: Nepakankama Dvejetainio Kodo Apsauga
Trūksta kodo obfuskacijos, tamper detection ir anti-debugging apsaugos, leidžiančios lengvai analizuoti aplikaciją.
M8: Saugumo Klaidinga Konfigūracija
Netinkamai sukonfigūruotos saugumo nuostatos, palikti debug režimai gamybinėje versijoje, per plačios failų prieigos teisės.
M9: Nesaugus Duomenų Saugojimas
Nesaugiai saugomos atsarginės kopijos, logai su jautria informacija, laikini failai su konfidencialiais duomenimis.
M10: Nepakankama Kriptografija
Silpni šifravimo algoritmai, netinkamas raktų valdymas, pasenusios kriptografinės bibliotekos.
Kaip Apsaugoti Vartotojų Paskyras?
MFA: Kodėl Vienas Slaptažodis Nebepakanka
Jei jūsų aplikacija saugo bet ką svarbesnio nei nuotraukas - MFA būtina. Štai kaip skirtingi metodai atrodo praktikoje:
| Faktorius | Tipas | Saugumo lygis | Vartotojo patirtis |
|---|---|---|---|
| Slaptažodis | Žinios | Vidutinis | Standartinė |
| SMS kodas | Turėjimas | Vidutinis | Gera |
| TOTP (Authenticator) | Turėjimas | Aukštas | Gera |
| Pirštų atspaudai | Biometrija | Aukštas | Puiki |
| Face ID | Biometrija | Aukštas | Puiki |
| Aparatinis raktas (FIDO2) | Turėjimas | Labai aukštas | Vidutinė |
OAuth 2.0 + PKCE: Standartas, Kurį Turite Naudoti
Jei implementuojate "Login with Google/Facebook/Apple" - naudokite OAuth 2.0 su PKCE. Be PKCE - nesaugu. Štai pagrindinės taisyklės:
- Authorization Code Flow + PKCE - vienintelis saugus būdas mobilioms aplikacijoms
- Access tokenai max 1 valanda - jei pavogtas, greitai nebegalioja
- Refresh tokenai su rotacija - kiekvienas atnaujinimas generuoja naują refresh token
- Revoke galimybė - jei vartotojas praranda telefoną, turi galėti atsijungti nuotoliniu būdu
Kur Saugoti Tokenus? (Konkrečiai)
- iOS: Keychain su kSecAttrAccessibleWhenUnlockedThisDeviceOnly. NE UserDefaults.
- Android: EncryptedSharedPreferences arba Android Keystore. NE paprastos SharedPreferences.
- Flutter: flutter_secure_storage (naudoja Keychain/Keystore po gaubtu)
- React Native: react-native-keychain
Šifravimas: Ką Reiškia "Duomenys Apsaugoti"?
Duomenys Telefone (At Rest)
Kai sakome "duomenys saugomi saugiai" - ką tai reiškia techniškai? Štai algoritmai, kuriuos rekomenduoju:
| Algoritmas | Naudojimas | Rakto ilgis | Rekomendacija |
|---|---|---|---|
| AES-256-GCM | Duomenų šifravimas | 256 bit | Rekomenduojama |
| ChaCha20-Poly1305 | Mobilūs įrenginiai | 256 bit | Rekomenduojama |
| RSA-2048+ | Raktų mainai | 2048+ bit | Tinkama |
| PBKDF2/Argon2 | Slaptažodžių hash'avimas | - | Rekomenduojama |
Šifravimas Perdavimo Metu (In Transit)
- TLS 1.3 - naujausias ir saugiausias transporto protokolas
- Certificate Pinning - apsauga nuo MITM atakų
- HSTS - privalomas HTTPS naudojimas
- Perfect Forward Secrecy - kiekviena sesija su unikaliu raktu
SSL/TLS Saugumo Kontrolinis Sąrašas
- Naudojamas TLS 1.2 arba 1.3 (ne senesnis)
- Išjungti nesaugūs cipher suite (RC4, DES, 3DES)
- Įgyvendintas certificate pinning
- Validuojamas sertifikato hostname
- Nenaudojami self-signed sertifikatai gamyboje
- Sertifikatų galiojimo tikrinimas
GDPR: Ne Tik Bauda, Bet Ir Reputacija
Daugelis galvoja apie GDPR tik kaip apie "dar vieną teisinį reikalavimą". Bet štai realybė: jei nuteka jūsų vartotojų duomenys ir paaiškėja, kad nesilaikėte GDPR - bauda + teisminiai procesai + žiniasklaidos dėmesys + prarastas vartotojų pasitikėjimas. Geriau iš karto padaryti teisingai.
Ką Praktiškai Reikia Įgyvendinti
| Reikalavimas | Aprašymas | Įgyvendinimas |
|---|---|---|
| Sutikimas | Aiškus ir savanoriškas sutikimas duomenų rinkimui | Opt-in checkboxai, granulinis sutikimo valdymas |
| Duomenų minimizavimas | Rinkti tik būtinus duomenis | Peržiūrėti kiekvieną renkamą duomenų lauką |
| Teisė pasiekti | Vartotojas gali gauti savo duomenų kopiją | Duomenų eksporto funkcija JSON/PDF formatu |
| Teisė būti pamirštam | Vartotojas gali prašyti ištrinti duomenis | Paskyros ir duomenų ištrynimo funkcija |
| Duomenų perkeliamumas | Duomenų perkėlimas kitam paslaugų teikėjui | Standartizuotas eksporto formatas |
| Pažeidimų pranešimas | Pranešti per 72 val. apie pažeidimą | Incidentų valdymo procedūros |
Baudos - Tai Tik Pradžia
Maksimali GDPR bauda: 20 mln. EUR arba 4% metinės apyvartos. Bet tai ne viskas. Lietuvoje 2024 metais skirta per 500,000 EUR baudų. Pridėkite advokatų išlaidas, klientų praradimą, ir sugadintą reputaciją - tikroji kaina daug didesnė nei oficiali bauda.
Privatumo Nustatymai Aplikacijoje
- Privatumo skydelis - centralizuota vieta visiems privatumo nustatymams
- Granulinis sutikimas - atskiras sutikimas kiekvienam duomenų tipui
- Sutikimo atšaukimas - paprastas būdas atšaukti sutikimą bet kada
- Duomenų peržiūra - galimybė matyti, kokie duomenys saugomi
- Eksportas ir ištrynimas - aiškūs mygtukai šioms funkcijoms
Kaip Žinoti, Ar Jūsų Aplikacija Saugi?
Testavimo Metodai: Nuo Pigių Iki Brangių
| Metodas | Aprašymas | Kaina Lietuvoje | Rekomenduojamas dažnumas |
|---|---|---|---|
| SAST | Statinė kodo analizė | 200-500 EUR | Su kiekvienu release |
| DAST | Dinaminė aplikacijos analizė | 300-800 EUR | Kas mėnesį |
| Penetracijos testas | Rankinis saugumo auditas | 1,500-5,000 EUR | Kas ketvirtį/pusmetį |
| Kodo peržiūra | Saugumo ekspertų kodo analizė | 1,000-3,000 EUR | Prieš didelius atnaujinimus |
| Bug Bounty | Atlygis už rastus pažeidžiamumus | Kintama | Nuolatinė programa |
Įrankiai, Kuriuos Naudoju
- MobSF - mano pirmas žingsnis kiekviename audite. Nemokamas, bet randa daug
- Burp Suite Pro - API testavimui ir trafiko analizei. Verta investicijos
- Frida + objection - kai reikia "pasikapstyti" aplikacijos viduje runtime
- jadx (Android) / Hopper (iOS) - dekompiliavimui ir reverse engineering
- OWASP ZAP - automatizuotam web API skanavimui
Ar Galima Apsisaugoti Nuo Reverse Engineering?
Sąžiningas Atsakymas: Ne 100%
Štai tiesa, kurios daugelis nenori girdėti: jei kas nors labai nori - jūsų aplikaciją išanalizuos. Bet galime apsunkinti jų darbą tiek, kad daugumai bus per sunku:
- Android: ProGuard (bazinis), R8 (rekomenduojamas), DexGuard (profesionalus)
- iOS: SwiftShield, iXGuard, Arxan
- Cross-platform: jscrambler (React Native, Flutter)
Runtime Apsauga
Runtime Saugumo Kontrolinis Sąrašas
- Root/Jailbreak aptikimas
- Debugger aptikimas
- Emuliatoriaus aptikimas
- Tamper detection (kodo modifikavimo aptikimas)
- SSL Certificate Pinning
- Anti-hooking apsauga
- Integrity checks (aplikacijos vientisumo tikrinimas)
Kiek Tai Kainuoja Lietuvoje?
| Paslauga | Bazinė kaina | Vidutinė kaina | Enterprise |
|---|---|---|---|
| Saugumo auditas | 500 EUR | 1,500-3,000 EUR | 5,000+ EUR |
| Penetracijos testas | 1,000 EUR | 2,500-4,000 EUR | 8,000+ EUR |
| GDPR atitikties auditas | 800 EUR | 2,000-3,500 EUR | 6,000+ EUR |
| Saugumo konsultacija (val.) | 50 EUR | 80-120 EUR | 150+ EUR |
| Saugumo funkcijų implementacija | 1,000 EUR | 3,000-8,000 EUR | 15,000+ EUR |
Ką Daryti Jau Šiandien?
Jei Dar Kuriate
- Pagalvokite apie grėsmes - kas norėtų įsilaužti? Ką galėtų pavogti? Tai padės suprasti, ką apsaugoti
- Naudokite saugias bibliotekas - prieš pridedant npm/pub paketą, patikrinkite jo saugumo istoriją
- Code review su saugumo akimis - kiekvienas PR turėtų būti peržiūrėtas ne tik dėl funkcionalumo
- SAST įrankiai CI/CD - automatizuotas skenavimas su kiekvienu build
- Secrets management - NE hardcoded, naudokite environment variables ar vault sprendimus
Jei Jau Production
- Saugumo auditas ASAP - nežinote, ko nežinote. Geriau sužinoti dabar
- Monitoringas - jei kas nors bando bruteforce'inti - turite apie tai žinoti
- Incidentų planas - ką darysite, jei rytoj sužinosite apie duomenų nutekėjimą?
- Dependency updates - senosios bibliotekos = žinomos spragos. Atnaujinkite reguliariai
- Backup testai - backupai be testavimo = galbūt veikiantys backupai
Dažniausiai Užduodami Klausimai (FAQ)
Pabaigai: Saugumas Nėra Vienkartinis Projektas
Štai kas mane nuolat stebina - verslo savininkai galvoja apie saugumą kaip apie checklistą: padarei ir pamiršai. Bet saugumas veikia kitaip. Nauja pažeidžiamybė gali atsirasti rytoj. Biblioteka, kuri vakar buvo saugi, šiandien gali turėti critical vulnerability.
Mano patarimas Lietuvos verslui - pradėkite nuo pagrindų:
- Pirmas žingsnis - saugumo auditas. Nežinote, ką taisyti, jei nežinote, kas blogai
- Antras žingsnis - ištaisyti critical ir high severity problemas. Medium gali palaukti
- Trečias žingsnis - reguliarus patikrinimas kas ketvirtį. Saugumas keičiasi, jūsų apsauga irgi turi
Neįmanoma padaryti 100% saugią aplikaciją. Bet galima padaryti pakankamai saugią, kad atakuotojai pasirinktų lengvesnį taikinį. Ir tą "pakankamai" galima pasiekti su protingu biudžetu ir sistemingu požiūriu.
Nežinote, Nuo Ko Pradėti?
Parašykite man - per 30 minučių pokalbį įvertinsiu jūsų situaciją ir pasakysiu, kur yra didžiausi rizikos taškai. Jokių įsipareigojimų, jokių pardavimo triukų - tiesiog profesionali nuomonė.
Pasikalbėkime Apie Saugumą