Share
Sikkerhet er et viktig aspekt av programvareutvikling. Nesten alle mobile applikasjoner omhandler brukerinformasjon eller kommuniserer med en ekstern server. Selv om sikkerheten har forbedret seg dramatisk de siste tiårene, fortsetter det å være et diskutert tema.
I denne artikkelen vil jeg fremheve en rekke emner som er relatert til sikkerhet og mobilutvikling. Underveis rører jeg på en rekke gode fremgangsmåter og forslag som du kan finne nyttige for å sikre programmene du skriver.
Sikkerheten er relativ. Sikkerhetsutnyttelser oppdages og oppdateres regelmessig. Ingenting er perfekt. Når det er sagt, er det en rekke ting du kan gjøre for å forbedre sikkerheten til mobilapplikasjonene dine. En innbruddstyv er mindre fristet til å bryte inn i en bygning som er omgitt av et elektrisk gjerde enn det som ikke er det.
Noen utviklere overser det faktum at brukerne av deres applikasjoner stoler på dem med sin informasjon. Som utvikler er du ansvarlig for å holde denne informasjonen sikker. Det spiller ingen rolle hva den informasjonen er. Selv om informasjonen kan se uansett for deg, er det viktig for brukeren.
Apple tar sikkerhet og personvern veldig alvorlig. HealthKit er et godt eksempel på Apples forpliktelse til å beskytte brukerens privatliv. Brukeren bestemmer hvilke helsedata et program har tilgang til. Selv om søknaden kan be om tilgang til brukerens helsedata, forteller HealthKit ikke hvilken data den har tilgang til. Med andre ord anser Apple at autorisasjonsstatusen til en søknad er sensitiv informasjon som den ikke bør vite om.
Før du bestemmer hvordan eller hvor du skal lagre et bestemt data, må du spørre deg selv om du skal lagre dataene i utgangspunktet. Er det for eksempel mulig å holde dataene i minnet i stedet for å skrive det til disk eller sende det til en ekstern server? Dette kan i stor grad forenkle programmets arkitektur og forbedre sikkerheten.
Hvis du bestemmer deg for at lagring av dataene lokalt er ditt eneste alternativ, må du bestemme hvor du planlegger å lagre dataene. For sensitiv informasjon, for eksempel legitimasjon, er nøkkelringen det beste alternativet. Dette er bare mulig for små mengder data, din søknad trenger ikke hyppig tilgang til.
Skal dataene sikkerhetskopieres til iCloud eller iTunes? Hvis det ikke er tilfelle, vil du kanskje vurdere å lagre dataene i Caches katalog av programmets sandkasse. Denne katalogen er ikke sikkerhetskopiert til iCloud og iTunes. Hvorfor er det viktig? Data som ikke eksisterer kan ikke kompromitteres.
Standardinnstillingene, tilgjengelig gjennom NSUserDefaults klassen, er en rask og enkel måte å lagre biter av data på. Dessverre blir standardinnstillingene ofte brukt av utviklere. Det skjer alt for ofte at sensitiv informasjon, for eksempel legitimasjon og tilgangstoken, lagres i standardinnstillingen.
En mye bedre plassering for lagring av små biter av sensitiv informasjon er systemets nøkkelring. Som navnet antyder, ble det designet med sikkerhet i tankene, og det har eksistert i mange, mange år. Selv om nøkkelringen håndteres av operativsystemet, har andre programmer som standard ikke tilgang til elementene søknaden din lagrer i nøkkelringen.
Det er sant at grensesnittet for å få tilgang til nøkkelringstjenesten er arkaisk. Heldigvis finnes det flere gode biblioteker som overvinne denne hindringen. Lockbox, for eksempel, er et lettvektsbibliotek for å samhandle med systemets nøkkelringtjenester. Lockbox grensesnitt er enkelt å bruke og forstå.
Det er fristende å lagre nøkler, tokens og til og med legitimasjonsbeskrivelser på lett tilgjengelige steder, for eksempel målets Info.plist eller en JSON-fil i programmets bunt. Sannheten er at det er barnas spill å trekke ut den informasjonen fra et program lastet ned fra App Store. Ved å lagre en API-token for en webtjeneste i søknadens Info.plist, Andre utviklere kan finne den og bruke den.
Sikkerhet og personvern har vært på Apples agenda i mange år, og sammen med andre store aktører har Apple besluttet å lede med eksempel. I løpet av fjorårets WWDC introduserte selskapet App Transport Security.
Med App Transport Security, har Apple som mål å forbedre sikkerheten til plattformene og programmene som kjører på dem. Uansett hvor mye Apple investerer i å sikre operativsystemene, er et system bare like sikkert som dets svakeste komponent, og det inkluderer tredjepartsprogrammer.
App Transport Security håndhever applikasjoner for å sende nettverksforespørsler over en sikker tilkobling. Hvis App Transport Security er aktivert for et program, sendes nettverksforespørsler som standard over HTTPS. Apple legger vekt på sin satsing på sikkerhet og personvern ved automatisk å aktivere App Transport Security for applikasjoner som er bygd med Xcode 7.
Du kan lese mer om App Transport Security på Envato Tuts +. Selv om det er enkelt å deaktivere App Transport Security, må du huske på at et av målene med App Transport Security er å få utviklere å vurdere nettverksadferdene til deres applikasjoner.
Nesten alle mobile applikasjoner bruker nettverket. Dette betyr at folk med dårlige intensjoner fokuserer sterkt på dette aspektet av applikasjonssikkerhet. Nettverk er en kompleks sak og applikasjoner bygger på toppen av en rekke teknologier for å hente dataene de er interessert i.
Som utvikler er det viktig at du holder deg til en rekke beste praksis. Vi har allerede diskutert App Transport Security og reglene denne nye teknologien håndhever. Det stopper ikke der, skjønt. Du vil kanskje også se på mer avanserte emner, for eksempel sertifikatpinne for å sikre at serveren din søknad kommuniserer med, ikke er bedragerisk. Moderne biblioteker, som Alamofire, gjør dette mye lettere.
De fleste applikasjoner bruker eller lagrer sensitiv brukerinformasjon. Mobile enheter har tilgang til et bredt spekter av brukerinformasjon som ofte er personlig og følsom, for eksempel plassering, adressebok og helseinformasjon.
Som jeg nevnte tidligere i denne artikkelen, er det første spørsmålet du må spørre deg selv om du trenger å få tilgang til denne informasjonen, og enda viktigere, om du må lagre den informasjonen.
Hvis du får tilgang til informasjonen du trenger gjennom et eget rammeverk, for eksempel HealthKit, er det ikke nødvendig å kopiere og lagre den informasjonen. For eksempel vil Apple avvise programmer som lagrer brukerens helseinformasjon i iCloud.
Forutsatt at du må lagre noen sensitiv informasjon, bør du vurdere om denne informasjonen skal holdes lokal. Er det nødvendig å sende sensitiv informasjon til en ekstern server?
Lagring av sensitiv informasjon kommer med en advarsel. Hvis serveren du lagrer sensitiv informasjon på, er kompromittert, kan du bli holdt ansvarlig for å utsette denne informasjonen for andre parter.
Online sikkerhet har utviklet seg enormt de siste tiårene. Autentiseringsprotokoller, for eksempel OAuth, har gjort kommunikasjonen med webtjenester mer sikker og gjennomsiktig.
Hvis søknaden din trenger å snakke med en sikker server, bør du vurdere hvordan søknaden din administrerer legitimasjon. Holder den dem til minne eller lagrer dem på disken? Hvis du spør brukerens brukernavn og passord for å hente tilgangstoken, er det greit å lagre det tilgangstokenet. Men bør du også lagre brukernavn og passord? Svaret er nei i de fleste situasjoner.
For applikasjoner som omhandler svært sensitive data, for eksempel helse eller finansiell informasjon, kan det til og med være bedre å holde tilgangstoken i minnet, og ikke lagre det på disk. Å holde det i minnet gjør det mye tryggere, og gjør søknaden mye mindre ansvarlig. Sjansene er at tilgangstoken har en kort levetid uansett.
Sikkerheten til et program er et grunnleggende aspekt ved programvareutvikling. Vurder hvilke data søknaden din har tilgang til, og om den skal lagre den informasjonen. Hvis du bestemmer deg for å lagre sensitiv informasjon, må du huske de ovennevnte tipsene og beste praksis. Pass på at du behandler brukerens informasjon med respekt. Selv om informasjonen kan se uansett for deg, er det viktig for brukeren.
Accentsconagua