KOMMENTARER

Er appen din sikker nok?

John Arild Johansen i Buypass presenterer her sikkerhetstips til app-utviklere.

Langt fra alle mobilapper utvikles med utgangspunkt i datasikkerhet.
Langt fra alle mobilapper utvikles med utgangspunkt i datasikkerhet. Bilde: PantherMedia / Cienpies Design
Harald BrombachHarald BrombachNyhetsleder
19. sep. 2014 - 13:56

Denne kommentaren gir uttrykk for skribentens meninger.

KRONIKK: En fersk undersøkelse viser at sikkerhet knyttet til mobilitet topper IT-sjefenes bekymringsliste. Her er våre beste tips til systematikk og rutiner som reduserer risiko i utviklingen av mobilapplikasjoner, og bygger sikkerhet inn i kulturen til hvert enkelt team:

Mobilapplikasjoner kan utgjøre en sikkerhetsrisiko for brukeren, og sensitive persondata på avveie kan være ødeleggende for produsentens omdømme. Sikkerhetsprogrammet til Buypass er designet for å unngå de vanligste «sikkerhetsfellene» i utvikling av applikasjoner. Programmet «Buypass Secure Software Development» (BSSD) omfatter retningslinjer og standarder for applikasjoner, inkludert apper for mobile enheter.

Basert på BSSD har Buypass definert en liste med tekniske råd og anbefalinger som skal med i alle nye prosjekter. Dette er punkter alle selskaper som utvikler apper for mobiltelefoner bør ha et bevisst forhold til.

Kronikkforfatteren, John Arild Johansen, er sikkerhetssjef i Buypass.
Kronikkforfatteren, John Arild Johansen, er sikkerhetssjef i Buypass.
  1. Bruk SSL/TLS ved kommunikasjon over åpne nett

    All kommunikasjon mellom en applikasjon og sentrale tjenester vil kunne være gjenstand for avlytting. Dersom det er personopplysninger eller andre sensitive data som overføres, må data beskyttes under overføring. Bruk av SSL/TLS, for eksempel ved å bruke HTTPS i stedet for HTTP er en enkel og akseptert måte å beskytte data under overføring. Bruk SSL/TLS i all kommunikasjon med sentrale tjenester og husk å verifisere at SSL-sertifikatet som tjenesten autentiserer seg med er utstedt av en godkjent leverandør. Alternativt kan man benytte CA- eller sertifikat-pinning, det vil si eksplisitt legge inn informasjon om hvilke sertifikatutstedere eller sertifikater man aksepterer.

  2. Krypter sensitive data som lagres i applikasjonen

    En smarttelefon eller et nettbrett er i utgangspunktet ikke et sikkert oppbevaringssted for sensitive data eller personopplysninger. Slike enheter kan «rootes» eller «jailbrakes» og man må forutsette at alle lagrede data kan være tilgjengelig fra andre app-er. Beskyttelsesverdig informasjon som lagres i appen eller enheten må krypteres. Benytt anerkjente krypteringsalgoritmer som RSA, 3DES, AES, ECC, etc.

  3. Sjekk input-data fra bruker og eksterne tjenester

    Verifiser at alle data som tastes inn av bruker, er av riktig type og med lovlige verdier. Det samme gjelder data som mottas fra sentrale tjenester. Dårlig kontroll over input-data kan utsette enheten for kjente sårbarheter og angrep ved bruk av Code Injection.

  4. Bruk domeneobjekter

    Organiser data og tilhørende operasjoner som domeneobjekter, for eksempel bør et mobiltelefonnummer være et eget objekt og ikke bare en String/NSString. Bruk av domeneobjekter gir et mer robust design og en tilsvarende mer robust og sikker applikasjon.

  5. Ikke send sensitive data i custom-url kommandoer

    Custom-url skjemaer kan benyttes for å kommunisere med en app for eksempel fra nettleseren. Sensitive data bør ikke sendes som parametre i url-en siden ondsinnede apper kan registrere seg som alternativ mottaker av samme custom-url. Det er også viktig at man her har inputkontroll på parametre som sendes inn via custom-url.

  6. Vær bevisst på forskjeller i ulike operativsystemer

    Android, iOS og Windows Phone har ulike egenskaper som medfører ulike styrker og svakheter i forhold til sikkerhet. Ha et bevisst forhold til dette, og sørg for at plattform-spesifikke svakheter og sårbarheter blir adressert. Nedenfor følger noen plattformspesifikke anbefalinger:

    • iOS: Bruk Objective-C fremfor standard ANSI C

      Objective-C er mye brukt og godt testet på iOS og er generelt mer robust enn standard ANSI C blant annet buffer underflow/overflow.

    • iOS: Sikre at buffer har plass til data

      Beregn alltid størrelsen på en buffer og sjekk størrelsen på data som skal lagres i bufferen, før lagring. Buffer overflow er den mest vanlige sårbarheten i plattformer basert på C, Objective-C og/eller C++.

    • Android: Ikke send sensitive data som intent-parametre

      Ondsinnede apper kan registrere seg som alternativ mottaker av samme intent.

Mobil sikkerhet er en av vår tids viktigste sikkerhetsutfordringer. Listen over er en god start for utviklere som vil jobbe systematisk med sikkerhet i produksjonen av nye apper, og dermed bidra til å beskytte brukere og eget omdømme mot sikkerhetstrusler. Det betyr ikke at vi mener sikkerhet begrenser seg til disse punktene, dette er først og fremst ment som en sjekkliste for de høyest prioriterte områdene innenfor sikker apputvikling. En sikker start på utviklingsprosessen.

Kronikkforfatteren, John Arild Johansen, er sikkerhetssjef i Buypass, hvor han for tiden fronter en kampanje om at sikkerhetssjefen bør være bedriftens superhelt.

Delta i debatten
Informasjon om debattinnlegg og kronikker i digi.no

Alle innlegg må sendes til redaksjon@digi.no. Husk å legge ved et portrettbilde. Vi forbeholder oss retten til å redigere innsendt materiale.

    Les også:

Les mer om:
Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.