ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 12
Abonament PDF

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.

Bibliografie

1. Apple iOS Developer Library

2. "Top 10 iPhone Security Tips" de Kunjan Shah

3. "Penetration Testing for iPhone / iPad Applications" de Kunjan Shah

4. "iOS Keychain Weakness FAQ" de Jens Heider, Rachid El Khayari

5. "Lost iPhone? Lost passwords!" de Jens Heider, Matthias Boll

6. https://www.viaforensics.com

7. http://www.useyourloaf.com

8. http://www.technologyreview.com

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO