Tfm- seguretat en sistemes biotmètricsdeim.urv.cat/~francesc.serratosa/2017_05_21_Axel_Picon...Tfm-...

AUTENTIFICACIÓ D’HUMANS A TRAVÉS DEL

RECONEIXEMENT DE LA SIGNATURA UTILITZANT

DISPOSITUS MÒBILS ANDROID

Màster Interuniversitari en Seguretat de les TIC

(MISTIC)

Memòria Final

Tutor: Francesc Serratosa Casanelles

Alumne: Axel Picón Magdalena

Data: Juny de 2017

Tfm- seguretat en sistemes biotmètrics

Axel Picón Magdalena - Treball Final de Màster Pàgina 2

“L’únic sistema segur és aquell que està apagat en l’interior d’un bloc d’hormigó

protegit en una habitació sellada rodejada per guardies armats”

Gene Spafford

Autor del projecte: Axel Picón Magdalena, 2017

Les imatges utilitzades en el projecte en tenen els drets els seu respectius propietaris i s’utilitzen seguint el dret de cita en l’àmbit

acadèmic i només per finalitats acadèmiques (article 32 de la Llei de la Propietat Intel·lectual)



Agraïments:

Amb aquest redactat es vol valorar i agrair, primerament l’ajuda del consultor i tutor

de la Universitat Rovira Virgili Francesc Serratosa Casanelles, que amb els seus

comentaris de les diferents situacions que s’han viscut en aquest projecte ha permès

que s’hagi completat el projecte i dissenyat una documentació final atractiva i

completa.

També en aquest apartat es vol fer un agraïment a la meva família que amb la seva

gran paciència i comprensió ha aportat a que durant la realització d’aquest projecte es

pogués dedicar el màxim de temps possible amb la finalitat de finalitzar aquest

projecte del màster MISTIC



Resum del projecte

Català:

En els mateixos casos, hi ha la necessitat d'autenticació si una persona ha signat un document.

En aquestes situacions, és habitual demanar-li a la persona que signi en un troç de full i una

persona autoritzada validi si la nova signatura és suficientment similar a la signatura del

document.

L'objectiu d'aquest projecte fi de màster és dissenyar i implementar un mètode per comparar

signatures fetes a mà a través d'un dispositiu mòbil. En primer lloc, la persona que ha de ser

autentificada signarà a la pantalla del mòbil. En segon lloc, la persona autoritzada, realitzarà

una fotografia a la signatura del document mitjançant el dispositiu mòbil. Finalment, s’haurà

de validar amb garantia el grau de similitud.

Castellà

En los mismos casos, existe la necesidad de autenticar si una persona ha firmado en un

documento. En estas situaciones, es habitual pedirle a la persona que firme en un trozo de

papel y una persona autorizada valide si la nueva firma es suficientmente similar a la firma del

documento.

El objetivo de este proyecto final de master es diseñar e implementar un método para

comparar firmas hechas a mano a través de un dispositivo móvil. Primero, la persona tiene que

ser autentificada firmando en la pantalla del móvil. En segundo lugar, la persona autoritzada

realizara una foto en la firma del documento mediante el dispositivo móvil. Finalmente, se

tendra que validar con garantia el grado de similitud

English

In same cases, there is the need of authenticating if a person has signed a document. In these

situations, it is usual to ask the person to sign in a piece of sheet and an authorised person

validates whether the new signature is similar enough to the document’s signature.

The aim of this Master thesis is to design and implement a method to compare hand-made

signatures through a mobile device. First, the person to be authenticated will sign at the

mobile screen. Second, the authorised person will take a picture at the document’s signature.

Finally, the device will output a similarity degree between both signatures.



INDEX

1) Introducció...................................................................................................................8-12

1.1) Situació actual, contextualització del Projecte ....................................................8-11

1.2) Objectius i motivació per a la realització del projecte .....................................11-12

1.3) Plannificació del projecte .......................................................................................12

2) Estructura Android/Interacció entre components ...................................................13-18

2.1) Estructura a nivell de xarxa Android ......................................................................18

3) Estructura i funcionament del projecte ....................................................................19-36

3.1) Aplicatiu Android ..............................................................................................20-30

3.2) Api rest ..............................................................................................................31-35

3.3) Servidor base de dades Sql server (Vmware) ........................................................36

4) Resultats de l’aplicatiu extern i introducció a la llibreria opencv ...........................37- 64

4.1) SIFT (Scale-Invariant Feartures) .......................................................................38-47

4.1.1) Escala-espai de detecció extrema .....................................................38 -39

4.1.2) Localització de keypoints….. ....................................................................40

4.1.3) Orientació…………………………………………………………………..……………..………..40

4.1.4) Punt clau descriptor ................................................................................40

4.1.5) Matchs dels keypoints .............................................................................41

4.1.6) Proves amb l’algorisme SIFT en el laboratori………………………...……….41-47

4.2) SURF (Speeded-Up Robust Features) ..............................................................48-56

4.2.1) Proves amb l’algorisme SURFT en el laboratori………………….………..…50-56

4.3) ORB (Oriented Fast and Rotated Brief) ..........................................................57-64

4.3.1) Proves amb l’algorisme ORB en el laboratori i dipositiu mòbil………..58-64

4.3.2) Conclusions amb l’algorisme ORB en el laboratori……………………..……….64

5) Elements de seguretat d’Android..............................................................................65-68

5.1) Arxiu AndroidManifest.xml................................................................................65-66

5.2) Usuari Linux i accés a l’arxiu...................................................................................66

5.3) L’esquema de permisos en Android……………………………………………………..…………….66

5.4) Mencanisme de seguretat sandbox…………………………………………….………..……….66-67

5.5) Partició del sistema i mode segur…………………………………………………………………..……67

5.6) Sistema de xifratge…………………………………………………………………………………….……….67

5.7) Protecció per contrasenya……………………………………………………………………………...…67

5.8) Administració de dipositius……………………………………………………………………….…..……68

5.9) Millores de seguretat en l’administració de la memòria………………………….…….……68

5.10) Permisos de “root” en els dispositius…………………………………………………….………….68

5.11) Signatura de les aplicacions……………………………………………………………………….……..68

6) Tipus d’atacs als dispositius Android ……………………………………………………………….….68-74

6.1) Atacs des del dispositiu.....................................................................................69- 72

6.1.1) Atacs procedents de carpetes emails o altres aplicacions ......................69-70

6.1.2) Atacs basats en telèfon/SMS……………………………………………….…………………70-71

6.1.3) Atacs bastas en aplicacions de tercers……………………………………………………….71

6.1.4) Atacs basats en sistema operatiu……………………………………………………….…71-72

6.2) Atacs procedents des de la xarxa.......................................................................72-73

6.3) Atacs procedents des d’un centre de dades (web service o base de dades).....73-74



6.3.1) Webservices …………………………………………………………………………………….……73-74

6.3.2) Base de dades…………………………………………………………………….……………………….74

7) Politiques de configuración en seguretat del dipositiu móbil................................. 74-76

8) Guia de seguretat pel desenvolupament d’aplicacions Android............................ 76 -93

8.1) Augmentar la complexitat del codi i l’ús d’ofuscació en l’aplicatiu Android……76-77

8.2) Evitar lògica simple………………………………………………………………………………………..77-78

8.3) Utilització de biblioteques de tercers……………………………………………………………….…78

8.4) Aplicar tècniques de protección contra manipulacions……………………….…………78-79

8.5) Emmagatzemar de forma segura dades confidenciasl en la memòria RAM…………79

8.6) Comprovar Eliminació segura de dades………………………………………………….………79-80

8.7) Evitar la cadena de consulta de les dades sensibles……………………………………….……80

8.8) Implementar emmagatzamatge segur de dades…………………………………………….……81

8.9) S’ha d’utilitzar un entorn per a les cookies…………………………………………………….……81

8.10) Validar totalment SSL/TLS…………………………………………………………………….………81-82

8.11) Protegir atacs downgrade SSL……………………………………………………………………………82

8.12) Protecció del tractament geològiques……………………………………………………….………83

8.13) Insertar temporització de la sesisió local en l’aplicatiu………………………………………83

8.14) Implementar auntentificació Enhaced/Two-Factor………………………………………83-84

8.15) Protegir la configuración de l’aplicació………………………………………………………………84

8.16) Amagar números de compte i l’ús de tokens…………………………………………….………84

8.17) Validar els valor de dades entrats pels usuaris………………………………………….………85

8.18) Evitar l’emmagatzamatge de dades en l’aplicació de còpies de seguretat…………85

8.19) Evitar tenir els registres logs habilitats en l’aplicatiu…………………………………………85

8.20) Tenir un control de registres de depuració generats per l’aplicatiu………………85-86

8.21) S’ha de ser concient de la funcionalitat en Android………………………………………..…86

8.22) Implementació de intents amb un controls exhaustiu…………………………………86 -87

8.23) Verificar el correcte funcionament de les activitats disenyades…………….…….……87

8.24) Utilització de broadcast amb cura……………………………………………………….……….……88

8.25) Implementació de pendingintents amb cura……………………………………………….……88

8.26) Protegir els serveis d’aplicacions………………………………………………………………….……88

8.27) Realitzar bones practiques del webview en els aplicatius Android…………….………89

8.28) Evitar l’emmagatzematge d’imatges de la càmera en memoria cau…………….……89

8.29) Els desenvolupadors sempre han de signar els arxius APK…………………………………90

8.30) Funcions de seguretat integrades en el sistema operatiu Android…….…………90-91

8.31) Permisos en aplicacions Android……………………………………………………………….………91

8.32) Segureta en l’utilització de xarxa en aplicatiu Android……………………………..………92

8.33) Ús de criptografía en aplicatius Android……………………………………………………………92

8.34) Seguretat de càrrega dinàmica de codi en Android………………………………………92-93

8.35) Utilització de programari lliure per milllorar la seguretat……………………….…………93

9) Eines d’android incloses en el programari pe analitzar i desenvolupar aplicacions

Android amb seguretat..............................................................................................94-96

10) Eines externes per analitzar i protegir aplicacions Android…………………………….….96-102

11) Tècniques d’ofuscació de codi en Android…………………………………………………………102-105

12) Guia per seguritzar l’aplicatiu contra atacs de Sql injection………………………………106-110



12.1) Escapar els caràcters especials utilitzats en les consultes Sql………………………..…106

12.2) Verificar sempre les dades que introduiex l’usuari en l’aplicatiu……………………..107

12.3) Assignar mínims privilegis a l’usuari que connecta amb la base de dades des de

l’aplicatiu …………………………………………………………………………………………………………………107

12.4) Realitzar modificacions del codi per tenir una codificació correcta………….………107

12.5) Protegir els logs ………………………………………………………………………………………………108

12.6) Utilitzar Sql dinàmic només si és absolutament necessàri……………….………………108

12.7) Instal·lar pegats (patch) regularment………………………………………………………………108

12.8) Treure tota la funcionalitat que no s’utilitizi……………………………………………………108

12.9) Utilitzar eines de proves automatitzades per les injeccions Sql…………….…………109

12.10) No revelar ni informació ni les credencials amb privilegis d’administrador

(enginyeria social)……………….…………………………………………………………………………….…….109

12.11) Utilització de firewall (application firewalls) …………………………………………………109

12.12) Xifrar les dades sensibles en la base de dades…………………………………….…109-110

12.13) No mostrar més informació de la necessària…………………………………………………110

12.14) No emmagatzemar dades sensibles…………………………………………………………..….110

13) Com monotoritzar i mitigar un possible atac en l’aplicatiu………………..…………..…111-114

13.1) Passos per prevenir un possible atac…………………………………....…………………111-112

13.2) Passos per mitigar un possible atac……………………………………………….…………112-114

14) Conclusions i treballs futurs………………………….……………………………………..……………115-116

15) Referències…………………………………………………………………………………………………..……117-123

16) Annex 1 Manual laboratori de proves………………………………………………………………..124-125

17) Annex 2 Manuals de l’aplicació completa ……………………………………………………..…..126-129

18) Annex 3 Storeds i taules utilitzades en el servidor de base de dades……………….…130-134



1. INTRODUCCIÓ

1.1 Situació actual, contextualització del projecte

Els requisits de seguretat de la societat d'avui, tenen la biometria col·locada en el centre d'un

gran debat, ja que, s'està convertint en un aspecte clau en una multitud de sistemes. Aquest

concepte de biometria és el reconeixement individual basat en les característiques distintives

d'una persona. Mentre altres tècniques utilitzen la possessió d'un objecte físic (és a dir, targeta

d'identificació, ID targeta, etc.) o el coneixement d'alguna cosa (és a dir, una contrasenya, clau

de fase, etc.) per a realitzar el reconeixement personal, en els últims anys s’han estat

implementant noves tècniques biomètriques les quals ofereixen la possibilitat d'utilitzar les

característiques inherents de la persona per a la seva identificació en qualsevol sistema. Per

tant, els sistemes biomètric no pateixen les desavantatges de qualsevol dels enfocaments

basats en objectes físics, en els aquals els atributs poden ser perduts o robats, i la perspectiva

basada en el coneixement, els atributs es poden oblidar.

Un sistema biomètric pot o bé verificar o identificar. En la verificació el sistema biomètric

autentifica la identitat de la persona sobre la base de coneixement de la seva identitat

declarada. En canvi, en el procés d'identificació, s'estableix la identitat de la persona (entre els

inscrits en una base de dades) sense els subjectes que tenen per reclamar la seva identitat.

En funció de les característiques personals es consideren dos tipus de dades biomètriques les

quals poden definir trets fisiològic o de comportament. El primers es basen en el mesurament

de les característiques biològiques dels usuaris, com, per exemple, empremta digital, cara,

geometria de la mà, la retina i l'iris o la segona segons els trets de comportament que posseix

el propi usuari que vol tenir accés a un sistema.

Les signatures manuscrites ocupen un lloc molt especial en aquest ampli conjunt de trets

biomètrics. Aixó es deu principalment al fet que les firmes manuscrites tenen ha establir-se

com el mitjà més estès de verificació personal.

Les firmes són generalment reconegudes com un mitjà legal de verificar la identitat d'un

individu en institucions administratives i financeres

D'altra banda, l’anàlisi de verificació de la signatura no requereix mesures invasives i la gent

està familiaritzada amb l'ús de signatures en la seva vida diària.



Per desgràcia, una signatura manuscrita és el resultat d'un complex procés en funció de l'estat

psicofísic del signant i les condicions en què el procés d'aposició signatura es produeix. Per

tant, les teories complexes han estat proposades per modelar els mecanismes psicofísics

subjacents en l’escriptura a mà i els processos de verificació de la signatura els quals segueixen

sent un repte obert, ja que, en una signatura es jutja la seva autenticitat o falsificació només

sobre la base d’unes poques referències.

Els estudis fins aleshores, s’han dividit en tres fases principals per realitzar el procés de

verificació de reconeixement de signatura de manera automàtica que són:

1) L’adquisició de dades.

2) Processament previ.

3) Extracció de característiques i classificació.

Durant la fase de classificació, s’extreuen les característiques extretes d'una firma introduïda

que es comparen amb la informació continguda a la base de coneixement, per tal de

diagnosticar l'autenticitat de la signatura introduïda. La verificació de signatura automàtica

implica aspectes de disciplines que van des de l'anatomia humana a l'enginyeria, i des de la

neurociència a la informàtica i la ciència.

A causa d'aquest fet, en els últims anys, els estudis sobre la verificació de signatures els

investigadors han treballat per a les universitats i les empreses, que estan interessades en no

només els reptes científics, sinó també en les valuoses aplicacions que es poden dissenyar a

partir del perfeccionament d’aquests coneixements.

Hi ha hagut molst avanços en aquest camp al 1994, una edició especial va reservar la recollida

de les activitats d'investigació més rellevants que van ser publicades fins aquell temps.

Successivament, diversos treballs han resumit l'augment dels esforços de recerca en aquest

camp, pel que fa a la zona més general d'escriptura anàlisi i processament.

En conjunció amb el creixement recent i l’extraordinària utilització d’Internet, la verificació

automàtica de signatures està sent considerada amb renovat interès. La creació de lleis i

reglaments específics, que han estat aprovats en molts països i l'atenció que diverses

associacions nacionals i internacionals han donat a la normalització de les dades de signatura

formats d'intercanvi, són evidència de la renovada atenció en aquest camp.



L'objectiu d'aquest projecte és realitzar un esforç per facilitar i millorar aquests estudis per a

realitzar un aplicatiu en dispositius Android on s’ha realitzat l’integració de l’avançada

tecnologia d’aquests dispositius amb els estudis més recents utilitzant conjuntament una

llibreria molt efectiva en els sistemes de visió per computació anomenada opencv amb la qual

s’han pogut fer anàlisis amb diferents algorismes de tractament d’imatges per poder verificar

l’autenticitat de la signatura extreta de la imatge feta sobre un document i la generada i

agafada per l’usuari des de la pantalla del dispositiu mòbil.

Amb aquest estudi es podrà realitzar una àmplia gamma d'aplicacions comercials com ara:

banca, assegurances, cura de la salut, la seguretat d'identificació, gestió de documents, el

comerç electrònic, etc. Com en el sector de la investigació a nivell universitari o docent.

En els últims anys s’ha estat testimoni d'un canvi constant en les tecnologies dels ordinadors

d'escriptori per dispositius mòbils. En el quadre global de les plataformes disponibles, Android

es destaca com un participant dominant en el mercat i la seva popularitat segueix en augment,

generant un benefici en portabilitat pels usuaris que utilitzen aquests tipus de dispositius,

aquest creixement ha creat al mateix temps un ambient prolífic per a l'explotació pels

desenvolupadors amb un nivell avançat, que dissenyen i implementen programari maliciós a

part de tenir la capacitat de reutilització obtinguda il·legalment per atacs d’enginyeria inversa

en aplicatius ja existents, amb finalitat fraudulenta o atacs com sql injection.

Per aquesta raó i donada la importància que en l’actualitat té la seguretat informàtica en

aquests tipus d’aplicatius, s’ha considerat fer un estudi amb profunditat dels aplicatius que es

poden utilitzar per seguritzar-la, a més de les diferents tècniques de protecció de codi que s’ha

de tenir en compte degut el valor de les dades que s’administren utililitzant aquests tipus de

dispositius, ja que, és molt important protegir-los seguint les configuracions de seguretat

pertinents en aquests dispositius i les sugerències de seguretat en el moment d’ampliar o

millorar les funcionalitats de l’aplicatiu realitzat



1.2 Objectius i motivació per a la realització del projecte

La motivació per a realizar aquest treball de final de màster, ha estat, el desig de treballar en el

món de la seguretat informàtica i poder utilitzar els coneixements en seguretat adquirits

durant la titulació per resoldre el cas exposat, a més de l’ampliació de coneixements en

aplicatius per a dispositius mòbils en plataformes Android.

L’objectiu principal d’aquest projecte és, utilitzant l’adquisició de nous coneixements en el

món de la programació per dispositius Android, poder implementar un aplicatiu en aquesta

plataforma, la qual els usuaris que hagin creat un compte per poder-se loguejar, tinguin la

capacitat de validar la firma realitzada en un document comparant-la amb la creada per

l’usuari que és vol validar mitjançant la pantalla del dipositiu.

Per a la realització d’aquest projecte final de màster es poden indenfiticar les següents fases:

Estudiar la situación actual en els sistemes d’indentificació de firmes

Estudiar com implementar un aplicatiu Android

Estudiar com incorporar les llibreries opencv en el projecte

Estudiar com capturar l’imatge de la firma realitzada en el document

Estudiar com emmgatzema l’imatge generada per l’usuari des de la pantalla del

dispositiu

Estudiar com realizar l’implementació de l’algorisme de verificació i autenticitat de les

firmes

Estudiar les diferents tècniques i metodologies per implementar una aplicatiu Android

amb seguretat.

Estudiar les diferents tècniques i metodologies per seguritzar la base de dades en

aplicatius Android.

Proposar accions i projecte a realizar per millor l’algorisme de verificació de firmes

implementat

Oferir els resultats de les accions i projectes proposats i realitzats, per obtenir-ne una

bona base de coneixements i extreure conclusions rellevants.

Estudiar com realizar l’implementació d’un MVC cojuntament amb un Api rest per

guanyar amb eficiència en el consum de recursos de l’aplicatiu en el dispositiu mòbil



1.3 Planificació del projecte

Per a la realització d’aquest projecte final de màster, es va decidir seguir amb el següent pla de

treball (veure figura 1.1)

A. Estudiar la situación actual en els sistemes d’indentificació de firmes

B. Estudiar com implementar un aplicatiu Android

C. Estudiar com incorporar les llibreries opencv en el projecte

D. Estudiar com capturar l’imatge de la firma realitzada en el document

E. Estudiar com emmgatzema l’imatge generada per l’usuari des de la pantalla del

dispositiu

F. Estudiar com realizar l’implementació de l’algorisme de verificació i autenticitat de les

firmes

G. Estudiar les diferents tècniques i metodologies per implementar una aplicatiu Android

amb seguretat.

H. Estudiar les diferents tècniques i metodologies per seguritzar la base de dades en

aplicatius Android.

I. Proposar accions i projecte a realizar per millor l’algorisme de verificació de firmes

implementat

J. Oferir els resultats de les accions i projectes proposats i realitzats, per obtenir-ne una


Figura 1.1- Diagrama de Gannt



2- ESTRUCTURA ANDROID / INTERACCIÓ ENTRE COMPONENTS

En aquest apartat s’explicarà de manera resumida l’estructura del sistema operatiu Android, a

més de les característiques principals dels components i la seva interacció entre ells (Figura 2.1)

Figura 2.1 - Esquema de les diferents capes que composa el sistema operatiu Android

L’arquitectura del sistema Android està dissenyada de forma jeràrquica (com es pot observar

en la imatge), els seus components són dividits en capes, on els nivells més baixos agrupen

components relacionats amb la interacció del maquinari del dispositiu, les capes superiors

corresponen a processos de més alt nivell.

De manera general els components d’una capa utilitzen els serveis equipats per la capa inferior

(si existeix) oferint els seus serveis a les capes superiors.

A continuació, es farà una descripció de les característiques i funcionalitats de les diferents

capes de les quals es composa el sistema operatiu Android.

1- Linux Kernel (Primera capa): El nucli d'Android està conformat pel sistema operatiu Linux.

Les funcionalitats que proveeix aquesta capa depenen d'un nucli Linux multiusuari que

s'encarrega, entre altres coses, de l'administració de la memòria, els processos i els drivers dels

diferents recursos del hardware. En aquest nucli també s'implementen aspectes bàsics de

seguretat.

Com és la primera capa en l'arquitectura i la base de l'estructura d’aquesta primera capa,

depenen en gran mesura les del segon nivell, ja que, si un fabricant inclou un nou element de

maquinari, el primer que s'ha de fer perquè pugui ser utilitzat des d’Android, és la creació de

les llibreries de control o drivers necessaris dins el nucli de Linux encastat en el propi Android.



2- Llibreries i temps d’execució (Segona capa): Aquesta capa s’agrupa, bàsicament en tres

tipus de componentes:

Llibreries natives: S’ofereix un conjunt de libreríes C/C++ que proveeixen alguns

serveis bàsics per aplicacions i altres programes. Aquests serveis són utilitzats pels

components de la capa superior. Entre aquestes funcionalitats s’inclouen facilitar

l’accés al hardware i a la base de dades. Aquestes llibreries natives funcionant en

diferents processos del kernel Linux.

Entre les libreries natives es troben:

- System C library: Una derivació de la libreria BSD de C estàndar (libe),

adaptada per a dispositius basats en Linux

- Media Framework (llibreria basada en PacketVideo's Apencare): Soporta

codecs de reproducció i grabació de multitud de formats d’àudio, vídeo i

imatges MPEG4, H.264, MP3, AAC, AMR, JPG y PNG.

- Surface Manager: Administra l’accés al subsistema de representació gràfica en

2D y 3D.

- WebKit: Soporta un modern navegador web utilitzat en el navegador Android i

en la vista webview. Es tracta de la mateixa llibreria que utilitza Google

Chrome i Safari de Apple

- SGL: Motor de gràfics 2D.

- LLibrerias 3D: Implementació basada en OpenGL ES 1.0 API. Les llibreries

utilitzant l’accelerador hardware 3D (si està disponible), o el software altament

optimitzat de projecció 3D.

- FreeType: Fonts en bitmap i renderització vectorial.

- SQLite: Potent i lleuger motor de bases de dades relacionals disponible per

totes les aplicacions.

- SSL: Proporciona serveis d’encriptació Secure Socket Layer.

• Màquina virtual: Android compta amb una màquina virtual, anomenada Dalvik, per a

l'execució de les aplicacions programades en Java. Aquesta executa arxius amb format Dalvik

executable (.dex) que està optimitzat per reduir al mínim el consum de memòria del dispositiu

mòbil. Cada aplicació Java és compilada a un format bytecode i posteriorment és executada en

una màquina virtual Dalvik pròpia, diferent a l'assignada a qualsevol altre aplicació. A més

d'utilitzar el llenguatge de programació Java en el desenvolupament d'una aplicació, també és



possible incloure codi natiu (com C o C ++) que corri per fora de la màquina virtual Dalvik.

Aquest tipus de codi, a compilar, s'executa directament en el processador del dispositiu mòbil.

No obstant això, l'execució de l'esmentat codi natiu continua sent afectat per les restriccions

del nucli Linux.

• Llibreries Estàndard. Proveeixen, a nivell d'execució d'aplicacions, la majoria de les

funcionalitats disponibles a les llibreries estàndar de Java, com per exemple, operacions

matemàtiques, de text, d'entrada / sortida entre altres coses

3- Framework d’aplicacions (Tercera capa). En aquesta capa es troba el framework que

s'encarrega d’entre altres coses, administrar el cicle de vida de cada aplicació, proveir el

conjunt d'Apis necessaris per al desenvolupament i fer de guia entre la interacció de les

aplicacions com amb les diferents parts que les composen.

Un dels objectius principals de l'arquitectura d'Android és la reutilització de components, ja

que, qualsevol aplicació pot oferir els seus serveis a una altre amb l'autorització corresponent,

és per aquesta raó que Android permet una comunicació entre els diferents components de

les aplicacions.

Una altra característica important del framework, és que un desenvolupador pot tenir accés a

les mateixes APIs que utilitzen les aplicacions principals , és a dir, aquelles aplicacions que ja

venen preinstal·lades al dispositiu. Totes les llibreries del framework estan escrites en Java i es

troben a la màquina virtual Dalvik de cada aplicació. Si l'aplicació requereix dur a terme alguna

acció, les llibreries es comuniquen amb el sistema Linux base on es verifiquen els permisos

d'accés als recursos del sistema de l'aplicació sol·licitant.

4- Aplicacions (Quarta capa) : En aquest nivell s'inclouen tant les aplicacions principals (per

exemple, client de correu electrònic, calendari, llibreta de contactes) com les noves aplicacions

escrites per altres desenvolupadors.

Tots dos tipus d'aplicacions s'executen en el marc imposat pel framework de la capa inferior.

No obstant això, l'accés a les APIs està restringit als fragments d'aplicacions escrits en el

llenguatge de programació Java. Si hi ha codi natiu, no es podrà accedir directament a les APIs

a través del mateix sense abans interposar codi Java que actuï com intermediari.

Els components d’una aplicació Android es construeixen a partir de diferents blocs anomenats

components. Cada component és una entitat única i compleix una funció específica, definint el



comportament general de l'aplicació. Un aspecte del disseny del sistema Android, és que una

aplicació pot iniciar un component d'una altre si es tenen els permisos respectius.

Totes les aplicacions per a dispositius Android (això inclou al malware) estan encapsulats en un

format específic, conegut com APK «Application Package File». Aquest format és l'utilitzat per

a la instal·lació i distribució d'aplicacions per a aquesta plataforma mòbil.

Hi ha quatre tipus de components d'una aplicació. Cada tipus s'utilitza per a un propòsit

diferent i té un cicle de vida diferent

Aquests tipus són:

Activitats (activity): Una activitat representa una pantalla de l'aplicació, on es proveeix

una interfície d'usuari per interactuar amb la mateixa. Típicament, cada aplicació té

una activitat principal que representa la primera pantalla que veu l'usuari en ser

iniciada des de la llista d'aplicacions disponibles. A partir d'aquest moment, és possible

passar a la següent pantalla (d'existir) cridant a una nova activitat.

Cada activitat té associada una vista. La vista constitueix el conjunt d'elements o

interfície gràfica que es presenten a l'usuari perquè interaccioni amb el sistema. Per

exemple, caixes d'edició, etiquetes o botons, entre d'altres. Per crear activitats

personalitzades és necessari definir una classe que hereti de la classe base Activity.

Tot i que una aplicació tingui una activitat principal, cadascuna d'aquestes és

independent de les altres, donant la possibilitat a una aplicació diferent d'iniciar

qualsevol activitat que no sigui, necessàriament, la principal (sempre que es tingui

l'autorització apropiada), per exemple una aplicació de correu electrònic.

Serveis (service): Un servei és un component d’execució que es desenvolupa en segon

pla sense oferir cap interfície amb l'usuari. Qualsevol component amb els permisos

adequats pot iniciar un servei o associar-se a un en execució per interactuar amb ell.

Si un component inicia un servei que ja es troba en execució, no es crea una nova

instància sinó que s'interactua amb la ja existent. L'ús més freqüent dels serveis és per

realitzar tasques que demanin una gran quantitat de temps (i no requereixin interacció

amb l'usuari); però, també poden ser utilitzats per tal de treballar conjuntament amb

processos remots. Per exemple, un servei podrà reproduir música o descarregar un

arxiu a través d'internet sense impedir que l'usuari segueixi utilitzant el seu telèfon

mòbil normalment (hi han dos tipus de serveis started i bounded)



Content Providers: És un component dissenyat per compartir informació entre

aplicacions. Aquesta informació pot estar guardada, per exemple, en bases de dades

SQLite, en una web o en qualsevol altre mitjà d'emmagatzematge persistent que

estigui disponible. D'aquesta manera un content provider actua com una interfície

entre les dades persistens i la resta de les aplicacions perquè, aquestes últimes, puguin

tant accedir com també modificar-se.

Broadcast Receivers: És un component el qual l’objetiu es rebre missatges, anuncis, els

quals són generats per el sistema o una altra aplicació, i disparar accions a partir dels

mateixos. Aquests missatges, anomenats broadcasts, es transmeten al llarg de tot el

sistema i són els broadcast receivers els encarregats de rebre i comunicar-ho a

l’aplicació a la qual pertanyen.

Tres dels quatre components descrits anteriorment (activitats, serveis i broadcast receivers)

són activitats que es comuniquen entre elles mitjançant un missatge asíncron anomenat

intent. Aquests missatges fan que diferents components individuals, perteneixents tant a una

mateixa aplicació com aplicacions diferents, es relacionin entre sí en temps d’execució.

Existeixen principalment dos maneres d’utilitzar un intent: com un broadcast o com un

missatge per interactuar amb activitats i serveis (Figura 2.2).

Figura 2.2 - Exemple de la interacció entre els components descrits anteriorment



2-1 Estructura a nivell de xarxa Android

Android utilitza biblioteques centrals per executar els serveis de xarxa; les biblioteques

centrals també utilitzen interfícies de programació d’aplicacions (API) que es desenvolupen

utilizant el llenguatge de programació Java (SDK de Android). L’API responsable de la gestió

inalàmbrica és la WifiManager i s’executa en el seu propi procés d’instància de la DVM.

El SDK d’Android ofereix un conjunt d’aplicacions per l’accés de dades sobre les xarxes Wi-Fi,

tals com intensitat del senyal, descobriment dels punts d’accés i l’execució de processos

vinculats al punt d’accés. Per permetre la conexió Wi-Fi gratuïta, hi ha certa informació

requerida que s’ha d’aquirir mitjançant la creació d’un permís explícit utilitzant l’arxiu

AndroidManifest.xml

Exemple de permisos de xarxa que es poden agregar als aplicatius Android fent servir el

AndroidManifest.xml (Figura 2.3)

1) CHANGE_WIFI_STATE: S’utilitza per autoritzar, establir o desactivar la Wi-Fi.

2) ACCESS_NETWORK_STATE: S’utilitza per donar permisos a l’aplicatiu per conectar-se a

internet.

3) ACCESS_WIFI_STATE: S’utilitza per sol·licitar qualsevol informació del servei de Wi -Fi.

Figura 2.3 - Exemple de configuració de androidManifest.xml



3. ESTRUCTURA I FUNCIONAMENT DEL PROJECTE

Pel funcionament del projecte, es va dissenyar incialment l’aplicatiu Android on l’usuari

obligatoriament haurà de crear-se un compte d’usuari per poder loguejar-se mitjançant el DNI

i contrasenya i poder utilizar les funcionalitats de l’aplicatiu, aquestes dades del compte

introduïdes per l’usuari seran administrades per un aplicatiu extern (Api rest) i les dades seran

emmagatzemades en un servidor de Sql. Altres funcionalitats que tindrà l’usuari desprès de

loguejar-se són: l’administració de les dades del seu compte (modificació (foto de perfil, nom,

email etc..) o baixa (s’eliminaran totes les dades enregistrades del compte) a més de la

funcionalitat de comparació de firmes, que es detallarà en apartats posteriors.

Per seguritzar la transmissió de dades, totes les dades que viatjaran entre (’aplicatiu – api rest

– servidor, servidor-api rest-aplicatiu) seran codificades en base 64 per evitar que si aquestes

dades són interceptades per algun atacant mitjançant algun programa d’anàlisi de xarxes com

el wireshark o altres (atac midle-man), aquestes dades no siguin fàcilment compreses per

aquest.

Cal dir que en el moment d’enregistrar la contrasenya de l’usuari en la base de dades , aquesta

serà codificada en Sha256 en el registre del servidor Sql, igual que en el moment que l’usuari

introdueixi la credencial de la contrasenya, aquesta serà codificada en Sha256 i comparada

amb els registres en el servidor de base de dades de Sql per permetre l’accés a les

funcionalitats o no.

L’aplicatiu Android enviarà les peticions a l’Api rest utilitzant el protocol HTTP i el mètode

POST. Es va utilizar aquest mètode “POST” d’enviament en lloc del “GET”, ja que, el mètode

“GET” envia les dades introduïdes per l’usuari en la mateixa Url quan es genera la petició, amb

aquest fet es perd seguretat, perquè, un atacant podria interceptar la petició i tenir

coneixement de quines dades ha enviat l’usuari, en canvi utilitzant el mètode “POST” les dades

introduïdes són enviades en el mateix cos de la petició amb la qual cosa dificulta la

interceptació d’aquestes.

A continuació l’Api rest interceptarà la petició realitzada per l’usuari mitjantçant l’aplicació

Android conjuntament amb les dades introduïdes per aquest i depenent de la petició

realitzada, l’Api rest enviarà la petició d’execució amb les dades introduïdes per l’usuari per

executar el stored corresponent el qual que está emmagatzemat en el servidor de base de

dades de Sql server.



A continuació el servidor Sql server executarà els storeds amb les dades introduïdes per

l’usuari provinents de l’Api rest i retornarà la resposta a l’Api rest (poden ser dades o valor

numèrics de comprovació).

A continuació l’Api rest codificarà aquestes dades rebudes pel servidor Sql i les transformarà

en un array en format json, aquesta array json serà enviada a l’aplicatiu Android i serà

codificada per obtenir les dades o les respostes enviades per l’Api rest i provinents de

l’execució dels diferents storeds en el servidor de base de dades de Sql (Figura3.1).

Figura 3.1 - En la imatge es pot veure un esquema del funcionament del sistema implementat

Després de realitzar una explicació global del funcionament del sistema, a continuació es farà

una explicació més detallada de les funcionalitats i característiques de cada component.

3.1 Aplicatiu Android

A continuació es mostre les diferents interficies gràfiques de l’aplicatiu i la interacció que

tindran amb la resta (Figura 3.1.1).

Figura 3.1.1 - Esquema de les diferents interficies gràfiques que composen l’aplicatiu Android



A continuació s’exposaran les funcionalitats de les diferents interficies per número com es pot

visuatlitzar en la figura 3.1.1

Pantalla número 1 (pantalla d’inici) (figura 3.1.2)

figura 3.1.2 - Pantalla d’inici

És la pantalla amb la qual l’aplicatiu s’iniciarà, mostrant la presentació del projecte,

sel·leccionant el botó entrar, l’usuari accedirà a la pantalla número 2 on podrà donar d’alta la

seva compte d’usuari o loguejar-se amb un compte ja creat. (dni/contrasenya) (figura 3.1.2)

Pantalla número 2 Menú usuari (figura 3.1.3)

figura 3.1.3 Menú usuari

A l’accedir aquesta interfície provinent de la pantalla número 1, l’usuari podrà accedir a la

interfície 3 per donar d’alta el compte d’usuari (seleccionant el botó alta usuari) o loguejar-se

si l’usuari ja posseix un compte creat (sel·leccionant el botó login) accedint a la interfície

gràfica número 4 (login).



Pantalla número 3 Alta compte usuari (figura 3.1.4)

Algunes de les validacions que realitza la interfície número 3.

Inicialment camps buits DNI incorrecte union longitud >20

figura 3.1.4 - Interfície alta compte usuari

Al seleccionar el botó donar d’alta de la interfície número 2, l’aplicatiu farà accedir a l’usuari a

l’interfície número 3 on podrà donar d’alta el seu compte d’usuari insertant una imatge (al

seleccionar el botó fer foto, s’obrirà una activitat amb la qual l’usuari podrà realitzar la foto del

seu compte de perfil (previsulitzant-la en la mateixa interfície)) a continuació l’usuari haurà

d’introduïr les seves dades (nom , cognoms , DNI , contrasenya i email).

La pròpia interfície conté controls com es mostren en les diferents imatges anteriors, on en el

moment de donar d’alta a l’usuari (prement el botó donar alta usuari) es faran unes

validacions prèvies d’aquestes dades.

Si es produeix un error en la connexió o per l’entrada no vàlida de dades, l ‘aplicatiu farà

vibrar el telèfon i mostrarà el missatge d’error corresponent avisant a l’usuari com en els casos

següents:

No es permetrà camps buits.

El format del DNI ha de ser correcte (s’ha implementat una funció perquè faci aquesta

validació)

No es permetrà que les dades introduïdes continguin la cadena union (la raó es que

s’evita que hi puguin haver atacs de sql injection a través de les diferents dades que

s’introdueixen en la interfície i s’utilitzant per donar d’alta el compte d’usuari).



Si el DNI ja ha sigut introduït en la base de dades en un compte d’usuari, es mostrarà

un missatge d’avís informant que l’usuari ja existeix (es realitza aquesta acció, perquè

el login serà a través del DNI i aquest ha de ser únic en la base de dades).

Si la logintud de qualsevol de les dades introduïdes per l’usuari a través de l’interficie

és superior a 20 caràcters, es consideraran dades no vàlides i l’aplicatiu mostrarà el

missatge d’error (aquesta validació es realitza per evitar atacs de Sql injection, ja que,

les dades que s’han d’introduïr, no poden ser superiors aquesta longitud).

Una dada important, és que les dades que s’enviaran a l’Api rest per fer la inserció

(imatge,nom,congom….etc) estaran codificades en base64 per augmentar la seguretat

d’aquestes i la contrasenya serà codificada en SHA256 i enviada a l’Api rest que a continuació

cridarà el stored corresponent i insertarà les dades en el servidor de base de dades.

Amb el botó neteja es podran netejar les dades introduïdes per l’usuari i també es podrà

retornar a l’interfície número 2 mitjançant el botó enrere.

Pantalla número 4 (login) (figura 3.1.5)

Inicialment credencials incorrectes cadena amb union camps en blanc caràcters >20

figura 3.1.5 - Interfície login

Al sel·leccionar el botó login de la interfície número 2, l’aplicatiu farà accedir a l’usuari a

l’interfície número 4 on podrà loguejar-se en l’aplicatiu mitjançant el DNI i contrasenya.



Els camps han d’estar introduïts obligatòriament, si aquest fet no es produeix, l’aplicatiu farà

vibrar el telèfon mòbil mostrant el missatge “cap dels camps pot estar buit” , altres accions

que pot validar l’aplicatiu és el fet que l’usuari introdueixi cadenes union o superior a 20 en

qualsevol de les dues entrades per loguejar l’usuari, l’aplicatiu mostrarà els missatges “cap del

camps pot contenir la cadena union “ o “cap dels camps pot tenir una longitud superior a 20”

respectivament segons els cas (com es mostren en les imatges)

Amb el botó enrere s’accedirà a la interfície número 2 i amb el botó netejar es tindrà la

capacitat de netejar els camps introduïts per l’usuari.

Pantalla número 5 Administrar compte usuari / Anàlisi firma (figura 3.1.6)

figura 3.1.6 -Interfície administrar compte usuari / Anàlisi firma

A l’introduir l’usuari les credencials, aquest accedirà a la interfície gràfica número 5 on tindrà

dues opcions: modificar les dades del compte al sel·leccionar el botó “administrar compte” o

realitzar l’anàlisi de firmes al sel.leccionar el botó “comparar firmes” , per últim al sel·leccionar

el botó menú Login, es retornarà a l’interfície número 4.

Pantalla número 6 Interfície administrar compte usuari (figura 3.1.7)

figura 3.1.7 Interfície administrar compte usuari

Al seleccionar el botó “administrar compte” de la interfície número 5, l’aplicatiu farà accedir a

l’usuari a l’interfície número 6 on podrà sel·leccionar les opcions “modificar compte” per



accedir a l’interfície número 7 o sel·leccionant el botó “baixa compte” per accedir a l’interfície

gràfica número 8 on l’usuari podrá donar de baixa el compte d’usuari. Seleccionant el botó

“enrera” l’aplicatiu farà accedir a l’usuari a l’interfície gràfica número 5.

Pantalla número 7 Modificar compte usuari (figura 3.1.8)

figura 3.1.8 - Interfície Modificar compte usuari

Al sel·leccionar el botó “administrar compte” de la interfície 6, l’aplicatiu farà accedir a l’usuari

a l’interfície número 7 on inicialment es carregaran les dades del compte d’usuari com: nom,

cognom, Email i imatge i l’usuari al seleccionar el botó “modificar compte”, podrà actualitzar

les dades introduïdes en l’interfície.

Les validacions en l’entrada de dades seguiran la línia que les interfícies anteriors en les quals

no es permetrà valors buits en cap dels camps, cadenes que continguin la cadena “union” i les

dades introduïdes amb una logintud superior a 20 caràcters (mostrant els missatge d’errors

corresponent i fent vibrar el telèfon mòvil).

El botó “enrera”, farà accedir a l’usuari a la interfície número 6 (hagi actualitzat les dades o no)

i amb el botó “neteja” es netejaran les dades de l’interfície.

Totes les dades seran codificades en base64 en el moment de ser enviades a l’Api rest que

posteriorment seran actualitzades en el servidor de base de dades.



Pantalla número 8 Eliminar compte (figura 3.1.9)

figura 3.1.9 - Interfície eliminar compte usuari

Al sel·leccionar el botó “baixa compte” de la interfície 6, l’aplicatiu farà accedir a l’usuari a

l’interfície 8 on l’usuari tindrà la capacitat d’esborrar el compte (figura 3.1.10).

figura 3.1.10 - Missatge de confirmació eliminació compte usuari

Quan l’usuari seleccioni el botó (central), apareixerà un popup de confirmació perquè l’usuari

estigui totalment segur que vol eliminar les seves dades i compte en el servidor de base de

dades a través de l’aplicatiu.

Si acepta, s’enviarà la petició a l’Api rest i posterioment l’Api rest al servidor de base de dades

perquè a través de l’id de l’usuari codificat en base64 en la transimissió de dades, aquest

seleccioni l’usuari que ha d’eliminar en el servidor de base de dades.

A continuació a l’eliminar-se el compte, l’aplicatiu enviarà a l’usuari a l’interfície 2, on podrà

tornar a sel·leccionar l’opció de crear un compte d’usuari nou o si en té més d’un tornar-se a

loguejar (sene comptar amb l’eliminada anteriorment)

Si es sel·lecciona el boto “enrera” l’aplicatiu farà accedir a l’usuari a l’interfície número 6



Pantalla número 9 Foto a signatura del document (figura 3.1.11)

figura 3.1.11 - Interfície Foto a signatura del document i activitat per extreure imatge

Al sel·leccionar el botó “comparar firmes” de la interfície 5, l’aplicatiu farà accedir a l’usuari a

l’interfície 9 on l’usuari tindrà la capacitat de realitzar l’imatge de la firma en el document.

En el moment que l’usuari sel·leccioni el botó fer foto, s’activarà la càmara i l’usuari podrà

realitzar l’imatge de la firma la qual quedarà guardarda en la interfície.

A continuació sel·leccionant el botó “extreure firma” la imatge serà codificada en base64 i

l’aplicatiu farà que l’usuari accedeixi a l’interfície 10, on podrà realitzar l’extracció de la firma

mitjançant la pantalla del dispositiu mòbil.

Al seleccionar el botó enrera l’aplicatiu farà accedir a l’usuari a l’interfície 5.

Pantalla número 10 signatura realitzada a en el dispositiu mòbil (figura 3.1.12)

figura 3.1.12- Interfície signatura realitzada a en el dispositiu móvil i activitat firma

Al sel·leccionar el botó “extreure firma” de la interfície 9, l’aplicatiu farà accedir a l’usuari a

l’interfície 10 on l’usuari tindrà la capacitat de realitzar la firma en la pantalla del dispositiu

mòbil.



En el moment que l’usuari sel.leccioni el botó “fer foto”, s’activarà una activitat on l’usuari

podrá realitzar la firma a la pantalla del dispositiu mòvil, tindra la possibilitat d’anular la

funcionalitat amb el botó “cancelar”, també l’usuari podrà esborrar la firma realitzada

utilitzant el botó de “borrar”, i tan bon punt l’usuari doni per vàlida la firma realitzada , amb la

sel·lecció del botó “guardar”, s’extraurà l’imatge de la firma i quedarà enregistrada en el visor

de interfície 10 (actual) .

Cal saber, que en el moment de realitzar la firma l’aplicatiu està dissenyat perquè l’usuari la

realitzi de manera hortizontal.

Al sel·leccionar el botó “comparar” es codificaran les dues imatges, la primera obtinguda de

l’interfície 8 (firma del document) i la segona realitzada en la pantalla (interfície actual) a més

dels privilegis de l’usuari que s’han enviat i codificat en base64 des de que l’usuari ha sigut

loguejat correctament en l’aplicatiu.

Al sel·leccionar el botó “enrera”, farà que l’usuari viatgi a l’interficie 9.

Pantalla número 11 Comparació de signatures (figura 3.1.13)

figura 3.1.13 Interfície comparació de signatures

Al sel.leccionar el botó “comparar” de la interfície 10, l’aplicatiu farà accedir a l’usuari a

l’interfície 11 on l’usuari tindrà la capacitat de realitzar la comparació de les dues firmes, al

sel·leccionar el botó “comparar” s’aplicarà la validació de la firma amb l’algorisme que

s’exposarà amb més detall en l’apartat de proves.

En aquesta interfície, es rebran les dues imatges codificades en base64 obtingudes de les

interfícies 9 (firma des del document) i 10 (firma de la pantalla) (incialment aquestes dues

imatges serán mostrades en l’interfície) a més dels privilegis de l’usuari.



Al sel·leccionar el botó “comparar”, es realitzarà l’anàlisi amb l’algorisme i el resultat serà un

valor numèric que será enviat i codificat a base64 conjuntament amb els privilegis de l’ usuari a

l’interfície 12 .

Al sel·leccionar “enrera” s’accedirà a l’interfície 10 amb les dos imatges a comparar.

Pantalla número 12 Resultats (investigador/normal) (figura 3.1.14)

Usuari investigador Usuari normal

figura 3.1.14 - Interfícies resultats (investigador/normal)

Durant l’explicació de les anteriors interfícies (5,9,10,11,12), s’ha fet referència que entre elles

intercanviaven els privilegis de l’usuari (és un camp de la taula usuari, que per defecte en el

moment de crear-se el compte, agafarà per defecte el valor de “normal” (fa referència a un

usuari amb privilegis no investigador) a més d’altres dades

Els privilegis dels usuaris poden ser de dos tipus (normal per defecte o investigador) .

Usuari amb privilegis d’investigador:

figura 3.1.15 - Interfícies resultats (negatiu/positiu)

En el moment d’accedir a l’interfície 12 amb els privilegis d’investigador, l’aplicatiu mostrarà

les dues imatges amb els punt d’interés entre la firma extreta de la pantalla del dipositiu mòbil



i la imatge realitzada de la firma des del document, en l’últim visor es mostraran les dues

imatges analitzades en una mateixa imatge amb els punts d’interés que han fet match

(aplicant l’algorisme que s’exposarà en el següent punt amb més detall) a més de mostrar un

missatge amb el resultat obtingut.

Usuari amb privilegis normal:

figura 3.1.16 - Interfícies resultats (normal)

En el moment d’accedir a l’interfície 12 amb els privilegis “normal”, l’aplicatiu mostrarà una

imatge amb un X vermella amb el misatge “Les firmes no són iguals”, si el dignosi és que la

persona que ha realitzat la firma en la pantalla del dispositiu mòbil i l’extreta de l’imatge des

del document no són la mateixa persona. L’aplicatiu mostrarà una V verda si el dignosi és que

són la mateixa persona.

En qualsevol dels privilegis que l’usuari accedeixi aquesta interfície, al seleccionar el botó

“enrera” l’usuari retornarà a l’interfície número 5 per iniciar el procés d’extracció de firmes de

nou (pantalla/foto) o administrar el compte d’usuari.



3.2 Api rest

El concepte del terme REST, es refereix originalment a un conjunt de principis d’arquitectura

que en l’actualitat és utilitzada en el sentit més ampli per descriure qualsevol interfície entre

sistemes que utilizi directament HTTP per obtenir dades o indicar l’execució d’operacions

sobre les dades, en qualsevol format (XML, JSON, etc) sense les abstraccions addicionals dels

protocols basats en patrons d’intercanvi de missatges, como per exemple SOAP.

Es possible dissenyar sistemes de serveis web d’acord amb l’estil d’arquitectura REST de

Fielding i també és possible dissenyar interfícies XML-HTTP d’ acord amb l’estil de trucada a

procediment remot (RPC), però sense utilitzar SOAP.

Aquest tipus de sistemes que segueixen els principis REST s’anomenen amb freqüència

RESTful.

REST afirma que la web té escalabilidad com ha resultat d’una sèrie de disenys fonamentals

que són el següents:

Un protocol client/servidor sense estat: cada missatge HTTP conté tota la informació

necessària per comprendre la petició. Com ha resultat, ni el client ni el servidor necessiten

recordar cap estat de les comunicacions entre missatges. Encara que, en la pràctica, moltes

aplicacions basades en HTTP utilitzen cookies i altres mecanismes per mantenir l’estat de la

sessió (algunes d’aquestes pràctiques, com la reescriptura de URLs, les quals no són permeses

per REST)

Un conjunt d’operacions ben definides que s’apliquen a tots els recursos d’ informació: HTTP

en sí defineix un conjunt petit d’operacions, les més importants són “POST”, “GET”, “PUT” i

“DELETE”.

S’utilitza una sintaxis universal per identificar els recursos. En un sistema REST, cada recurs es

direccionable únicament a través del seu URI.

L’utilització de hipervincles, tant per l’informació de l’aplicació com per les transicions d’estat

de l’aplicació fa que la representació dels estats en un sistema REST siguin típicament HTML o

XML.

Como resultat d’això, és possible navegar d’un recurs REST a molts altres, simplement seguint

enllaços sense requerir l’uilització de registres o una altre infraestructura addicional.



Utilitzant aquesta infrastructura (Api rest) es va implementar lo que s’anomena MVC model-

vista-controlador.

La vista seria el propi dispositiu mòbil (les interfícies gràfiques) que seria el que rep les dades

provinents de l’Api rest i que anteriorment han estat demanades per aquest últim al servidor

de base de dades mitjançant storeds procedures conjuntament amb l’utilització i la creació de

dos models datos i datosmanager a més de la classe controller que faria la funció de

controlador.

L’Api rest espera les diferents peticions http realitzades. Utilitzant la classe ApiAreaRegistration

on es defineixen les diferents urls que es criden per realitzar les accions passant-li al

controlador i el mètode que cridarà aquest .

Exemple visual Alta usuari (aplicatiu-Api rest-servidor base de dades) .

En la l’interfície número 3 de l’aplicatiu Android, en el moment de sel.leccionar el botó “alta

usuari” i quan les dades introduïdes per l’usuari passin les validacions a les quals s’han fet

referència en l’apartat anterior d’aquest punt (3.1 aplicatiu Android). L’aplicatiu com es mostre

en el codi java (imatge de mà dreta i marcat en vermell) realitzarà l’enviament d’aquestes

dades codificades en base64 (per seguretat) mitjançant el mètode post a la url definida

(ip/port/nom) (figura 3.2.1) .

figura 3.2.1 - Exemple visual interfície gràfica (alta usuari) i codi java de l’aplicatiu Android

Mitjançant la clase definida com ApiAreaRegistration (figura 3.2.2) s’han definit les diferents

urls que s’utilitzaran per intercanviar les dades entre els dos aplicatius i el servidor de base de

dades, quan l’usuari realitzi la petició http mitjançant el mètode post a la url (des de l’aplicatiu



Android) , l’Api rest cridarà al controlador i l’acció o mètode a realitzar (com es pot veure en

l’imatge i marcat en vermell).

figura 3.2.2 - Exemple classe Apiregistrarion en l’api rest url utilitzada per donar alta usuari

A continuació s’accedirà al controlador (datoscontroller) que rebrà els paràmetres del cos de la

petició http pel mètode post i s’enviarà al mètode cridat anteriorment en el

apiArearegistration (action = “xxx2”).

Tot seguit es cridarà el model utilizant els paràmetres mitjançant l’objecte DatosManager.

Cridant el mètode corresponent (que en la imatge és datosmanager.xxx67(paràmetres))

passant-li els paràmetres rebuts provinents del cos de la petició http pel mètode post

generada pel dipositiu mòbil, aquesta funció (xxx2) les dades que retorna serán convertides

en un array json que pot ser un valor numèric o un conjunt de dades segons el mètode cridat

(en el cas de l’imatge, retornarà un valor numèric confirmant si s’ha donat d’alta l’usuari o no,

el qual serà enviat al dispositiu mòbil per ser analitzat) (figura 3.2.3)

figura 3.2.3 - Mètode cridat donar alta usuari en el controlador

Es varen definir els dos models mitjançant dues clase la “Datos”, que és l’objecte mitjançant

s’enviant i es reben les dades provinents de la transmisió entre els dos 2 aplicatius i el servidor

de base de dades. (figura 3.2.4)



figura 3.2.4 - Exemple model datos

El segon model implementat és la clase Datosmanager, mitjançant la qual es realitza la

connexió al servidor de base de dades com es veu en la imatge (figura 3.2.5) i els metodes per

obternir les dades del servidor de base de dades

figura 3.2.5 - Exemple visual de la conection string que es declara en el model datosManager

En la imatge es pot veure com en el model es decrlara la connectionstring que s’utilitzara per

realizar la connexió al servidor de base de dades

Finalment s’executarà el mètode que farà la crida al stored, el qual realitzarà la funció

d’insertar les dades per crear el compte d’usuari en el servidor de base de dades amb els

paràmetres (figura 3.2.6).

Figura 3.2.6 - Exemple del mètode implementat per donar d’alta la compte d’usuari

Com es pot observar en la imatge, per millorar en la seguretat en la transmissió de les dades i

les comunicacions entre l’aplicatiu Android , l’Api rest i el servidor de base de dades, s’han

seguritzar aquestes, utilitzant algunes de les tècniques a les quals es faran referència amb més



detall en apartats posteriors aquest, com són les tècniques d’ofuscació, que s’utilitzen per

nombrar dades, mètodes i altres amb noms poc comuns, amb la finalitat que si es produeix un

atac sigui en el codi o en la mateixa transició d’aquestes dades entre els aplicatius, hi hagi un

augment en la dificultat de la comprensió de les funcionalitats i dades per part de l’atacant.

La utilització de stored amb les tècniques d’ofuscació, fa que no s’enviïn les consultes a la base

de dades en clar donant informació a l’atacant del possible funcionament i estructura del

servidor de base de dades, seguritzant aquest servidor i dificultant possibles atacs.

A continuació l’Api rest retornarà la reposta que l’aplicatiu Android haurà d’analitzar (figura

3.2.7) per mostrar els diferents missatges implementats (s’ha creat el compte d’usuari o no)

figura 3.2.7 - Exemple visual analisi resposta de la crida del mètode post de la url en Android

En la imatge es pot veure la continuació del codi java per donar d’alta a l’usauri, on es recupera

la reposta que ha rebut l’aplicatiu Android de l’Api rest provinent del servidor de base de

dades, en aquest cas será un valors numèric (en altres funcionalitats pot ser un conjunt de

dades) (figura 3.2.8).

figura 3.2.8 - Exemple codi java aplicatiu Android analisi reposta mètode post donar alta usuari

Aquesta resposta serà tractada per l’aplicatiu per donar les diferents indicacions a l’usuari (si

s’ha creat el compte o no)



3.3 Servidor base de dades Sql server (Vmware)

Per implementar el servidor de base de dades es va utilitzar un màquina virtual, amb un

Windows server i Sql Server 2012 (figura 3.3.1).

figura 3.3.1 - Exemple Visual servidor de base de dades sql dels stored i taula implementades

En la imatge es pot veure les taules on es guarden les dades i els diferents storeds que cridarà

l’Api rest.

Per a visualitzar l’estructura de la base de dades amb els storeds realitzat, anar a l’Annex 1.



4. RESULTATS DE L’APLICATIU EXTERN I INTRODUCCIÓ A LA LLIBRERIA

OPENCV

Per a realitzar l’algorisme d’anàlisi per diagnosticar que la firma realitzada en el document i la

feta per l’usuari en la pantalla del dispositiu Android són la mateixa persona, es va realitzar

una aplicació externa en llenguatge c++, amb la qual es va poder crear un laboratori de proves

per diagnosticar, quin era el millor algorisme conjuntament amb els paràmetres, que fessin

que el tant per cent d’encert fos molt més elevat.

En aquest laboratori creat, es va incorporar la llibreria opencv (Open Source Computer Vision)

la qual és una llibreria de codi obert dirigida principalment a la visió per computador en temps

real, desenvolupada per la divisió russa Intel en el centre de Nijni Nóvgorod (la llibreria

OpenCV és multiplataforma).

Aquesta es centra principalment, en el processament d'imatges en temps real. Està

optimitzada per ser utilitzada en processadors Intel, perquè si la llibreria detecta que les

llibreries d'Intel IPP (Integrated Performance Primitives) es troben en el sistema, en farà ús

automàticament per tal d'accelerar el rendiment de l'aplicació.

Aquesta llibreria es va incoporar tan al projecte per realitzar al laboratori de probes, com en el

projecte d’Android studio (es pot descarregar la llibreria per dipositius Android en la mateixa

web de opencv)

Els resultats tant en el laboratori com en el projecte Android utilitzant els algorismes, van ser

els mateixos, aquesta acció de crear aquest projecte extern, es va realitzar per poder fer

proves amb rapidesa i poder diagnosticar, quin era el millor algorisme per implementar en

l’aplicatiu desenvolupat per dispositius mòbils Android. A més, perquè els futurs

desenvolupadors que continuin el projecte, no hagin de carregar l’aplicatiu Android cada

vegada en el dispositiu.

Els algorismes que es van utilitzar d’aquesta llibreria anomenada opencv per a realitzar les

proves van ser:



4.1 SIFT (Scale-Invariant Feature Transform)

Amb aquest algorisme els detectors de cantonada com Harris i les rotacions dels objectes són

invariants, és a dir, fins i tot si es gira la imatge, es poden trobar les mateixes cantonades (és

obvi perquè les cantonades també són cantonades quan la imatge està girada també).

Un racó pot no ser una cantonada, si s'escala la imatge. Per exemple, es pot comprovar en

l’imatge de sota (figura 4.1). Un racó en una petita imatge dins d'una petita finestra la qual és

plana quan es redueix la imatge en la mateixa finestra. Amb aquest fet es fa que l’escabilitat

fós un problema.

figura 4.1 - tractament imatge algorisme Sift

Així que , el 2004, D.Lowe, va implementar un nou algorisme per reduïr aquesta casuística

mitjançant l’algorisme SIFT (Scale-invariant feature Transform), amb el qual es va definir les

característiques de les imatges analitzades mitjançant Keypoints invariants en l’escalat, amb

els quals s’obtenen els punts clau per calcular-ne els descriptors.

Hi ha principalment quatre etapes implicades en l'algoritme SIFT. Que s’exposaran a

continuació :

4.1.1 Escala-espai de detecció extrema Partint de la imatge de sota (figura 4.2), és obvi que no es pot utilitzar la mateixa finestra per

detectar punts clau amb diferents escalats. Està bé amb una petita cantonada. Però per

detectar cantonades més grans es necessiten finestres més grans.

Per aquesta raó, s'utilitza el filtrat d'espai escala. En ell, Laplacià de Gauss es troba per a la

imatge amb diferents valors de sigma. Log actua com un detector de bombolla que detecta

taques en diverses mides a causa del canvi en σ. En resum, σ actua com un paràmetre d'escala.

Per exemple, a la imatge superior (imatge 4.1), el nucli gaussià amb σ baixa dóna un alt valor

per a la petita cantonada mentre el nucli Guassia amb una alta σ s'adapta bé per ampliar la

cantonada. Així, es pot trobar els màxims locals en tota l'escala i l'espai que es dóna en una

llistat de valors (x, y, σ) significa que hi ha un punt significatiu potencial en (x, y) en l'escala σ.



No obstant això, aquest registre és una mica costós, per la qual l’algorismes SIFT utilitza la

diferència de gaussianes que és una aproximació de registre. La Diferència de Gauss, s'obté

com la diferència de desenfocament gaussià d'una imatge amb dues σ diferents, que sigui σ i

kσ. Aquest procés es realitza per diferents vuitenes de la imatge en piràmide gaussian com es

representa en la imatge de sota (figura 4.2) :

Figura 4.2 Piràmides gaussianes

Una vegada que es troba aquest dog (diferència gaussiana), les imatges es busquen els

extrems locals sobre l'escala i l'espai. Per exemple, un píxel en una imatge es compara amb els

seus 8 veïns, així com 9 píxels en escala següent i 9 píxels en escales anteriors. Si es tracta d'un

extrem local, és un punt significatiu potencial. Bàsicament vol dir que aquest punt clau està

millor representat en aquesta escala (com es mostra en la figura 4.3)

Figura 4.3 tractament de l’escalat per l’algorisme SIFT

Alguns dels diferents paràmetres, que es poden configurar (SIFT) són:

1) Nombre d'octaves = 4,

2) El nombre de nivells d'escala = 5,

3) Inicial σ = 1,6,

4) K = 2-√



4.1.2 Localització de Keypoints

Una vegada que es troben les ubicacions possibles , és a dir, punts clau, han de ser refinats per

obtenir resultats més precisos. Per a realitzar això s’utilitza l’expansió de Taylor de la sèrie de

l'espai escalat per obtenir la ubicació més exacta dels extrems, si la intensitat en aquest

extrems és menor que un valor llindar es rebutja. Aquest llindar es diu contrastThreshold a

OpenCV (és un paràmetre configurable)

El dog (diferència gaussiana), té major resposta per les vores, de manera que les vores també

han de ser eliminades. Per a això, s'utilitza un concepte similar al detector de cantonada

Harris. Normalment s’utilitza una matriu 2x2 de Hesse (H) , per calcular la curvatura principal.

Amb aquesta acció es té coneixement que la cantonada del detector de Harris per les vores, té

un valor propi i que aquest valor és més gran que’l definit.

Si aquesta relació és més gran que un llindar, anomenat edgeThreshold en OpenCV, aquest

punt significatiu es descarta. Realitzant aquesta acció, s’elimina qualsevol punt clau de baix

contrast i els punts clau de vora, quedant només els punts d'interès més forts.

4.1.3 Orientació

Ara l’orientació s'assigna a cada punt clau per aconseguir invariància en la rotació de la imatge.

Es pren al voltant de l’ubicació del punt significatiu depenent de l'escala, la magnitud i direcció

del gradient amb el qual es calcula en aquesta regió.

Es crea un histograma d'orientació amb 36 contenidors que cobreixen 360 graus. Es pondera

per magnitud del gradient i la finestra circular-gaussiana ponderada amb σ igual a 1,5 vegades

l'escala de punt significatiu. El pic més alt en l'histograma es pren i qualsevol pic per sobre del

80% de la mateixa també es considera per calcular l'orientació. Es creen punts significatius

amb la mateixa ubicació i l'escala, però diferents direccions. Contribuint en l'estabilitat de

l’anàlisi.

4.1.4 Punt clau descriptor

A continuació es crea el descriptor amb el punt clau. Una finestra de 16x16 al voltant del punt

clau es definida. Es divideix en 16 sub-blocs de mida 4x4. Per a cada sub-bloc, es crea l’

histograma d'orientació. Pel qual un total de 128 valors d'ubicació estan disponibles. Es

representa com un vector per crear el descriptor en el punt significatiu. A més d'això, es

prenen diverses mesures per aconseguir robustesa enfront de canvis d'il·luminació, rotació etc.



4.1.5 Matchs dels keypoints

Punts clau entre dues imatges es corresponen amb la identificació dels seus veïns més propers.

No obstant això, en alguns casos, el segon més proper pot estar molt a prop de la primera. Pot

ocórrer a causa del soroll o algunes altres raons. En aquest cas, es pren la relació de més

proper distància a-segon més proper distància. Si és major de 0,8, són rebutjats. Amb aquesta

acció s’eliminen al voltant de 90% de falsos matchs, mentre que només es consideren el 5%

com a correctes.

4.1.6 Proves amb l’algorisme SIFT en el laboratori

Dues imatge idèntiques

Imatge 1 imatge 2

Exemple 1



Exemple 2

Exemple 3



Dues imatges semblants

Imatge 1 Imatge 2

Exemple 1

Exemple 2



Exemple 3

Dues imatges diferents

Imatge 1 Imatge 2

Exemple 1



Exemple 2

Exemple 3



Comparació imatges extretes des de la pantalla del móvil (semblants)

Imatge 1 Imatge 2

Exemple 1

Exemple 2



Totalment diferents

Imatge 1 Imatge 2

Exemple 1

Exemple 2



4.2 SURF (Speeded-Up Robust Features):

És una versió del SIFT però més accelerada . En 2006, tres persones, Badia, H., Tuytelaars, T. i

Van Gool, L, van publicar un altre article, "Surf: accelerar característiques robustes", que va

introduir un nou algoritme anomenat SURF. Com el seu nom indica, és una versió accelerada

de l’algorisme SIFT.

En SIFT, Lowe aproximà La placià de Gauss amb la diferència de Gauss per trobar l'escala-espai.

SURF va una mica més enllà i s'aproxima el registre amb caixes de filtre.

A continuació la figura 4.4 mostra una demostració d'aquesta aproximació. Un gran avantatge

d'aquesta aproximació és que, la convolució amb filtre de caixa es pot calcular fàcilment amb

l'ajuda d'imatges integrals. I pot fer-se en paral·lel per a diferents escales. També el SURF es

basa en el factor determinant de la matriu de Hesse, tant per l'escala i ubicació.

Figura 4.4 - Matriu de Hesse

Per a l'assignació de l'orientació, SURF utilitza respostes en la direcció horitzontal i vertical pels

veïns de mida 6s. També s’apliquen els pesos gaussians. A continuació es representen en un

espai donat com es mostra a la imatge (figura 4.5)

L'orientació dominant, s'estima calculant la suma de totes les respostes dins d'una finestra de

posició amb un angle de 60 graus. L'interessant és que, la resposta es pot trobar utilitzant

imatges integrals molt fàcilment a qualsevol escala. Per a moltes aplicacions, no es requereix la

invariància de rotació, de manera que no hi ha necessitat de trobar aquesta orientació, fent

que s’acceleri el procés.



SURF proporciona una funcionalitat tal anomenat Upright-SURF o O-SURF. Amb el qual es

millora la velocitat i la robustesa fins a + - 15º. OpenCV és calcula mitjançant un flag el qual

es pot configurar amb el valor de 0 si s’ha de calcular l'orientació o un 1 si l'orientació no s’ha

de calcular , depenet de la configuració s’aconsegueix guanyar en velocitat de procés..

figura 4.5 tractament de l’orientació algorisme SURF

Per les característiques descrites de la funció, SURF s’utilitzen respostes en direcció horitzontal

i vertical (de nou, l'ús d'imatges integrals facilita les coses). Es calcula utilitzant els veïns amb

una finestra de mida 20sX20s prenent al voltant del punt clau on S és la mida. Està dividit en

subregions 4x4. Per a cada subregió, les respostes d'ones horitzontals i verticals es representen

com un vector d'aquesta manera, . Aquest quan es

representa com un vector, dóna la característica del descriptor SURF amb un total de 64

dimensions. Aixó fa baixar la dimensió, aconseguint més velocitat de computació, a més de

proporcionar una millora de distinció de les característiques.

Per obtenir més distinció, la descripció del caràcter SURF té una versió estesa amb dimensió

128. Les sumes de i | es calculen per separat per i . De la mateixa

manera, les sumes de i se separen d'acord amb el signe de , duplicant així el

nombre de característiques. No s’afegeix molta complexitat de càlcul. OpenCV suporta el valor

del flag ampliat amb 0 i 1 per 64-dim i 128-dim respectivament (per defecte és 128-dim)

Una altra millora important, és l'ús del senyal de Laplace (es tracta d’una matriu de Hesse) la

qual subjau punts d'interès. Aquesta acció, no afegeix cap cost de computació, ja que, es

calcula durant la detecció. El signe del Laplacià distingeix taques brillants sobre fons foscos de

la situació inversa. En l'etapa d'adaptació, només es comparen les característiques si es tenen



el mateix tipus de contrast (com es mostra en la figura 4.6). Aquesta informació mínima

permet ajustar el més ràpid, sense reduir el rendiment del descriptor ..

Figura 4.6 - tractament punt d’interés que fan match

En resum, SURF afegeix un munt de característiques per millorar la velocitat en cada pas.

L'anàlisi mostra que és 3 vegades més ràpid que SIFT mentre que el rendiment és comparable

a SIFT. SURF és bo en el maneig d'imatges amb distorsió i la rotació, però no és bo en el

maneig de canvi de punt de vista i el canvi d'il·luminació.

4.2.1 Proves amb l’algorisme SURF en el laboratori

Dues imatge identiques

Imatge 1 imatge 2

Exemple 1



Exemple 2

Exemple 3




Imatge 1 Imatge 2

Exemple 1

Exemple 2



Exemple 3


Imatge 1 Imatge 2

Exemple 1



Exemple 2

Exemple 3



Comparació imatges extretes des de la pantalla del movil

Imatge 1 Imatge 2

Exemple 1

Exemple 2



Totalment diferents

Imatge 1 Imatge 2

Exemple 1

Exemple 2



4.3 ORB: (Oriented Fast and Rotated Brief)

Aquest algoritme, va ser creat per Ethan Rublee, Vincent Rabaud, Kurt Konolige i Gary R.

Bradski és una alternativa eficient per SIFT O SURFT el qual es va implementaren l'any 2011.

ORB és bàsicament una fusió de detector punt significatiu FAST i descriptor Breu amb moltes

modificacions per millorar el rendiment. En primer lloc, es més ràpid que els seu antecessor en

trobar punts clau, A més aquest aplica la mesura de contonada de Harris per trobar els millors

N punts entre ells. També utilitzar les piràmides per produir múltiples escales-característiques.

Es calcula la intensitat ponderada baricentre del pegat (patch) amb la cantonada situada al

centre. La direcció del vector d'aquest punt de cantonada en el centroide dóna l'orientació. Per

millorar la invariància en rotació, els moments es calculen amb x i y que han d'estar en una

regió circular de radi r, on r és la mida del pegat (patch).

ORB utilitza descriptors brief. Per a qualsevol conjunt de característiques de proves binàries n

en la posició es defineixen un 2*n vegades en la matriu, S, que conté les coordenades

d'aquests píxels. Després, utilitzant l'orientació del pegat (patch) , , la seva matriu de rotació

es troba i es fa girar a S per obtenir la versió amb la rotació guiada de S. ORB discretitza l'angle

a increments de (12 degrees), i construeix una taula de recerca de patrons brief

precalculats. Sempre que el punt clau d'orientació és consistent a través de punts de vista, el

conjunt correcte de punts s'utilitza per calcular el seu descriptor.

El ser un descriptor brief, té una propietat important i és que cada característica de bits té una

gran variància i una mitjana prop de 0,5. Però una vegada que està orientat al llarg de la

direcció punt clau, perd aquesta propietat a l’estar més distribuïda.

Aquesta alta variància, és un tret característic més discriminatiu, ja que, respon de manera

diferencial a les entrades.

Una altra característica a destacar en l’algorisme ORB, és que executa una recerca exhaustiva

entre totes les possibles proves binàries per trobar els que tenen alta variància i significa que

tenen un valor proper de 0.5, a més de ser correlacionades. El resultat obtingut es diu rBRIEF.

Per a l'adaptació dels descriptors, LSH multi-sonda que millora la LSH tradicional, s'utilitza , per

guanyar en velocitat , aquest fet fa que l’algorisme ORB sigui molt més ràpid que SURF i

seleccioni els descriptor funcionant millor que els seus antecesors (SURF i SIFT). ORB és una

opció excel·lent per dispositius mòbils tant de baixa potència com d’alta en el moment de

tractar la composició panoràmica de les imatges.



4.3.1 Proves amb l’algorisme ORB en el laboratori

Dues imatge identiques

Imatge 1 imatge 2

Exemple 1

Exemple 2



Exemple 3


Imatge 1 Imatge 2

Exemple 1



Exemple 2

Exemple 3




Imatge 1 Imatge 2

Exemple 1

Exemple 2



Exemple 3

Algorisme ORB amb imatges extretes de la pantalla del mòvil

Imatges semblants

Imatge 1 Imatge 2

Exemple 1



Exemple 2

Totalment diferents

Imatge 1 Imatge 2

Exemple 1



Exemple 2

4.3.2 Conclusions amb l’algorisme ORB en el laboratori

Realitzades les proves en el laboratori amb els diferents algorismes (SIFT , SURF, ORB) i el

background estudiat de diferents articles respecte a la temática que es vol resoldre, es va

poder diagnosticar que l’algorisme que donava millor resultat pel reconeixements de firmes

era el ORB, ja que, aquest algorisme trovaba més trets caracteristics correctes respecte els

altres algorismes utilitzats, a més que el cònsum de recursos del dipositiu es redueix

considerablement amb aquest algorisme (cal esmentar que en la documentació s’han mostrat

els milllors resultats de cada algorisme en les diferents situacions).

Per tant, en l’aplicatiu Android es va implementar el mateix algorisme ORB realitzat en les

proves per poder validar la firma del solicitant.



5. ELEMENTS DE SEGURETAT D’ANDROID

La majoria de les mesures de seguretat entre el sistema i les aplicacions deriva dels estàndars

de Linux, el nucli constitueix el nucli principal d'Android. Cap aplicació té els permisos per a

realitzar operacions que puguin alterar el comportament del sistema, com llegir o escriure

arxius o fitxers privats, accés a la xarxa o habilitar maquinari. A continuació es farà referència

alguns dels elements de seguretat que es poden configurar en Android:

5.1 Arxiu AndroidManisfest.xml

Un element de seguretat d'Android és l'arxiu de manifest. El fitxer de manifest està inclòs en el

paquet d'instal·lació d'Android (arxiu .apk), juntament amb el codi de bytes i altres recursos

relacionats. L'arxiu segueix l'estructura XML i proporciona tota la informació necessària a la

plataforma Android per a l'execució de l'aplicació. El fitxer de manifest és important per al

sistema, ja que, és on es defineixen els permisos de cada aplicació. Aquests permisos

funcionen de dues formes, la primera és com l'aplicació interactua amb el sistema mitjançant

l'accés a l'API del sistema i en segon lloc, la forma com el sistema i altres aplicacions

interactuen amb l'aplicació donada.

Per defecte, cada aplicació s'executa en un entorn d'espai aïllat sense cap tipus de permís per

realitzar una acció que pugui afectar el sistema operatiu en sí mateix.

Tota sol·licitud de permisos es realitza durant el moment d'instal·lació, on l'usuari aprova o

rebutja els permisos que sol·licita l'aplicació. Per tant, si l'usuari decideix concedir permís a

l'aplicació, a continuació, els recursos del sistema protegit estaran disponibles per l'aplicació,

en cas contrari l'accés als recursos serà denegat. És aquí on moltes aplicacions malicioses aprofiten per

instal·lar-se al sistema i accedir a la informació del dispositiu o denegar algun servei.

Els paquets d'instal·lació d'Android han de ser signats digitalment pel seu creador, amb una identificació

única per cada aplicació. En el model de seguretat d'Android no cal que el certificat del desenvolupador

estigui signat per un certificat d'autoritat de confiança, per tant les aplicacions són generalment

signades de manera digital amb certificats auto-signats, proporcionant la capacitat de verificar l'origen i

la protecció de la integritat.

Per establir un permís per a una aplicació, cal declarar-ho en el manifest un o més elements <uses-

permission> on s'especifica el tipus de permís que es vol habilitar.



A la classe Android.Manifest.permission s'especifiquen tots els possibles permisos que es poden

concedir a una aplicació: utilització de wi-fi, bluetooth, trucades telefòniques, càmera, internet,

missatges SMS i MMS, vibrador, etc.

En els dispositius mòbils la seguretat juga un paper important, ja que, la descàrrega d'aplicacions

malicioses poden actuar de manera que llegeixin la llista de contactes, esbrinar la posició GPS, enviar

tota aquesta informació per Internet i acabar enviant missatges SMS. La seguretat en Android es

fonamenta en els següents tres pilars:

- Android impedeix que les aplicacions tinguin accés directe al hardware o interfereixin amb

recursos d’altres aplicacions.

- Tota aplicació ha de ser signada amb un certificat digital que identifiqui el seu autor. La

signatura digital també garantitza que el fitxer de l’aplicació no hagi sigut modificat.

- Si es desitja modificar l’aplicació aquesta ha de ser signada de nou, i només podrà fer-ho el

propietari de la clau privada.

5.2 Usuari Linux i accés a arxius

Per protegir l’accés a recursos utilitzats per altres aplicacions, contempla aïllament de

processos, ja que, té un mencanisme de seguretat extensible i permet eliminar parts

innecessàries i potencialment insegures, a més, Android crea un compte d’usuari Linux (user

ID) nou per a cada paquet (APK) instal·lat en el sistema. Aquest usuari és creat quan s’instal·la

l’aplicació i està de manera permanent durant toda la seva vida en el dispositiu.

5.3 L’esquema de permisos en Android

Per protegir certs recursos i característiques especials del hardware, Android defineix un

esquema de permisos. Totes les aplicacions que accedeixin aquests recursos estan obligades a

declarar la seva intenció d’utilizar-los. En cas de que una aplicació intenti accedir a un recurs

del que no ha sol·licitat permís, generarà una excepció de permís i l’aplicació serà

interrompuda immediatament. Quan l’usuari instal·la una aplicació, aquesta podrà examinar la

llista de permisos que sol·licita l’aplicació i decidir si es considera oportú instal·lar-la.

5.4 Mecanisme de seguretat sandbox

Aquest mecanisme és obligatori per a totes les aplicacions, ja que, realitza l’execució com un

procés amb identificadors de grup i usuari particulars. El que es permet amb aquestes

polítiques, és que els accessos puguin ser definits per a cada aplicació depenent dels seus

requeriments i propòsits. Aquests permisos són aprovats per l'usuari en temps d'instal·lació,



mitjançant l'acceptació de l’arxiu android manifest esmentat en aquest mateix punt. Els errors

de corrupció de memòria comprometen la seguretat completa del dispositiu; aquests errors

són minimitzats en Android a causa de que totes les aplicacions i els seus recursos estan en un

espai aïllat, de manera que una corrupció en memòria només permetrà l'execució del codi en

el context de l'aplicació i amb els permisos establerts per aquesta.

5.5 Partició del sistema i mode segur

La partició del sistema conté el nucli de Linux, les llibreries, el temps d'execució, el framework

d'aplicacions i les aplicacions. Aquesta partició és de només lectura. Quan un usuari inicia

l'equip en mode segur, només s'inicia la partició del sistema, de manera que només les

aplicacions bàsiques d'Android estaran disponibles, el que assegura que l'usuari pot iniciar el

seu telèfon amb un ambient lliure d'aplicacions de tercers i per tant, en un mode segur.

5.6 Sistema de xifratge

Des de la versió 3.0 d’Android es proporciona xifrat complet dels fitxers. Totes les dades es

xifran en el kernel utilitzant una clau derivada de la contrasenya de l’usuari per evitar atacs de

força bruta, aquesta es combina amb un salt a l’atzar i un hash al moment de l’encriptació, a

més, aquest xifratge es realitza amb un algoritme AES de 128 bits mitjançant CBC. La màster key

es xifra amb una altre clau AES de 128 bits, per aquesta raó s'utilitza la funció PBKDF2, implementada en

OpenSSL. EL salt es genera a partir d'una seqüència de nombres o contrasenya establerta per l'usuari.

Aquest és un procés irreversible en el qual es xifra per complet el sistema de fitxers, només es pot

revertir en cas de realitzar un esborrat a l'estat de fàbrica, perdent així les dades emmagatzemades.

Quan és necessari accedir a un fitxer determinat aquest es desxifra i es torna a xifrar un cop finalitzada

la seva modificació. El procés es realitza a nivell de bloc del sistema de fitxers. Actualment, el sistema

també permet el xifrat de dispositius d'emmagatzematge extern, un cop realitzat el procés, els fitxers

xifrats només seran accessibles des del mateix dispositiu.

La funcionalitat d’això és proporcionar resistència contra atacs de diccionari, ja que, Android compte

amb regles de complexitat de contrasenyes que es poden configurar a l’administrador del dispositiu i

són executades pel sistema operatiu.

5.7 Protecció per constrasenya

Android es pot configurar perquè sol·liciti una contrasenya d'usuari abans de proporcionar accés al

dispositiu, això facilita la prevenció de l'ús no autoritzat del dispositiu i la contrasenya utilitzada per

l'algorisme de xifrat.



5.8 Administració de dispositius

Android proporciona un API per a l'administració de dispositius que conté funcions a nivell del sistema.

Fent ús d'aquest API es poden configurar funcionalitats com esborrar la informació de forma remota o

restaurar els valors de fàbrica, el que és útil en cas de pèrdua o robatori.

5.9 Millores de seguretat en l’administració de la memoria

Android ha inclós característiques de seguretat que fan difícil aprofitar els problemes comuns de

corrupció de memòria. Algunes d'aquestes característiques són a l’escollir de forma aleatòria les

posicions importants en memòria, reduïnt problemes de desbordaments i evitant l’execució de codi a la

pila i el heap.

5.10 Permisos de "root" en els dispositius

En Android només el nucli i un subconjunt petit d'aplicacions principals s'executen amb permisos de

root. Els permisos de root poden modificar el sistema operatiu, el nucli i qualsevol altra aplicació, a més,

es disposa de llibertat absoluta a les dades d'aplicació. Si un usuari modifica els permisos del dispositiu i

concedeix aquests permisos de root a les aplicacions, aquesta augmenta el risc de seguretat contra

aplicacions malicioses. Android ha permès que els permisos de root es puguin configurar, ja que,

aquesta és una propietat important per als desenvolupadors i per als usuaris que volen permetre la

instal·lació d'un sistema operatiu alternatiu.

5.11 Signatura de les aplicacions

La sol·licitud de signatura del Codi (paquet APK) permet als desenvolupadors identificar l'autor i

responsable de l'aplicació, les aplicacions que intenten instal·lar-se sense ser signades són rebutjades.

Aquesta signatura es fà per mitjà de certificats que són verificats en el moment de la instal·lació.

6. TIPUS D’ATACS ALS DISPOSITIUS ANDROID

Abans de realitzar un anàlisis dels possibles atacs que pot patir un dispositiu Android, es farà una

descripció dels tipus d’aplicacions que poden funcionar en un dispositiu mòbil Android, les quals es

poden dividir en tres categories operatives:

Web : Les aplicacions que funcionen a través d'un navegador web de propòsit general. De vegades

es refereix com WAP o llocs mòbils, aquests són l'equivalent a les aplicacions web mòbils funcionals

que han proliferat en l'última década i ofereixen múltiples opcions. Tot i que els llocs web normals

es poden utilitzar en els navegadors web mòbils, moltes empreses desenvolupen una aplicació web



per a mòbils separada, amb la finalitat d’optimitzar-les com ara la mida de pantalla més petita, la

navegació basada en el contacte i la disponibilitat de GPS.

Native: Aplicacions que operen fora del sistema operatiu del dispositiu mòbil natiu,

compilat per a la plataforma mòbil específica i l'aprofitament dels seus API. Aquests són

descarregats e instal·lats a través d'un mercat d’aplicacions.

Wrapper: Aplicacions que operen mitjançant l'aprofitament de les pàgines web dins del codi natiu

amb l’embolcall de l’aplicació, també es refereix a vegades com "aplicacions de petxina" o bé

"aplicacions híbrides." que apareixen com una aplicació nativa per a l'usuari final, la funcionalitat

basada en la web pot donar lloc a diferents vulnerabilitats que es troben en aplicacions natives

totalment codificades.

A continuació, després d’haver analitzat els tipus d’aplicatius que poden funcionar en un dipositiu

Android, es realitzarà un estudi de les principals amenaces en seguretat que poden patir els

smartphones amb aquest sistema operatiu, els quals es divideixen en tres grups segons la

procedència de l’atac.

1. Atacs des del dispositiu 2. Atacs des de la xarxa 3. Des del centre de dades

6.1 -Atacs des del dispositiu Els dispositius mòbils representen riscos significatius per a la informació corporativa sensible (SCI);

els riscos inclouen tant la pèrdua de dades com posar en perill la seguretat del dispositiu. Els

atacants es poden dirigir al dispositiu utilitzant una varietat de punts d'entrada:

1. Atacs procedents de carpetes, emails o altres aplicacions prerecarregades 2. Atacs procedents de Telèfon /Sms 3. Atacs procedent d’apliacions de tercers (apps) 4. Atacs al Sistema Operatiu

6.1.1 Atacs procedents de carpetes, emails o altres aplicacions Els atacs basats en carpetes poden incloure:

Phishing: Consisteix en l'adquisició d'informació personal, com noms d'usuari,

contrasenyes, i dades de la targeta de crèdit fent-se passar per una entitat de

confiança mitjançant correu electrònic spoofing.

La investigació ha demostrat que els usuaris mòbils tenen tres vegades més

probabilitats que els usuaris d'escriptori enviant informació personal a llocs phishing.



Això és, en part, probablement a causa del baix escalat d’un navegador mòbil on es

mostra només una petita part de les direccions URL a causa del limitat visual de la

pantalla, els quadres de diàleg d'alerta limitats, reducció d’icones de bloqueig segures,

i la renúncia a molts indicadors d'interfície d'usuari, com ara grans icones ressaltants

com: parades d'emergència, barres de direcció, i altres indicadors visuals.

Framing: implica el lliurament d'un lloc web / WAP en un marc flotant, que pot

permetre el contenidor del lloc ser utilitzat per a executar atacs de clickjacking.

Clickjacking: També conegut com la reparació de la interfície d'usuari, el clickjacking

implica enganyar els usuaris en revelar informació confidencial o de prendre el control

del seu dispositiu quan l'usuari fa clic a l’enllaç o botó aparentment innòcua. Aquest

atac pren la forma de codi encastat o seqüències d'ordres que s'executen sense el

coneixement de l'usuari. Clickjacking s'ha explotat en els llocs incloent Facebook per

robar informació o usuaris directes per atacar llocs.

Drive-by-downloading: Android en particular, ha estat vulnerable a aquest atac, on

una visita al lloc web provoca una descàrrega sense el coneixement de l'usuari. La

descàrrega pot ser una aplicació maliciosa, amb la qual de forma automàtica s’instal·li

en el dispositiu. Aquests tipus d’atac tenen éxit quan els dispositius Android permeten

que les aplicacions de "fonts desconegudes" es puguin instal.lar.

L'home-en-el-Mobile (MitMo): Permet als usuaris maliciosos aprofitar el malware

instal·lat en els dispositius mòbils, amb la finalitat d’eludir els sistemes de verificació

de contrasenya, que envien els codis a través de missatges SMS de text els telèfons

dels usuaris per confirmar la identitat.

6.1.2 Atacs basats en telèfon/SMS

Baseband attacks: Els atacs que exploten les vulnerabilitats trobades en un telèfon

GSM / 3GPP processador de banda base, que és el maquinari que envia i rep senyals

de ràdio a la cel·la de les torres.

Smishing: Igual que en el phishing, però utilitza missatges de text de mòbil en lloc del

correu electrònic amb la finalitat de sol·licitar als usuaris a visitar llocs web il·legítims i

introduïr informació com noms d'usuari, contrasenyes i números de targetes de crèdit.



RF Attacks: Bluejacking, atacs NFC i altres RF, són atacs amb la finalitat de trobar

vulnerabilitats en diversos canals de comunicació perifèrics, els quals es fan servir

típicament en les rodalies de dispositius en les comunicacions.

6.1.3 Atacs basats en aplicacions de tercers

Sensitive Data Storage: Es va tenir constància, que aplicacions populars

emmagatzemaven dades mostrejades de forma insegura.

No Encryption/weak encryption: Aplicacions que permeten la transmissió de les

dades xifrades dèbilment, són vulnerables als atacs.

Improper SSL validation: Errors en la capa de connexió segura d'una aplicació (SSL)

de validació, pot permetre vunerabilitats de seguretat de dades.

Config-manipulation: Inclou l'accés no autoritzat a l'administració d’interfícies,

botigues de configuració i recuperació de dades de configuració de text sense xifrar.

Dynamic runtime injection: Permet a un atacant manipular i abusar del temps

d'execució d'una aplicació per eludir els panys de seguretat, controls d'accés, la lògica

de desviació amb parts privilegiades d'una aplicació, i fins i tot robar dades

emmagatzemades a la memòria.

Unintended permissions: Les aplicacions mal configurades a vegades poden obrir la

porta a atacants mitjançant la concessió de permisos no desitjats.

Escalated privileges: Explota un error, defecte de disseny o configuració de supervisió

per tal d’obtenir accés als recursos protegits normalment des d'una aplicació o usuari.

6.1.4 Atacs basats en sistema operatiu

No passcode: Molts usuaris opten per no establir un codi d'accés, o utilitzar un PIN

feble, contrasenya o patró de bloqueig.

iOS jailbreaking: És un terme per a l'eliminació dels mecanismes de seguretat

implementats pel fabricant per tal d'evitar que el codi no autoritzat s'executi al

dispositiu. Una vegada que s'eliminen aquestes restriccions, el dispositiu pot

esdevenir una porta d'entrada pel malware i altres atacs.

Android rooting: Igual que en el jailbreaking, permet que els usuaris d'Android puguin

alterar o reemplaçar les aplicacions i ajustos del sistema i executar aplicacions

especialitzades que requereixen permisos d'administrador. Com al jailbreaking, pot

donar lloc a l'exposició de dades sensibles .



Passwords and data accessible: Dispositius com ara la línia de dispositius, tenen

vulnerabilitats conegudes en els seus mecanismes criptogràfics per emmagatzemar

contrasenyes xifrades i dades. Un atacant amb el coneixement d'aquestes

vulnerabilitats pot desxifrar el dispositiu, deixant al descobert les contrasenyes

d'usuari, claus de xifrat i altres dades privades.

Carrier-loaded software: Programari preinstal·lat en els dispositius poden contenir

errors de seguretat. Recentment, s'han trobat algunes aplicacions pre-carregades en

els telèfons Android per contenir vulnerabilitats en la seguretat, que podrien ser

utilitzades per grabar àudio, robar dades, i fins i tot espiar en trucades.

Zero-day exploits: Aquest atac sovint es produeix quan una vulnerabilitat és

explotada abans que els desenvolupadors de programari són capaços d'emetre un

comunicat per abordar-la.

6.2 Atacs procedents des de la xarxa

Wi-Fi (weak encryption/no encryption): Les sol·licituds que no implementen xifrat

quan s'utilitzen xarxes WI-FI, produeixen un augment en el risc de ser interceptades

per un espionatge maliciós mitjançant un atac a la connexió sense fils. Moltes

aplicacions utilitzen SSL/TLS, que proporciona un cert nivell de protecció; però,

alguns atacs contra SSL/TLS s'ha demostrat que poden exposar les dades critiques

d'usuari per part d’un atacant.

Rogue access points: Consisteix en instal·lar físicament l'accés sense fil no autoritzat,

en un punt que habiliti les parts d'accés a una xarxa segura.

Packet sniffing: Permet a un usuari maliciós, capturar i analitzar el tràfic de xarxa, que

normalment inclou nom d'usuari i la contrasenya de la informació transmesa en text clar.

Man-in-the-Middle (MITM): implica l'espionatge en una xarxa existent

en connexió, realitzant la intercepció de missatges, i la modificació d’aquestes dades.

SLStrip: És una tècnica de man-in-the-middle que explota la debilitat en el SSL / TLS

en els llocs web, en que l'usuari verifica que una connexió HTTPS

està present. L'atac rebaixa de manera invisible les connexions HTTP, sense xifrat, i

és difícil per als usuaris detectar-los en els navegadors mòbils.

Session hijacking: Implica l'explotació d'una clau de sessió per obtenir accés no

autoritzat a la informació de xarxa de l'usuari.



DNS poisoning: L'explotació de DNS de la xarxa es pot utilitzar pels usuaris directes

d'una pàgina web a un altre lloc escollit per l'atacant. En alguns casos els atacs

també poden injectar contingut a través d'aplicacions.

Fake SSL certificates: És una altre tècnica man-in-the-middle que implica l'emissió

de falsos certificats SSL, amb el qual permet a un usuari maliciós interceptar el

trànsit en una suposat segment.

6.3 Atacs procedents des d’un centre de dades (web service o base de dades)

6.3.1 web services

Platform vulnerabilities: Les vulnerabilitats en el sistema operatiu, programari

de servidor, o mòduls d'aplicacions que s'executen en el servidor web poden

ser explotades per un atacant. Aquestes vulnerabilitats poden ser descobertes

mitjançant el control de la comunicació entre un dispositiu mòbil i el servidor

web, amb la finalitat de trobar debilitats en el protocol o l'accés a controls.

Server misconfiguration: Un servidor web mal configurat pot permetre no

autoritzar l’accés als recursos que normalment estan protegits.

Cross-site scripting (XSS): És un atac que consisteix a injectar codi JavaScript

maliciós en una pàgina web. Pàgines que són vulnerables a aquest tipus d’atac

són le que no realitzen cap control de les dades introduïdes per els ususaris a

través de la interfície. Aquest atac és utilitzat sovint per executar codi de forma

automàtica quan un usuari visita una pàgina, prenent el control del navegador

d'un usuari. Un cop establert el control del navegador, l'atacant pot aprofitar

aquest control en una varietat d'atacs, com la injecció de contingut o

propagació de malware.

Cross-site Request Forgery (CSRF): Petició en llocs creuats amb falsificació

per part d’un atacant en la creació d'HTTP (web), mitjançant les sol·licituds

basades en el coneixement de com una aplicació web en particular funciona,

enganyant un usuari o navegador en la presentació d'aquestes sol·licituds. Si

un lloc és vulnerables, l'atac es pot executar mitjantçant transaccions o

enviaments que semblin provenir de l'usuari. CSRF s'utilitza normalment

després que un atacant hagi aconseguit el control d'un usuari durant la sessió,

ja sigui a través de XSS, enginyeria social o altres mètodes.

Weak input validation: Molts dels serveis web confien excessivament en

l'entrada procedent de les aplicacions mòbils proporcionades per l'usuari final.



No obstant això, els atacants poden forçar la seva pròpia comunicació amb el

lloc web o de derivació de controls lògics d'aplicació en la seva totalitat, amb la

conseqüència que es permet prendre avantatge en la validació lògica al

servidor, per realitzar accions no autoritzades

Brute-force attacks : Es tracta d'endevinar les entrades vàlides per a un camp,

sovint utilitzant una alta taxa d'intents i diccionaris de valors possibles. El més

ús comú d'un atac de força bruta és l'autenticació, però també es pot utilitzar

per descobrir altres valors vàlids en una aplicació web.

6.3.2 Base de dades

QL injection: Les interfícies que no validen correctament l'entrada de l'usuari

poden donar lloc a ser vulnerables atacs de SQL injection, fent que la base

de dades s’exposi o es manipulin les dades que haurien d'estar restringides

per part de l'usuari o sol·licitud.

OS command execution: Similar a la injecció de SQL, certs sistemes de bases

de dades proporcionen una mètode per a executar comandaments a nivell

de sistema operatiu. Un atacant pot injectar aquestes comandes en una

consulta, fent que la base de dades per executar aquestes comandes al

servidor, proporcionant a l’atacant privilegis addicionals, fins i tot incloent

l'accés al sistema a nivell d’arrel.

Privilege escalation: Això passa quan un atac aconsegueix guanyar un major

accés. En les bases de dades això pot conduir al robatori de dades sensibles.

abocament de dades , ja que , l’atacant fa que la base de dades bolqui alguns

o totes les dades dins d'una base de dades, exposant registres sensibles.

7. POLÍTIQUES DE CONFIGURACIÓ EN SEGURETAT DEL DISPOSITIU MÒBIL

Buscant protegir de millor manera els dispositius mòbils, s'han de tenir en compte les següents

recomanacions:

1- Utilitzar mètodes de bloqueig en el dispositiu. Existeixen mètodes com

contrasenyes, patrons, bloquejos biomètrics, de reconeixement de veu, entre

d'altres.

2- Realitzar suport periòdic dels elements importants emmagatzemats al dispositiu.

Hi ha eines de backup al núvol (No local) que permeten gestionar i mantenir-los

segurs, per si es requereix alguna recuperació.



3- Aplicar xifrat a la memòria d'emmagatzematge, per fer impossible la còpia de les

dades i per tant l'extracció d'aquestes.

4- Fer servir algun mètode d'esborrat remot, que pot configurar-se a través de

múltiple mètodes. Per mitjà de Google Sync o Google Apps és possible realitzar

aquesta funció. D'aquesta manera si es perd o és robat el dispositiu es pot eliminar

la informació, per evitar la seva divulgació o manipulació.

5- Instal·lar antivirus en els dispositius, això donarà suport no només el tema

d'infeccions, sinó que podrà controlar l'accés no autoritzat al dispositiu, fent a

vegades de tallafocs a més de contenir algunes altres funcionalitats com

capturació de càmera, per si s'intenta desbloquejar el dispositiu de forma errònia

en múltiples ocasions, prendrà una foto per conèixer qui tracta de desbloquejar-lo.

Els antivirus tenen múltiples funcions i a nivell de seguretat és molt important

comptar amb ells.

6- S'ha de tractar d'evitar connexions a xarxes públiques i altres de procedència

dubtosa. Això inclou accés a Wi-Fi però també per mitjà de Bluetooth i infraroig. És

possible que a través d’aquests tipus de connexions, pugui ser robada informació

del dispositiu. Evitar instal·lar aplicacions desconegudes, de fonts no identificades,

fins i tot si provenen de Google Play. La majoria d'elles contenen malware i

elements que infecten el dispositiu, permetent el control remot.

7- Les actualitzacions de les aplicacions i del sistema operatiu són fonamentals per

protegir els dispositius, ja que, majoritàriament porten patchs de seguretat de

bugs (Falles) trobats durant la seva operació i per això sempre s'han d'instal·lar.

8- No connectar els dispositius via USB en equips públics i desconeguts, ja que, també

es poden tenir bretxes de seguretat a realitzar aquesta acció.

9- És important llegir manuals i instruir-se en quant a l'ús del dispositiu i del sistema

operatiu. En moltes ocasions es cometen errors i es deixen d'habilitar funcions de

seguretat per la falta de coneixement.

10- Per evitar la instal·lació de ROMS (Imatges del sistema operatiu) custom o

personalitzats. Aquests en general no tenen els nivells òptims de seguretat i poden

contenir elements maliciosos que poden generar problemes en el dispositiu, així

com el robatori d'informació.



11- Si l’usuari és inexpert en el maneig d'Android, és recomana evitar fer "root" en el

sistema operatiu per obtenir permisos de súper usuari. Moltes aplicacions

malicioses s'aprofiten d'això per fer danys.

12- Permetre control remot. En cas de robatori, és important tenir una aplicació en el

dispositiu móbil que permeti controlar remotament. Aixi, es pot localitzar el

dispositiu, recuperar les seves dades emmagatzemades o borrades perquè no

siguin compromeses. També es pot tenir una aplicació que borri les dades

automàticament després de varis intents d’accessos fallits.

13- Habilitar accés inicial mitjançant codi pin o contrasenya.

8 GUIA DE SEGURETAT PEL DESENVOLUPAMENT D’APLICACIONS

ANDROID

A continuació, es farà referència a les pautes que tenen que seguir els desenvolupadors

d’aplicacions Android, per assegurar la confidencialitat , integritat i privacitat de les dades que

administren aquests tipus de dispositius mòbils.

Les pautes que han de seguir els desenvolupadors d’Android són les següents :

8.1 Augmentar la complexitat del codi i ús d’ofuscació en l’aplicatiu Android

Les aplicacions d'enginyeria inversa poden proporcionar informació valuosa sobre com

funciona l’aplicació. Dissenyar i programar una aplicació més complexa internament, fa que

sigui més difícil pels atacants l’anàlisi del funcionament de l'aplicació, aconseguint reduir el

nombre de vectors d'atac.

En el moment d’implementar l’aplicació en Android s’ha de limitar l’accés a:

1- Restricció del debugger: Una aplicació pot especificar mitjançant una trucada al

sistema específic i evitar que el sistema operatiu permeti al depurador inserir-se en el

procés. Per la prevenció d'un depurador de fixació, la capacitat d'un atacant per

interferir a baix nivell en temps d'execució és limitat. Un atacant primer ha de sortejar

les restriccions de la depuració per tal d’atacar l'aplicació en un nivell baix. Això afegeix

més complexitat a l’atac. Les aplicacions d’Android han de tenir aquest paràmetre

android: depurable = "false" definit en el Androidmanifest.xml, amb la finalitat d’

evitar la manipulació d’execució per un atacant o malware.

2- Comprovació de traça: Una aplicació pot determinar si és o no està sent actualment

traçat per un depurador o una altre eina de depuració. Si està sent rastrejat, l'aplicació



pot realitzar qualsevol nombre d'accions de resposta, com ara, descartar les claus de

xifrat per protegir dades d'usuari, notificar a un administrador del servidor o d'un altre

tipus de respostes en un intent per defensar-se. Això pot ser determinat pel control

dels indicadors d'estat del procés o l'ús d'un altre tècnica com la comparació del valor

de retorn de la traça adjunta. El control de la matriu de procés, depuradors de llistes

negres en la llista de processos o la comparació de les marques de temps en diferents

llocs del programa són algunes de les accions que es poden realitzar.

3- Optimització : Per amagar els càlculs matemàtics avançats i altres tipus de

lògica complexa, utilitzant les optimitzacions del compilador pot ajudar a ofuscar el

codi objecte perquè no pugui ser fàcilment desmuntat per un atacant. Això fa que sigui

més difícil per a un atacant obtenir una comprensió del codi particular. En Android això

es pot aconseguir més fàcilment mitjançant la utilització de les biblioteques de forma

nativa dels compilats amb el NDK. A més, utilitzant una LLVM ofuscador o qualsevol

SDK protector proporcionarà un millor codi màquina ofuscat.

4- Exclusió de binaris natius: És una manera eficaç d'augmentar el temps

i l'habilitat que es requereix d'un atacant per tal de veure l’aplicació implementada i

els nivells de les seves funcions. En eliminar un binari, la taula de símbols del binari es

queda buit amb la finalitat que l’atacant no pugui depurar fàcilment o realitzar

enginyeria inversa d'una aplicació. Excloent els binaris fa que es dificulti l’èxit en la

utilització de tècniques sstriping o UPX de reutilització de codi com es pot realitzar en

sistemes GNU / Linux .

8.2 Evitar lògica simple

Les proves lògiques simples en codi són més susceptibles a l'atac. exemple:

if sessionIsTrusted == 1

Aquestes proves lògiques simples en codi són més susceptibles a l'atac. Si un atacant pot

canviar el valor, permetrà que l’atacant sigui capaç d’eludir els controls de seguretat (Android

té els arxius binaris en Dalvik). Aquestes proves lògiques són fàcils d'eludir en molts nivells. En

Android, l'aplicació es pot descompilar amb Smali i la condició de branca ser modificada avanç

de ser compilada.

Per solucionar aquest fet, s’ha de pensar amb el millor paradigma de programació , on els

privilegis són imposats pel servidor quan la sessió no és de confiança o mitjançant la prevenció

de certes dades que han de ser desxifrades o disponibles d'una altre manera, això es realitza



amb la finalitat que l'aplicació pugui determinar que la sessió és de confiança amb l'ús de

desafiament / resposta, OTP, o altres formes d'autenticació. A més, és recomana declarar totes

les funcions de comprovació de seguretat de línia estàtica. Amb aquest enfocament es

compilen en línia fent més difícil la implementació del patch (és a dir, un atacant no pot

simplement anul·lar una funció o posar patchs en una funció). Aquesta tècnica requereix que

l'atacant es vegi obligat a posar pegats a cada instància de la verificació de l'aplicació, generant

un augment en la complexitat de l’atac. Per a aplicacions altament sensibles, és més sofisticat

enfocaments fundats en principis de codificació segura, poden iniciar una investigació

addicional. La integració de tècniques com ara el xifrat, les devolucions de trucada amb hora i

data de la programació basada en flux i altres tècniques, afegeixen un augment en la

complexitat dels possibles atacs.

8.3 Utilització de biblioteques de tercers

Els desenvolupadors depenen a vegades de biblioteques de tercers. És important fer un test de

proves d’aquestes llibreries mitjançant el codi que s’està desenvolupant o utilitzant altres tipus

d’eines per diagnosticar que aquestes biblioteques implementades per tercers, poden contenir

vulnerabilitats i debilitats que s’han d’evitar. Molts desenvolupadors erròniament assumeixen

que les biblioteques de tercers estan ben desenvolupades i provades, ja que , aquestes poden

generar un gran problema en el funcionament i seguretat en l’aplicatiu.

8.4 Aplicar tècniques de protecció contra manipulacions

Els atacants poden manipular o instal·lar una porta del darrere en una aplicació, tornar a signar

i publicar la versió amb el codi maliciós als mercats d'aplicacions de tercers (no Google Play) .

Aquest tipus d'atacs solen centrar-se en aplicacions populars i aplicacions financeres. Per

solucionar aquesta situació s’ha d’utilitzar tècniques de antisabotatge i detecció de

manipulacions tècniques per prevenir que l’aplicació sigui corrupta. Utilitzar mètodes com

checksum de comprovació, signatures digitals i altres mecanismes de validació per ajudar a

detectar l'arxiu i la seva manipulació, ajuden a diagnosticar aquest tipus d’atacs, ja que, quan

un atacant intenta manipular l'aplicació, el correcte checksum de comprovació no es conserva i

per tant és un mecanisme que serveix per poder detectar i prevenir l’execució. Aquestes

tècniques no són totalment infal·libles i poden ser anul·lades per una hacker amb

coneixements avançats. Quan el cheksum fa la comprovació de la signatura digital

conjuntament amb altres tècniques de validació, produeix un augment en la quantitat de

temps i esforç per part de l’atacant que ha de passar a descodificar amb èxit l'aplicació.



Les aplicacions que s'han detectat amb una manipulació han de ser notificades a

l’administrador d’aquesta. En Android, la clau pública utilitzada per signar una aplicació es pot

llegir en el certificat de l'aplicació i s'utilitza per verificar si l'aplicació va ser signada amb la clau

privada del desenvolupador. Això es pot saber utilitzant la classe PackageManager amb la qual

és possible recuperar les firmes de l’aplicació i comparar-les amb el valor correcte. Si algun

atacant ha manipulat o re-signat l'aplicació, la comparació fallarà donant com a resultat la

detecció de la manipulació indeguda de l’aplicatiu.

8.5 Emmagatzemar de forma segura dades confidencials en la memòria RAM

Quan una aplicació està en ús, l'usuari o les dades específiques de l'aplicació poden ser

emmagatzemats en la memòria RAM i sense eliminar-les correctament quan l'usuari tanca la

sessió o els temps d'espera de la sessió a finalitzat. Les claus de xifrat poden romandre en la

memòria, per tant un atacant que es troba o roba el dispositiu, pot adjuntar un depurador i

bolcar la memòria de l'aplicació o carregar un mòdul del nucli per bolcar tot el contingut de la

RAM.

La gestió de contrasenyes i altres informacions sensibles de les aplicacions poden quedar

emmagatzemades en memòria, fins i tot si la memòria intermitja s'allibera durant algun temps.

Això pot crear un problema, si l'aplicació instal·lada realitza un atac al dispositiu utilitzant la

tècnica de desbordament de memòria intermitja (produint una fuga de dades). Aquest tipus

d’atac dona la capacitat a un atacant de bolcar la memòria del procés i recuperar les dades

sensibles emmagatzemades en la memòria. Les solucions per protegir el dispositiu contra

aquest tipus d’atac són: no mantenir les dades sensibles (per exemple, claus de xifrat) en la

memòria RAM més temps del necessari, anul·lar les variables que posseeixen les claus després

del seu ús, evitar l'ús d'objectes immutables de tecles sensibles o contrasenyes (com ara en

Android java.lang.String) i l'ús de matriu de caràcters al seu lloc. Encara que es referenciés els

objectes immutables, s'eliminin o anul·lin, poden romandre en la memòria fins l’esborrat total

d’aquests (que no pot ser forçat per l'aplicació).

Això es pot fer només pels llenguatges de baix nivell a causa que els compiladors i

màquines virtuals ignoraran aquestes operacions per raons de rendiment.

8.6 Comprovar la correcta eliminació segura de dades

En Android trucant File.delete () no esborra de manera segura l'arxiu de destí, una

arxiu sempre que no es sobreescrigui, pot ser recuperat en una imatge física del dispositiu.



Tradicionalment els enfocaments per esborrar un arxiu generalment no funcionen en els

dispositius mòbils a causa de l'agressiva gestió de la memòria Flash NAND. La solució per

realitzar aquesta acció és operar sota el supòsit que les dades gravades en un dispositiu es

poden recuperar. Alguns casos, el xifrat podria afegir una capa addicional de protecció. A més ,

no es recomana per a la majoria de les aplicacions, la possible eliminació dels arxius i per tant

s’ha de sobreescriure tot l'espai disponible amb un arxiu de grans dimensions (el que obligaria

que NAND tingui que esborrar tot l'espai no assignat). Els inconvenients d'aquesta tècnica

inclouen el desgast Flash NAND, fent que l'aplicació i tot el dispositiu responguin lentament, a

més de que el consum d'energia sigui significatiu. Sempre que sigui possible, s’ha d’evitar

l'emmagatzematge de dades confidencials en el dispositiu i el xifrat de les dades confidencials

emmagatzemades en arxius, s’ha de reescriure el contingut del fitxer i sincronitzar-se abans

d'esborrar-se, però com s'ha descrit anteriorment, no són solucions totalment fiables per

solucionar el problema.

8.7 Evitar la cadena de consulta de les dades sensibles

Una vulnerabilitat important és produeix en l’execució d’una cadena de consulta senzilla

modificada. Els paràmetres de cadena de consulta són més visibles i amb freqüència es poden

emmagatzemar en memòria cau de forma inesperada (historial web, servidor web o un

servidor intermediari de registres, etc.) utilitzant una cadena de consulta. Per aquesta raó

aquest conjunt significatiu de dades s’han de xifrar. Si les credencials es transmeten com a

paràmetres de cadena de consulta (a diferència d'una sol·licitud POST que es realitza en el cos)

llavors aquestes són susceptibles d'estar connectades a diversos llocs.

Per exemple, en l’històrial del navegador de l'usuari, al servidor web, OGS, i dins dels proxies

inversos utilitzats dins de la infraestructura d'allotjament. Si un atacant aconsegueix

comprometre qualsevol d'aquests recursos, llavors pot ser capaç d’escalar privilegis mitjançant

la captura de les credencials d'usuari emmagatzemats allà. Per solucionar aquesta situació,

s’ha de fer l’ús del POST de manera segura i enviar les dades de l'usuari utilitzant tècniques

com XSRF amb protecció de testimoni. Les dades posteriors no són connectades per defecte en

àrees on les dades de cadena de consulta es poden trobar. POST o GET, s'han d'utilitzar

conjuntament amb les galetes de sessió temporals. El xifrat de dades utilitzant un no-zero amb

un vector d'inicialització i claus de sessió temporals, també poden ajudar a prevenir atacs de

reproducció. Les dades de la cadena de consulta poden ser encriptades utilitzant una clau de

sessió negociada temporalment entre els hosts que fan servir algoritmes de seguretat, com ara

Diffie-Hellman.



8.8 Implementar emmagatzematge segur de dades

L'emmagatzematge de dades de forma segura en un dispositiu mòbil requereix una tècnica

adequada. Quan sigui possible, simplement no s’han d’emmagatzemar dades en la memòria

cau (aquesta és la manera més segura d'evitar riscos de dades en el dispositiu). Per tant,

sempre s’han de xifrar les dades de l'usuari, l'objectiu de xifrar utilitzant un clau mestre

generada de forma aleatòria, fa que també es xifrin utilitzant una contrasenya subministrada

per l'usuari cada vegada que les dades son visitades. Això evitarà que les dades siguin

recuperades amb facilitat mitjançant el dispositiu. (no es recomana que la clau principal o una

contrasenya s'emmagatzemi en el dispositiu).

8.9. S’ha d’utilitzar un entorn segur per a les cookies

Si una galeta no està marcada com "segur", pot ser transmesa a través d'una connexió

insegura sigui o no la sessió amb el host segur. En altres paraules, pot ser transmesa a través

d'una connexió HTTP. A més, l'establiment de l'indicador "HttpOnly" en una galeta prevé atacs

com cross-site scripting (XSS), a causa de que la galeta no es pot accedir a través del costat del

client (per exemple, no es pot accedir utilitzant un fragment de codi JavaScript). Per solucionar

aquesta situació, s’ha de posar en les capçaleres Set-Cookie per utilitzar la configuració en

mode "segur" i "HttpOnly". Aquests ajustos s'han d'aplicar a totes les galetes per les

aplicacions natives i / o web.

8.10 Validar totalment SSL / TLS

Moltes aplicacions no validen correctament els certificats SSL / TLS, deixant-los vulnerables a

atacs man-in-the-middle (MITM). Si una aplicació no pot validar correctament la seva

connexió al servidor, l'aplicació és susceptible a un atac MITM per un atacant de xarxa

privilegiada. Aquest tipus d'atac dóna a l’atacant la capacitat de capturar, veure i modificar el

tràfic enviat/rebut entre l'aplicació i el servidor.

Per solucionar aquesta situació, s’ha de fer que per a qualsevol aplicació que fagi servir les

dades altament sensibles, certificar el seu ús per protegir-les contra atacs MITM. La majoria de

les aplicacions estan definides conjuntament amb els llocs als quals s’han de connectar

(servidors de back-end) de manera inherentment i confiant en la infraestructura en la qual es

connecten, per tant, és acceptable (i, sovint més segur) utilitzar una infraestructura de clau

pública/privada, separant-les de les autoritats de certificació públiques. Amb aquest

enfocament, un atacant necessita TH i les claus privades del costat del servidor per dur a terme

un atac MITM contra un dispositiu del qual no es tingui accés físic. Les claus del certificat no



han de ser implementades per qualsevol funcionalitat de l’aplicació, ja que, fa servir les dades

altament sensibles. Per tant, s’ha d’aplicar el certificat adequat realitzant una correcta

validació d’aquests, que consta de dues parts:

1- Validació del certificat: Aquests Certificats han d'estar completament validats per

l'aplicació i estar signats per una autoritat de certificació de confiança.

2- Validació de nom d'amfitrió: L'aplicació ha de comprovar i verificar que el nom

d'amfitrió (Common Nom o CN) extret del certificat, no coincideix amb el del host i la

l’aplicació que té la intenció de comunicar.

La utilització dels certificats a un client HTTP Apache per defecte inclòs en Android, consisteix

en l'obtenció d'un certificat per al host desitjat, transformant el CERT en format .bks, llavors

s’ha de fixar el CERT a una instància de DefaultHttpClient. BKS té un magatzem de claus que

inclouen normalment els actius dins del l'arxiu APK de l'aplicació.

8.11 Protegir contra atacas downgrade SSL

Utilitzant la tècnica man-in-the-middle, un atacant pot evitar SSL / TLS transparent i segrestar

el trànsit HTTP en una xarxa, a més de realitzar un control del seguiment de les sol·licituds

HTTPS, l'eliminació de SSL / TLS crea una connexió no segura entre el client i el servidor.

Aquest atac pot ser particularment difícil de prevenir en aplicacions web mòbils (Aplicacions

web mòbils són essencialment pàgines web fetes per semblar-se a una aplicació). Per

solucionar aquest cas s’ha de ridereccionar tot el trànsit, fins i tot, el trànsit no sensible a

través d'TLS. Això evita qualsevol possible atac de downgrade o d'extracció, ja que, un atacant

necessita un text clar "punt d'entrada" inicial per dur a terme aquest atac. Per tant, s’ha de

validar que SSL / TLS està actiu. La validació de SSL / TLS és relativament senzilla en aplicacions

natives. Les aplicacions web mòbils poden validar SSL / TLS a través de JavaScript de manera

que si una connexió HTTPS no es detecta, el client seà redirigit.

Evitar l'ús d'icones o llenguatge dins de l'aplicació, garanteix que els usuaris d'una connexió

segura no depengui d'una sessió HTTPS validada. La formació d'usuaris és un component

important per reduir el risc d'atacs de downgrade SSL / TLS , a més de la utilització d’ alertes i

textos dins de l'aplicació, reforcen la conscienciació dels usuaris de la importància de protegir

el transit de la xarxa a través de HTTPS.



8.12 Protecció del tractament de dades geològiques

Android pot utilitzar el GPS per determinar amb precisió la ubicació de l’usuari que utilitza

l’aplicatiu. El mal maneig d'aquest GPS de dades és un problema de privacitat i pot fer que

l'usuari vulnerable pateixi algun tipus d’atac si aquestes dades són adquirides per part d’un

atacant coneixent les ubicacions actuals o passades de la victima. La Informació sobre

Bluetooth local i/ o etiquetes NFC / RFID també poden filtrar informació de geolocalització.

A més, les aplicacions amb accés a la galeria d'imatges també poden impedir que els

posicionaments dels GPS emmagatzemin informació en ells (si existeix), mitjançant la

comprovació de les marques de temps i suposant que l'usuari va ser l’autor de la foto,

provocant un problema de privacitat per a l'usuari.

S’ha de pensar en les implicacions d’ús i evitar l'emmagatzematge de dades GPS. Aquesta

mesura permet adquirir una augment en la protecció de l’intimidat de dades sensibles que

utilitzen la majoria dels serveis de localització. Llevat que sigui necessari, no s’han de registrar

o emmagatzemar aquesta informació provinent del GPS. Mentre que pot ser útil l'ús de GPS

per a certes aplicacions, és rarament necessari enregistrar i emmagatzemar aquest tipus de

dades. Evitar això evita vulnerabilitats de privacitat i seguretat.

8.13 Insertar temporització de la sessió local en l’aplicatiu

Els dispositius mòbils són freqüentment robats o perduts, un atacant pot prendre avantatge

d'una sessió activa per accedir a dades sensibles, executar transaccions, o realitzar

reconeixement en els comptes d'usuari d'un dispositiu. A més, sense una sessió apropiada amb

temps d'espera, una aplicació pot ser susceptible a la intercepció de dades a través d'un atac

Man-in-The-Middle. Per protegir l’aplicació, s’ha de fer que quan aquesta no s’utilitza durant

més de 5 minuts, finalitzi la sessió activa, i redirigeixi l'usuari a la pantalla de registre fent que

l’usuari tingui que introduir les credencials d'accés per accedir a l'aplicació de nou.

8.14 Implementar autentificació Enhanced / Two-Factor

L'autenticació feble o inexistent pot concedir a un atacant l'accés no autoritzat a una aplicació.

Per protegir l’aplicació, s’ha de fer que les contrasenyes no siguin simples. La millor manera és

demanar la introducció de contrasenyes complexes i alfanumèriques, dotant-les almenys de sis

caràcters (més caràcters és sempre més forta). Exigir la selecció d'una paraula secreta o icona

com a part del procés d'inici de sessió pot ajudar a protegir els comptes dels usuaris.



Hi han altres tipus d’autentificació a part de la clàssica (nom i contrasenya) que pot dificultar

els atacs com:

1- Paraula secreta addicional / icona.

2- Codi addicional proporcionat per SMS o correu electrònic.

3- Contrasenya més valor addicional conegut per l’ usuari,

4- Preguntes i respostes de seguretat, seleccionades per l'usuari amb antelació (per

exemple, durant el registre).

8.15 Protegir la configuració de l'aplicació

Els desenvolupadors d'Android solen emmagatzemar els ajustaments en un arxiu XML

compartit o preferències com les base de dades de SQLite, les quals estan encriptades per

defecte i poden ser llegides o fins i tot modificades amb permisos de root.

Per solucionar aquest problema, s’ha de compilar els ajustos en el codi quan sigui possible i

xifrar tots els fitxers de configuració mitjançant una connexió clau mestra conjuntament amb

la contrasenya xifrada, la qual ha de ser subministrada per l'usuari o amb una clau

proporcionada de forma remota quan un usuari es registrat en el sistema.

8.16 Amagar números de compte i l’ús de tokens

Moltes aplicacions emmagatzemen números de compte complets en diverses pantalles. per

solucionar-ho, s’ha de donar l'ús generalitzat d'aplicacions mòbils en llocs públics, on es

presenten els números parcials, això pot ajudar a garantir la màxima privacitat per obtenir

aquesta informació (Llevat que hi hagi una necessitat d'emmagatzemar el nombre complet en

el dispositiu, ja que, s’han de guardar els números parcialment ocults).

Sovint, els números de compte s'utilitzen per fer referència a les dades del compte al servidor;

Aquestes dades poden ser fàcilment robades de la memòria, o en alguns casos manipulades

per treballar amb els comptes que l'usuari no ha de tenir permís d'accés. Es recomana que en

lloc de números de compte, s’utilitzin tokens que poden assignar-se a cada compte i

proporcionar al client més seguretat.

Aquests tokens, que no han de ser deduïbles per l'usuari, han de ser mapatjats en el servidor

per a una compte real. En cas de ser robades les dades de l’aplicació, els números de compte

de l'usuari no seran exposats, per tant, un atacant tampoc serà capaç de fer referència als

números de compte directament, sinó que ha de determinar en primer lloc el símbol que

s'assigna al compte.



8.17 Validar els valors de dades entrats pels usuaris

Els aplicatius generen dades que són emmagatzemades, això fa possible que aquestes dades

hagin estat interceptades i manipulades per atacants, aquest fet és la causa del tancament de

l'aplicació (generen un registre de clau de bloqueig), desbordaments de memòria intermitja,

injecció SQL, i altres atacs. Per aquesta raó, igual que amb la seguretat d'aplicacions web, tota

entrada des del client ha de ser tractada com a no fiable i per tant validar que el contingut

d’aquestes dades siguin el desitjats. Per aquesta raó els serveis han de filtrar a fons i validar

l'entrada de l'aplicació, a més de realitzar una desinfecció adequada de les dades introduïdes

per l'usuari abans de transmetre-les durant la recepció d’aquestes.

8.18 Evitar l'emmagatzematge de dades en l'aplicació de còpies de seguretat

La realització d'una còpia de seguretat de les dades en un dispositiu Android és potencialment

perillós, ja que, aquestes còpies de seguretat emmagatzemen informació sensible dins el

directori privat d'una aplicació. Per solucionar això, el programadors han de posar per defecte

el paràmetre allowBackup dins del fitxer del manifest (AndroidManisfest.xml) amb el valor de

false, ja que, si aquest atribut no té aquest valor, el sistema operatiu Android genera un fitxer

de còpia de seguretat (backup.ab) el qual inclou tots els subdirectoris i arxius continguts dins

el directori privat d'una aplicació en el sistema de fitxers del dispositiu.

8.19 Evitar tenir els registres logs habilitats en l’aplicatiu

Hi ha diversos frameworks de seguiment de funcionament de l’aplicatiu Android per part de

l'usuari, el quals recullen els registres de fallades d’Android, aquestes eines són molt útils per

al desenvolupament, però és important trobar un balanç entre mostrar suficient informació de

depuració per als desenvolupadors i la informació per a la reducció de possibles atacs. Si una

aplicació es bloqueja, el registre resultant pot proporcionar una valuosa informació a un

atacant. Per tant, per evitar aquesta vulnerabilitat s’ha d’assegurar que les aplicacions

publicades es construeixen sense advertiments i es provisionin a fons per evitar accidents.

Aquest test, sens dubte sempre s’ha de realitzar a causa del valor d'una registre de bloqueig.

Una altra mesura important és evitar l'enviament de registres d'errors a la xarxa de text

simple.

8.20 Tenir un control de registres de depuració generats per l’aplicatiu

Els registres de depuració estan dissenyats generalment per a ser utilitzats per detectar

defectes en una aplicació. Aquests registres poden tenir fuites d'informació sensibles que pot

ajudar a un atacant a crear atacs més poderosos. Per solucionar aquesta situació els



desenvolupadors han de tenir en compte el risc que els registres de depuració poden plantejar

en un entorn de producció.

S’ha de desactivar en producció el registre del sistema Android, el qual és utilitzat per

aplicacions per donar sortida als missatges de depuració mitjançant un buffer circular d'uns

pocs kilobytes emmagatzemats en la memòria. També pot ser possible recuperar registres de

depuració del sistema d'arxius en el cas d'una emergència en el nucli. En les versions més

recents dels arxius de registre d'Android han estat més acuradament aïllats i no requereixen

permisos de nivell de sistema.

En Android també es pot aprofitar Proguard o DexGuard per eliminar del tot el mètode de

crida a la classe de registre en les versions de llançament, eliminant així totes les trucades a

Log d’Entrada.

8.21 S’ha de ser conscient de la funcionalitat de copiar i enganxar en Android

Android suporta la funcionalitat de copy/paste. Les dades sensibles poden emmagatzemar-se,

recuperar-se o fins i tot podrien ser modificades des del porta-papers en text clar

independentment de si la font de les dades es xifren inicialment o no. Si és en text pla en el

moment en què l'usuari realitzi el copy, ho farà en text pla quan altres aplicacions accedeixin al

porta-papers. .

Això vol dir, que les aplicacions no poden ser d’escriptura el porta-papers, i l'única manera

d'utilitzar-les és mitjançant la interacció de l'usuari, fent llargues derivacions al menú del

porta-papers. Per solucionar aquest fet, s’ha de desactivar la funcionalitat de copy i paste per

al maneig de dades sensibles. La deshabilitació d’aquesta opció, pot ajudar ha evitar l'exposició

de les dades. En Android al porta-papers pot ser accedit per qualsevol aplicació i així es

recomana que es configuri apropiadament el seu contingut.

8.22 Implementació de Intents amb un control exhaustiu

Intents s'utilitzen per a la senyalització entre components i es poden utilitzar per:

1. Per iniciar una activitat, generalment l'obertura d'una interfície d'usuari per a una

aplicació.

2. Com transmissions per informar al sistema i aplicacions dels canvis.

3. Per iniciar, aturar, i comunicar-se amb un servei en segon pla.

4. Per accedir a les dades a través ContentProviders.



5. Com a devolucions de trucades de gestió d’esdeveniments (una aplicació incorrecta

pot causar la pèrdua de dades i funcions restringides sent el carrer del flux del

programa el que està sent manipulat).

L’aplicació incorrecta dels intents pot causar la pèrdua de dades, funcions restringides sense

retorn i el mal flux del programa que està sent manipulat.

Per solucionar aquesta problemàtica s’ha de seguir les següents recomanacions:

1. Els components els qual s'accedeix a través d’intents poden ser públics o privats. El

valor per defecte depèn del filtre i és fàcil permetre erròniament habilitar el

component com a públic sent privat (establint el component androide: exported =

false a l'App Manifest per evitar aquesta situació).

2. Els components públics declarats en el manifest per defecte són oberts per a qualsevol

aplicació la qual pot accedir-hi. Un component no té perquè ser visitat per totes les

altres aplicacions, considerar l'establiment de permisos per al component declarat en

el manifest mitiga aquesta situació.

3. Les dades rebudes dels components públics no es poden confiar i han de ser

examinades.

8.23 Verificar el correcta funcionament de les activitats (activities) dissenyades

En les aplicacions Android una activitat és una "pantalla".

Una activitat pot ser invocada per qualsevol aplicació, permetent a un atacant carregar

elements de la IU d’una manera què el desenvolupador pot no pretendre, com saltar més enllà

d'una pantalla de bloqueig de contrasenya per accedir a dades o funcionalitats. Ens les

activitats s’ha definir un filtre d'Intenció per a una activitat que sense ell no pugui ser

exportada pel sistema.

Per tant, les activitats han de garantir un comportament adequat mitjançant la comprovació

d'estat de l'aplicació interna per verificar que estan disponibles per ser carregades. Per

exemple, veure primer si l'aplicació està en l'estat "desbloquejat" i si torna a la pantalla de

bloqueig. Independentment del que els filtres d'Intenció es defineixen, les activitats es poden

invocar directament amb les dades, de manera que la validació d'entrada és recomanada quan

s'opera en les dades proporcionades per una font no fiable.



8.24 Utilització de broadcast amb cura

Si no hi ha permís, s'estableix quan s'envia un Intent de difusió, llavors qualsevol aplicació

sense privilegis pot rebre el “intent” llevat que tingui una destinació explícita. Un atacant

podria aprofitar un intent que no té cap permís de la següent manera:

1. Crear una aplicació maliciosa que inclou un component amb el mateix nom que un

component legítim.

2. Mentre que el nom (o espai de noms) no està ja en ús, l'aplicació maliciosa s’instal·la

en el dispositiu de destinació.

3. Extreure informació confidencial de l’intent de difusió enviat amb aquest nom de

component “?”.

Per solucionar aquestes possibilitats esmentades anteriorment, s’han d’utilitzar permisos per

protegir els Intents en l’aplicació. S’ha de tenir en compte que a l'enviar informació a través

d'un Intent de difusió a un component de tercers, aquest component podria haver estat

substituït per una instal·lació maliciosa.

8.25 Implementació de pendingintents amb cura

Un PendingIntent permet a una aplicació passar un Intent d'una segona aplicació, que més

endavant pot ser executat com si es tractés de l'aplicació d'origen (amb idèntics permisos).

Aquest permet a altres aplicacions tornar a cridar els components particulars de l'aplicació

d'origen. L’aplicació externa, si és maliciosa, pot tractar d'influir en la destinació e integritat de

les dades. Per evitar això, s’ha d’utilitzar els PendingIntents com a devolucions de trucada

retardada a BroadcastReceivers com a privades o emissions d’activitats, i per tant s’ha d’

especificar explícitament el nom del component a la base de l’intent.

8.26 Protegir els serveis d'aplicacions.

Els serveis s'utilitzen normalment per al processament en segon pla. Igual que

BroadcastReceivers i les activitats de les aplicacions, els serveis d'aplicacions poden ser

invocats per aplicacions externes i per tant han de ser protegides pels permisos d'exportació.

Una solució és quan es crida un servei amb dades sensibles, s’ha de validar que el servei és

correcte, és a dir, no pot ser un servei malintencionat. Si es té coneixement del nom exacte

del component del qual es vol connectar, s’ha d’especificar aquest nom en el intent utilitzat

per connectar. Un altre mètode que pot utilitzar és el checkPermission () , el qual serveix per

comprovar els permisos del paquet necessaris per rebre el intent desitjat. Aquests permisos els

concedeix l’usuari durant la instal·lació de l’aplicatiu.



8.27 Realitzar bones pràctiques del webview en els aplicatius Android

Un WebViews pot introduir un nombre de problemes de seguretat, i s'ha d'aplicar

acuradament. En particular, una sèrie de vulnerabilitats explotables derivades de la utilització

de la API addJavscriptInterface s'han descobert, per evitar aquesta vulnerabilitat s’ha de

desactivar el suport de JavaScript i Plugin si no són necessaris. Si bé totes dues estan

desactivades per defecte, les millors pràctiques s’utilitzen per desactivar els fitxers locals. Això

restringeix l'accés al directori i mitiga els recursos actius de l'aplicació, generant protecció

contra atacs des d'una pàgina web amb la finalitat de tenir accés a una altre a nivell local a

través dels arxius accessibles. Una altre solució, és no permetre la càrrega del contingut dels

amfitrions de tercers. Això pot ser difícil d’aconseguir dins de l'aplicació. No obstant això, un

desenvolupador pot anul·lar el shouldOverrideUrlLoading i shouldInterceptRequest per

interceptar, inspeccionar i validar la majoria de les sol·licituds iniciades des de dins d'un

WebView. Un desenvolupador també pot considerar la implementació d'un esquema de llista

blanca utilitzant la classe URI, amb la finalitat d’inspeccionar els components d'un URI per

assegurar-se que coincideix amb una entrada d’una llista dels recursos aprovats.

8.28 Evitar l'emmagatzematge d'imatges de la càmera en memòria cau

Les aplicacions de comprovació remota de dipòsit permeten a una persona prendre una

imatge d'un xec amb el seu mòbil amb la càmera del telèfon i després enviar la imatge a la

seva institució financera per al seu dipòsit. Això té una problemàtica i és que moltes d'aquestes

aplicacions conservaran la imatge de verificació (o part d'ella) en la memòria NAND del

dispositiu mòbil, fins i tot després que s'elimini.

Per solucionar això, s’ha d’evitar transmetre una imatge de verificació mitjançant

l'emmagatzematge no volàtil del dispositiu, a continuació s’explica una possible alternativa:

1. Crear un SurfaceView que mostri una vista prèvia de la càmera o la vista prèvia en viu

del sensor de la càmera que està funcionant.

2. Inserir i programar un botó que permeti torna la vista prèvia de la càmera com una

matriu de píxels.

3. Finalment, convertir la matriu de píxels de mapa de bits, comprimir a un .jpg, codificar

a Base64 i enviar-lo a la localització remota.



8.29 Els desenvolupadors sempre han de signar els arxius APK

Els arxius APK han d'estar correctament signats amb un certificat no caducat, per evitar això

s’ha de seguir els següents passos:

1. Signar una aplicació de producció amb un certificat de producció, no un certificat de

depuració.

2. Assegurar que el certificat inclou un període suficient de validesa (és a dir, no es expiri

durant la vida útil esperada de l'aplicació).

3. Google recomana que utilitzi el seu certificat com a mínim de 2048 bits de xifrat.

4. Assegurar que el magatzem de claus que conté la clau de signatura es protegeix

adequadament.

5. També, restringir l'accés al magatzem de claus que només aquelles persones que la

requereixen absolutament.

8.30 Funcions de seguretat integrades en el sistema operatiu Android

Android té funcions de seguretat integrades en el sistema operatiu que redueixen

notablement la freqüència i l'impacte dels problemes de seguretat de l'app. El sistema està

dissenyat de manera que es puguin compilar les apps amb permisos per defecte del sistema

d'arxius i evitar haver de prendre decisions difícils sobre seguretat.

Entre algunes de les funcions de seguretat principals que poden ajudar els desenvolupadors a

compilar apps segures s'inclouen les següents:

Durant l’implementació d’una aplicació Android, s’ha d’utilitzar una zona de proves

d'aplicacions, la qual aïlli les dades sensibles i l'execució de codi de l’app de les altres

apps.

S’ha de realitzar la utilització de framework d'aplicacions amb implementacions amb

funcionalitats sòlides de seguretat, utilitzant tècniques de criptografia, permisos ,IPC

segura i d’altres que es puguin implementar.

Les tecnologies com ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc

i Linux mmap_min_addr , són tecnologies que els desenvolupadors han de tenir en

compte per mitigar riscos associats amb errors comuns d'administració de memòria i

d’altres.

Un desenvolupador ha de tenir un sistema d'arxius encriptat que pugui ser habilitat

per protegir les dades en dispositius perduts o robats.



Per seguritzar l’aplicatiu a desenvolupar, el desenvolupador ha de tenir molt clar els

permisos que seran otorgats a cada usuari per restringir l'accés a funcions del sistema

i dades que només han de tenir accés els usuaris autoritzats.

En la configuració de la app, el desenvolupador a de definir els permisos de la

aplicació para controlar l’accés els recursos de l’app com accés internet, bluetooth ,

càmera i altres funcionalitats que puguin tenir els dispositius per aquesta plataforma.

8.31 Permisos en aplicacions Android

En el moment que els desenvolupadors implementin els permisos en l’aplicació, aquest ha de

minimitzar la quantitat de permisos que la app sol·liciti. La manca d'accés a permisos sensibles

redueix el risc d'utilitzar aquests permisos de forma inadvertida i errònia, pot millorar la

captació d'usuaris i fa que la app sigui menys vulnerable pels atacants. En general, si no es

requereix un permís perquè la app funcioni, no s’ha d’insertar.

Una recomanació, és que els desenvolupadors poden dissenyar l’aplicació de manera que no

requereixi permisos, cosa que es molt recomanable i redueix la possibilitat que l’aplicatiu sigui

vulnerable atacs. Per exemple, en lloc de sol·licitar accés a informació del dispositiu per crear

un identificador únic, s’ha de crear un únic GUID per l’aplicació. Com a alternativa, els

programadors en lloc d'utilitzar l’emmagatzematge extern (que requereix permís declarat en el

AndroidManifest), poden guardar aquestes dades en l'emmagatzematge intern.

A més de sol·licitar permisos, l’aplicació pot utilitzar <permissions> per protegir IPC que

comporti riscos de seguretat i s’exposi a altres aplicacions, com el ContentProvider. En general,

es recomana que els desenvolupadors utilitzin controls d'accés que no siguin permisos

confirmats pels usuaris quan sigui possible, ja que, aquests poden resultar confusos. Per

exemple, els programadors han de considerar fer servir el nivell de protecció de signatura,

mitjançant els permisos de comunicació IPC utilitzats entre aplicacions ofertes per un mateix

desenvolupador.

Els desenvolupadors en tot moment han d’evitar permetre fuites de dades protegides amb

permisos. Això passa quan l’app s’exposa, a través d'IPC, a dades que són accessibles perquè

l’app té permíssos per accedir-hi. No és recomanable que els usuaris de la interfície IPC de

l’app, no tinguin aquest mateix permís d'accés a les dades.



8.32 Seguretat en l’utilització de xarxa en aplicatius Android

Les transaccions en xarxa són, per naturalesa, perilloses per a la seguretat, ja que inclouen la

transmissió de dades de l'usuari que podrien ser privades. Els usuaris són cada vegada més

conscients dels problemes de seguretat d'un dispositiu mòbil, especialment quan el dispositiu

realitza transaccions en xarxa, per la qual cosa és molt important que els desenvolupadors

implementin totes les pràctiques recomanades per protegir la seguretat de les dades de

l'usuari en tot moment.

8.33 Ús de criptografia en aplicacions Android

A més de proporcionar aïllament de dades, habilitar l'encriptació per part del programador en

tot el sistema d'arxius i proporcionar canals de comunicació segurs, genera una àmplia

varietat d'algoritmes per protegir les dades que fan servir criptografia.

En general, el desenvolupador ha de fer servir el nivell més alt d'implementació de framework

preexistent que pugui admetre el cas d'ús. Si aquests necessités recuperar de forma segura un

arxiu d'una ubicació coneguda, un simple URI HTTPS pot ser adequat i no requereix

coneixements de criptografia. Si el desenvolupador necessités un túnel segur, ha de considerar

utilitzar HttpsURLConnection o SSLSocket, en lloc d'escriure el seu propi protocol.

Si el desenvolupador té coneixement que no necessita implementar el seu propi protocol, es

recomana que no realitzi els seus propis algoritmes criptogràfics. És millor que els

desenvolupadors utilitzin algorismes existents i que ja s’han comprovat la seva eficàcia, com

per exemple algoritmes criptogràfics existents com els de la implementació d'AES o RSA,

proporcionats a la classe Cipher.

El desenvolupador ha d’utilitzar un generador de nombres aleatoris segur, SecureRandom, per

inicialitzar les claus criptogràfiques, KeyGenerator. L'utilització d'una clau que ha sigut

generada amb un generador de nombres aleatoris segur, debilitarà notablement la protecció

de l'algoritme i podria permetre atacs sense connexió. Si s’ha d’ emmagatzemar una clau per

tornar a utilitzar-la, el desenvolupador ha d’utilitzar un mecanisme com keystore, el qual

proporciona un mecanisme per a l'emmagatzematge i la recuperació de claus criptogràfiques.

8.34 Seguretat de càrrega dinàmica de codi en Android

No es recomana carregar codi des de fora de l'APK de l’aplicació. Fer-ho augmenta

notablement les probabilitats que es comprometi l'aplicació per la inserció o manipulació de

codi. També suma complexitat a l'administració de versions i la prova d'aplicacions. Finalment,



pot impossibilitar la verificació del comportament d'una aplicació, per la qual cosa podria estar

prohibida en alguns entorns.

Si l’aplicació implementada pel desenvolupador càrrega codi de forma dinàmica, el més

important que s’ha de recordar sobre el codi carregat dinàmicament, és que s'executi

conjuntament amb els mateixos permisos de seguretat que el APK de l'aplicació. L'usuari ha de

prendre la decisió d'instal·lar l’aplicació en funció de la identitat, i esperar que se li proporcioni

tot el codi necessari en l'aplicació, inclòs el codi de càrrega dinàmica.

El principal risc de seguretat associat amb la càrrega dinàmica de codi , és que aquest ha de

provenir d'una font verificable. Si els mòduls s'inclouen directament en l’aplicatiu APK, no

podran modificar-se a través d'altres aplicacions. Això és així, independentment que el codi

sigui una biblioteca nativa o una classe carregada amb DexClassLoader.

Hi ha moltes instàncies d'aplicacions que intenten carregar codi de fonts insegures, com a codi

descarregat de la xarxa mitjançant protocols sense xifrar o d'ubicacions que admeten

escriptura pública, com a mitjans d'emmagatzematge extern. Aquestes ubicacions podrien

permetre que algú a la xarxa modifiqui el contingut en trànsit, o que una altra aplicació del

dispositiu de l'usuari modifiqui el contingut en el dispositiu, respectivament.

8.35 Utilizació de programari lliure per millorar la seguretat

El programari antivirus Smartphone Android està disponible i és molt recomanable a causa del

mercat obert per Android Apps. S’ha de recordar que han aparegut falses aplicacions anti-

malware, per tant, s’ha de tenir constància que aquests aplicatius han estat descarregats des

del lloc del fabricant i no des de fons desconegudes, evitant instal·lar malware en el dipositiu.

Els antivirus que es poden utilitzar per augmentar la seguretat en els dipositiu mòbils són els

següents:

1. Free Antivirus: Antivirus gratuït per Android.

2. AVG Antivirus: Dóna seguretat mòbil lliure i antivirus per Android .

3. DR. Web Anti-virus Light : Antivirus gratuït per Android GuardX.

4. GuardX: Programari lliure d’antivirus per Android Lookout.

5. Lookout: Seguretat mòbil i antivirus per Android Norton Mobile Security.

6. Norton Mobile Security: Seguretat mòbil lliure i antivirus per telèfons Android ( l’aplicació

és gratuïta per mòbils i tablets).

7. Webroot Secure Mobile: Aplicació de seguretat per telèfons Android .

8. Orbot: Millora la privacitat amb comunicacions més segures.

9. WhisperCore: Proporciona xifrat i tallafocs d'aplicacions per Android.

https://market.android.com/details?id=com.drweb

https://market.android.com/details?id=org.qstar.guardx

https://market.android.com/details?id=com.lookout

https://market.android.com/details?id=com.symantec.mobilesecurity



9. EINES D’ANDROID INCLOSES EN EL PROGRAMARI PER ANALITZAR I

DESENVOLUPAR APLICACIONS ANDROID AMB SEGURETAT

En aquest apartat es descriuren diferents eines incloses en el programari de Android que els

desenvolupadors poden utilitzar per analitzar les aplicacions Android amb la finalitat de

fortificar la seguretat. Les tècniques poden ser tant dinàmiques com estàtiques, és possible

detectar un disseny de l'aplicació amb sobreprivilegis, i trobar patrons de comportament

maliciós o traça de dades d’usuaris com ara les credencials d'accés.

L'anàlisi dinàmic és el procés d'extracció de la desitjada informació en temps d'execució.

Aquest mètode requereix la simulació de l'entrada completa del domini de la sol·licitud

examinada per aconseguir una alta precisió en l'avaluació del comportament del programa o

per fer un seguiment amb èxit de les dades desitjades.

Per contra, l'anàlisi estàtic s'executa en el codi de bytes en brut. En general, una eina

automàtica s'executa a través de l'objectiu en el codi i dóna sortida a una aproximació del seu

flux de control i flux de dades. L’aproximació exactitud depèn dels algoritmes d'enginyeria

inversa utilitzats per el desenvolupador amb l'eina d'anàlisis, així s’obtenen maneres de

protecció i un análisis de la tècnica del codi i quin ha sigut el seu comportament a sometre-la

aquestes tècniques.

A continuació s'enumeneran algunes les eines internes d'anàlisis que es poden utilizar per

millorar la seguretat en els aplicatius Android.

• Dexdump: Inclòs com a part del SDK d'Android estàndard, aquest és el més fàcil accés

a l’eina per a la realització d'un desenvolupador de codi de bytes Dalvik per realizat el

desmuntatge dels aplicatius Android.El programador por utilizar aquest algoritme

d'anàlisi implementat per realizar escombrat lineal, és a dir, analitzar el codi de bytes i

esperar per cada instrucció la resposta i diagnostricar si té exit l’aplicació analitzada.

En el cas de codi no ofuscat el desmuntatge serà un èxit, però, una modificació en el

control de la complexitat del flux pot fallar el procés de recuperació.

• Dedexer: Una eina desensamblador d'arxius. La qual pot ser utilitzada pel

desenvolupador per emetre el codi de bytes recuperats en una Jasmin de sintaxi

similar.

• baksmali Un dels descompiladores Dalvik codi de bytes més populars. Conté alguns

dels més sofisticats algoritmes d'anàlisi subjacent, recorregut recursiu taxa de

recuperació de baksmali etc. La millora d’aquest algoritme cau en el fet que la següent



instrucció no ha de ser necessàriament immediatament seguint els salts de corrent, és

a dir, ha de ser un procés correctament codificat. No obstant això, aquest enfocament

només minimitza, però no elimina els efectes d'alguns dels fluxos de control. A causa

de la seva popularitat, és utilitzat per baksmali en múltiples eines d'enginyeria inversa

com un desensamblador de base, entre els quals també ésta apktool coneguda

• dex2jar: Una eina de conversió d'arxius binaris que pren com a entrada un arxiu i

genera un .dex, el seu corresponent arxiu .jar el qual conté els arxius .class extrets.

Mitjançant dex2jar i qualsevol decompilador Java com JAD JD-GUI el programador o

pot utilizar per veure el codi Font.

• radare2 Una eina de consola interactiva, tant pel desmuntatge i l'anàlisi del codi byte.

Aquesta habilita als programadors un control molt precís de les accions de l'usuari

respecte al procés de descompilació. Per a les funcions de codi de bytes específics, la

descompilació es realitza amb la integració de codi obert mitjançant el decompilador

bumerang.

A més de l'ús de recorregut recursiu, els programadors tenen la capacitat d’especificar

la descompilació a partir d'una direcció específica. A causa d'aquest híbrid

enfocament, algunes tècniques d'ofuscació que trenquen altres descompiladors són

reversibles amb radare2, però, no de manera automàtica.

• Androguard: Aquesta eina realitza un anàlisi i processament de l'eina de desmuntatge

tant de codi de bytes i Dalvik bytecode optimitzat. L'eina té tres descompiladors

diferents: TAT, i DED JAD. El qual s'utilitza per defecte és TAT que és també el més

ràpid a causa del fet que es tracta d'un decompilador de codi natiu. El seu algoritme

subjacent és recorregut de manera recursiva.

També Androguard conté una base de dades de codi obert gran en línia amb els

patrons de malware coneguts. Les característiques addicionals, com ara el

mesurament de l'eficiència ofuscadora comparant un programa amb la seva versió

ofuscada, la visualització de l'aplicació en forma de gràfics i permisos d'exploració

estan disponibles com guions independents els quals el desenvolupador pot utilizar

per analitzar l’aplicació.

• Dexter: És una eina d'anàlisi en línia del processament d'arxius APK i mostre un

conjunt de resultats entre els quals es destaquen: permisos definits i utilitzats en



l'aplicació, relació d’ofuscat enfront el codi no ofuscat, relació d'interior enfront de

paquets externs, receptors i proveïdors de contingut transmès. Aquesta eina també

permet els desenvolupadors la visualització gràfica de la sol·licitud i la llista completa

de cadenes utilitzades per l'aplicació. encara que la llibertat d'utilitzar és més limitat, ja

que, Dexter té el seu codi tancat a la banda del servidor i només es pot realizar

l'anàlisis exclusivament de manera estàtica

• Dexguard: És un conjunt de scripts actualment automatitzat amb fils d’ofuscació i

recuperació de l'arxiu de .dex. Aquesta eina té una enfocament híbrid d'anàlisi dinàmic

i estàtic i es compon de:

1. L'arxiu .dex lector.

2. Desensamblador Dalvik.

3. Emulador Dalvik.

4. Arxiu analitzador .dex.

• IDA Pro: És una eina més comercial que el desenvolupadors poden utilizar per realitzar

enginyeria inversa en múltiples arquitectures suportades. Té diverses característiques

com el gràfic del programa la visualització i el suport dels plug-ins el quals s’estenen en

la seva funcionalitat estàndard

10. EINES EXTERNES PER ANALITZAR I PROTEGIR APLICACIONS ANDROID +

En el punt anterior s’ha fet una descripció d’eines incloses en els programari de

desenvolupadment d’Android, les quals els desenvolupadors poden utilitzar per analitzar el

comportament i realitzar enginyeria inversa en aplicacions d’Android, a continuació en aquest

punt es farà una descripició d’eines externes que es poden utilitzar o incorporar per realitzar

l’anàlisi d’aplicacions Android, amb la finalitat de fortificar la seguretat d’aquestes, que són les

següents:

1. CuckooDroid: És una extensió de cucut Sandbox sent un programari de codi obert per

a l'automatització d'anàlisi d'arxius sospitosos de programari maliciós. Proporciona la

inspecció APK tant estàtica com dinàmica, així permet evadir certes tècniques com:

detecció d'entorn virtual, extracció de clau de xifrat, inspecció SSL, empremta de

trucada d'API, firmes bàsiques de comportament i moltes altres característiques. És

molt personalitzable i extensible aprofitant el poder de la gran comunitat de cucut

existent.



2. Cuco Sandbox: És un sistema d'anàlisi de programari maliciós de codi obert. Aquesta

aplicació permet analitzar arxius sospitósos, proporcionant resultats detallats que

s’efectuen a l'executar-la dins d’un entorn aïllat.

Aquest lloc és la principal eina dels cibercriminals i dels principals ciberatacs en

organitzacions empresarials. En aquests temps la detenció i eliminació de programari

maliciós no és suficient, és de vital importància entendre com funcionen en els

sistemes quan es desplega, comprendre el context, les motivacions i els objectius de

l'atac, les quals poden ser analitzades pels desenvolupadors del món de la seguretat,

mitjançant aquesta eina.

Algunes dades que es poden obtenir mitjançant aquesta eina: són la violació interna

de codi, recol·lecció de dades processables i anàlisi de possibles amenaces. Cuckoo

genera diferentes dades que incluoen:

1. Les funcions natives i API de Windows anomenades petjades.

2. Les còpies dels arxius creats i eliminants del sistema de fitxers.

3. Volcat de la memòria del procés sel·leccionat.

4. Volcat complet de memòria de la màquina d’anàlisi.

5. Captures de pantalla de l’escriptori durant l’execució de l’anàlisi del malware.

6. Volcat de xarxa generat per la màquina que ha de ser utilitzada per l’anàlisi.

Amb la finalitat que els resultats siguin millor interpretats per els desenvolupadors,

Cuckoo es capaç de processar i generar diferents tipus d’informes, que podrían

incloure:

o Informe JSON.

o Informe HTML.

o Informe MAEC.

o Interfície de MongoDB.

o Interfície HPFeeds.

El mès interesant, és que gràcies a l’amplia estructura modular del Cuckoo, es

possible personalitzar tant el processament com la fase de presentació d’informes.

Cuckoo proporciona tots els requisits per integrar fàcilment un entorn aillat amb

els sistemes existents, amb les dades que es desitgin, de la manera que es vulguin i

amb el format demanat.



3. AndroL4b: És una màquina virtual orientada als aspectes de seguretat en Android

basats en la companyia Ubuntu, que inclou la col·lecció dels últims marcs, tutorials i

laboratoris, de seguretat, per realitzar enginyeria inversa i anàlisi de programari

maliciós en aplicacions Android. Conté les següents eines i laboratoris:

APKStudio: És un IDE multiplataforma per a l'enginyeria inversa i

recompilació de binaris d'aplicacions Android, dins d'una sola Interfície

d'usuari. Compte amb un disseny amigable, amb un editor de codi que

suporta ressaltat de sintaxi per Android smali i arxius de codi (*

.smali).

ByteCodeViewer: És la suite d'enginyeria inversa d'aplicacions

Android, amb diferents descompiladors Java, Editors de Codi de bytes,

compiladors de Java i connectors específics.

Marc Mobile Security (MobSF): És una applicació de codi obert per a

Mòbils Android. Conté un marc capaç de realitzar l'anàlisi estàtic i

dinàmic (Només es té permès l'anàlisi estàtic en aquesta màquina

virtual). Pot ser utilitzat per a un anàlisi de seguretat d'aplicacions

eficaç i ràpid, a més és compatible amb els binaris (APK i IPA) i el codi

font comprimit.

MobSF també pot realitzar proves de seguretat amb l’utilització de

Fuzzer AP, el qual port fer de: Recull d'informació, anàlisi de capçaleres

de seguretat, identificar vulnerabilitats específiques de la API mòbil

com: la XXè, FRSS de traspàs de rutes, IDOR i altres qüestions lògiques

relacionades amb la sessió.

4. Dorzer: Permet realitzar recerques de vulnerabilitats de seguretat en aplicacions i

dispositius, assumint el paper d’una aplicació, permetent interaccionar amb la

màquina virtual Dalvik, els punts finals de l'IPC d'altres aplicacions i el sistema operatiu

subjacent.

5. APKtool: És una eina que s’utilitza en l'enginyeria inversa de binaris d'aplicacions

Android. Pot descodificar als recursos de manera gairebé originals i reconstruir-los,

després de fer algunes modificacions, a més, també és possible depurar codi smali pas

a pas. Aquesta eina facilita el treball amb l'estructura d'arxius en projectes i amb

l'automatització de tasques repetitives, algunes com la construcció d'Apk.



6. Android Studio IDE: És un entorn de desenvolupament integrat (IDE) per al

desenvolupament d'aplicacions Android, basat en IntelliJ idea. Android Studio ofereix

característiques que milloren la productivitat i seguretat en la construcció d'aplicacions

Android.

7. ClassyShark: És una eina per a desenvolupadors Android, permetent navegar de

manera fiable a través d’arxius executables d’Android i mostrant Informació important

com: les interfícies de classe i dels membres, el recompte de Dex i dependències. A

més també, suporta múltiples formats incloent: biblioteques (.dex, .aar, .so),

executables (.apk, .jar, .class) i tots els binaris XMLS Android: AndroidManifest,

recursos, dissenys, etc.

8. BurpSuite: És una plataforma integrada per a la realització de proves de seguretat

d'aplicacions Web. La diversitat d’eines fa que funcioni perfectament donant la

capacitat de realitzar tot el procés de proves com: cartografia i anàlisi de la superfície

d'atac d’una petició inicial a través de la recerca i explotació de vulnerabilitats de

seguretat.

9. Wireshark: És l'analitzador de protocols de xarxa més important del món. Permet

veure el que està succeint en una xarxa analitzada. Sent utiitzat tant en la industria

com en institucions educatives.

10. MARA: És un conjunt d'eines comunament utilitzades en enginyeria inversa i anàlisi

d'aplicacions per mòbils sota els estàndards de OWASP.

11. FindBugs-IDEA: S’utilitza per a realitzar l’anàlisi estàtic de codi de bytes a la recerca de

fallades en el codi Java.

12. AndroBugs: És un escàner de vulnerabilitats de seguretat d'Android que permet als

desenvolupadors i pentesters cercar possibles vulnerabilitats de seguretat en

aplicacions d'Android.

13. Metasploit: És un projecte de codi obert de seguretat informàtica que proporciona

informació sobre vulnerabilitats de seguretat i ajuda en proves de penetració

"Pentesting" i el desenvolupament de signatures per a sistemes de detecció d'intrusos.

14. DIVA Android: És una apliació dissenyada expressament per ser insegura. L'objectiu

d’aquesta és ensenyar els desenvolupadors, defectes que generalment es troben

presents en les aplicacions, causades per pràctiques de codificació pobres o insegures.



15. InsecureBankv2: És una aplicació Android feta per desenvolupadors de seguretat

informàtica per aprendre les inseguretats d'aplicacions d'android. El seu component

de servidor de fons esta escrit en Python.

16. DroidBench: És un conjunt de proves de codi obert per evaluar l’eficàcia de les eines

d'anàlisi específiques per a aplicacions d'Android. La Suite es pot utilitzar per evaluar

tant estàticament com dinàmicament. Però en concret, conté interessants casos de

prova per a problemes d'anàlisi estàtic (sensibilitat de camp, la sensibilitat d'objectes,

avantatges i desavantatges en les longituds de via d'accés, etc.), així com modelar

correctament el cicle de vida d'una aplicació, maneig de devolucions de trucades

asíncrones i interaccionar amb la interfície d'usuari.

17. GoatDroid: És un entorn de formació totalment funcional i autònom per educar els

desenvolupadors de seguretat d'Android. GoatDroid requereix dependències mínimes

i és ideal tant per a principiants com per els usuaris més avançats.

18. AppUse: Va ser creat com una màquina virtual específica els pentester que estan

interessats en una plataforma personalitzada per a les proves de seguretat

d'aplicacions Android, amb opcions de captura dels problemes de seguretat i anàlisi

del trànsit d'aplicacions.

No hi ha la necessitat d’instal·lar emuladors, ni eines de prova, només es necessiten

certificats SSL del programari de servidor intermig (tot bé pre-Instal·lat). Pràcticament

és com una ruta inversa, ajustada específicament per a les proves de seguretat

d'aplicacions Android. No es permet realitzar proves en solitari de penetració

d'aplicacions, a més, també és possible analitzar-les en la recerca de programari

maliciós.

Les caracteritiques més destacades són:

o Totalment compatible amb varis dispositius. o Assistents per fer tècniques de pirateria. o Proxy amb suport de protocols binaris. o Posseeix seccions amb dades d'aplicació. o Vista en arbre de carpeta i estructura d'arxius de l'aplicació. o Capacitat per a eliminar, veure i editar arxius. o Capacitat per a extreure les bases de dades. o Dinàmic Proxy. o Permet realitzar enginyeria inversa d'aplicacions. o Indicador dinàmic per a l'estat del dispositiu Android. o Analitzadors avançats de APK. o Compatible amb Android. o Anàlisi de malware.



19. HelDroid: És una eina per fer front a l'anàlisi de ransomware en aplicacions Android. El

que realitza és trobar pistes en el codi de bytes d'aplicacions Android, que indiquen la

presència de codi utilitzat per implementar les característiques típiques de

ransomware. Les característiques són:

Ús de rutines de xifrat en intervenció de l'usuari.

Bloquejar la pantalla i fer que el dispositiu quedi inutilitzable.

Missatges amenaçadors en la pantalla.

Abús de l'API d'administració de dispositius per al bloqueig o neteja

sense supervisió.

Aquesta eina es centra en les rutines que estan vinculades i l'abús de l'API d'Android

per la implementació de ransomware. L'enfocament de HelDroid és gairebé 100%

d'Anàlisi estàtic d'arxius APK.

Cada HelDroid analitza l’APK Android per decidir si es tracta d’una mostra de

ransomware mitjançant tres tipus de detectors Independents, que poden executar-

se en paral·lel:

Detector de text amenaçant.

Detector de xifrat.

Detector de bloqueig.

Cada detector busca un indicador específic de comportament de ransomware.

20. AndroTotal: És Un servei gratuït per escanejar arxius APK sospitosos contra múltiples

aplicacions antivirus mòbils. El qual es pot descarregar en http://andrototal.org

21. Annubis : És una eina d'anàlisi que es basa en executar els binaris i és emulat en un

entorn de proves. L'anàlisi es centra en els aspectes rellevants per la seguretat de les

accions de l'aplicació, fent un procés d’analisis senzill i permet obtenir resultats més

precisos. El qual es pot descarregar en http://ift.tt/V8JHvk

22. CopperDroid: Reconstrueix automàticament i amb precisió esdeveniments d'Interès,

no hi ha interaccions en solitari, sinó que realitza les comunicacions entre processos,

del qual semànticament és típic contextualitzat a través d'objectes complexos

d’Android. A causa de la cua els mecanismes de reconstrucció de copperDroid realitza

un diagonisi a través dels mètodes d'acció d'invocats, a més, és capaç de capturar

accions tant de Java com d'execució de codi natiu. L'anàlisi que realitza CopperDroid

gènera perfils de comportament detallats, que són molt adequats per proporcionar

http://andrototal.org/

http://ift.tt/V8JHvk



trets interessants i obrir la possibilitat de noves línies d'investigació de malware. El

qual es pot descarregar en http://ift.tt/2gRWg3F

23. SandDroid: És un sistema d'anàlisi d’aplicacions Androi que funciona automàticament

combinant tècniques d'anàlisi estàtic i dinàmic. El qual es pot descarregar en

http://ift.tt/1tZNByl

24. Tracedroid: Permet pujar un arxiu APK d'Android per a realitzar un anàlisi

automatitzat. Registra el comportament de l'Aplicació executada, per desencadenar el

comportament reial de l'aplicació, Tracedroid emula algunes accions com: la Interacció

de l'usuari, les trucades entrants i missatges SMS,etc. Revelant la majoria dels intents

maliciosos d'una aplicació. La qual es pot descarregar en : http://ift.tt/21h5YdD

11. TÈCNIQUES D’OFUSCACIÓ DE CODI EN ANDROID

Les eines d’enginyeria inversa demostren la facilitat que el codi font pot ser recuperat

mitjançant programari per reconfigurar un aplicatiu amb intenCions malicioses, per aquesta

raó es farà una exposició de les diferents tècniques d’ofuscació que es poden implementar per

dificultar aquesta reconfiguració i produir una fortificació en la seguretat del codi

implementat.

Les següents tècniques es classifiquen en ordre ascendent d'acord amb el còmput de dificultat

per a la seva enginyeria inversa.

Identities name scrambling: Aquesta tècnica afecta el disseny del programa i pot ser

implementat tant en codi font com a nivell de codi de bytes. El seu propòsit és ocultar

el programa en un nivell abstracte mitjançant la substitució dels noms de les variables

significatives, mètodes, classes, els arxius amb els que proporcionen informació

metadades en relació amb la del codi. El nom d’identitats s’aleatoritza i s'implementa

tant en Proguard com en APKfuscator, amb algunes diferències importants.

Proguard treballa en el codi font de Java i utilitza el reemplaçament amb cadenes de

lèxics ordenats {a, b, c,..., aa, ab,...} el qual té un baix cost d'espai que és essencial en

dispositius mòbils. En canvi quan s’utilitza APKfuscator en el nivell de codi de bytes,

aquest explota la restricció del sistema de fitxers Unix amb un nom de classe per no

excedir de 255 caràcters. Aquest fet és possible, ja que, també a Dalvik el codi de bytes

produeix que l'estructura de classe d'element es defineixi utilitzant el format d'arxiu

.dex (un requisit del format .dex és tenir totes les cadenes ordenades alfabèticament).

http://ift.tt/2gRWg3F

http://ift.tt/1tZNByl

http://ift.tt/21h5YdD



Encoding manipulations: Aquesta transformació es posa a disposició tant d'arxius com

en estructures de dades del programa. Per especificació, l'ordre dels bytes en el

format .dex és ascendent cap a l'esquerra. El manual ARM en l’arquitectura de

referència afirma que els processadors ARM donen suport a l'accés mixta ascendent

cap a l'esquerra en el maquinari, el que significa que es poden fer funcionar tant en

littleEndian o maneres big-endian.

Per tant, el verificador DVM se suposa que és capaç de detectar la codificació de l'arxiu

.dex interpretat i convertir bigEndian a l'ascendent cap a l'esquerra i viceversa. Mentre

que el canvi de la codificació no és difícil de posar en pràctica, es suggereix com

potencialment eficaç, ja que, la majoria de les eines d'anàlisi de codi de bytes Dalvik

només funcionen amb codificació d’arxius

Strings obfuscation: Aquesta tècnica és coneguda perquè realitza la transformació de

dades aplicant-lo en el nivell de codi font. Tot i que no està implementada per

qualsevol codi obert examinat amb ofuscadors, és possible ajustar-la al nivell de Dalvik

en codi de bytes. Aquesta técnica d’ofuscació de cadena impedeix l'extracció

d'informació de metadades i és eficaç contra l'anàlisi estàtic. Atès que hi ha moltes

aplicacions de tractament de dades personals, és bastant comú emmagatzemar

cadenes tals com credencials d'usuari en una base de dades.

No obstant això, fa que la conseqüència de mantenir aquest últim en text pla, sigui un

blanc fàcil per a l'enginyeria inversa. Hi ha un significat per ofuscar el fils d'un

programa d'aleatorització i la variable de noms. El canvi d'aquest últim no afecta a la

semàntica del programa. Per contra, cadenes que han d'estar en una part xifrada s’ha

d'impedir l'extracció estàtica i, d'altra banda, han d'estar disponibles com a text sense

format en temps d'execució de tal manera que un procés com a usuari pugui ser

verificada i portada a terme amb èxit.

Depenent de si s'aplica sobre l'ofuscació codi font o el nivell de codi de bytes, l'esforç

necessari per obtenir la cadena de text sense format varia. Es pot fer a nivell de codi

font passant la cadena com a argument a un invertible funció de transformació F és F

(s) la qual s'emmagatzema en el codi.

Dead code injection variants: Injecció de codi Dead, és una altra transformació que

s'ha pres del x86. Afecta el flux de control de l'aplicació i s'implementa en nivell de

codi de bytes per tant Dalvik-obfuscador i APKfuscator, cadascuna de les eines utilitza

la seva pròpia variació de la tècnica. En essència, aquest algoritme modifica el flux de



control mitjançant la inserció de codi que mai s'executa, però, afegeix nodes i vores

per al programa gràfic que augmenta la complexitat, respectivament.

Per garantir que l'execució no passa pels camins falsos introduïts, una branca

condicional s'utilitza per a la redirecció. Per tant, cal que aquesta condició sigui

especialment triada com la producció (a priori se sap el resultat del programador),

però una que és computacionalment difícil d'estimar en temps d'execució, és a dir, o

bé és sempre veritat (dirigint a rutes "bones") o sempre és falsa (mai dirigir als camins

"dolents").

Tals construccions condicionals es diuen predicats opacs i que s'han utilitzat, entre

altres, en Java codi font ofuscació. En el codi de bytes és implementat en les dues

variants d'injecció de codi ofuscadors que están sent utilitzats legítimament, i aquesta

es defineix amb instruccions una mica especials.

Dalvik-obfuscator: El codi de transformació d'injecció morts esquerdat utilitzen eines

tant d'escombrat lineal i recursius per desmuntar algoritmes en el moment de la seva

presentació. Per injectar el codi de la instrucció de longitud variable fill-matriu-

datapayload s'utilitza abans que el punt d'entrada del mètode a ser ofuscat.

Dues instruccions s'afegeixen en la matriu de dades de càrrega útil que es solapen amb

el codi del mètode i un precedent predicat opac que torna a dirigir l'execució dels

continguts de mètodes vàlids. La xifra dóna una idea intuïtiva de la diferència entre el

codi no ofuscat i el codi ofuscat després d’utilitzar aquesta tècnica.

Executable compression: Aquest tècnica ès coneguda sota l'arquitectura x86 perquè

és sovint utilitzada pel malware per ocultar el seu codi. L'objectiu d'aquest mètode és

la construcció d'un sol executable que conté el codi comprimit del programa complet

mitjançant un descompresor.

La compressió, amb freqüència en combinació amb el xifrat de codi, s'utilitza tant per a

disminuir la mida de l'executable, així com a ofuscar el codi. Durant l'execució del

descompressor stub s'extreu en primer lloc el codi comprimit i després executa el

programa original.

La Inversió d'un programa que s'ha sotmès a una transformació d'aquest tipus no es

pot fer amb l'anàlisi estàtic. Els dos mètodes principals per analitzar, són o bé l'examen

manual del tros de la descompressió després de desemblar el programa o mitjançant

la realització d’anàlisis dinàmics.



Self modifying code: La modificació és una transformació del codi conegut aplicat amb

èxit en l'arquitectura x86 el seu propòsit és impedir anàlisi dinàmic. S'utilitza sovint pel

malware en combinació amb atacs de desbordament de memòria intermitja, que

també ha trobat la seva aplicació en tècniques d'ofuscació de programari legítim.

Havent-hi un programa protegit contra els resultats d'anàlisi estàtic d'una manera més

complexa i idèntic sobre cada flux de control d'execució. Per contra, els canvis de codi

dinàmics tenen un efecte en temps d'execució que és alterar la ruta d'execució en

cada trucada del programa.

No és estrany que una tècnica d'ofuscació hagi estat dissenyada per equilibrar entre la

complexitat del programa afegit i la robustesa del codi modificat contra l'anàlisi. En

aquest sentit, les tècniques d'ofuscació dinàmic augmenten considerablement de la

capacitat de recuperació, però pot ser un repte per aplicar d’una manera uniforme en

un arxiu d'entrada APK.

Inserció Junkbyte: És una tècnica ben coneguda sota l'arquitectura x86. S'utilitza per a

confondre els desensambladors d'una manera que ells produeixen errors de

desmuntatge i no permetin interpretacions correctes per un analista. Això es realitza

mitjançant la inserció junkbytes en llocs seleccionats dins el codi de bytes en un

desensamblador el qual espera una instrucció. La posició d'un junkbyte ha de prendre

l'estratègia de desmuntatge per tal d'aconseguir un màxim de codi ofuscat.

Una altra condició per a la ubicació és que el junkbyte no s'ha d'executar, a causa

d'una execució donaria lloc a un comportament no desitjat de l'aplicació. Un junkbyte

ha d'estar ubicat en un bloc bàsic que mai serà executat. Poden assegurar que aquest

bloc bàsic no serà executat per l'addició d'un salt incondicional. També és possible

utilitzar una bifurcació condicional alhora que garanteix que els resultats de l’argument

avaluat en un valor constant. Aquesta tècnica utilitza predicats opacs.



12- GUIA PER SEGURITZAR L’APLICATIU CONTRA ATACS SQL INJECTION

Utilitzant el fitxer APK subministrat, es va poder observar que l’aplicatiu utilitzava formularis

per cercar I insertar dades a través d’aquests per part de l’usuari (figura 12.1).

figura 12.1 - Interficie gràfica per donar d’alta el compte d’usuari

En la imatge es pot observar el formulari que utiliza l’aplicatiu per cercar els usuaris

Tota aquesta informació consultada i administrada pel dispositiu, està emmagatzemada en un

servidor de base de dades.

Per aquesta raó, s’ha considerat en aquesta documentació, fer referència a les tècniques més

importants per seguritzar l’aplicatiu analitzat contra atacs de Sql injection, els quals milloren la

seguretat, confidencialitat I integritat de les dades administrades per aquest aplicatiu.

12.1 Escapar els caràcters especials utilitzats en les consultes Sql

En parlar "escapar caràcters" s’està fent referència a afegir la barra invertida "\" davant de les

cadenes utilitzades en les consultes SQL per evitar que aquestes corrompin la consulta. Alguns

d'aquests caràcters especials que és aconsellable escapar són les cometes dobles ( "), les

cometes simples ( ') o els caràcters \ X00 o \ X1A, ja que, són considerats com a perillosos per

que poden ser utilitzats durant els atacs. Els diferents llenguatges de programació ofereixen

mecanismes per aconseguir escapar aquests caràcters.



12.2 Verificar sempre les dades que introdueix l'usuari en l’aplicatiu

Si en una consulta s’està a l'espera de rebre un enter, no s’ha de confiar que sigui així, sinó que

és aconsellable prendre mesures de seguretat i realitzar la comprovació que realment es tracta

del tipus de dada que s’està esperant. Per a realitzar això, els llenguatges de programació

ofereixen funcions que realitzen aquesta acció, com per exemple en JAVA mitjançant la funció

isnumeric(), que retorna un booleà true o false segons si la cadena passada per paràmetre és

un valor numèric o no.

També és aconsellable comprovar la longitud de les dades per descartar possibles tècniques

d'injecció SQL, ja que, si per exemple s’està esperant rebre el nom de l’usuari no pot ser que

l’extensió de la cadena introduïda sigui superior a 20 caràcters. Per aquesta raó, en el moment

de rebre les dades l’aplicactiu, hauria de realitzar una anàlisi de l’extensió dels diferents

paràmetres que construirà la consulta SQL mitjançant la funció lenght (la qual retorna la

longitud del string).

12.3 Assignar mínims privilegis a l'usuari que connectarà amb la base de dades des de l’aplicatiu.

L'usuari que s’utilitzi per connectar-se a la base de dades des del codi implementat, ha de tenir

els privilegis justos per a realitzar les accions que necessita. No utilitzar mai un usuari amb

privilegis d’administrador llevat que hi hagi una raó de pes per fer-ho, ja que, d'aquesta

manera s’estarà donant facilitats als atacants perquè puguin accedir a tota la informació, amb

aquesta mesura utilitzant l’ús d’un compte d'accés limitat, és molt més segur i limita les

accions que es capaç de realitzar l’atacant.

12.4 Realitzar modificacions del codi per tenir una codificació correcta

Encara que pugui semblar una mesura poc important, no hi ha millor mesura per evitar aquest

tipus d'atacs que fer una bona programació, posant en pràctica les necessitats bàsiques i

l'interès per desenvolupar una aplicació totalment segura. A més de les mesures que es poden

prendre a l'hora d'implementar el codi, sempre s’ha d’utilitzar auditories de codi per assegurar

que no s’ha deixat cap tipus de porta oberta.

Aquesta tècnica consisteix, en la versió més bàsica, fent cerques dins del mateix codi per a

localitzar patrons de fragments de codi que siguin potencialment vulnerables a problemes

coneguts. És recomanable que l'auditoria no la faci la mateixa persona que ha escrit el codi,

sinó un equip diferent, per assegurar la imparcialitat.



12.5 Protegir els logs

Una mesura important és desinfectar els missatges de registre de sortida utilitzant una llista

blanca de caràcters permesos. Es podria, per exemple, limitar tots els registres en caràcters

alfanumèrics i espais en l’aplicatiu. Els missatges detectats fora d'aquesta llista de caràcters

que puguin ser corruptes i que condueixi a un missatge de registre en relació amb un potencial

de LFI, permet notificar sobre un potencial atac.

És un mètode simple per als registres de text simple, on inclouen qualsevol entrada que no

sigui de confiança en el missatge. Una defensa secundària que podria utilitzar l’aplicatiu

analitzat és realitzar una codificació en base64 de la porció d'entrada quan no es confia, la

qual manté un perfil de caràcters limitats permesos, alhora que permet una àmplia gamma

d'informació que s'emmagatzema en el text.

12.6 Utilitzar SQL dinàmic només si és absolutament necessari.

SQL dinàmic gairebé sempre es pot reemplaçar amb declaracions preparades, consultes amb

paràmetres o procediments emmagatzemats. Les declaracions preparades, es pot utilitzar

procediments emmagatzemats. A diferència de les declaracions preparades, els procediments

emmagatzemats es mantenen a la base de dades (Totes dues requereixen en primer lloc

definir el codi SQL, i després passar-li els paràmetres aconsellablament filtrats per l’aplicatiu)

12.7 Instal·lar pegats (patch) regularment.

Tot i que el codi no tingui vulnerabilitats SQL, quan el servidor de base de dades, el sistema

operatiu, o les eines de desenvolupament (Android studio) que s’utilitzin per implementar el

codi tinguin vulnerabilitats, això també és arriscat. És per això que sempre s'ha d'instal·lar els

pegats (patch) i especialment els que facin referència a vulnerabilitats SQL.

12.8 Treure tota la funcionalitat que no s'utilitzi.

Els servidors de bases de dades són complexes i tenen molta més funcionalitat de la que es

necessita. Pel que fa a la seguretat, és millor per exemple, utilitzar els procediments

emmagatzemats quan l’aplicatiu analitzat realitza les diferents consultes a base de dades, ja

que, són més segurs respecte el xp_cmdshell en MS SQL, aquest llança un shell de

comandaments de Window, passa una cadena per a la seva execució i això és just el que un

pirata informàtic pot utilitzar per a realitzar atacs. Per aquesta raó, és aconsellable desactivar

aquest procediment i qualsevol altra funcionalitat que pot ser fàcilment utilitzada

inadequadament tant en base de dades com en el propi aplicatiu.



12.9 Utilitzar eines de proves automatitzades per a les injeccions SQL.

Fins i tot si els desenvolupadors segueixen les regles i fan tot el possible per evitar consultes

dinàmiques amb l'entrada de l'usuari segur, encara s’ha de tenir un procediment per verificar

el compliment. Hi ha eines de proves automàtiques per controlar les injeccions SQL i

comprovar la fortificació de tot el codi de les aplicacions amb bases de dades.

Una de les eines més fàcils per provar les injeccions SQL, és l’anomenada Metasploit

(http://metasploit.com), el qual és una suite de penetració de prova, Metasploit té mòduls

específics de SQL-Server, amb els quals es poden realitzar simulació d’atacs, com per exemple

obtenir la clau de l’usuari “sa” d'una instància de SQL Server (l’eina es subministra amb

documentació completa i pot ser automatitzada per a proves de penetració a nivell d'empresa

o usuari).

12.10 No revelar ni informació ni les credencials amb privilegis d’administrador

(atacs d’ enginyeria social)

A part de validar les dades que els diferents usuaris introdueixen en l’aplicatiu, també s’ha

d’assegurar que els responsables o usuaris que administren l’aplicació Android, no revelin les

credencials que permetin tenir privilegis d’administrador (tant en l’aplicatiu mòbil com en la

base de dades), ja que, aquest tipus d’atacs estan basats en enganyar a un usuari o

administrador des d’un lloc en internet o altres (telefònicament), per obtenir informació o

credencials amb privilegis d’administrador. Per aquesta raó s’ha d’estar segur que els

administradors i usuaris estiguin conscienciats d’aquests tipus d’atacs.

12.11 Utilització de Firewall (application firewalls)

Si l’aplicació analitzada utilitzés un servidor web seria molt recomanable utilitzar els Web

Application Firewalls (WAF), ja que, són les aplicacions que s'instal·len a escala de servidor per

a controlar les peticions malintencionades que podrien donar lloc a un possible atac. Això es fa

mitjançant unes regles que es configuren i que permeten detectar possibles atacs fins i tot

abans que es produeixin. A més, aquests sistemes actuen en conjunció amb els servidors web,

de manera que permeten el bloqueig de la petició maliciosa i eviten l'atac.

12.12 Xifrar les dades sensibles en la base de dades



Com s’ha esmentat anteriorment, l’aplicatiu utilitza formularis mitjançant els quals l’usuari es

pot loguejar o realitzar consultes en base de dades, tot això inclou introduir dades com noms,

cognoms, contrasenyes i informació que pugui ser útil als agents maliciosos.

Per aquesta raó s'ha d'assegurar que, fins i tot si els atacants posseeixen les dades sensibles,

no siguin capaços d'explotar-les immediatament, donant temps per descobrir la infracció,

tapar el forat, i prendre altres mesures reactives, com ara l'aplicació de restabliment de

contrasenyes, per assegurar-se que les dades robades perden el seu valor abans que l'atacant

ho desxifri. Si s’utilitza el hashing de contrasenyes, s’ha d’utilitzar algoritmes forts com ara

SHA-2, que aviat es convertiran en l'estàndard de la indústria per a la protecció de

contrasenya. MD5 i SHA-1 són obsolets i poden revertir-se.

12.13. No mostrar més informació de la necessària:

Els atacants aprenen molt sobre l'arquitectura de base de dades mitjançant els missatges

d'error, per aquesta raó s’ha d’assegurar que l’aplicatiu analitzat mostri la mínima informació

quan es produeix un error, sigui en base de dades o en el propi aplicatiu Android implementat,

a més garanteix que si l’error és generat per un atacant extern, no rebi informació que faciliti

la millora del seu atac.

12.14 No emmagatzemar dades sensibles

Si no ho necessita cada vegada que s'emmagatzema la informació a la base de dades, s’ha de

tenir en compte el perjudici que pot arribar a ser si cau en les mans equivocades, i decidir si

realment és necessari emmagatzemar-les o no. Per tant, és molt important no emmagatzemar

informació confidencial a la base de dades a menys que realment s’hagi de fer. I tot i així, és

una bona política eliminar aquestes dades quan la informació no és d'ús.



13- COM MONOTORITZAR I MITIGAR UN POSSIBLE ATAC EN L’APLICATIU

Al llarg del temps, l'avanç dels mitjans tecnològics i de comunicació ha provocat el sorgiment

de nous vectors d'atacs i de noves modalitats delictives que han transformat a Internet i les

tecnologies informàtiques en aspectes summament hostils per a qualsevol tipus d'organització

i persona que tingui un aplicatiu en un dispositiu mòbil connectat a internet .

En conseqüència, el present punt pretén oferir una ràpida visió de les mesures de

monitorització que es poden realitzar per detectar un atac lo abans possible o per contra si

s’ha patit un atac els passos a realitzar tan bon punt s’ha patit i s’han traspassat els esquemes

de seguretat en els sistemes informàtics.

13.1 Passos per prevenir un possible atac:

1) S’ha d’utilitzar l’aplicatiu de captura de paquets de Wireshark i l’execució d’alertes utilitzant

Snort, les quals s’han d’utilitzar per avisar els administradors que s’està patint un atac de sql

injection (també es podrien implementar altres regles per detectar altres tipus d’atac apart de

l’esmentat).

2) S’ha de realitzar un anàlisis del port obert, s’ha de tenir la seguretat que en el servidor no

s’estiguin realitzant connexions externes a ports no controlats, per aquesta raó s’ha de tenir un

control dels ports que utilitza l’aplicatiu amb el servidor i si es detecta que hi ha algun obert no

controlat, tancar-lo immediatament evitant que hi pugui haver portes del darrere (backdoors).

3) S’ha de realitzar un anàlisi dels processos que genera l’aplicatiu dins el sistema operatiu del

dipositiu mòbil on està funcionant. Amb aquesta acció es té la capacitat de detectar si hi ha

hagut alguna modificació del codi dissenyat per algun atacant que els administradors no

tinguin controlat, immediatament realitzar un versió nova, perquè tots els usuaris puguin

actualitzar l’aplicació mitigant aquesta modificació.

4) Utilitzant el msdos (incio -> ejectuar) es pot veure una llista amb totes les interfícies

connectades al servidor utilitzant la comanda netstat (figura 13.1).

figura 13.1 - Exemple netstat



Mitjançant aquesta comanda (netstat) es pot obtenir tot tipus d’informació de les connexions

realitzades al servidor (port, tipus de protocol de connexió, estat, mac). Realitzant aquesta

consulta, es pot tenir un control de les ip de la xarxa i ports que s’estan utilitzant en el

servidor, poden diagnosticar si hi ha algun intrús en el servidor.

Actualment molts dels routers actuals contenen utilitats de diagnòstic de xarxa poden facilitar

la tasca de detecció d’intrusos.

5) Tenint diagnosticat les ips les quals no es tenen constància que el servidor ha de interactuar

amb elles, es pot obtenir informació utilitzant aplicatius web com whois i altres, les quals

ajuden a analitzar la procedència de les ips, donant la capacitat als administradors de poder

diagnosticar si s’està produint un atac al servidor de l’aplicatiu, per una o varies ips externes al

servidor.

6) Una altra eina molt útil per detectar intrusos és Nmap, ja que, és una aplicació multi

plataforma usada per explorar xarxes i obtenir informació sobre els serveis, sistemes operatius

i vulnerabilitats derivades de la conjunció d'aquests. Amb aquesta eina es podria realitzar un

anàlisis de la xarxa i poder diagnosticar si s’està patint un atac.

13.2 Passos per mitigar un posible atac:

1) S’ha de realitzar la tallada de totes les connexions al servidor afectat per l’atac, d’aquesta

manera s’aconsegueix aïllar el servidor de l’aplicatiu mòbil i i evitar que l’atacant continuï

realitzant atacs (on està la base de dades de la qual s’obtenen les dades).

2) És molt important tenir un servidor de backups, per si es produeixen atacs es puguin

recuperar la major quantitat de dades possibles (donada la importància, s’ha considerat que

l’empresa o entitat té aquest servidor de còpies de seguretat funcionant correctament, en

aquest anàlisi s’ha de realitzar un còpia de seguretat diàriament de la base de dades utilitzada

per l’aplicatiu a un servidor intern (amb un accés molt restringit i una protecció extremada)),

també cada cert període de temps s’ha de realitzar una neteja d’aquestes còpies de seguretat

(les més antigues), aquesta neteja s’ha de realitzar per temes de espai i funcionalitat del

servidor intern.

3) Un vegada obtinguda la copia de seguretat, s’ha de realitzar un comparació entre la base de

dades d’anyada o atacada amb el backup més recent, fent aquesta comparació es pot

diagnosticar si s’ha realitzat alguna modificació o eliminació de dades (hi han programes que



es poden fer servir per realitzar comparacions entre base de dades (ALTOVA)), si fos així s’ha

de realitzar un anàlisis d’aquestes dades eliminades o modificades tenint coneixement en

quina part de l’aplicatiu s’utilitzen, amb aquesta acció es dóna la capacitat als administradors

de localitzar on estan les possibles vulnerabilitats de l’aplicatiu mòbil.

4) Un cop realitzada la comparació de la base de dades i tenint una aproximació per on es pot

haver generat l’atac. S’ha de realitzar un recuperació de les dades eliminades o modificades

per l’atacant (amb la comparació esmentada anteriorment es pot saber aquesta informació) i

actualitzar o recuperar aquestes dades mitjançant el backup en la base de dades de producció.

5) Un cop realitzada la recuperació de les dades danyades per l’atac esmentat en el punt

anterior, s’ha de realitzar una auditoria i revisar mitjançant els passos esmentats (en el punt 3

“Pautes per seguritzar l’aplicatiu conta atacs de sql Injection”) en aquest document que s’hagin

implementat correctament, A més de la utilització de programes com SQLmap o Metasplopit,

perquè tan bon punt hi hagi la seguretat que aquestes mesures estan implementades

correctament, es posin a prova totes elles.

6) Un cop realitzat els passos anteriors i tenint la seguretat que les mesures de seguretat tant

en base de dades com en l’aplicatiu mòbil funcionen correctament, s’ha de tornar a posar en

marxa el servidor de l’aplicatiu mòbil de base de dades. Un dada important, és que els passos

esmentats anteriorment per mitigar l’atac s’han de realitzar sense tenir el servidor i la base de

dades funcionant en producció, amb aquesta acció es té la seguretat que l’atacant no té la

capacitat de seguir explotant les vulnerabilitats de l’aplicatiu mòbil contra la base de dades.

Les mesures de monitorització que s’han de realitzar per detectar l’atac ràpidament són:

La utilització de Snort pot ajudar molt en realitzar monotorizacions, ja que, és un sniffer de

paquets i un detector d'intrusos basat en xarxa (es monitoritza tot un domini de col·lisió).

És un programari molt flexible que ofereix capacitats d'emmagatzematge de les seves bitàcoles

tant en arxius de text com en bases de dades obertes com MySQL. Implementa un motor de

detecció d'atacs i escombrat de ports que permet registrar, alertar i respondre davant

anomalies prèviament definides. Així mateix existeixen eines de tercers per mostrar informes

en temps real (ACID) o per convertir-lo en un sistema detector i preventor d’intrusos (IDS).



Aquest IDS implementa un llenguatge de creació de regles flexible, potent i senzill. Pot

funcionar com sniffer, és a dir, realitza el registre de paquets (permet guardar en un arxiu els

logs per a la seva posterior anàlisi, un anàlisi offline) com un IDS normal (en aquest cas NIDS).

Quan un paquet coincideix amb algun patró establert en les regles de configuració, es logueja.

Així se sap quan, d'on i com es va produir l’atac. Durant l’anàlisi es pot tenir un aplicatiu

Android vulnerable a Sql injection a través dels paràmetres que s’introdueixen en els

formularis d’aquesta.

Una altra eina molt útil per diagnosticar l’estat i correcte funcionament de la xarxa és el

programa wireshark abans conegut com Ethereal, és un analitzador de protocols utilitzat per a

realitzar anàlisis i solucionar problemes en xarxes de comunicacions, per a desenvolupament

de programari i protocols.

La funcionalitat que proveeix és similar a la de tcpdump, però afegeix una interfície gràfica i

moltes opcions d'organització i filtrat d'informació. Així, permet veure tot el trànsit que passa a

través d'una xarxa (usualment una xarxa Ethernet, encara que és compatible amb algunes

altres) establint la configuració en mode promiscu (absorció de tots els paquets que circulen

per la xarxa analitzada). També inclou una versió basada en text anomenada tshark.

Permet examinar dades d'una xarxa viva o d'un arxiu de captura salvat en disc. Es pot analitzar

la informació capturada, a través dels detalls i sumaris per cada paquet. Wireshark és

programari lliure, i s'executa sobre la majoria de sistemes operatius Unix i compatibles,

incloent Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Android, i Mac OS X, així com en Microsoft

Windows.



14. CONCLUSIONS I TREBALLS FUTURS

Durant la realització, es va iniciar un investigació exhaustiva de les diferents possibilitats que

els sistemes de visió per computació podien ser aplicables en l’anàlisi de comparació de firmes

que s’ha realitzat en aquest treball final de màster, es va incorporar la llibreria opencv i

conjuntament amb els coneixements previs que es varen adquirir amb les ùltimes

investigacions, es va implementar un laboratori de proves amb els diferents algorismes pel

tractament i d’anàlisi d’imatges que incorpora aquesta llibreria.

D’aquest estudi es van poder seleccionar els 3 algorisnes que es varen considerar més eficaços

pel cas que s’estava realitzant (SURF,SIFT,ORB), amb els quals es va realizar un estudi més

exhaustiu d’aquests i quins paràmetres podien ser modificables per aconseguir una major

efectivitat per satisfer les necessitats del projecte més satisfactòricament (signatures) .

Per aquesta ráo i perquè els desenvolupadors que vulguin realizar millores en el treball

realitzat, es va implementar un aplicatiu extern amb el qual es va guanyar rapìdessa per a

realitzar la bateria de proves (aquest aplicatiu extern esta afegit conjuntament amb el codi

Font), obtenint els mateixos resultats que realitzant l’implementació en el dipositiu Android (es

va comprovar prèviament).

Fent referència aquest punt, es va poder diagnosticar que el millor algorisme en resultat i en

eficiència en el consum de recursos en el dispositiu móvil, era el ORB respecte els altres

algorismes candidats.

Durant la realització del treball de màster i els coneixements que es varen anar adquirint es

van poder assolir els següent objectius marcats incialment:

Estudiar la situació actual en els sistemes d’indentificació de signatures.

Estudiar com implementar un aplicatiu Android.

Estudiar com incorporar les llibreries opencv en el projecte.

Estudiar com capturar l’imatge de la firma realitzada en el document.

Estudiar com emmgatzemar la imatge generada per l’usuari des de la pantalla del

dispositiu.

Estudiar com realitzar l’implementació de l’algorisme de verificació i autenticitat de les

signatures.

Estudiar com realizar l’implementació d’un MVC cojuntament amb un Api rest per

guanyar amb eficiència en el consum de recursos de l’aplicatiu en el dispositiu mòbil.



A més, durant la realització del projecte i com a futur professional de la seguretat informàtica,

es va realitzar un estudi en profunditat en seguretat en aplicacions mòbils Android, ja que,

cada vegada hi ha una major entrada en el món empresarial, on es realitzen

desenvolupaments a mida per interactuar amb les aplicacions de negoci. L'auditoria i les bones

pràctiques en l’implementació d'aplicacions mòbils per part dels desenvolupadors, és

necessària per garantir la confidencialitat de la informació gestionada per les aplicacions

internes i per les aplicacions comercials.

Amb aquest anàlisis i estudi de les diferents eines i tècniques per protegir i millorar la

seguretat en l’aplicatiu Android desenvolupat, es van assolir els següents objectius de cares els

futurs desenvolupadors que estiguin interessats en continuar el projecte:

Estudiar les diferents tècniques i metodologies per implementar una aplicatiu Android

amb seguretat.

Estudiar les diferents tècniques i metodologies per seguritzar la base de dades en

aplicatius Android.

A partir dels objetius resolts i de l’implementació de l’aplicatiu demanat, els treballs futurs que

es poden realitzar a partir del projecte implementat són el següents:

Millorar l’algorisme ORB mitjançant els paràmetres que té per elevar el tant per cent

d’efectivitat.

En lloc de loguejar l’usuari mitjançant el DNI i contrasenya , es podria implementar un

sistema mitjançant el sistema biomètric de la ditada com s’exposa en la següent url :

http://www.androidhive.info/2016/11/android-add-fingerprint-authentication/

Realitzar proves amb el laboratori implementat amb algorismes de tractament

d’imatges diferents als esmentats en aquesta memòria.

Ampliar les funcionalitats de l’aplicatiu, segons les necessitats de l’entitat o usuari que

utilitizi l’aplicatiu.

Proposar accions i projecte a realizar per millorar l’algorisme de verificació de firmes

implementat

Oferir els resultats de les accions i projectes proposats i realitzats, per obtenir-ne una


http://www.androidhive.info/2016/11/android-add-fingerprint-authentication/



15- REFERÈNCIES

Documentació consultada

https://radiosyculturalibre.com.ar/biblioteca/INFOSEC/Ataques-a-bases-de-datos.pdf

file:///C:/Users/axel/Downloads/Tecnicas-de-SQL-Injection.pdf

https://es.wikipedia.org/wiki/Inyecci%C3%B3n_SQL

https://www.owasp.org/index.php/SQL_Injection

https://pdfs.semanticscholar.org/d2d0/01e2a45614528cd014040becb67a80a1af8d.pd

f

http://stackoverflow.com/questions/17063826/how-to-create-jar-for-android-library-

project

https://www.cryptolux.org/images/9/94/Alexandrina-thesis.pdf


http://isyou.info/jowua/papers/jowua-v6n4-4.pdf

https://www.defcon.org/images/defcon-22/dc-22-presentations/Strazzere-

Sawyer/DEFCON-22-Strazzere-and-Sawyer-Android-Hacker-Protection-Level-

UPDATED.pdf

https://pdfs.semanticscholar.org/d5cb/d4cb442be8fe0268d809cdd496f02b06f100.pdf

http://www.cs.wayne.edu/fengwei/16sp-csc5991/labs/lab5-instruction.pdf

https://tirateunping.wordpress.com/2016/12/07/herramientas-para-el-analisis-de-

aplicaciones-maliciosas-en-android/

http://blog.segu-info.com.ar/2013/08/apkanalyser-permite-analizar-archivos.html

http://gustavopeiretti.com/android-reducir-apk/

https://miguelangellv.wordpress.com/2013/04/23/proguard-optimiza-reduce-y-

ofusca-el-codigo-de-tus-aplicaciones-android/

http://www.techrepublic.com/blog/software-engineer/protect-your-android-apps-

with-obfuscation/

http://www.vogella.com/tutorials/AndroidLibraryProjects/article.html

http://fuzion24.github.io/android/obfuscation/ndk/llvm/o-llvm/2014/07/27/android-

obfuscation-o-llvm-ndk/

http://fuzion24.github.io/android/obfuscation/ndk/llvm/o-llvm/2014/07/27/android-

obfuscation-o-llvm-ndk/

https://www.excelsior-usa.com/articles/java-obfuscators.html

https://insights.sei.cmu.edu/sei_blog/2014/04/two-secure-coding-tools-for-analyzing-

android-apps.html

http://www.vogella.com/tutorials/AndroidTools/article.html

http://tools.android.com/recent/dealingwithdependenciesinandroidprojects

https://www.researchgate.net/publication/311222768_Android_Code_Protection_via

_Obfuscation_Techniques_Past_Present_and_Future_Directions

http://www.androidengineer.com/2010/07/optimizing-obfuscating-and-

shrinking.html

http://blog.scalac.io/2016/02/11/android-reverse-engineering.html

https://radiosyculturalibre.com.ar/biblioteca/INFOSEC/Ataques-a-bases-de-datos.pdf

https://es.wikipedia.org/wiki/Inyecci%C3%B3n_SQL

https://www.owasp.org/index.php/SQL_Injection

https://pdfs.semanticscholar.org/d2d0/01e2a45614528cd014040becb67a80a1af8d.pdf

https://pdfs.semanticscholar.org/d2d0/01e2a45614528cd014040becb67a80a1af8d.pdf

http://stackoverflow.com/questions/17063826/how-to-create-jar-for-android-library-project

http://stackoverflow.com/questions/17063826/how-to-create-jar-for-android-library-project



http://isyou.info/jowua/papers/jowua-v6n4-4.pdf

https://www.defcon.org/images/defcon-22/dc-22-presentations/Strazzere-Sawyer/DEFCON-22-Strazzere-and-Sawyer-Android-Hacker-Protection-Level-UPDATED.pdf




http://www.cs.wayne.edu/fengwei/16sp-csc5991/labs/lab5-instruction.pdf

https://tirateunping.wordpress.com/2016/12/07/herramientas-para-el-analisis-de-aplicaciones-maliciosas-en-android/

https://tirateunping.wordpress.com/2016/12/07/herramientas-para-el-analisis-de-aplicaciones-maliciosas-en-android/

http://blog.segu-info.com.ar/2013/08/apkanalyser-permite-analizar-archivos.html

http://gustavopeiretti.com/android-reducir-apk/

https://miguelangellv.wordpress.com/2013/04/23/proguard-optimiza-reduce-y-ofusca-el-codigo-de-tus-aplicaciones-android/

https://miguelangellv.wordpress.com/2013/04/23/proguard-optimiza-reduce-y-ofusca-el-codigo-de-tus-aplicaciones-android/

http://www.techrepublic.com/blog/software-engineer/protect-your-android-apps-with-obfuscation/

http://www.techrepublic.com/blog/software-engineer/protect-your-android-apps-with-obfuscation/

http://www.vogella.com/tutorials/AndroidLibraryProjects/article.html

http://fuzion24.github.io/android/obfuscation/ndk/llvm/o-llvm/2014/07/27/android-obfuscation-o-llvm-ndk/




https://www.excelsior-usa.com/articles/java-obfuscators.html

https://insights.sei.cmu.edu/sei_blog/2014/04/two-secure-coding-tools-for-analyzing-android-apps.html

https://insights.sei.cmu.edu/sei_blog/2014/04/two-secure-coding-tools-for-analyzing-android-apps.html

http://www.vogella.com/tutorials/AndroidTools/article.html

http://tools.android.com/recent/dealingwithdependenciesinandroidprojects

https://www.researchgate.net/publication/311222768_Android_Code_Protection_via_Obfuscation_Techniques_Past_Present_and_Future_Directions

https://www.researchgate.net/publication/311222768_Android_Code_Protection_via_Obfuscation_Techniques_Past_Present_and_Future_Directions

http://www.androidengineer.com/2010/07/optimizing-obfuscating-and-shrinking.html

http://www.androidengineer.com/2010/07/optimizing-obfuscating-and-shrinking.html

http://blog.scalac.io/2016/02/11/android-reverse-engineering.html



http://blog.theliel.es/2011/02/android-algo-de-ingenieria-inversa-para-parchear-una-

aplicacion-firmarla-y-volver-a-colocarla.html

https://developer.android.com/studio/projects/android-library.html

https://robotsandpencils.com/blog/use-proguard-android-library/

https://handouts.secappdev.org/handouts/2016/Eric%20Lafortune/Code%20Obfuscat

ion%20Techniques.pdf


https://arxiv.org/pdf/1502.01625.pdf

http://stackoverflow.com/questions/14570989/best-practice-for-storing-private-api-

keys-in-android

https://realm.io/news/360andev-ana-baotic-best-practices-app-security-android/

https://www.cnet.com/how-to/protect-your-android-device-from-malware/

http://www.androidcentral.com/three-basic-steps-protecting-your-android-device-

viruses

http://www.javaworld.com/article/2076837/mobile-java/twelve-rules-for-developing-

more-secure-java-code.html

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Android - Content Provider Injection Case of Study - https://viaforensics.com/mobile-

security/ebay-android-content-provider-injectionvulnerability.html

ANDROID OS (2012). HISTORIA DE ANDROID. [Citado: Mayo 28 de 2015]. Disponible

en: http://androidos.readthedocs.org/en/latest/data/historia/

CARACTERÍSTICAS DEL SISTEMA OPERATIVO ANDROID (1995). [Citado Mayo 25 de

2015] Disponible en: http://www.samsung.com/co/article/android-2-2os-explained/

DRAKE, Joshua; FORA; Pau Oliva; ZA Lanier; COLLIN, Mulliner. Etal. Android Hackers’s

handbook. Indianapolis: John Wiley & Sons, Inc., 2013, 577 p.

EL ANDROID LIBRE. LA HISTORIA DE ANDROID EN IMÁGENES: DESDE SUS INICIOS

HASTA AHORA.[Citado Abril 10 de 2015].Disponible en:

http://www.elandroidelibre.com/2014/06/la-historia-de-android-en-imagenes-

desdesus-inicios-hasta-ahora.html

EVOLUCIÓN DE MÓVILES[Citado: Mayo de 2014] Disponible

en:http://dispositivosmobilesits.blogspot.com/2012/02/evolucion-de-moviles.html

http://www.hacking-tutorial.com/hacking-tutorial/hacking-android-

smartphonetutorial-using-metasploit/#sthash.9RNHAwR0.dpbs

FERNANDES, Jerónimo. Banco de pruebas de seguridad para plataformas móviles

Android. Cartagena, 2014. Tesis de Grado: Universidad Politécnica de Cartagena.

GIRONES, Jesús Tomas. El gran libro de Android. México: Alfaomega, 2012. 403p.

INSTITUTO NACIONAL DE TECNOLOGÍAS DE LA COMUNICACIÓN INTECO. (2008).

[Citado: Febrero de 2015] Estudio sobre seguridad en dispositivos móviles y

Smartphones. Disponible en: https://www.inteco.es/file/rdj_9ad_DHM_jZcyjTYRlw

INSTITUTO NACIONAL DE TECNOLOGÍAS DE LA COMUNICACIÓN INTECO.

(2011).Estudio sobre hábitos seguros en el uso de Smartphones por los niños y

adolescentes españoles. Disponible en:

http://www.inteco.es/Estudios/Estudio_smartphones_menores

http://blog.theliel.es/2011/02/android-algo-de-ingenieria-inversa-para-parchear-una-aplicacion-firmarla-y-volver-a-colocarla.html

http://blog.theliel.es/2011/02/android-algo-de-ingenieria-inversa-para-parchear-una-aplicacion-firmarla-y-volver-a-colocarla.html

https://developer.android.com/studio/projects/android-library.html

https://robotsandpencils.com/blog/use-proguard-android-library/

https://handouts.secappdev.org/handouts/2016/Eric%20Lafortune/Code%20Obfuscation%20Techniques.pdf

https://handouts.secappdev.org/handouts/2016/Eric%20Lafortune/Code%20Obfuscation%20Techniques.pdf


https://arxiv.org/pdf/1502.01625.pdf

http://stackoverflow.com/questions/14570989/best-practice-for-storing-private-api-keys-in-android

http://stackoverflow.com/questions/14570989/best-practice-for-storing-private-api-keys-in-android

https://realm.io/news/360andev-ana-baotic-best-practices-app-security-android/

https://www.cnet.com/how-to/protect-your-android-device-from-malware/

http://www.androidcentral.com/three-basic-steps-protecting-your-android-device-viruses

http://www.androidcentral.com/three-basic-steps-protecting-your-android-device-viruses

http://www.javaworld.com/article/2076837/mobile-java/twelve-rules-for-developing-more-secure-java-code.html

http://www.javaworld.com/article/2076837/mobile-java/twelve-rules-for-developing-more-secure-java-code.html



LABORATORIO DE REDES Y SEGURIDAD. Ataques a dispositivos móviles. Recuperado

de:

http://redyseguridad.fip.unam.mx/proyectos/buenaspracticas/ataquesadispositivos

moviles.html

LA HISTORIA DE ANDROID. [Citado: Mayo 28 de 2015]. Disponible en:

http://www.android.com/intl/es-419_mx/history/

NORMA TECNICA COLOMBIANA NTC 1486. Documentación, presentación de tesis,

trabajos de grado y otros trabajos de investigación. Bogotá: Icontec.

SANTANA, A. (Enero de 2011). “Una infraestructura de comunicaciones clienteservidor

para dispositivos móviles”. Disponible en:

http://tesis.bnct.ipn.mx/dspace/bitstream/123456789/9891/1/210.pdf

TODO ANDROID (2015).Qué es Android 5.0 Lollipop: novedades y características de

esta versión de Android. Disponible en: http://www.todoandroid.es/index.php/faq-

de-android/65-versiones/1672-que-esandroid-5-0-lollipop-novedades-y-

caracteristicas-de-esta-version-de-android.html

REFERENCIAS [1] J. Fingas, “Android climbed to 79 percent of smartphone market

share in 2013, but its growth has slowed,” January 2014. [Online].

Available: http://www.engadget.com/2014/01/29/ strategy-analytics-2013-

smartphone-share/ [2] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, and S. Dolev,

“Google Android: A State-of-the-Art Review of Security Mechanisms,” ArXiv e-prints,

Dec. 2009. [3] E. Chin, A. P. Felt, V. Sekar, and D. Wagner, “Measuring user confidence

in smartphone security and privacy,” Proceedings of the Eighth Symposium on Usable

Privacy and Security - SOUPS ’12, no. 1, p. 1, 2012. [Online].

Available: http://dl.acm.org/citation.cfm? doid=2335356.2335358 [4] Google, “Notes

on the implementation of encryption in android 3.0,” 2014. [Online].

Available: https://source.android.com/devices/tech/ encryption/android crypto

implementation.html [5] ——, “Android 4.3 apis,” 2014. [Online].

Available: http://developer. android.com/about/versions/android-4.3.html [6] ——,

“Platform versions,” 2014. [Online]. Available: http://developer.

android.com/about/dashboards/index.html [7] ——, “Detecting pirated applications,”

Febrero 2014. [Online]. Available:

http://www.google.com/patents/EP2693356A2?cl=en [8] B. Bosschert, “Steal

whatsapp database (poc),” Marzo 2014. [Online].

Available: http://bas.bosschert.nl/steal-whatsapp-database/ [9] ——, “Steal whatsapp

update,” Marzo 2014. [Online].

Available: http://bas.bosschert.nl/steal-whatsapp-update/ [10] US-CERT/NIST,

“Vulnerability summary for cve-2013-6271,” Diciembre 2013. [Online].

Available: http://web.nvd.nist.gov/view/ vuln/detail?vulnId=CVE-2013-6271 [11]

Google, “Facial recognition,” Junio 2013, pN 8457367. [Online].

Available: http://patft1.uspto.gov/ [12] V. Rastogi, Y. Chen, and X. Jiang, “Evaluating

Android Anti-malware against Transformation Attacks,” NORTHWESTERN University,

no. March, 2013. [Online]. Available: https://www.eecs.northwestern.edu/

docs/techreports/2013 TR/NU-EECS-13-01.pdf



http://www.android.com/

http://developer.apple.com/technologies/ios/

http://www.infospyware.com/. ¿Qué son los Malwares?

http://www.cnccs.es/. Malware en Smartphones CNCCS

http://www.genbeta.com/. Tapjacking, un problema de seguridad en los móviles

Android

http://www.securitybydefault.com/. Aplicaciones de seguridad desde Android

http://www.diariopyme.com/. Decálogo de seguridad para dispositivos móviles

http://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-

webviews/ https://developer.android.com/training/articles/security-

tips.html#WebView

Pinto, Marcus (2007). The Web Application Hacker’s Handbook: Discovering and

Exploiting Security Flaws (Kindle Locations 2813-2816). Wiley. Kindle Edition

https://developer.android.com/tools/publishing/app-signing.html#cert

ObjC-Obfuscator https://github.com/FutureWorkshops/Objc-Obfuscator iOS-Class-

Guard https://github.com/Polidea/ios-class-guard FairPlay DRM overview on iOS

https://www.theiphonewiki.com/wiki/Copy_Protection_Overview Bugging Debuggers

on iOS https://www.theiphonewiki.com/wiki/Bugging_Debuggers LLVM-Obfuscator

https://github.com/obfuscator-llvm/obfuscator/wiki (for iOS and Android)

http://developer.android.com/guide/publishing/licensing.html#app-obfuscation

Android - ProGuard: http://proguard.sourceforge.net/ -

http://developer.android.com/tools/help/proguard.html Android - DexGuard:

Android - https://gist.github.com/scottyab/b849701972d57cf9562e

http://www.sans.org/reading-room/whitepapers/forensics/forensic-analysis-

iosdevices-34092

Android/iOS Full Database Encryption - http://sqlcipher.net/ Android Storage Options -

http://developer.android.com/guide/topics/data/datastorage.html

Your app shouldn’t suffer SSL’s problems - https://moxie.org/blog/authenticity-

isbroken-in-ssl-but-your-app-ha/

Moxie Marlinspike’s sslstrip exploitation tool - https://moxie.org/software/sslstrip/

http://op-co.de/blog/posts/android_ssl_downgrade/ M1 - Weak Server Side Controls

CWE 325 Protect Against CSRF with Form Tokens DETAILS REMEDIATION REFERENCES

•

http://commonsware.com/blog/2013/09/11/beware-accidental-apis-avoid-

intentsextras.html http://commonsware.com/blog/2014/04/30/if-your-activity-has-

intent-filter-exportit.htm

Sample code here https://gist.github.com/scottyab/d5ab6a284622ebc46d5a

Documentació provinent de CWE/OWASP

CWE: https://cwe.mitre.org/

OWASP: https://www.owasp.org/index.php/Main_Page

M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections CWE-

656: Reliance on Security Through Obscurity

https://moxie.org/blog/authenticity-isbroken-in-ssl-but-your-app-ha/

https://moxie.org/blog/authenticity-isbroken-in-ssl-but-your-app-ha/

https://moxie.org/software/sslstrip/

http://commonsware.com/blog/2014/04/30/if-your-activity-has-intent-filter-exportit.htm

http://commonsware.com/blog/2014/04/30/if-your-activity-has-intent-filter-exportit.htm

https://gist.github.com/scottyab/d5ab6a284622ebc46d5a

https://cwe.mitre.org/



M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections CWE

200 C

M10 - Lack of Binary Protections CWE-354: Improper Validation of Integrity Check

Value

M8 - Security Decisions via Untrusted Inputs CWE 829 M4 - Unintended Data Leakage

CWE-316: Cleartext Storage of Sensitive Information in Memory

CWE-200: Information Exposure

CVE-2014-0160 Heartbleed M4 - Unintended Data Leakage

CWE-312: Cleartext Storage of Sensitive Information

CWE-313: Cleartext Storage in a File or on Disk • M2 - Insecure Data Storage,

M4 - Unintended Data Leakage CWE 598 OWASP Mobile Top 10: M2 - Insecure Data Storage

CWE: CWE-312 - Cleartext Storage of Sensitive Information,

CWE-313 - Cleartext Storage in a File or on Disk,

CWE-522 - Insufficiently Protected Credentials,

CWE- 215 - Information Exposure Through Debug Information R OWASP Mobile Top 10: M9 - Improper Session Handling

CWE CWE-614 - Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

OWASP Mobile Top 10: M3- Insufficient Transport Layer Protection

CWE: CWE-319 - Cleartext Transmission of Sensitive Information


CWE: CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm

Downgrade')

M5 - Poor Authorization and Authentication

M5 - Poor Authorization and Authentication

CWE-200: Information Exposure

M4 - Unintended Data Leakage

CWE 200

OWASP Mobile Top 10: M9 - Improper Session Handling

CWE: CWE-613 - Insufficient Session Expiration

OWASP Mobile Top 10: M5 - Poor Authorization and Authentication

CWE: CWE-308: Use of Single-factor Authentication

M2 - Insecure Data Storage,


CWE 312, 313


CWE: CWE-311 - Missing Encryption of Sensitive Data,

CWE-319 - Cleartext Transmission of Sensitive Information



M8 - Security Decisions via Untrusted Inputs

CWE 79, 89, 120

OWASP Mobile Top 10: M2 - Insecure Data Storage,


CWE: CWE-538 - File and Directory Information Exposure

M2 - Insecure Data Storage,


CWE 312, 313, 522, 200


CWE 215

M2 - Insecure Data Storage;


CWE 312, 313, 522

M10 - Lack of Binary Protections; M8 - Security Decisions via Untrusted Inputs

CWE 215


CWE 200

M1 - Weak Server Side Controls

CWE 325

M2 - Insecure Data Storage

CWE 280

M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections

CWE 927

M8 - Security Decisions via Untrusted Inputs;

M10 - Lack of Binary Protections

CWE-927: Use of Implicit Intent for Sensitive Communication

https://developer.android.com/training/articles/security-tips.html#Permissions

http://shop.oreilly.com/product/0636920022596.do


CWE-925: Improper Verification of Intent by Broadcast Receiver Use Broadcasts

Carefully


CWE-927: Use of Implicit Intent for Sensitive Communication



CWE-280: Improper Handling of Insufficient Permissions or Privileges


M10 - Lack of Binary Protection

CWE 285: Improper Authorization

M7 - Client Side Injection

CWE 926: Improper Export of Android Application Components


http://shop.oreilly.com/product/0636920022596.do



CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site

Scripting) •


CWE 200: Information Exposure


CWE 200: Information Exposure

M6 - Broken Cryptography

CWE-310: Cryptographic Issues

CWE-326: Inadequate Encryption Strength Sign Android APKs DETAILS REMEDIATION •

• • • • REFERENCES •


CWE 203

Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010 -

http://op-co.de/blog/posts/android_ssl_downgrade/ OWASP

Mobile Top 10: M1 - Weak Server Side Controls

CWE: CWE-326 - Inadequate Encryption Strength REFERENCES •

M9 - Improper Session Handling

CWE 613


CWE 307, 200, etc. (could be multiple)


CWE 200 - Multiple CWE's

Documentació provinent opencv

https://enoxsoftware.github.io/OpenCVForUnity/3.0.0/doc/html/class_open_c_v_for_unity_1

_1_o_r_b.html

http://opencv-python-

tutroals.readthedocs.io/en/latest/py_tutorials/py_feature2d/py_matcher/py_matcher.html

https://wwwpub.zih.tu-

dresden.de/~cvweb/teaching/Courses/WS_2014_15/HS/UpdateOnFeatures_StefanHaller.pdf

http://www.sersc.org/journals/IJSEIA/vol8_no3_2014/2.pdf

http://cs.au.dk/~jtp/SURF/report.pdf

http://docs.opencv.org/2.4/opencv_tutorials.pdf

http://mirror-eu.wiki.ros.org/attachments/Events(2f)CoTeSys(2d)ROS(2d)School/OpenCV.pdf

https://www.inf.fu-berlin.de/lehre/SS09/CV/uebungen/uebung09/SIFT.pdf

https://pdfs.semanticscholar.org/3f67/3caedafdfea1c5b4e77118792b6a22fa4998.pdf

https://en.wikipedia.org/wiki/Scale-invariant_feature_transform

https://enoxsoftware.github.io/OpenCVForUnity/3.0.0/doc/html/class_open_c_v_for_unity_1_1_o_r_b.html

https://enoxsoftware.github.io/OpenCVForUnity/3.0.0/doc/html/class_open_c_v_for_unity_1_1_o_r_b.html

http://opencv-python-tutroals.readthedocs.io/en/latest/py_tutorials/py_feature2d/py_matcher/py_matcher.html

http://opencv-python-tutroals.readthedocs.io/en/latest/py_tutorials/py_feature2d/py_matcher/py_matcher.html

https://wwwpub.zih.tu-dresden.de/~cvweb/teaching/Courses/WS_2014_15/HS/UpdateOnFeatures_StefanHaller.pdf

https://wwwpub.zih.tu-dresden.de/~cvweb/teaching/Courses/WS_2014_15/HS/UpdateOnFeatures_StefanHaller.pdf

http://www.sersc.org/journals/IJSEIA/vol8_no3_2014/2.pdf

http://cs.au.dk/~jtp/SURF/report.pdf

http://docs.opencv.org/2.4/opencv_tutorials.pdf

http://mirror-eu.wiki.ros.org/attachments/Events(2f)CoTeSys(2d)ROS(2d)School/OpenCV.pdf

https://www.inf.fu-berlin.de/lehre/SS09/CV/uebungen/uebung09/SIFT.pdf

https://pdfs.semanticscholar.org/3f67/3caedafdfea1c5b4e77118792b6a22fa4998.pdf

https://en.wikipedia.org/wiki/Scale-invariant_feature_transform



Annexa 1 manual laboratori de proves

Per a realizar aquest aplicatiu, es var utilitzar visual studio 2013 i la incorporació al projecte de

la llibreria opencv 3.2.0.

1) S’ha d’executar el programa des de l’executable (figura 1.1).

figura 1.1 - Exemple visual com obrir el projecte del laboratori de proves

2) Per fer funcionar l’aplicatiu, s’ha de canviar les rutes d’on s’agafaran les dues imatges a

analitzar, es varen realitzar diferents firmes des de la pantalla del dipositiu mòbil i a

documents amb la firma a mà, per fer l’anàlisi d’autenticitat de l’usuari.

El codi es composa d’un main, on es pot observar l’utilització de imread de la llibreria opencv

on s’emagatzemen les imatges a analitzar com un objecte Mat. (figura 1.2)

figura 1.2 - es mostren les rutes modificables on s’obtenen les imatges a analitzar

A continuació, s’ha de configurar amb quin algorisme es realitzarà la detenció del punt clau, en

el codi es pot veure com es poden declarar un dels tres tipus (ORB,SIFT,SURF) segons

l’algorisme i les necessitats del cas , com s’ha esmentat anterioment el més eficient amb

l’estudi realitzat és el ORB i per tant s’ha deixat descomentat i és el que agafarà per defecte.

(imatge 1.3)

figura 1.3 - es pot veure l’algorisme per defecte que utilitzarà l’aplicatiu



Utilitzant el drakeypoint, es dibuixaran els punt claus en les imatges que posterioment seran

mostrades, declaran els descriptos amb els paràmetres que es considerin oportuns.(figura 1.4)

figura 1.4- configuració incial per dibuixar els punts claus

Es declara quin tipus d’algorisme match es vol implementar per diagnosticar els punt claus que

coincideixen entre les dues imatges analitzades, per defecte l’aplicatiu utilitzarà força bruta (hi

han altres tipus de match configurables)

A continuació, es dibuixaran en la mateixa imatge les dues imatges analitzades amb els punts

d’interès que fan match amb l’algorisme definit, a més de les dues imatges separades per

finestres. (figura 1.5)

figura 1.5- es pot veure com mitjançant els descripto es mostrarà l’anàlisi

Es pot observar, com es mostren les dues imatges analitzades amb els punts d’interès i la final

que serien les dues juntes amb els seus punts d’interès i quin punts claus fan match (figura 1.6)

figura 1.6- resultat obtingut



Annexa 2 manual de l’aplicació completa

La configuració que s’ha de realitzar des de l’aplicatiu Android és el següent:

S’ha de modificar la ip en totes les funcionalitats on es realitzi la petició post a l’Api rest per la

ip de la màquina on estigui funcionant l’Api rest, com es pot veure en la figura 2.1:

figura 2.1 - exemple de petició post la qual s’haura de canviar la ip que es marca en vermell per

la ip de la màquina on s’estigui executant l’Api rest

Per fer funcionar l’aplicatiu Api rest s’ha de seguir els següents passos.

1) Botó dret sobre l’icona del visual studio amb permisos d’administrador (no s’adjuntat

un executable amb el codi, ja que, s’ha de configurar la connexió de l’Api rest amb el

servidor de base de dades i cada connexió és diferent) (figura 2.2)

figura 2.2- s’ha d’obrir el visual studio amb permisos d’administrador

2) S’ha d’obrir el projecte des del programa visual studio (figura 2.3)

figura 2.3- Com obrir el projecte des del visual studio



3) S’ha de buscar l’executable del projecte (figura 2.4)

figura 2.4- l’executable del projecte

4) S’ha d’accedir a la classe de datosmanager com es veu en la (figura 2.5 )

figura 2.5- es pot observar la connection string (cadenaconnexio) des d’aquesta clase

5) S’ha de modificar la “cadenaconnexio” la qual s’utilitza per fer que l’Api rest es

connecti a la màquina virtual on està el servidor de base de dades de Sql .

6) A continuació, s’exposaran els paràmetres que s’han de configurar de la variable

“cadenaconnexio” esmentada anteriorment.

6.1) data source: És el nom del servidor que té el Window server, com es pot

comprovar en la figura 2.6 es pot obtenir aquesta informació en el mateix

administrador del servidor de Windows server (figura 2.6).

figura 2.6- Es pot observar com obtenir el valor del paràmetre data source



6.2) Initial catalog: És a la base de dades, on anirà a buscar les dades l’Api rest (xx4)

6.3) User Id (sa): És amb l’usuari que accedirà al servidor de base de dades (per

seguretat es varen limitar els permisos d’aquest usuari, perquè només tingués els

permisos suficients per a realitzar les accions que necessita l’aplicació).

6.4) Password: És la contrasenya per accedir el servidor de Sql.

El servidor de base de dades, si es configura mitjançant un màquina virtual com s’ha realitzat

en el projecte, s’ha de configurar un bridge en aquesta màquina virtual perquè estigui dintre

de la xarxa i del mateix rang de ip.

En el cas realitzat 192.168.(número) (figura 2.7)

figura 2.7- es pot observar com la màquina virtual i la local estan en la mateixa xarxa

Per configurar el bridge en la màquina virtual, s’ha realitzat de la següent manera :

figura 2.8 - En aquesta imatge es pot veure com configurar el pont de la màquina virtual



Es configura amb la targeta de xarxa corresponent sigui wi fi o de xarxa, automàticament la

màquina virtual estarà dintre del rang d’ip de la màquina host. (figura 2.9)

figura 2.9 es pot observar com la màquina virtual utilizarà la tarja de xarxa per connectar la

màquina virtual a la xarxa local .

Realitzant la comprovació que estan dintre de la mateixa xarxa utilitzant la comanda ping del

cmd de Windows (figura 2.10)

Figura 2.10 En la imatge es pot veure com la màquina virtual està connectada a la xarxa



Annexa 3 Storeds i taules utilitzades en el servidor de base de dades.

Per implementar la base de dades i els storeds es va utilitzar una tècnica anomenada

d’ofuscació, la qual fa que el nom de la taula, els storeds i els paràmetres que rebran aquests

per administrar el compte d’usuari, continguin noms poc comuns per dificultar la comprensió

d’aquests per part d’un posible atacant.

La taula on s’emagatzemen les dades dels comptes dels diferents usuaris (figura 3.1) .

figura 3.1- taula on s’emmagatzement les dades dels usuaris

xx45 = El primer camp és un id autoincrementable

xx4 = És el camp on s’emmagatzema la contrasenya del compte d’usuari amb form SHA256

xx6 = S’emmagatzema el cognom de l’usuari que ha creat la compte

xx81 = És el camp on s’emmagatzema l’imatge codificada.

xx89 = És el dni de l’usuari que ha creat la compte

xx91 = És el email de l’usuari que ha creat la compte

xx193 = És el nom de l’usuari que ha creat la compte

X68 = Permisos de l’usuari (valor numeric 1 (normal) o zero (investigador))

Als diferents storeds, hi haurà una validació de les dades, per evitar atacs de sql injection

mitjançant l’introducció de sentències Sql malicioses com per exemple union en els

parametres que rebrant els diferents storeds.

Els diferents storeds, com s’esmentat en apartats anteriors on s’exposava el funcionament de

l’Api rest i com interectua amb el servidor de base de dades, contenen noms ofuscats per no



facilitar la comprensió del funcionament del servidor de base de dades i com interectuen amb

els diferents disposisitus movils, per si hi ha un possible atacant.

Per què els futurs desenvolupadors que vulguin continuar el projecte i no tinguin problemes

de comprensió, tots els storeds contenen comentaris de la seva funcionalitat de quin són i

amb quin ordre rebrant els paràmetres.

Els diferents stored que es varen utilizar són els següents:

Stored Actualitzar usuaris

Aquest stored la funcionalitat és permetre a l’usuari actualitzar les dades del compte d’usuari

creat mitjançant el nom, cognom,email, imatge, aquestes dades són introduides a través de

l’interficie de l’aplicatiu Android i enviades a l’Api rest el qual crida el stored passant-li els

paràmetres i actualitzant les dades.

Incialment es fa un validació de les dades introduides per asegurar que no contenen

sentències union en la consulta de sql (per evita atacs de sql injection).

Al finalitzar l’actualització, el stored enviarà un valor nùmeric a l’Api rest confirmant si s’han

actualitzat les dades de l’usuari correctament i aquest mateix valor numèric será enviat a

l’aplicatiu Android que avisarà a l’usuari que el compte d’usuari s’actualitzat correctament o

no (figura 3.2).

figura 3.2- Stored Actualitzar usuaris



Stored eliminar usuari

El stored següent, la funcionalitat que té és eliminar el compte d’usuari quan l’usuari clica

sobre el botó de l’interficie desde l’aplicatiu Android i confirma l’eliminació del compte.

Aquest enviarà el id a l’Api rest i aquest cridarà el seguent stored per realizar el delete del

compte, si el compte s’ha esborrat correctament s’esborraran les dades i enviarà un valor null

que serà enviat a l’Api rest i aquest l’enviarà a l’aplicatiu Android per finalment ser tractat

(figura 3.3)

figura 3.3- Stored eliminar usuari

Stored obtenir permisos usuari

Amb el següent stored s’obtenen els permisos de l’usuari després de realitzar el login,

(investigador/normal) i per tant la manera en que l’aplicati mostrarà els resultats variarà

segons el valor d’aquests camp (figura 3.4)

figura 3.4- Stored obtenir permisos usuari



Stored Login

L’usuari introduirà les dades per loguejar-se en l’aplicatiu mitjançant el DNI i contrasenya,

(s’ha fet la mateixa validació dels paràmetres per evitar atacs de sql injection) , si conté la

cadena union retornarà un valor NULL i que serà enviat a l’Api rest i aquest l’enviarà a

l’aplicatiu Android, el qual farà un tractament d’aquesta dada i avisarà a l’usuari mitjançant un

missatge d’avís que les dades no poden contenir la cadena Union (figura 3.5).

figura 3.5- Stored Login

Obtenir dades usuari

En l’interficie de l’aplicatiu Android la qual permet a l’usuari modificar les dades del compte,

aquesta utilitza el següent stored amb el qual mitjançant el id de l’usuari obté les seves dades,

que a continuació seran enviades a l’Api rest i aquest les enviarà a l’aplicatiu Android per

mostrar-les (figura 3.6).

figura 3.6- Obtenir dades usuari



Stored Alta usuaris

Quan l’usuari introdueix les dades per donar el compte d’usuari i ha passat les validacions,

aquestes són enviades a l’Api rest la qual realitzarà la crida del següent stored passant-li els

paràmetres , el stored agafarà les dades i farà una última validació d’aquestes per evitar atacs

de sql injection, si alguns dels paràmetres conté aquesta cadena(union) , automàticament el

stored enviarà un valor null a l’Api rest i que posterioment es enviat a l’aplicatiu Android el

qual serà tractat i avisarà a l’usuari amb el missatge corresponent, si les dades són correctes

seran insertades i crearà un nou registre, el qual retornarà un valor numèric mitjançant el

count i que aquest l’enviarà a l’aplicatiu Android, perquè sigui tractat i avisi que el compte s’ha

creat correctament (figura 3.7)

figura 3.7- Stored Alta usuaris

Stored Existeix usuari

Amb el stored següents farà una validació que el DNI introduït depenent si el DNI existeix o no

el Stored retornarà un 1 (si existeix) o un zero (si no existeix) , aquest stored és molt important

, ja que, el DNI no pot estar repetit en el servidor de base de dades ha de ser únic.

figura 3.8 - Stored Existeix usuari

Tfm- seguretat en sistemes biotmètricsdeim.urv.cat/~francesc.serratosa/2017_05_21_Axel_Picon...Tfm-...

Documents

Transcript of Tfm- seguretat en sistemes biotmètricsdeim.urv.cat/~francesc.serratosa/2017_05_21_Axel_Picon...Tfm-...