Seguretat de les aplicacions mòbils: Com garantir-la?

Què és el que busquen els atacants en els nostres dispositius mòbils?

• Accés a credencials
• Dades personals (adreces, dades de targeta de crèdit, localització…)
• Accedir a l'emmagatzematge de dades de l'aplicació
• Realitzar enginyeria inversa, per localitzar vulnerabilitats, credencials incrustades o algorismes que generin claus
• Instal·lació de malware o bloqueig de funcions existents
• Accedir al dispositiu i controlar les connexions
• Etc.

Com podem observar, dotar la nostra aplicació de mecanismes de seguretat que impedeixin realitzar les accions anteriors es converteix en alguna cosa imprescindible.

Blindatge en aplicacions mòbils: per què no és l'habitual?

La principal raó és que els desenvolupadors posen l'accent en què aquestes funcionin correctament i en una gamma àmplia de dispositius, que compleixin amb tots els requisits definits… i es focalitzen sobretot en aspectes més atractius per a l'usuari com són la usabilitat, l'experiència d'usuari i la interfície gràfica.

No obstant això, l'essencial és que siguem conscients que implementar mecanismes de seguretat en una aplicació mòbil és igual d'important, sobretot tenint en compte el gran volum d'usuaris que poden fer ús de la mateixa.

De fet, cada vegada són més les empreses les aplicacions de les quals han de passar per un procés de hacking ètic, que tracta de hackejar un sistema i identificar i reparar possibles vulnerabilitats, la qual cosa prevé eficaçment l'explotació per hackers maliciosos.

Mesures bàsiques en seguretat per a aplicacions mòbils

Quan fem el nostre desenvolupament mòbil, hem de posar el focus en diverses àrees i complir una sèrie de requisits en cadascuna d'elles. Per això, podem basar-nos en l'estàndard de seguretat d'aplicacions mòbils OWASP, que s'encarrega de preveure requeriments per a arquitectes i desenvolupadors de programari que busquen desenvolupar aplicacions mòbils segures.

Aquesta guia define 2 nivells de verificació de seguretat, així com un conjunt de requisits de resistència a l'enginyeria inversa.

La elecció del nivell dependrà del context de la nostra aplicació. El nivell L1 conté requisits genèrics de seguretat recomanats per a totes les aplicacions mòbils. El següent nivell, L2, està enfocat a aplicacions que gestionen dades altament sensibles (sector financer, indústria de la salut).

A continuación especificamos els requisits de seguretat més destacables que hauríem de tenir en compte en el desenvolupament de la nostra aplicació categoritzats en set àrees, si bé podem trobar el llistat complet a la pròpia guia OWASP:

Emmagatzematge de dades i privacitat

La protecció de dades sensibles, com acreditaris i informació privada és, a més d'un imperatiu legal, un aspecte crític en la seguretat mòbil.

Alguns dels requisits que permeten prevenir l'accés a aquesta informació són els següents:

• No guardar informació sensible a l'emmagatzematge local del dispositiu, i en cas de ser necessari, aquesta ha d'estar xifrada fent servir una clau derivada del maquinari d'emmagatzematge segur, el qual requereix autenticació prèvia.
• No escriure informació sensible en els logs del sistema ni en còpies de seguretat.
• No exposar informació sensible com contrasenyes o números de targeta a través de la IU (interfície d'usuari) o captures de pantalla, i desactivar la memòria cau del teclat en els camps de text que contenen aquesta informació.

Ús de claus criptogràfiques

A l'hora de poder protegir la informació sensible emmagatzemada en el nostre dispositiu, la criptografia és un component fonamental. A l'hora de fer ús de claus criptogràfiques hem de tenir en compte els següents requisits:

• No dependre únicament de criptografia simètrica les claus de la qual es trobin directament en el codi font de l'app.
• No reutilitzar una mateixa clau criptogràfica per a diversos propòsits.
• Els valors aleatoris són generats utilitzant un generador de números aleatoris suficientment segur.

Autenticació i control de sessions

Perquè una aplicació sigui segura, ha de comptar amb un mecanisme d'autenticació i control de la sessió d'usuari. Si bé és cert que la majoria d'aquesta lògica es troba en el costat servidor, a continuació indiquem alguns requisits que hem de tenir en compte:

• La autenticació biomètrica, si la hi ha, no està associada a esdeveniments (p. ex. fent servir una API que simplement retorna "true" o "false"), sinó basada en el desbloqueig del keychain/keystore (emmagatzematge segur).
• Per a aplicacions que gestionen informació molt sensible, aplicar mecanismes de doble factor d'autenticació.
• Les sessions i els tokens han d'expirar passat un temps predefinit d'inactivitat per part de l'usuari.

Comunicació amb serveis

Un aspecte important en les apps, és garantir la seguretat en la comunicació amb el servidor, assegurant la confidencialitat i integritat de les dades intercanviades. Per això, alguns requisits són:

• La informació és enviada xifrada utilitzant el protocol TLS.
• L'aplicació verifica el certificat X.509 del sistema remot en establir el canal segur i només s'accepten certificats signats per una CA de confiança.
• L'aplicació utilitza el seu propi magatzem de certificats o realitza pinning del certificat o la clau pública del servidor.

Interacció amb la plataforma mòbil

La interacció entre les aplicacions i els sistemes operatius s'ha de dur a terme tenint en compte els següents aspectes:

• L'aplicació requereix la quantitat de permisos mínimament necessària.
• L'aplicació no exposa cap funcionalitat sensible a través de mecanismes IPC llevat que aquests mecanismes estiguin degudament protegits
• Deshabilitar JavaScript de los Webviews llevat que sigui necessari.
• Les WebViews es configuren per permetre el mínim dels esquemes (idealment, només https). Esquemes perillosos com file, tel i app-id estan deshabilitats.

Qualitat del codi

Malgrat que les apps no són tan vulnerables a atacs de tipus Cross-Site Scripting, els desenvolupadors han de seguir una guia de bones pràctiques perquè el codi sigui segur:

• L'aplicació ha de ser signada i proveïda amb un certificat vàlid, així com ser publicada en mode release.
• L'aplicació captura i gestiona adequadament les possibles excepcions.
• Les funcionalitats de seguretat gratuïtes de les eines, com la minificació del byte-code, protecció de la pila, suport PIE i comptatge automàtic de referències, es troben activades.
• Fer ús d'eines que permetin analitzar el codi font per detectar possibles vulnerabilitats com per exemple SonarQube.

Mecanismos contra la manipulación e ingeniería inversa

Cal evitar que un atacant pugui manipular la nostra aplicació o realitzar l'enginyeria inversa del codi. Per això, existeixen diversos mecanismes que es deuen implementar:

• Firmat de l'aplicació: Una de les tècniques de seguretat més importants en Android és el firmat de les aplicacions utilitzant claus públiques i privades.

A l'hora de compilar una aplicació amb tots els elements que la componen (textos, gràfics, codi...) cada desenvolupador ha d'assegurar-la amb el seu certificat perquè la signatura identifiqui l'aplicació i sigui possible saber si ha estat modificada o es manté intacta. Aquesta és l'única manera de saber si una app és falsa o autèntica: en el cas que s'hagi modificat la signatura, si n'hi ha, no es correspondrà amb el desenvolupador original.

• Anti-Tamper: Les tècniques anti-tamper dificulten que un atacant pugui modificar un programari, realitzant enginyeria inversa i validant la seva integritat per al seu posterior ús modificat. Per a això, es verifica que la signatura de l'aplicació sigui la original i s'apliquen mecanismes de comprovació del checksum.
• Ofuscació del codi: La ofuscació del codi permet compactar, optimitzar i fer il·legible el codi canviant semànticament classes, camps, mètodes i noms. El resultat és una aplicació més petita i complexa de desxifrar, dificultant la comprensió dels mateixos davant dels ulls maliciosos.
• Verificació de l'origen de l'instal·lador: Amb aquesta tècnica es comprova que l'aplicació ha estat distribuïda des de l'origen fiable, evitant que tinguem en el nostre terminal una còpia de l'APK que hagi pogut ser infectada amb malware.
• Anti-Debug: Les tècniques anti-debug dificulten o detecten la depuració d'una aplicació, amb l'objectiu de poder aplicar determinades accions que evitin que un atacant continuï amb el procés. El mecanisme més senzill és a través d'una propietat en el propi manifest de l'app, si bé es recomana comprovar dinàmicament i en diversos punts si la depuració està tenint lloc o no.
• Anti-Emulador: Si la nostra aplicació s'està executant en un emulador fora del procés de desenvolupament, indica que algú més que nosaltres està intentant analitzar l'aplicació. Per això, una bona pràctica és comprovar que en una versió release, no s'està accedint a l'aplicació mitjançant un emulador que faciliti atacar la seguretat de la mateixa.
• Anti-Root: Cal evitar sempre que sigui possible que una aplicació s'executi en terminals rootejats, ja que són terminals molt més vulnerables i que permeten accés a la memòria reservada del sistema i de l'aplicació, comprometent la persistència i per tant la privacitat de les dades que es manejen.
• Anti-Clone: mecanismo per evitar que l'aplicació pugui ser clonada, a aquest respecte es definiran les propietats adequades per evitar fer una còpia de l'aplicació instal·lada i obtenir el binari que un possible atacant podria utilitzar per aplicar tècniques d'enginyeria inversa.
• Dispositiu fiable: Google disposa d'una API anti-abús (SafetyNet Attestation API), permet avaluar si el dispositiu Android en el qual s'executa una aplicació és fiable.

Conclusió

Cada dia fem servir de més aplicacions mòbils i cada vegada aquestes emmagatzemen una major quantitat d'informació sensible de l'usuari. Per això és molt important estar al dia sobre noves mesures de seguretat que vagin sorgint, i aplicar-les de manera proactiva sobre els nostres desenvolupaments. L'objectiu no ha de ser només que l'usuari interactuï amb una bona UX, sinó que també ho faci amb total seguretat.

“Ser consciente de las vulnerabilidades es ya la mitad de la seguridad”.