Title: Seguretat
Course: CFGS - Desenvolupament d'aplicacions web > Section: Planificació d'una aplicació mòbil

Seguretat

Android. System Permissions

Android és un sistema operatiu que separa les aplicacions per privilegis, en concret cada aplicació s'executa amb una identificació diferent, tant l'usuari com el grup són diferents. Així mateix el sistema s'executa amb una identitat diferent.

Una altra mesura de seguretat que proporciona Android és un mecanisme de permisos en el que les aplicacions cal que demanin accés a un recurs, sol·licitant-lo abans d'accedir-hi mitjançant una URL permission.

Per defecte qualsevol aplicació Android no té permisos per realitzar cap acció, això inclou lectura de contactes, emails, arxius... Cada aplicació Android s'executa en una process sandbox. Aquest mecanisme de seguretat permet executar les aplicacions de forma independent, les unes de les altres. Com a resultat d'aquesta independència, les aplicacions han de demanar explícitament recursos i dades i per fer-ho cal que declarin els permisos que necessitaran. D'aquesta forma Android en el moment de la instal·lació pregunta a l'usuari el seu consentiment.

Totes les aplicacions APK (arxius .apk) han d'anar signats mitjançant certificat pel desenvolupador. Aquest certificat identifica l'autor de l'aplicació, encara que aquests certificats no han d'estar signats per cap autoritat de certificació sinó que es tracta de certificats auto-signats.

Permisos classificats com a normals:

Permisos classificats com a perillosos:

APP Manifest

Cada aplicació ha de contenir un arxiu anomenat AndroidManifest.xml que es troba a la carpeta arrel de l'aplicació. Aquest arxiu de manifest  proporciona tota la informació necessària al sistema Android abans d'executar l'aplicació. Entre les diferents informacions que hi podem trobar, hi ha:

- Nom del Java Package. Que funciona a mode d'identificador únic per a l'aplicació
- Components de l'aplicació: activities, services, broadcast receivers, content providers. Aquesta informació permet saber a Android quins components incorpora l'aplicació i en quin moment cal executar-los
- Permisos necessaris per a la seva execució: accés a l'API, interacció entre aplicacions o components
- Versió mínima de l'Android API per executar l'aplicació
- Llibreries enllaçades i necessàries

Més informació:

[ Android Developer Guide. System Permissions ]

[ Dalvik VM ]

[ AndroidManifest.xml ]

iOS. Authentication, Authorization, and Permissions

iOS és un sistema operatiu que separa les aplicacions per privilegis. Per defecte qualsevol aplicació no té permisos per realitzar cap acció, això inclou lectura de contactes, emails, arxius... Cada aplicació s'executa en una process sandbox. Aquest mecanisme de seguretat permet executar les aplicacions de forma independent, les unes de les altres. Com a resultat d'aquesta independència, les aplicacions han de demanar explícitament recursos i dades el primer cop que en fan ús, de forma que iOS demana el consentiment a l'usuari i recorda l'opció triada per aquest, per a les properes execucions.

iOS protegeix només l'accés a determinades característiques:

- Location: Localització del dispositiu
- Photos: Accés a la galeria fotogràfica del dispositiu
- Music, video, media assets: Autorització per accedir a la música i vídeos del dispositiu
- Contacts: Agenda de contactes del dispositiu
- Calendar: Informació relativa als calendaris del dispositiu
- Reminders: Alarmes establertes en el dispositiu
- Bluetooth: Accés a dispositius externs via bluetooth
- Microphone: Accés al micròfon (des de iOS 7)
- Camera: Accés a la càmera (des de iOS 7)

Més informació:

[ Guia codificació segura Apple ]

Resum iOS / Android

Android

Android té un sistema de permisos a nivell individual per a les APPs, de forma que només cal la conformitat de l'usuari en el moment de fer la instal·lació. En canvi iOS permet prendre alguna decisió més.

Quan s'instal·la una aplicació des de Google Play o des de qualsevol altre lloc, el sistema mostra una llista dels permisos que necessita l'aplicació: accés a internet, lectura USB, estat GPS, estat telèfon...

Si no acceptem aquesta llista de requeriments, l'aplicació no s'instal·la, de forma que si l'usuari no hi para atenció aquesta és una font d'instal·lació d'aplicacions amb accés a recursos maliciosos.

En aquest sentit Android en la seva versió 6.0 incorporarà la possibilitat de configurar els permisos de forma individualitzada, de forma similar a com ho fa iOS.

iOS

Els permisos en iOS funcionen de forma diferent. Qualsevol aplicació que s'instal·la en un dispositiu (iPhone, iPad...) té uns permisos bàsics com per exemple l'accés a internet. En el moment de fer la instal·lació l'usuari no ha de prendre cap decisió. Únicament pel fet d'instal·lar, no és necessari que es preocupi d'atorgar permisos d'accés al GPS o als contactes.

Per utilitzar alguns permisos, com accés als contactes, a la localització via GPS, als calendaris, a les alarmes, a les fotos, al bluetooth, al micròfon, etc.. l'aplicació demana el consentiment a l'usuari respecte de l'aplicació que en vol fer ús per primera vegada. Per exemple, quan s'instal·la Google Maps i s'executa per primera vegada i aquest intenta accedir a la ubicació per mostrar-la, ens apareix una alerta pop-up demanant a l'usuari l'autorització.

Una altra característica que incorpora iOS és la possibilitat que dóna a l'usuari de cancel·lar en qualsevol moment algun dels permisos que aquesta ha requerit, mitjançant les opcions de privacitat.

Seguretat en serveis REST

Una de les principals característiques dels serveis RESTful respecte a la resta de serveis de comunicacions és que els serveis REST mantenen la informació sobre el seu estat en la banda del client, el servidor no manté cap informació al voltant de l'estat. Això implica que el client ha de proveir de tota la informació necessària per fer la petició del recurs.

HTTP Basic authentication

El mecanisme més bàsic és la utilització de l'autenticació del protocol HTTP. Aquest mecanisme incorpora a la capçalera HTTP la informació relativa a usuari:password codificada en base64.

GET / HTTP/1.1
Host: servidor.cat
Authorization: Basic dXN1YXJpX2FwaTpjbGF1X3NlZ3VyYQ==

En l'anterior exemple podem veure la capçalera que es correspondria si el nostre servei es trobés a servidor.cat i la informació de l'usuari es troba codificada en base64  dXN1YXJpX2FwaTpjbGF1X3NlZ3VyYQ== que si decodifiquéssim obtindríem usuari_api:clau_segura

Encara que les credencials estiguin codificades, això no vol dir que estiguin xifrades. Resulta molt fàcil obtenir l'usuari i la clau d'una autenticació bàsica [Decode base64]. No s'ha d'utilitzar aquest esquema d'autenticació en HTTP pla, només s'hauria d'emprar mitjançant SSL/TLS que proporciona comunicacions segures mitjançant protocols criptogràfics.

HMAC

Un dels principals inconvenients de l'autenticació bàsica és que cal enviar la contrasenya dins de la capçalera de cada sol·licitud. A més aquesta informació no es troba protegida contra manipulacions. Una altra forma de fer-ho és emprant HMAC (hash based message authentication), en aquest cas, en lloc d'enviar contrasenyes, en realitat s'envia una versió hash de la contrasenya amb informació addicional. Per exemple, imagineu-vos que tenim les següents credencials: usuari-> joan i com a contrasenya-> secret. Suposem que intentem accedir a un recurs protegit /usuaris/joan/registresfinancers. Primer necessitem obtenir tota la informació necessària i concatenar-la.

GET+/usuaris/joan/registresfinancers

Prenem el verb HTTP i la URL actual, podem afegir-hi informació com la data/hora actual, un numero aleatori o un hash md5 de cos del missatge per prevenir atacs per modificació o per replay. Un cop obtinguda aquesta informació ens cal calcular el hmac:

digest = base64encode (hmac("sha256","secret","GET+/usuaris/joan/registresfinancers"))

Ara es pot enviar aquesta informació a traves de la capçalera HTTP:

GET /usuaris/joan/registresfinancers HTTP/1.1
Host: servidor.cat
Authorization: hmac joan:[digest]

En aquest moment el servidor reconeix que l'usuari joan intenta accedir a un recurs. Aquest servidor pot generar de nou aquest digest, ja que disposa de tota la informació. (Noteu que la contrasenya està xifrada al servidor i el servidor necessita conèixer-lo, per això se n'anomena secret i no contrasenya).

Si algú intercepta aquesta conversa no podria utilitzar la informació de la connexió per canviar les dades financeres del joan via POST o PUT, o visualitzar la informació d'un altre usuari, ja que això canviaria el digest. L'únic que es podria fer seria accedir a la informació d'en joan tantes vegades com es vulgués, ja que no canvia el digest. Per això moltes vegades s'envia més informació, com l'hora actual.

digest = base64encode (hmac("sha256","secret","GET+/usuaris/joan/registresfinancers+10jan201611:59:45+123456"))

Afegim dos nous fragments d'informació en el càlcul del digest. La data actual i un número que només es pot emprar un sol cop.

ET /usuaris/joan/registresfinancers HTTP/1.1
Host: servidor.cat
Authorization: hmac joan:123456:[digest]
Date: 20 jan  2016 11:59:45


El servidor pot reconstruir el digest de nou, però aquest cop el client envia un número i la data. Si la data enviada no es troba dins d'un determinat rang respecte el servidor (10 minuts), el servidor pot ignorar el missatge, ja que segurament es tractaria d'un replay d'un missatge generat anteriorment (també pot ser un error en la data/hora del client)

El número només el podem emprar un cop de forma que si volem accedir al mateix recurs un altre cop, cal canviar aquest numero. D'aquesta forma si en el mateix segon s'intenta accedir al mateix recurs ho detectaríem ja que el digest seria diferent. Així mateix evitaríem els atacs per replay.

OAuth

Un dels inconvenients del HMAC és que no hi ha més contrasenyes, sinó que només hi ha secrets. Quan es descobreix el secret de joan, tothom pot accedir a aquest compte. Una forma d'evitar això és utilitzar tokens temporals, de forma que l'usuari joan demana al servidor un recurs per a un token i secret particulars per accedir.

Oauth és un mecanisme que permet crear tokens temporals, de forma que s'ha convertit en un esquema comú per a l'autenticació i l'autorització encara que resulta una mica més complexa la seva implementació. Existeixen moltes implementacions ja desenvolupades en diferents llenguatges.

OAuth2

Es tracta d'una nova implementació de OAuth que ha canviat completament la seva estructura. Aquesta nova via resulta més fàcil d'implementar i mantenir, encara que aquesta no s'ha convertit en standard i actualment s'està utilitzant en molts llocs aquest mètode basat en els diferents esborranys.

Consideracions

L'autenticació bàsica i OAuth haurien d'anar protegides sempre mitjançant SSL/TLS, en lloc d'emprar HTTP. Emprar nombres nonces pot millorar la seguretat, sempre i quan s'emmagatzemi i es compari en el servidor. Un problema habitual quan s'utilitzen finestres de temps en les peticions, és la sincronia del servidor i el client, sobretot quan el client no té establerta correctament l'hora. Per això cal assegurar-se que tant client com servidor utilitzen sistemes NTP per mantenir la sincronia horària.

Més informació:
[ REST Cookbook ]
[ Def. SSL/TLS ]
[ REST a la pràctica ]