Dezvoltarea de aplicaţii iOS ţinând cont de securitate

Cristian Roșa
mobile developer
@ISDC

DIVERSE

Securitatea a devenit din ce în ce mai importantă în dezvoltarea aplicaţiilor mobile datorită informaţiilor sensibile/confidenţiale de pe telefoanele noastre inteligente. Toate aşteptările şi estimările privind utilizarea sunt depăşite an după an de potopul de utilizatori ai telefoanelor inteligente, în dezavantajul celor care folosesc laptopuri sau desktopuri. Şi cine poate să îi acuze? Dispozitivul ce poate fi ţinut în mână a devenit "portmoneul" erei moderne, plin cu date personale (poze, filme, note) şi date confidenţiale (de sănătate, medicale, jurnale, permise sau cupoane).

Mai mult, există un trend ce defineşte mobilele prin prisma modului în care sunt conectate afacerile, indiferent de categorie. Informaţii bancare (număr de cont, card de credit, informaţii de autentificare, token-uri de securitate) sunt stocate pe dispozitivele mobile sau sunt trimise prin intermediul reţelelor wireless nesecurizate - aşadar există un risc mai mare decât pentru aplicaţiile de desktop.

Este aşadar esenţial ca atunci când sunt dezvoltate aplicaţii mobile să se ţină cont de securitate, din cauza multitudinii de atacuri ce pot produce prejudicii semnificative.

Arhitectura Apple

Apple a reuşit să găsească, până acum, cel mai bun echilibru între uzabilitate şi securitate prin arhitectura sa ce este strâns legată de hardware şi software. Acest lucru face ca în acelaşi timp să fie uşor pentru clienţi să cripteze date pe dispozitivele proprii şi pentru hackeri să fie greu să fure şi să decripteze informaţii confidenţiale.

Piatra de temelie a securităţii Apple este algoritmul Advanced Encryption Standard (sau AES), un sistem de codare a datelor considerat de "ne-spart". Implementarea acestuia pe dispozitivele Apple se face prin intermediul unei chei de criptare stocată adânc în memoria flash, ea însăşi criptată prin intermediul unei parole de utilizator. Setarea unei "ştergeri de date" după 12 încercări eşuate de introducere a parolei face dispozitivul aproape impenetrabil.

Sandbox-ul Aplicaţiilor

iOS "îngrădeşte" fiecare aplicaţie în propriul sandbox la momentul instalării, fapt ce limitează accesul la fişiere, resurse de reţea, hardware şi date private. Calea către directorul home al aplicaţiei are forma ../ApplicationRoot/ApplicationID

Chiar dacă sandbox-ul limitează pagubele pe care un potenţial atac le-ar putea produce, iOS-ul nu îl poate preveni. Aceasta înseamnă că un hacker poate să acceseze informaţii confidenţiale din cadrul sandbox-ului, lăsând dezvoltatorului doar opţiunea de a lua contramăsuri suplimentare de securitate.

Criptează datele cât timp dispozitivul este blocat

Cât timp dispozitivul este blocat, anumite fişiere marcate de către dezvoltator pot să fie criptate în mod automat, însă acest lucru presupune permiterea capacităţilor de criptare şi configurarea lor. În stadiul blocat, sandbox-ul aplicaţiei împiedică accesul altor aplicaţii; mai mult, chiar şi aplicaţia propriu-zisă nu are acces.

Criptarea se realizează prin setarea nivelului dorit de protecţie: fără protecţie, complet, complet cu excepţia faptului când e deja lansată şi complet până la prima logare. API-uri ce oferă Protecţia Datelor sunt NSData ce folosesc writeToFile:options:error; NSFileManager pentru setarea atributelor fişierelor cu setAttributes:ofItemAtPath:error; schimbarea valorii NSFileProtectionKey şi opţiunea sqlite3_open_v2 pentru sqlite3.

După setarea protecţiei fişierului, aplicaţia trebuie să implementeze nişte delegaţi pentru a fi pregătită pentru pierderea temporară a accesului la acel fişier.

Protecţia datelor cu Keychain Access

"Keychain Services" este o interfaţă programabilă ce vă permite să găsiţi, adăugaţi, modificaţi şi să ştergeţi item-uri din keychain. Keychain este singurul loc în care puteţi stoca date în siguranţă, deoarece sunt criptate în propriul lor set de item-uri ai aplicaţiei. Acestor item-uri le este creată o copie de siguranţă atunci când utilizatorul îşi sincronizează dispozitivele prin intermediul iTunes şi vor fi păstraţi şi în cazul unei reinstalări. Toate acestea fac din keychain principalul loc de depozitare a datelor confidenţiale, cum ar fi parole, chei de licenţă, numere de cont, etc. .

Pentru a folosi "Keychain Services", binarul aplicaţiei trebuie să fie legat cu arhitectura Security.framework. Spre deosebire de alte arhitecturi iOS, aceasta este o arhitectură C aşa că toate tipurile de apeluri de metode sunt în acel limbaj.

În acelaşi mod în care criptarea datelor cât timp dispozitivul este blocat are niveluri de protecţie, la fel şi protecţia datelor din keychain: întotdeauna protejat, protejat AfterFirstUnlock sau WhenUnlocked. De asemenea, fiecare clasă există în variaţii migrabile şi non-migrabile - sufixul ThisDeviceOnly ce leagă criptarea de un dispozitiv anume.

Cea mai bună abordare în folosirea Keychain Access este să declaraţi un dicţionar de căutări de bază folosit pentru toate apelurile către serviciile keychain. Acesta va conţine atribute ale itemului keychain de creat, găsit, actualizat sau şters.

Cache-ul tastaturii

Aţi observat vreodată că atunci când folosiţi browsere, auto-complete-ul îşi intră în rol atunci când încercaţi să retastaţi ceva? Aţi observat că la fel se întâmplă şi cu iPhone-urile? Dacă nu încă, ar trebui să ştiţi că toate tastările de pe un iPhone ar putea fi salvate în cache dacă nu se iau măsuri pentru dezactivare. Acest lucru este valabil pentru tot ceea ce tastaţi, cu excepţia câmpurilor de parolă.

Vestea proastă este că aproape orice cuvând non-numeric este salvat în cache şi conţinutul cache al tastaturii depăşeşte privilegiile administrative ale aplicaţiei, adică nu pot fi îndepărtate din aplicaţie.

Acest lucru lasă dezvoltatorului o singură opţiune, şi anume să dezactiveze caracteristicile de auto-corectură setând proprietatea de autocorrectionType la UITextAutocorrectionNo.

Capturi de ecran automate

Pentru a oferi o experienţă bogată utilizatorului, iOS are multe efecte de micşorare, împingere, apariţie sau dispariţie. Totuşi, acestea au şi o latură negativă: atunci când aplicaţia este mutată în fundal, iOS face o captură automată de ecran a ferestrei iPhone-ului în timp ce efectuează efectul de micşorare şi dispariţie. Toate aceste capturi de ecran sunt stocate în partea de sistem NANS flash a dispozitivului şi sunt teoretic şterse după ce aplicaţia a fost închisă.

În cele mai multe cazuri, ştergerea nu îndepărtează fişierele permanent de pe dispozitiv. Acestea pot conţine date privind utilizatorul şi aplicaţia. Ca o posibilă soluţie pentru această problemă, este nevoie de blocarea cache-ului capturilor de ecran ale aplicaţiei folosind un cod sau o configuraţie API. Un mod uşor de a face acest lucru este folosirea metodei API willEnterBackground, în care se poate implementa ştergerea informaţiilor confidenţiale. Apoi puteţi crea un ecran animat pe care aplicaţia să îl afişeze în timp ce se mută în fundal.

Punerea în cache a datelor aplicaţiei

Datele aplicaţiei pot fi capturate într-o varietate de artefacte, cum ar fi fişiere de log/debug, cookies, fişiere listă de proprietăţi sau baze de date SQLite. În timp ce fişierele listă de proprietăţi, bazele de date SQLite şi fişierele/documentele comune pot fi criptate oferind astfel un nivel de siguranţă, fişierele de log, debug sau crash sunt potenţial accesibile.

Dacă aplicaţia se blochează, rezultatul este logat, lăsând atacatorului o potenţială soluţie pentru a sustrage date confidenţiale. Luaţi de asemenea în considerare dezactivarea NSAssert pentru iOS pentru că aplicaţia se va bloca imediat după o avarie; un mod elegant de rezolvare a problemei este interceptarea şi prelucrarea acestor erori.

Ar trebui de asemenea să dezactivaţi logurile înainte de a publica aplicaţia; acestea pot să stocheze date confidenţiale. Dezactivarea acestora pot să prevină scurgerea de informaţii confidenţiale şi de asemenea se poate vedea o mică creştere în performanţă.

PasteBoards

Clasa UIPasteboard permite unei aplicaţii să împărtăşească date în cadrul aplicaţiei sau cu altă aplicaţie folosind pasteboards la nivel de sistem sau specifice pentru aplicaţie. Sună cunoscut? Uitaţi-vă la imaginea de mai jos.

Sunt sigur că aţi văzut asta în multe aplicaţii iOS. Atunci când utilizatorul cere o operaţiune de copiere sau tăiere pe o bucată selectată din interfaţa utilizatorului, un obiect scrie datele pe un pasteboard. Dacă nu este setat un nivel adecvat de securitate, alte aplicaţii pot avea acces la datele salvate anterior creând astfel riscuri mari de securitate. De asemenea, persistenţa acelor date trebuie controlată, deoarece, dacă atributele nu sunt setate în mod corect, informaţia copiată va fi stocată necriptată în sistemul de fişiere al telefonului şi va fi menţinută chiar şi după închiderea aplicaţiei.

Ca o ultimă remarcă, să ţineţi minte că practicile de securitate doar îngreunează viaţa hackerilor. Nu se poate să vă asiguraţi în proporţie de 100% că măsurile dumneavoastră nu vor putea fi ocolite. La urma urmei, toate versiunile de iOS au fost sparte/decodate. Deşi devine din ce în ce mai greu pentru hackeri, ar trebui să vă pregătiţi pentru situaţii neprevăzute. La urma urmei, trebuie să găsiţi proporţia adecvată între uzabilitate şi practici de intimidare ce vi se potrivesc cel mai bine dumneavoastră, clientului şi utilizatorilor dumneavoastră.

Mulţumiri speciale lui Mircea Botez și lui Andrei Adiaconitei.