Share
Android-operativsystemet har mange innebygde sikkerhetsfunksjoner, for eksempel applikasjonssandboksing, beskyttelse mot buffere og heltal overløbsangrep og segregerte minnesområder for programinstruksjoner og data. Som et resultat kan enkle Android-apper som ikke utfører filsystem eller nettverksoperasjoner, ofte betraktes som sikre som standard.
Hvis du utvikler en mer komplisert app, er det imidlertid ditt ansvar å gjøre det sikkert og beskytte personvernet til brukerne. I denne artikkelen kommer jeg til å liste noen av de beste metodene du kan følge for å bygge en sikker Android-app som ikke lekker data eller tillatelser, og er generelt mindre sårbar for ondsinnede apper som kan installeres på brukerens enhet.
Hver Android-app har en intern lagringskatalog tilknyttet den hvis sti er basert på pakkens navn på appen. Filer i denne katalogen er veldig sikre fordi de bruker MODE_PRIVATE filopprettingsmodus som standard. Dette betyr at filene ikke kan nås av andre apper på enheten. Derfor er det det beste stedet å lagre alle sensitive dataene til appen din i den interne lagringsmappen.
For å bestemme den absolutte banen til appens interne lagringskatalog, anbefales det at du bruker getFilesDir () metode. Når du kjenner sin vei, er det enkelt å referere til filer i det som refererer til filer i en hvilken som helst annen katalog. For eksempel, her er hvordan du kan referere til en fil som heter myfile.dat i den interne lagringsmappen til appen din:
Fil myFile = Ny fil (getFilesDir (), "myfile.dat");
Den interne lagringskapasiteten til en Android-enhet er ofte begrenset. Derfor kan du til tider ikke ha annet valg enn å lagre sensitive data på eksterne lagringsmedier, for eksempel et flyttbart SD-kort.
Fordi data på eksterne lagringsmedier kan nås direkte av begge brukere og andre apper på enheten, er det viktig at du lagrer det i kryptert format. En av de mest populære krypteringsalgoritmer som brukes av utviklere i dag, er AES, kort for Avansert krypteringsstandard, med en nøkkelstørrelse på 256 biter.
Skrive kode for å kryptere og dekryptere appens data ved hjelp av javax.crypto pakke, som er inkludert i Android SDK, kan være forvirrende. Derfor foretrekker de fleste utviklere bruk av tredjepartsbiblioteker, som Facebook's Conceal-bibliotek, som vanligvis er mye lettere å jobbe med.
Erfarne programmerere som er nye til Android-applikasjonsutvikling, prøver ofte å bruke stikkontakter, navngitte rør eller delte filer for å asynkront kommunisere med andre programmer installert på en Android-enhet. Disse tilnærmingene er ikke bare vanskelige og ulykkelige, men også utsatt for trusler. En enklere og sikrere tilnærming til interprosesskommunikasjon på Android-operativsystemet er å bruke hensikt.
For å sende data til en bestemt komponent i en app, må du opprette en ny forekomst av Intent klassen og bruk dens setComponent () Metode for å angi både pakkens navn på appen og komponentens navn. Du kan deretter legge til data til det ved hjelp av putExtra () metode.
For eksempel, her kan du sende strengen Hei Verden til en Aktivitet kalt MyActivity, som tilhører en app hvis pakkenavn er my.other.app:
Accentsconagua
// Opprett en hensikt Intent intention = new Intent (); // Angi komponentnavnet intent.setComponent (nytt ComponentName ("my.other.app", "my.other.app.MyActivity")); // Legg til data intent.putExtra ("DATA", "Hello World!"); // Send hensikten til aktiviteten startAktivitet (hensikt);Hvis du vil sende data til flere apper samtidig, kan du sende intensjonen som en kringkasting ved hjelp av sendBroadcast () metode. Som standard kan en kringkasting leses av alle apper som er riktig konfigurert BroadcastReceiver.
Derfor, hvis du vil sende sensitiv informasjon som kringkasting, må du bruke en egendefinert tillatelse hvis protectionLevel er satt til signatur. Ved å gjøre dette, sørger Android-operativsystemet for at bare apps som ble signert ved hjelp av signeringsnøkkelen, kan motta sendingen.
Her er en kodebrikke som viser hvordan du sender strengen Hei Verden som en sikker kringkasting:
// Opprett en hensikt Intent intention = new Intent (); // Legg til data intent.putExtra ("DATA", "Hello World"); // Angi et handlingsnavn for // mottakerens intent-filter intent.setAction ("my.app.receive"); // Send som et kringkasting ved hjelp av en egendefinert tillatelse sendBroadcast (intent, "my.custom.permission");Vær oppmerksom på at koden ovenfor fungerer som forventet bare hvis den egendefinerte tillatelsen er deklarert og brukt i manifestfiler av både avsender- og mottakerappene.
All kommunikasjon mellom appen og serverne dine må være over en HTTPS-tilkobling, helst ved hjelp av HttpsURLConnection klasse. Hvis du tror å bruke HTTP for data som ikke er konfidensielt, er det bra, tenk igjen.
Mange Android-brukere koble til flere åpne Wi-Fi-hotspots i fellesområder hver dag. Noen av disse hotspots kan være skadelige. Et skadelig hotspot kan enkelt endre innholdet i HTTP-trafikken for å få appen til å opptre uventet, eller enda verre, injiser annonser eller utnytter det.
Ved å bruke HTTPS, så lenge serveren er konfigurert med et sertifikat utstedt av en klarert sertifiseringsinstans, for eksempel DigiCert eller GlobalSign, kan du være sikker på at nettverkstrafikken din er sikker mot både avlytting og man-i-midten-angrep.
Hvis appen din har mye nettverkskode og du er redd for at du kanskje ikke vil sende noen data som cleartext, bør du vurdere å bruke nogotofail, et åpen kildekodeverktøy bygget av Google for å finne slike feil.
Tilbake da GCM, kort for Google Cloud Messaging, ikke eksisterte, brukte mange utviklere SMS til å trykke data fra sine servere til sine apper. I dag er denne øvelsen stort sett borte.
Hvis du er en av de utviklerne som fremdeles ikke har skiftet fra SMS til GCM, må du vite at SMS-protokollen ikke er kryptert eller sikker mot spoofingangrep. Dessuten kan en SMS leses av en hvilken som helst app på brukerens enhet som har READ_SMS tillatelse.
GCM er mye sikrere og er den foretrukne måten å presse meldinger til en app fordi alle GCM-kommunikasjoner er kryptert. De er autentisert ved hjelp av jevnlig oppdaterte registreringspapirer på klientsiden og en unik API-nøkkel på serverens side. Hvis du vil vite mer om GCM, kan du se denne veiledningen om push notifications.
Brukerens personvern er gitt stor betydning i disse dager. Faktisk finnes det lover, som EUs databeskyttelsesdirektiv og Canadas personopplysningsloven og elektroniske dokumenterloven, som innebærer beskyttelse av personvern til en bruker. Derfor, med mindre du har en god grunn og en veldig sikker infrastruktur for å samle inn, lagre og overføre personlig brukerinformasjon, må du unngå å be om det i appene dine.
En bedre tilnærming til brukerautentisering og brukerprofilinformasjon ser opp på Android er gjennom Google Identity Platform. Google Identity Platform lar brukerne raskt logge på appen sin med sin Google-konto. Etter en vellykket pålogging via plattformen, kan appen din når som helst lete opp ulike detaljer om brukeren, for eksempel brukerens navn, e-postadresse, profilbilde, kontakter og mer. Alternativt kan du bruke gratis tjenester som Firebase som kan administrere brukerautentisering for deg.
Hvis du må håndtere brukeropplysningene selv, anbefales det at du lagrer og overfører dem i form av sikker hash. Den enkleste måten å generere forskjellige typer hashes ved hjelp av Android SDK, er å bruke MessageDigest klasse.
Her er en liten kodebit som viser hvordan du lager en hash på strengen Hei Verden bruker SHA-256 hashing-funksjonen:
// Initialiser MessageDigest for å bruke SHA-256 MessageDigest md = MessageDigest.getInstance ("SHA-256"); // Konverter strengen til en hash byte [] sha256Hash = md.digest ("Hello World" .getBytes ());På Android fører ikke til ugyldig brukerinngang til sikkerhetsproblemer som bufferoverskridelser. Men hvis du tillater brukere å kommunisere med en SQLite-database eller en innholdsleverandør som internt bruker en SQLite-database, må du enten nøye sanitere brukerinngang eller bruke parameteriserte spørringer. Hvis du ikke gjør det, blir dataene dine sårbare for SQL-injeksjonsangrep.
På samme måte er validering og sanitisering av brukerinngang også svært viktig hvis du bruker brukerinngang for å dynamisk generere kode for å kjøre på en innebygd skriptmotor, for eksempel Mozilla Rhino.
Sikkerhetsforanstaltninger som er innebygd i en Android-app, kan bli alvorlig kompromittert hvis angriperne er i stand til å få hendene på kildekoden. Før du publiserer appen din, anbefales det å bruke et verktøy som heter ProGuard, som er inkludert i Android SDK, for å forvirre og redusere kildekoden.
Android Studio inkluderer automatisk ProGuard i byggeprosessen hvis buildType er satt til utgivelse. Standard ProGuard-konfigurasjonen er tilgjengelig i Android SDK ProGuard-android.txt filen er tilstrekkelig for de fleste apper. Hvis du vil legge til egendefinerte regler i konfigurasjonen, kan du gjøre det inne i en fil som heter proguard-rules.pro, som er en del av hvert Android Studio-prosjekt.
Jeg håper du nå har en bedre forståelse av hvordan du gjør dine Android-apper sikre. De fleste av de beste metodene jeg nevnte i denne artikkelen, gjelder bare hvis du bruker Android SDK til å utvikle appene dine. Hvis du bruker Android NDK i stedet, må du være mye mer forsiktig fordi du, mens du programmerer på C-språket, forventes å administrere detaljer på lavt nivå, for eksempel pekere og minnefordeling selv.
Hvis du vil vite mer om sikkerhet på Android, kan du se AOSP-sikkerhetsdokumenter.
