Darmowy fragment publikacji:
Tytuł oryginału: The Mobile Application Hacker s Handbook
Tłumaczenie: Robert Górczyński
ISBN: 978-83-283-3693-3
Copyright © 2015 by John Wiley Sons, Inc., Indianapolis, Indiana
Ali Rights Reserved. This translation published under license with the original publisher John Wiley
Sons. Inc.
Translation copyright © 2017 by Helion SA
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, without
either the prior written permission of the Publisher
Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley Sons, Inc. and/or
its affiliates, in the United States and other countries, and may not be used without written permission.
All other trademarks are the property of their respective owners. John Wiley Sons, Inc. is not
associated with any product or vendor mentioned in this book.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje
były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za
związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo
HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe
z wykorzystania informacji zawartych w książce.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/beapmo
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
• Kup książkę
• Poleć książkę
• Oceń książkę
• Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis treści
O autorach
O recenzencie technicznym
Podziękowania
Wprowadzenie
Ogólne omówienie książki
W jaki sposób zorganizowana jest ta książka?
Kto powinien przeczytać tę książkę?
Niezbędne narzędzia
Co znajdziesz w witrynie internetowej?
Rozdział 1.
(Nie)bezpieczeństwo aplikacji mobilnych
Ewolucja aplikacji mobilnych
Najczęstsze kategorie aplikacji mobilnych
Zalety aplikacji mobilnych
Bezpieczeństwo aplikacji mobilnych
Kluczowe czynniki problemu
Projekt OWASP Mobile Security
Narzędzia rekomendowane przez OWASP Mobile Security
Przyszłość dziedziny zapewniania bezpieczeństwa aplikacjom mobilnym
Podsumowanie
15
17
19
21
22
22
27
27
27
29
30
31
32
32
35
36
40
42
43
5
Poleć książkęKup książkę 6
Spis treści
Rozdział 2.
Analiza aplikacji iOS
Poznajemy model bezpieczeństwa
Inicjalizacja systemu iOS za pomocą łańcucha procedur bezpiecznego rozruchu
Wprowadzenie Secure Enclave
Ograniczenie procesów aplikacji dzięki podpisywaniu kodu
Izolacja aplikacji za pomocą piaskownicy na poziomie procesu
Ochrona informacji za pomocą szyfrowania przechowywanych danych
Ochrona przed atakami dzięki funkcjom ograniczającym możliwość
wykorzystania luk w zabezpieczeniach
Poznajemy aplikacje iOS
Dystrybucja aplikacji iOS
Struktura aplikacji
Instalacja aplikacji
Poznajemy uprawnienia aplikacji
Omówienie jailbreakingu
Powody przeprowadzania jailbreakingu urządzenia
Rodzaje jailbreakingu
JailbreakMe v3 Saffron
Jailbreak evasi0n
Jailbreak evasi0n7
Przygotowanie środowiska testowego
Przygotowanie podstawowego zestawu narzędzi
Przeglądanie systemu plików
Pliki typu property list
Binarne pliki cookie
Bazy danych SQLite
Poznajemy API Data Protection
Poznajemy pęk kluczy w systemie iOS
Kontrola dostępu i polityka uwierzytelniania w iOS 8
Uzyskanie dostępu do pęku kluczy w iOS
Poznajemy Touch ID
Inżynieria odwrotna plików binarnych w iOS
Analiza plików binarnych w systemie iOS
Identyfikacja funkcji związanych z zapewnianiem bezpieczeństwa
Deszyfrowanie plików binarnych pochodzących ze sklepu App Store
Analiza odszyfrowanych plików binarnych
Deasemblacja i dekompilacja aplikacji iOS
Podsumowanie
45
45
46
47
47
48
48
49
50
51
52
53
54
56
57
58
58
60
60
61
62
67
69
69
70
70
73
75
76
77
79
79
82
85
88
93
93
Poleć książkęKup książkę Spis treści
Rozdział 3.
Atakowanie aplikacji iOS
Wprowadzenie do bezpieczeństwa w warstwie transportu
Identyfikacja niebezpieczeństw czyhających w warstwie transportu
CVE-2014-1266: SSL/TLS „Goto Fail”
Przechwytywanie szyfrowanej komunikacji
Niebezpieczeństwa związane z instalacją profili
Ominięcie mechanizmu przypinania certyfikatu
Niebezpieczeństwa związane z instalacją narzędzi
pozwalających obejść kwestie zaufania
Identyfikacja niebezpiecznego magazynu danych
Modyfikacja aplikacji za pomocą deasemblera Hopper
Atak na środowisko uruchomieniowe iOS
Poznajemy języki Objective-C i Swift
Instrumentacja środowiska uruchomieniowego iOS
Poznajemy komunikację międzyprocesową
Atak na procedurę obsługi protokołu
Niebezpieczna procedura obsługi w aplikacji Skype
Rozszerzenia aplikacji
Ataki typu injection
Atak injection na komponent UIWebView
Aplikacja Skype na platformie iOS i ataki XSS
Atak typu injection na magazyn danych po stronie klienta
Atak typu injection na analizator składni XML
Atak typu injection na procedurę obsługi pliku
Podsumowanie
Rozdział 4.
Identyfikowanie problemów w implementacji aplikacji iOS
Ujawnienie danych osobowych
Obsługa identyfikatora urządzenia
Przetwarzanie książki adresowej
Obsługa danych geolokalizacji
Wykrywanie wycieku danych
Wyciek danych w dziennikach zdarzeń aplikacji
Wykrywanie wycieku danych poprzez schowek systemowy
Obsługa zmiany stanu aplikacji
Buforowanie klawiatury
Buforowanie odpowiedzi HTTP
Uszkodzenie pamięci w aplikacjach iOS
Luki w zabezpieczeniach związane z ciągiem tekstowym formatowania
Próba użycia obiektu po jego usunięciu
Inne problemy związane z implementacjami kodu natywnego
Podsumowanie
7
95
95
96
101
103
106
106
107
107
111
117
118
120
142
142
145
145
147
147
150
150
151
153
154
155
155
156
157
157
158
159
159
161
162
163
164
164
167
168
168
Poleć książkęKup książkę 8
Spis treści
Rozdział 5.
Tworzenie bezpiecznych aplikacji iOS
Ochrona danych w aplikacji
Ogólne reguły projektowe
Implementacja szyfrowania
Ochrona danych w trakcie transportu
Unikanie luk w zabezpieczeniach pozwalających na przeprowadzenie
ataku typu injection
Unikanie ataków typu SQL injection
Unikanie ataków typu XSS
Ochrona aplikacji z użyciem zabezpieczeń binarnych
Wykrycie przeprowadzenia jailbreakingu urządzenia
Zabezpieczenie środowiska uruchomieniowego aplikacji
Zabezpieczenie aplikacji przed modyfikacjami
Implementacja zabezpieczeń antydebugowania
Zaciemnienie aplikacji
Podsumowanie
169
169
170
171
174
176
176
177
178
179
183
187
188
189
190
Rozdział 6.
Analiza aplikacji Android
Przygotowanie pierwszego środowiska Android
Poznajemy aplikacje Android
191
192
197
197
Podstawy systemu Android
199
Poznajemy pakiety Androida
203
Użycie narzędzi do przeglądania zasobów Androida
213
Wprowadzenie do komponentów aplikacji
Spojrzenie pod maskę
218
ART, czyli zamienne środowisko uruchomieniowe dla oprogramowania Dalvik 222
223
223
229
Poznajemy model zapewniania bezpieczeństwa
Podpisanie kodu
Poznajemy uprawnienia
Słowo ostrzeżenia dotyczące taktyki najczęściej stosowanej
przez oprogramowanie typu malware
235
235
Piaskownica aplikacji
Szyfrowanie systemu plików
237
Ogólne mechanizmy obronne przed wykorzystaniem luk w zabezpieczeniach 239
Dodatkowe mechanizmy obronne jądra przed eskalacją uprawnień
241
241
Poznajemy kwestię uzyskania uprawnień użytkownika root
Gingerbreak — wykorzystanie luk w zabezpieczeniach kodu jądra AOSP
245
Exynos — wykorzystanie luk w zabezpieczeniach niestandardowych
sterowników
Samsung Admire — nadużycie uprawnień pliku za pomocą
dowiązań symbolicznych
245
246
Poleć książkęKup książkę Spis treści
9
Acer Iconia — wykorzystanie luk w zabezpieczeniach plików binarnych SUID 247
Błędy klucza głównego — wykorzystanie luk w zabezpieczeniach
kodu systemowego AOSP
Towelroot — wykorzystanie luk w zabezpieczeniach jądra w systemie Android
Modyfikacja w urządzeniu Nexus własnego obrazu przeznaczonego
do odzyskiwania systemu
Inżynieria odwrotna aplikacji
Pobieranie plików APK
Wyświetlenie pliku manifestu
Wyświetlanie plików XML
Wygenerowanie danych wyjściowych do pliku
Deasemblacja kodu bajtowego DEX
Dekompilacja kodu bajtowego DEX
Dekompilacja zoptymalizowanego kodu DEX
Deasemblacja kodu natywnego
Narzędzia dodatkowe
Praca ze środowiskiem ART
Podsumowanie
Rozdział 7.
Atakowanie aplikacji Android
Dziwactwa modelu zapewniania bezpieczeństwa
Współpraca z komponentami aplikacji
Atak na komponenty aplikacji
Poznajemy intencje
Poznaj Sieve, czyli pierwszą atakowaną aplikację
Przeprowadzanie ataku na czynności
Kilka słów na temat aliasów czynności
Rzeczywisty przykład: CVE-2013-6271 — usunięcie blokady urządzenia
z wydania Android 4.3 lub starszego
Rzeczywisty przykład — zmiana kodu PIN w urządzeniu bez podania
dotychczasowego
Wykorzystanie luk w niezabezpieczonych dostawcach treści
Użycie istniejących narzędzi do wykrywania SQL injection
Rzeczywisty przykład — luki w zabezpieczeniach wielu aplikacji Androida
zainstalowanych standardowo w urządzeniach Samsunga
Rzeczywisty przykład — aplikacja Shazam
Przeprowadzanie ataku na niezabezpieczone usługi
Rzeczywisty przykład — usługa schowka w urządzeniach firmy Samsung
Błędy podczas kompilacji własnych klas Javy
Przeprowadzanie ataku na odbiorcę komunikatów
Systemowe komunikaty rozgłoszeniowe
247
248
249
250
251
252
253
254
254
256
259
261
261
262
264
265
266
266
272
273
275
279
281
283
287
289
295
295
300
301
302
310
310
311
Poleć książkęKup książkę 10
Spis treści
Rzeczywisty przykład: CVE-2013-6272 — zainicjowanie lub zerwanie połączenia
bez odpowiednich uprawnień w systemie Android 4.4.2 lub starszym
Rzeczywisty przykład — zdalne usunięcie zawartości urządzenia
Samsung Galaxy
Uzyskanie dostępu do pamięci masowej i dzienników zdarzeń
Uprawnienia plików i katalogów
Rzeczywisty przykład — możliwy do zapisu przez wszystkich użytkowników
skrypt DroidWall wykonany przez użytkownika root
Praktyki dotyczące szyfrowania pliku
Pamięć masowa na karcie SD
Rzeczywisty przykład — pamięć masowa aplikacji WhatsApp
Rejestracja danych
Błędne zastosowanie niezabezpieczonej komunikacji
Przegląd ruchu sieciowego
CVE-2012-6636 — wykonanie dowolnego kodu zdefiniowanego
w metodzie addJavascriptInterface()
Inne mechanizmy komunikacji
Inne płaszczyzny ataku
Przeprowadzanie ataku na kod natywny
Wykorzystanie luk w zabezpieczeniach błędnie skonfigurowanych
atrybutów pakietu
Przeprowadzenie ataku na aplikację z włączoną opcją debuggable
z poziomu innej aplikacji bez szczególnych uprawnień
Dodatkowe techniki testowania
Stosowanie poprawek w aplikacji
Błędy podczas podpisywania pakietu
Manipulacja środowiskiem uruchomieniowym
Podsumowanie
312
318
319
319
322
324
325
326
326
327
327
335
336
340
340
347
354
355
356
358
359
364
Rozdział 8.
Identyfikowanie problemów w implementacji aplikacji Android
Przegląd standardowo zainstalowanych aplikacji
Wyszukanie aplikacji o szerokich uprawnieniach
Wyszukiwanie płaszczyzn dla zdalnego ataku
Wyszukiwanie lokalnych luk w zabezpieczeniach
Wykorzystanie luk w zabezpieczeniach urządzeń
Narzędzia ataku
Poznajemy poziomy uprawnień
Praktyczne ataki fizyczne
Praktyczne zdalne ataki
Infiltracja danych użytkownika
Użycie istniejących modułów narzędzia drozer
Inne techniki do zastosowania w uprawnionych scenariuszach
Podsumowanie
365
365
366
369
376
377
377
385
387
398
426
426
431
436
Poleć książkęKup książkę Spis treści
Rozdział 9.
Tworzenie bezpiecznych aplikacji Android
Reguła najmniejszego odkrycia się
Komponenty aplikacji
Magazyn danych
Współpraca z niezaufanymi źródłami
Żądanie minimalnych uprawnień
Sprawdzenie plików znajdujących się w pakiecie APK
Podstawowe mechanizmy obronne
Przegląd punktów wejścia w komponentach aplikacji
Bezpieczne przechowywanie plików
Bezpieczne udostępnianie plików innym aplikacjom
Prowadzenie bezpiecznej komunikacji
Zabezpieczenie komponentu WebView
Konfiguracja pliku manifestu
Rejestracja zdarzeń
Zmniejszenie ryzyka związanego z kodem natywnym
Skrypt checksec nie działa
Zaawansowane mechanizmy zabezpieczeń
Wykrycie obniżenia poziomu ochrony
Ochrona niewyeksportowanych komponentów
Spowolnienie procesu inżynierii odwrotnej
Zaciemnianie kodu źródłowego
Wykrywanie użycia konta użytkownika root
Wykrycie debugowania
Wykrycie modyfikacji aplikacji
Podsumowanie
Rozdział 10. Analiza aplikacji Windows Phone
Poznajemy model zapewniania bezpieczeństwa
Podpisywanie kodu i DRM
Piaskownica aplikacji
Szyfrowanie przechowywanych danych
Proces zgłaszania aplikacji do sklepu Microsoft Store
Poznajemy funkcje mechanizmów obronnych
Poznajemy aplikacje na platformie Windows Phone 8.x
Pakiety aplikacji
Języki programowania i typy aplikacji
Manifest aplikacji
Katalogi aplikacji
Rozpowszechnianie aplikacji Windows Phone
Przygotowanie środowiska testowego
Narzędzia SDK
Odblokowanie możliwości urządzenia
11
437
437
438
438
438
438
439
439
439
445
449
450
453
455
457
457
458
458
459
460
460
460
461
463
463
464
467
468
468
469
471
472
474
482
482
482
484
489
489
493
494
499
Poleć książkęKup książkę 12
Spis treści
Wykorzystanie dostępu do systemu plików
Wykorzystanie dostępu do rejestru
Użyteczne narzędzia hakera
Analiza plików binarnych aplikacji
Proces inżynierii odwrotnej
Analiza funkcji mechanizmów obronnych
Podsumowanie
Rozdział 11. Atakowanie aplikacji Windows Phone
Analiza pod kątem punktów wejścia danych
Kontrolki WebBrowser i WebView
Bluetooth
Sesje HTTP
Gniazda sieciowe
NFC
Kod kreskowy
Karta SD
Interfejsy komunikacji międzyprocesowej
Powiadomienia typu toast
Atak na warstwę transportową
Identyfikacja i przechwytywanie komunikacji w postaci zwykłego tekstu
Identyfikacja i przechwytywanie komunikacji HTTPS
Przechwytywanie ruchu sieciowego innego niż HTTP i HTTPS
Błędy związane z weryfikacją certyfikatu SSL
Ataki na kontrolki WebBrowser i WebView
Ataki typu XSS
Ataki skryptów lokalnych
Komunikacja między językami JavaScript i C#
Identyfikacja luk w zabezpieczeniach implementacji IPC
Procedura obsługi protokołu
Procedura obsługi pliku
Powiadomienia typu toast
Atak na analizator składni XML
Wprowadzenie do API XDocument
Atak DoS podczas rozwinięcia encji
Atak typu XXE
Atak na bazę danych
API LINQ to SQL
SQLite i SQLCipher
Atak na procedurę obsługi pliku
Wprowadzenie do obsługi pliku
Ataki polegające na poruszaniu się po katalogach
Modyfikacje podzespołu .NET
Podsumowanie
512
514
514
515
515
516
517
519
519
520
522
524
525
525
527
528
530
532
533
533
537
539
539
541
541
543
548
549
549
553
557
566
566
569
571
574
574
575
579
579
581
584
591
Poleć książkęKup książkę Spis treści
Rozdział 12.
Identyfikowanie problemów
w implementacji aplikacji Windows Phone
Identyfikacja niebezpiecznego magazynu danych ustawień aplikacji
Wykrywanie wycieku danych
Magazyn danych plików cookie HTTP(S)
Buforowanie HTTP(S)
Rejestracja danych w aplikacji
Identyfikacja niebezpiecznego magazynu danych
Niezaszyfrowany magazyn danych plików
Niezabezpieczony magazyn bazy danych
Niebezpieczne generowanie liczby losowej
Przewidywalność System.Random
Wiele egzemplarzy System.Random
Bezpieczeństwo wątku System.Random
Niebezpieczna kryptografia i użycie hasła
Klucze kryptograficzne na stałe umieszczone w kodzie
Niebezpieczny magazyn kluczy kryptograficznych
Przechowywanie klucza lub hasła w niemodyfikowalnym obiekcie
ciągu tekstowego
Nieudane usunięcie z pamięci klucza kryptograficznego lub hasła
Niebezpieczne generowanie klucza
Użycie słabych algorytmów kryptograficznych i trybów oraz kluczy
o niewystarczającej długości
Użycie statycznych wektorów inicjalizacji
Błędne użycie API Data Protection na platformie Windows Phone
Wykrywanie luk w zabezpieczeniach kodu natywnego
Przepełnienie bufora stosu
Przepełnienie bufora sterty
Inne błędy związane z obsługą liczb całkowitych
Błędy ciągu tekstowego formatowania
Błędy związane z indeksowaniem tablicy
Błędy związane z odmową usług
Niebezpieczny kod C#
Podsumowanie
Rozdział 13. Tworzenie bezpiecznych aplikacji Windows Phone
Ogólne rozważania dotyczące bezpiecznego projektu aplikacji
Bezpieczne szyfrowanie i przechowywanie danych
Bezpieczne algorytmy i tryby szyfrowania
Generowanie klucza i zarządzanie nim
Szyfrowanie pliku
Szyfrowanie bazy danych
13
593
594
597
598
599
599
600
600
603
607
607
610
610
611
612
612
613
614
615
617
620
621
623
624
626
628
630
631
632
632
633
635
635
636
636
636
637
639
Poleć książkęKup książkę 14
Spis treści
Bezpieczne generowanie liczby losowej
Zapewnianie bezpieczeństwa danych w pamięci i usuwanie zawartości pamięci
Uniknięcie ataku typu SQL injection
Implementacja bezpiecznej komunikacji
Użycie SSL i TLS
Weryfikacja certyfikatu SSL i TLS
Uniknięcie ataków typu XSS w komponentach WebBrowser i WebView
Użycie SSL i TLS w komunikacji sieciowej
Wyłączenie obsługi JavaScript
Bezpieczne tworzenie dynamicznego kodu HTML i JavaScript
Unikanie ataków przeprowadzanych przez skrypty lokalne
Bezpieczne przetwarzanie danych XML
Usunięcie bufora internetowego i plików cookie
Usunięcie plików cookie
Usunięcie bufora internetowego
Unikanie błędów kodu natywnego
Użycie funkcji mechanizmów obronnych
Podsumowanie
Rozdział 14. Tworzenie aplikacji mobilnych niezależnych od platformy
Wprowadzenie do aplikacji mobilnych niezależnych od platformy
Zastosowanie funkcjonalności natywnej
Udostępnienie funkcjonalności natywnej w systemie Android
Udostępnienie funkcjonalności natywnej w systemie iOS
Udostępnienie funkcjonalności natywnej w systemie Windows Phone
Poznajemy frameworki PhoneGap i Apache Cordova
Funkcje standardowe PhoneGap
Zapewnienie bezpieczeństwa aplikacji utworzonych za pomocą
frameworków PhoneGap i Cordova
Wiele luk w zabezpieczeniach frameworka Cordova
Ominięcie białej listy we frameworku Cordova
dla protokołu innego niż HTTP
Podsumowanie
Skorowidz
640
640
642
643
643
644
645
645
646
646
647
647
648
648
649
649
650
651
653
653
655
656
657
658
659
659
660
661
663
664
665
Poleć książkęKup książkę Rozdział
1
(Nie)bezpieczeństwo
aplikacji mobilnych
Nie ulega wątpliwości, że urządzenia mobilne zmieniły świat. W szczególności sposób pracy,
a także współdziałania i komunikacji z innymi osobami nie będzie już więcej taki sam. Użytkow-
nicy urządzeń mobilnych otrzymali wręcz nieskończone możliwości, które przez cały czas pozo-
stają dostępne w zasięgu ich palców. Sprawdzenie salda konta bankowego, poczty elektronicznej,
przeprowadzenie transakcji na giełdzie i znacznie więcej innych operacji jest po prostu na wycią-
gnięcie ręki. Opracowywanie aplikacji stało się na tyle popularnym zajęciem, że slogan Apple „Do
tego celu jest aplikacja” nie odbiega od rzeczywistości.
W tym rozdziale dowiesz się, jak przebiegała ewolucja aplikacji mobilnych, oraz poznasz ofe-
rowane przez nie korzyści. Przedstawię również dane dotyczące podstawowych luk w zabezpie-
czeniach, które występują w aplikacjach mobilnych. Te dane pochodzą bezpośrednio z mojego
doświadczenia i pokazują, że większość aplikacji mobilnych jest daleka od bezpiecznych. Następ-
nie przejdę do skategoryzowania wspomnianych luk w zabezpieczeniach na podstawie opraco-
wanej przez organizację OWASP (ang. open web application security project) listy dziesięciu naj-
większych zagrożeń dla aplikacji mobilnych. Zaprezentuję również ogólne omówienie wybranych
narzędzi typu open source zalecanych przez OWASP przeznaczonych do sprawdzania bezpie-
czeństwa aplikacji mobilnych. Zobaczysz też, jak za pomocą tych narzędzi identyfikować pewne
problemy wskazywane przez OWASP i gdzie ich szukać. Na końcu rozdziału przejdę do najnow-
szych trendów w zakresie zapewniania bezpieczeństwa aplikacjom mobilnym i tego, czego można
w tym obszarze oczekiwać w przyszłości.
29
Poleć książkęKup książkę 30
Rozdział 1 (cid:31) (Nie)bezpieczeństwo aplikacji mobilnych
Ewolucja aplikacji mobilnych
Pierwsze aplikacje dla telefonów komórkowych zostały opracowane samodzielnie przez samych
producentów urządzeń. Dla tych aplikacji istniała szczątkowa dokumentacja i można było znaleźć
niewiele informacji dotyczących wewnętrznego sposobu działania tych programów. Przyczyną
takiego stanu rzeczy były prawdopodobnie obawy producentów, że otwarcie platformy na aplika-
cje opracowane przez firmy zewnętrzne mogłoby doprowadzić do ujawnienia tajemnic jeszcze nie
do końca dopracowanej technologii. Wczesne aplikacje były podobne do wielu dostarczanych
przez producentów także w telefonach obecnej generacji, czyli na przykład książka adresowa, ka-
lendarz i proste gry, takie jak popularna gra Snake stworzona przez Nokię.
Wraz z pojawieniem się smartfonów jako następców palmtopów (ang. personal digital assistant,
PDA) tworzenie oprogramowania naprawdę nabrało rozpędu. Wzrost liczby dostępnych aplikacji
dla urządzeń mobilnych mógł być też spowodowany bezpośrednio zwiększeniem mocy oblicze-
niowej oraz możliwości oferowanych przez smartfony, a także pochodzącym z rynku konsumenc-
kiego wzrostem popytu na funkcjonalność. Gdy smartfony ewoluowały, aplikacje mobilne zaczęły
wykorzystywać usprawnienia wprowadzane na platformach. Do wspomnianych usprawnień zali-
czamy między innymi dodanie systemu nawigacji satelitarnej (ang. global positioning system,
GPS), aparatu fotograficznego, zwiększenie czasu działania urządzenia na baterii, wprowadzenie
lepszej jakości ekranów oraz procesorów. Te wszystkie ulepszenia spowodowały pojawianie się
coraz bardziej rozbudowanych aplikacji, które dzisiaj znamy.
Opracowywanie aplikacji mobilnych przez firmy zewnętrzne urzeczywistniło się w 2008 roku,
gdy firma Apple ogłosiła powstanie pierwszej usługi przeznaczonej do rozpowszechniania tego
rodzaju aplikacji — App Store. Sklep App Store powstał rok po wypuszczeniu na rynek pierwszego
smartfona Apple, czyli iPhone’a. Taki sam ruch wykonała firma Google ze swoim Android Market,
który obecnie jest znany pod nazwą Google Play. Do dzisiaj pojawiło się wiele kolejnych sklepów
oferujących aplikacje dla urządzeń mobilnych, między innymi Microsoft Store, Amazon Appstore
i BlackBerry World.
Coraz większa konkurencja na rynku tworzenia aplikacji dla urządzeń mobilnych doprowa-
dziła do pewnej fragmentacji rynków programistycznych. Większość aplikacji mobilnych jest
przeznaczona dla konkretnej platformy, a twórcy oprogramowania są zmuszeni do pracy z różnymi
systemami operacyjnymi, językami programowania i narzędziami, aby móc opracować programy
dla wielu platform. Aplikacje na platformę iOS tradycyjnie były tworzone w języku Objective-C,
aplikacje dla systemów Android i BlackBerry są tworzone w języku Java (w przypadku BlackBerry 10
również w Qt), natomiast aplikacje Windows Phone z użyciem .NET Framework. Tego rodzaju
fragmentacja bardzo często prowadzi do konieczności istnienia w firmie tworzącej oprogramowanie
dla urządzeń mobilnych wielu zespołów programistów oraz wielu baz kodu.
Jednak w ostatnim czasie na polu tworzenia aplikacji działających na różnych platformach
mobilnych można dostrzec pewne zmiany, które wynikają z chęci zmniejszenia kosztów związa-
nych z opracowywaniem programów. Niezależne od platformy frameworki oraz aplikacje oparte
na standardzie HTML5 i działające w przeglądarkach WWW zyskały popularność dokładnie
z wymienionych powodów. Można się spodziewać, że ten trend będzie coraz większy.
Poleć książkęKup książkę Ewolucja aplikacji mobilnych
31
Najczęstsze kategorie aplikacji mobilnych
Aplikacje mobilne powstały dla praktycznie każdego możliwego do wyobrażenia sobie celu. Tylko
w sklepach utrzymywanych przez Apple i Google znajduje się ponad 2 miliony aplikacji przezna-
czonych do różnorodnych zastosowań, między innymi wymienionych poniżej:
(cid:31) bankowość internetowa (Barclays),
(cid:31) zakupy (Amazon),
(cid:31) serwisy społecznościowe (Facebook),
(cid:31) streaming (Sky Go),
(cid:31) hazard (Betfair),
(cid:31) komunikatory internetowe (WhatsApp),
(cid:31) komunikatory głosowe (Skype),
(cid:31) poczta elektroniczna (Gmail),
(cid:31) współdzielenie plików (Dropbox),
(cid:31) gry (Angry Birds).
Aplikacje mobilne bardzo często oferują funkcjonalność dostępną także za pomocą aplikacji
internetowych. W wielu przypadkach używane jest to samo podstawowe API po stronie serwera,
a widok przeznaczony dla smartfonów jest generowany na poziomie warstwy prezentacyjnej.
Poza aplikacjami dostępnymi w różnych sklepach istnieją jeszcze aplikacje, które zostały sze-
roko zaadaptowane w świecie biznesu i przeznaczone do zapewniania obsługi kluczowych zadań
biznesowych. Wiele tego rodzaju aplikacji oferuje dostęp do ściśle strzeżonych danych korpora-
cyjnych. Poniżej wymieniłem wybrane rodzaje programów, na które się natknąłem podczas wy-
konywania zadań zleconych przez klientów:
(cid:31) Aplikacje magazynu dokumentów, pozwalające użytkownikom na uzyskanie dostępu
na żądanie do ściśle strzeżonych dokumentów biznesowych.
(cid:31) Aplikacje przeznaczone do prowadzenia małej księgowości, umożliwiające
użytkownikom tworzenie, przechowywanie i przekazywanie do wewnętrznych
systemów zestawień wydatków.
(cid:31) Aplikacje HR, pozwalające użytkownikom na uzyskanie dostępu do listy płac, kart pracy,
informacji o dniach wolnych oraz innych danych, które można uznać za poufne.
(cid:31) Aplikacje usług wewnętrznych, takie jak zoptymalizowane pod kątem zapewniania
dostępu do zasobów wewnętrznych, na przykład intranetu korporacyjnego.
(cid:31) Aplikacje wewnętrznych komunikatorów, umożliwiające użytkownikom komunikację
w czasie rzeczywistym niezależnie od ich położenia.
We wszystkich wymienionych powyżej przykładach aplikacje są uznawane za „wewnętrzne”
i zwykle są opracowywane przez daną organizację lub specjalnie na jej zlecenie. Dlatego też wiele
tych aplikacji wymaga użycia wirtualnej sieci prywatnej (ang. virtual private network, VPN) lub
dostępu do sieci wewnętrznej, aby mogły prawidłowo funkcjonować wraz z wewnętrzną infra-
strukturą. Zyskującym coraz większą popularność trendem w aplikacjach korporacyjnych jest
Poleć książkęKup książkę 32
Rozdział 1 (cid:31) (Nie)bezpieczeństwo aplikacji mobilnych
wprowadzenie technologii „geo-fence”, w której to aplikacja używa wbudowanego w urządzenie
GPS-u w celu sprawdzenia, czy użytkownik na pewno znajduje się w określonej lokalizacji, na
przykład biurze firmy, a następnie na podstawie wyniku tego sprawdzenia udziela dostępu lub
nakłada ograniczenia funkcjonalności.
Zalety aplikacji mobilnych
Nietrudno dostrzec, dlaczego aplikacje mobilne nabrały tak dużego znaczenia w stosunkowo
krótkim okresie. Bodźce komercyjne i korzyści przynoszone przez aplikacje mobilne są oczywiste.
Dają organizacjom możliwość dotarcia do użytkowników końcowych praktycznie w każdej chwili,
a ze względu na ogromną popularność smartfonów trafiają do znacznie większej grupy docelowej.
Jednak na sukces aplikacji mobilnych wpływ miało również wiele innych czynników, z których
wybrane wymieniłem poniżej:
(cid:31) Fundamenty dla aplikacji mobilnych powstały na bazie istniejących i popularnych
protokołów. W szczególności protokół HTTP jest doskonale znany przez programistów
i dlatego pozostaje dość powszechnie stosowany we wdrożeniach mobilnych.
(cid:31) Techniczny rozwój smartfonów pozwolił aplikacjom mobilnym na zaoferowanie znacznie
bardziej zaawansowanych funkcji oraz lepszych wrażeń, jakie odnoszą użytkownicy tych
aplikacji. Usprawnienia wprowadzone w zakresie rozdzielczości ekranu oraz pojawienie się
ekranów dotykowych stanowiły najważniejsze czynniki wpływające na poprawę interaktywności
programu, szczególnie w grach. Wydłużenie czasu działania urządzenia na baterii oraz
zwiększenie mocy obliczeniowej pozwalają nowoczesnym smartfonom na jednoczesne
uruchomienie nie tylko jednej, ale wielu aplikacji, które na dodatek będą działały znacznie
dłużej. To oznacza doskonałe udogodnienie dla użytkowników końcowych, ponieważ
otrzymują pojedyncze urządzenie, które może służyć do wielu celów.
(cid:31) Usprawnienia wprowadzone w technologiach sieci komórkowych doprowadziły do
znacznego wzrostu szybkości komunikacji. W szczególności powszechny zasięg 3G i 4G
pozwala użytkownikom na szerokopasmowy dostęp do internetu w smartfonach.
Aplikacje mobilne w pełni wykorzystują zalety szybkiej komunikacji, oferując dostęp
do naprawdę wielu usług internetowych.
(cid:31) Prostota podstawowych technologii oraz języków programowania używanych do
tworzenia aplikacji mobilnych pomogła w rewolucji mobilnej. Programy mogą być
tworzone za pomocą popularnych i dopracowanych języków, takich jak Java, które są
doskonale znane i mają ogromne bazy użytkowników.
Bezpieczeństwo aplikacji mobilnych
Aplikacje mobilne są narażone na istnienie wielu różnych luk w zabezpieczeniach, z których część
jest dziedziczona po tradycyjnych atakach zarówno na aplikacje internetowe, jak i zwykłe pro-
gramy komputerowe. Jednak kilka innych klas ataków jest charakterystycznych wyłącznie dla
platform mobilnych i pojawia się jako efekt sposobu użycia aplikacji mobilnych i na skutek ist-
nienia względnie unikatowych punktów wejścia i płaszczyzn ataku tworzonych przez te aplikacje.
Poleć książkęKup książkę Bezpieczeństwo aplikacji mobilnych
33
Poniżej wymieniłem możliwe płaszczyzny ataku na aplikacje mobilne — programiści powinni
mieć świadomość ich istnienia i potrafić się przed nimi bronić.
(cid:31) Większość aplikacji mobilnych prowadzi pewnego rodzaju komunikację sieciową.
Ze względu na sposób używania urządzeń mobilnych wspomniana komunikacja może
odbywać się przez niezaufane lub niebezpieczne sieci, takie jak Wi-Fi udostępniane przez
hotel lub lokal gastronomiczny, mobilne hot-spoty lub sieć komórkowa. Jeśli dane nie są
odpowiednio zabezpieczone podczas ich przesyłania, aplikacja może być narażona na wiele
różnych niebezpieczeństw, między innymi ujawnienie poufnych danych i ataki typu injection.
(cid:31) Skoro użytkownik nosi ciągle przy sobie urządzenie mobilne, rodzi to naprawdę wiele
możliwości jego zagubienia lub kradzieży. Programiści aplikacji mobilnych muszą zdawać
sobie sprawę z niebezpieczeństwa, jakie wiąże się z próbami odzyskania danych z systemu
plików urządzenia. Każda trwała treść pozostawiana przez aplikację w systemie plików
— niezależnie od tego, czy w trwałym magazynie danych, czy w buforze tymczasowym
— może potencjalnie doprowadzić do ujawnienia atakującemu poufnych danych.
(cid:31) Dość unikatowym dla aplikacji mobilnych scenariuszem jest zagrożenie płynące ze strony
samego urządzenia. Złośliwie działające malware szerzy się na platformie mobilnej,
co przynajmniej po części wynika z istnienia nieoficjalnych kanałów dystrybucji
oprogramowania. Programiści muszą zdawać sobie sprawę z niebezpieczeństwa,
jakim może być atak ze strony innej aplikacji zainstalowanej w urządzeniu mobilnym.
(cid:31) Aplikacje mobilne mogą pobierać dane wejściowe z wielu różnych możliwych źródeł,
co powoduje utworzenie znacznej liczby potencjalnych punktów wejścia. Na przykład
nietrudno natknąć się na aplikację akceptującą dane z jednego lub wielu wymienionych
źródeł: NFC (ang. near field communication), Bluetooth, aparat fotograficzny, mikrofon, SMS
(ang. short message service), USB (ang. universal serial bus), kody QR (ang. quick response) itd.
Do najpoważniejszych ataków na aplikacje mobilne zaliczamy te, które powodują ujawnienie
poufnych danych lub też ułatwiają włamanie do urządzenia. Tego rodzaju luki w zabezpiecze-
niach są najczęściej związane z urządzeniem mobilnym i danymi użytkownika końcowego, a dużo
rzadziej z wszystkimi użytkownikami danej usługi. Wprawdzie istniejące po stronie serwera luki
w zabezpieczeniach stanowią największe zagrożenie dla wdrożeń aplikacji mobilnych jako całości,
ponieważ mogą umożliwić niczym nieograniczony dostęp do systemów back endu, ale te problemy
są doskonale udokumentowane i rozumiane przez programistów. Istniejące po stronie serwera luki
w zabezpieczeniach wpływające na aplikacje mobilne nie będą omawiane w tej książce. Jeżeli chcesz
dowiedzieć się więcej na temat tego rodzaju ataków, zachęcam Cię do zapoznania się z książką The Web
Application Hacker’s Handbook (http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118026470.html).
Kwestie bezpieczeństwa aplikacji mobilnych nadal są błędnie postrzegane, choć z drugiej strony
ten obszar nie jest jeszcze w pełni dojrzały. Tak naprawdę większość aplikacji mobilnych wciąż
można uznać za niewystarczająco zabezpieczone. Po przetestowaniu w ostatnich latach setek aplika-
cji mobilnych w większości z nich znajdowałem jeden lub więcej poważnych błędów w zabezpie-
czeniach. Na rysunku 1.1 pokazałem procentowe dane dotyczące przetestowanych od 2012 roku
aplikacji mobilnych, w których znalazłem pewne najczęściej spotykane kategorie luk w zabezpie-
czeniach po stronie klienta.
Poleć książkęKup książkę 34
Rozdział 1 (cid:31) (Nie)bezpieczeństwo aplikacji mobilnych
Rysunek 1.1. Częstotliwość występowania luk w zabezpieczeniach aplikacji ostatnio sprawdzanych przez autora
(cid:31) Niezabezpieczony magazyn danych (63 ). Ta kategoria luk w zabezpieczeniach obejmuje
różne defekty, które prowadzą do tego, że aplikacja przechowuje w urządzeniu mobilnym
dane w postaci zwykłego tekstu. Z reguły jest stosowany zaciemniony format wykorzystujący
na stałe umieszczony w kodzie klucz lub też inne rozwiązanie pozwalające osobie
atakującej w dość łatwy sposób odczytać informacje przechowywane w magazynie danych.
(cid:31) Niezabezpieczone dane podczas ich transmisji (57 ). Ta kategoria obejmuje każdy
przypadek, gdy aplikacja nie używa szyfrowania warstwy transportu w celu ochrony
danych podczas ich transmisji. To obejmuje także sytuacje, w których wykorzystano
szyfrowanie warstwy transportu, choć sam mechanizm szyfrowania został
zaimplementowany w niewystarczająco bezpieczny sposób.
(cid:31) Brak zabezpieczeń binarnych (92 ). Ten defekt oznacza, że aplikacja nie stosuje żadnej
formy mechanizmu obronnego utrudniającego przeprowadzenie procesu inżynierii
odwrotnej, złośliwe manipulowanie programem lub jego debugowanie.
(cid:31) Możliwość ataku typu injection po stronie klienta (40 ). Ta kategoria luk w zabezpieczeniach
dotyczy scenariuszy, w których niezaufane dane wejściowe są przekazywane aplikacji, gdzie
następnie będą przetwarzane w niebezpieczny sposób. Typowe źródła ataków typu injection
obejmują na przykład inne aplikacje zainstalowane w urządzeniu oraz pochodzące z serwera
dane wejściowe przekazywane do aplikacji.
(cid:31) Na stałe umieszczone w kodzie hasła lub klucze (23 ). Ten problem powstaje, gdy
programista na stałe umieszcza w kodzie aplikacji pewne informacje wrażliwe, takie jak
hasło lub klucz szyfrowania.
(cid:31) Wyciek poufnych danych (69 ). Ta kategoria obejmuje sytuacje, w których aplikacja przypadkowo
ujawnia poufne dane w wyniku ataku typu side-channel, polegającego na utworzeniu dodatkowego
kanału informacyjnego. W szczególności mam tutaj na myśli następujący bez wiedzy programisty
wyciek danych na skutek użycia pewnego frameworka lub systemu operacyjnego.
Poleć książkęKup książkę Bezpieczeństwo aplikacji mobilnych
35
Kluczowe czynniki problemu
Problemy związane z bezpieczeństwem aplikacji mobilnych pojawiają się z wielu różnych powo-
dów. Z kolei luki w zabezpieczeniach zwykle występują, gdy aplikacja musi obsługiwać lub chronić
poufne dane bądź też przetwarzać dane pochodzące z niezaufanych źródeł. Jednak połączenie kilku
innych czynników może jeszcze bardziej spotęgować problem.
Niewystarczająca świadomość dotycząca zapewniania bezpieczeństwa
W przeciwieństwie do większości aplikacji internetowych, w których płaszczyzna ataku jest ogra-
niczona do pochodzących od użytkownika danych wejściowych, programiści tworzący aplikacje
mobilne muszą uwzględnić wiele różnych sytuacji powodujących problemy i odpowiednio chro-
nić program przed nimi. W porównaniu do budowy innego rodzaju aplikacji, tworzenie aplikacji
mobilnych jest dość unikatowe z tego względu, że nie można ufać systemowi operacyjnemu urzą-
dzenia, a nawet własnej aplikacji. Świadomość istnienia wielu płaszczyzn ataku i sposobów obrony
przed nimi jest dość ograniczona i właściwie słabo rozpowszechniona w społeczności programi-
stów tworzących tego rodzaju aplikacje. W kwestii zapewniania bezpieczeństwa mobilnego nadal
mamy do czynienia z szeroko rozpowszechnioną dezorientacją i błędnym pojmowaniem podsta-
wowych koncepcji. Jako przykład można tutaj przedstawić przekonanie wielu programistów o braku
konieczności szyfrowania lub ochrony danych trwale przechowywanych w urządzeniu. Ci pro-
gramiści tłumaczą to istnieniem szyfrowania standardowo zapewnianego przez wiele urządzeń.
Jak się później przekonasz, to założenie jest niewłaściwe i może doprowadzić do ujawnienia po-
ufnych danych użytkownika.
Nieustannie zmieniające się płaszczyzny ataku
Badanie poziomu bezpieczeństwa urządzeń mobilnych i aplikacji to nieustannie ewoluująca dzie-
dzina, w której regularnie są odkrywane nowe zagrożenia i koncepcje. Szczególnie w przypadku
urządzeń odkrywane są nowe luki w zabezpieczeniach, które mogą podważyć powszechnie przy-
jęte i stosowane w aplikacjach strategie ich ochrony. Jako przykład można tutaj podać odkrycie
w urządzeniach Apple luki o nazwie „goto fail” (https://support.apple.com/en-us/HT202934), osła-
biającej spójność tego, co wcześniej było uznawane za bezpieczny kanał komunikacji. W przypadku
tej luki można było obejść nawet zalecane środki bezpieczeństwa, takie jak przypinanie certyfikatu.
To doprowadziło do tego, że wielu programistów i ludzi profesjonalnie zajmujących się kwestia-
mi zapewniania bezpieczeństwa zaczęło szukać drugiego schematu szyfrowania i implementować
go w celu ochrony danych przepływających przez kanał SSL i TLS. Tego rodzaju luki w zabezpie-
czeniach potwierdzają, że nieustanne badania mogą wpływać na profil zagrożenia dla aplikacji
lub go zmieniać, nawet w trakcie prowadzenia już prac nad nią. Zespół programistów rozpo-
czynający pracę nad projektem i posiadający dokładną wiedzę na temat aktualnych zagrożeń mo-
że być zmuszony do wprowadzenia zmian w kwestii zapewniania bezpieczeństwa, jeszcze zanim
aplikacja zostanie ukończona i wydana.
Ograniczenia ekonomiczne i czasowe
Większość projektów programistycznych boryka się ze ściśle określonymi ograniczeniami zasobów
i czasu; projekty aplikacji mobilnych nie są pod tym względem wyjątkiem. Kwestie ekonomiczne
podczas tworzenia aplikacji bardzo często oznaczają, że zatrudnienie na stałe eksperta z dziedziny
Poleć książkęKup książkę 36
Rozdział 1 (cid:31) (Nie)bezpieczeństwo aplikacji mobilnych
bezpieczeństwa jest dla firmy po prostu niewykonalne. To dotyczy zwłaszcza mniejszych organi-
zacji, w których testowanie pod kątem zapewniania bezpieczeństwa zwykle jest przeprowadzane
na bardzo późnym etapie cyklu życiowego projektu. Nie ulega wątpliwości, że mała firma zwykle
ma dużo mniejszy budżet, a tym samym charakteryzuje się mniejszą skłonnością do ponoszenia
wydatków na usługi konsultingowe w zakresie zapewniania bezpieczeństwa. Wprawdzie krótki
test penetracyjny prawdopodobnie pozwoli na wykrycie najprostszych luk w zabezpieczeniach,
ale z reguły nie doprowadzi do wskazania znacznie subtelniejszych i skomplikowanych proble-
mów, które można odkryć, mając więcej czasu i cierpliwości. Nawet jeśli podczas pracy nad pro-
jektem jest stale dostępny ekspert z dziedziny bezpieczeństwa, to ścisłe ograniczenia czasowe mo-
gą uniemożliwić dokładną analizę każdego wydania aplikacji. Stosowanie zwinnych (ang. agile)
metod programowania, w których mamy do czynienia z wieloma iteracjami w krótkim okresie,
może jeszcze bardziej spotęgować ten problem.
Niestandardowy proces tworzenia aplikacji
Aplikacje mobilne są zwykle tworzone przez programistów danej organizacji lub zespoły zewnętrzne.
W pewnych przypadkach stosowane jest połączenie obu wymienionych podejść. Ogólnie rzecz bio-
rąc, jeśli organizacja regularnie opracowuje wiele aplikacji, doskonale przetestowane komponenty
będą wielokrotnie używane w różnych projektach, co bardzo często prowadzi do promocji znacz-
nie bardziej solidnego i bezpiecznego kodu. Jednak nawet jeśli aplikacje wykorzystują już istniejące
komponenty z innych projektów, to i tak bardzo często w tych programach pojawiają się biblioteki
lub frameworki, które nie zostały opracowane przez programistów budowanej aplikacji. W takim
przypadku twórcy projektu mogą nie mieć pełnej i dokładnej wiedzy dotyczącej używanego kodu,
co może z kolei doprowadzić do powstania problemów związanych z zapewnianiem bezpieczeństwa.
Co więcej, w niektórych przypadkach biblioteki również mogą zawierać luki w zabezpieczeniach,
jeśli nie zostaną dokładnie przetestowane. Przykładem może być tutaj luka addJavascriptInterface,
wpływająca na komponent Webview w systemie Android. Po jej wykorzystaniu osoba atakująca
może zdalnie włamać się do urządzenia. Dalsze badania nad tą luką pozwoliły określić, że wystę-
powała ona w bibliotekach używanych w celu zapewnienia integracji z reklamami i potencjalnie mogła
wpływać na ogromną liczbę aplikacji (https://labs.mwrinfosecurity.com/blog/webview-addjavascript
(cid:180)interface-remote-code-execution/).
Projekt OWASP Mobile Security
Projekt OWASP Mobile Security (https://www.owasp.org/index.php/OWASP_Mobile_Security_Project)
to inicjatywa utworzona przez OWASP, czyli grupę typu non profit, która jest doskonale znana ze
swojej pracy nad kwestiami związanymi z zapewnianiem bezpieczeństwa aplikacji internetowych.
Z uwagi na wiele podobieństw istniejących między aplikacjami mobilnymi i internetowymi natu-
ralne jest to, że grupa OWASP stara się promować i zwiększać świadomość w zakresie problemów
dotyczących bezpieczeństwa mobilnego.
Projekt oferuje bezpłatne, scentralizowane źródło klasyfikowania ryzyka w zakresie bezpieczeń-
stwa mobilnego. Ponadto dokumentuje działania programistyczne, które mogą zmniejszyć wpływ
lub prawdopodobieństwo wykorzystania danej luki w zabezpieczeniach. Projekt jest skoncentro-
wany na warstwie aplikacji, a nie bezpieczeństwie platformy mobilnej. Jednak pod uwagę jest
brane również ryzyko nierozerwalnie związane z użyciem poszczególnych platform mobilnych.
Poleć książkęKup książkę Bezpieczeństwo aplikacji mobilnych
37
10 najważniejszych zagrożeń aplikacji mobilnych według OWASP
Podobnie jak w przypadku dziesięciu największych zagrożeń OWASP, twórcy projektu Mobile
Security zdefiniowali odpowiadających im dziesięć najważniejszych problemów związanych z bez-
pieczeństwem na platformach mobilnych. W tym zakresie projekt dość szeroko kategoryzuje pewne
największe zagrożenia. Teraz pokrótce podsumuję pozycje wymienione na tej liście OWASP.
Znacznie bardziej szczegółowe omówienie poszczególnych problemów i wskazówki dotyczące ich
rozwiązań znajdziesz na stronie wiki projektu pod adresem https://www.owasp.org/index.php/
OWASP_Mobile_Security_Project#tab=Top_10_Mobile_Risks. Graficznie dziesięć najważniejszych
problemów według OWASP pokazałem na rysunku 1.2.
Rysunek 1.2. Wymienione przez grupę OWASP dziesięć najważniejszych problemów związanych
z bezpieczeństwem na platformach mobilnych
Oto krótkie omówienie dziesięciu największych zagrożeń aplikacji mobilnych według pro-
jektu OWASP Mobile Security:
(cid:31) M1: słaba kontrola po stronie serwera. Ta kategoria ryzyka została oceniona jako
najpoważniejsze zagrożenie dla aplikacji mobilnych. Wpływ tej kategorii został określony
jako niezwykle ciężki, poważny błąd w kontroli po stronie serwera, który może mieć istotne
konsekwencje dla biznesu. Ta kategoria obejmuje wszelkie luki w zabezpieczeniach, które
mogą występować po stronie serwera, między innymi w usługach sieciowych, konfiguracjach
serwerów WWW oraz w tradycyjnych aplikacjach internetowych. Umieszczenie tej kategorii
na liście najpoważniejszych zagrożeń dla platformy mobilnej można uznać za kontrowersyjne,
ponieważ problem nie występuje w urządzeniu mobilnym. Istnieją oddzielne projekty,
które wyraźnie zajmują się zagrożeniami aplikacji internetowych. Wprawdzie zdaję sobie
Poleć książkęKup książkę 38
Rozdział 1 (cid:31) (Nie)bezpieczeństwo aplikacji mobilnych
sprawę z wagi tego zagrożenia, ale ta kategoria nie jest dokładnie omówiona w książce,
ponieważ została już doskonale udokumentowana w innych publikacjach, na przykład we
wspomnianej wcześniej książce zatytułowanej The Web Application Hacker’s Handbook
(http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118026470.html).
(cid:31) M2: niezabezpieczony magazyn danych. Ta kategoria ryzyka wiąże się z sytuacją, gdy
aplikacja przechowuje w urządzeniu mobilnym poufne dane w formacie zwykłego tekstu
lub innej postaci łatwej do odczytania przez osobę atakującą. Wpływ tej kategorii został
określony jako niezwykle ciężki, poważny błąd, który zwykle może mieć poważne
konsekwencje dla biznesu, na przykład doprowadzi do kradzieży tożsamości, oszustwa
lub utraty reputacji. Poza umożliwieniem fizycznego dostępu do urządzenia,
niebezpieczeństwo wykorzystania luki w tej kategorii wiąże się również z uzyskaniem
dostępu do systemu plików, co może nastąpić poprzez użycie oprogramowania typu
malware lub złamanie zabezpieczeń urządzenia w inny sposób.
(cid:31) M3: niewystarczająca ochrona warstwy transportowej. Ta kategoria ryzyka odnosi się
do ochrony ruchu sieciowego i może pojawić się w każdej sytuacji, w której dane są
przekazywane w postaci zwykłego tekstu. Może dotyczyć także scenariuszy, w których
ruch jest szyfrowany, choć samo szyfrowanie zostało zaimplementowane w nieprawidłowy
sposób, na przykład przez dopuszczenie użycia samodzielnie podpisanych certyfikatów,
przeprowadzenie niewystarczającej weryfikacji certyfikatów lub użycie niebezpiecznych
pakietów szyfrowania. Tego rodzaju problemy mogą zostać wykorzystane przez osobę
atakującą znajdującą się w sieci lokalnej lub sieci operatora; nie jest wymagany fizyczny
dostęp do urządzenia.
(cid:31) M4: niezamierzony wyciek danych. Tego rodzaju problem pojawia się, gdy programista
przypadkowo umieszcza poufne informacje lub dane w miejscach urządzenia mobilnego,
które są łatwo dostępne z poziomu innych aplikacji. Bardzo często tego rodzaju zagrożenia
pojawiają się jako efekt uboczny danej platformy, przede wszystkim na skutek braku
wystarczającej wiedzy programistów odnośnie sposobów przechowywania danych przez
system operacyjny. Często spotykałem się z przykładami niezamierzonego wycieku
danych, między innymi z powodu stosowania buforowania, migawek i dzienników
zdarzeń aplikacji.
(cid:31) M5: kiepski mechanizm autoryzacji i uwierzytelniania. Ta kategoria ryzyka jest związana
z błędami popełnianymi podczas uwierzytelniania i autoryzacji, które mogą występować
w aplikacji mobilnej lub w implementacji działającej po stronie serwera. Lokalne
uwierzytelnianie w aplikacji mobilnej jest dość powszechne, szczególnie w aplikacjach
zapewniających dostęp do poufnych danych i wymagających działania w trybie offline.
W przypadku braku zastosowania odpowiednich środków bezpieczeństwa istnieje ryzyko
obejścia mechanizmu uwierzytelniania i tym samym uzyskania dostępu do aplikacji.
Tego rodzaju niebezpieczeństwo wiąże się również z błędami autoryzacji, które mogą
występować w aplikacji działającej po stronie serwera. Skutkiem jest wówczas umożliwienie
uzyskania dostępu lub wykonanie pewnych funkcji ponad uprawnieniami przydzielonymi
danemu użytkownikowi.
Poleć książkęKup książkę Bezpieczeństwo aplikacji mobilnych
39
(cid:31) M6: nieprawidłowe stosowanie kryptografii. Powszechnie przyjętą koncepcją jest to,
że aplikacja przechowująca dane w urządzeniu mobilnym powinna je szyfrować w celu
zapewnienia poufności tych danych. Stosowanym w takich przypadkach rozwiązaniem jest
szyfrowanie, ale ryzyko pojawia się, gdy jego implementacja zawiera pewne słabe strony.
W najgorszym przypadku osoba atakująca może uzyskać fragmenty danych w postaci
zwykłego tekstu lub nawet oryginalne dane w niezaszyfrowanej postaci. Najczęściej
niebezpieczeństwo pojawia się na skutek kiepskiego procesu zarządzania kluczem
szyfrowania. Przykładem może być tutaj umieszczenie klucza prywatnego w aplikacji,
umieszczenie na stałe w kodzie klucza statycznego lub użycie klucza, który może być
w niezwykle łatwy sposób znaleziony w urządzeniu — jak użycie jako klucza po prostu
identyfikatora urządzenia Android.
(cid:31) M7: możliwość przeprowadzenia ataku typu injection po stronie klienta. Ataki typu
injection mogą występować, gdy aplikacja mobilna akceptuje dane wejściowe pochodzące
z niezaufanych źródeł. To mogą być źródła wewnętrzne dla urządzenia, na przykład inna
aplikacja, lub też zewnętrzne, takie jak komponent działający po stronie serwera. Rozważ
przykład aplikacji społecznościowej pozwalającej użytkownikom na publikowanie komunikatów
zawierających różne informacje o tym, co się w danej chwili dzieje z daną osobą. Aplikacja
mobilna pobiera z witryny internetowej opublikowane przez innych użytkowników komunikaty,
które następnie wyświetla. Jeżeli osoba atakująca będzie w stanie utworzyć fałszywy
komunikat przechowywany we wspomnianej witrynie internetowej i pobrany później
przez innego użytkownika aplikacji mobilnej, wówczas po umieszczeniu tego komunikatu
w komponencie widoku sieciowego bądź w bazie danych działającej po stronie klienta
powstaje potencjalne niebezpieczeństwo przeprowadzenia ataku typu injection.
(cid:31) M8: podejmowanie ważnych decyzji na podstawie niezaufanych danych wejściowych.
Ryzyko w tej kategorii pojawia się, gdy decyzja dotycząca bezpieczeństwa jest podejmowana
na podstawie danych wejściowych pochodzących z zaufanego źródła. W większości
przypadków ryzyko wiąże się z mechanizmem komunikacji międzyprocesowej (IPC).
Na przykład rozważ organizację posiadającą zestaw aplikacji komunikujących się z tym
samym back endem. Programista decyduje, że zamiast wymagać uwierzytelnienia
użytkownika w każdej aplikacji, będą one współdzieliły jeden token sesji. Takie podejście
pozwala każdej aplikacji na uzyskanie dostępu do tokenu sesji. Do współdzielenia
wspomnianego tokenu używany jest mechanizm IPC, taki jak dostawca treści. Jeżeli
mechanizm IPC nie zostanie prawidłowo zabezpieczony, wszelkie inne zainstalowane
w urządzeniu aplikacje o złośliwym działaniu mogą potencjalnie użyć interfejsu IPC
w celu pobrania tokenu sesji i uzyskania dostępu do sesji użytkownika.
(cid:31) M9: nieprawidłowa obsługa sesji. Zarządzanie sesją to ważna koncepcja podczas tworzenia
oprogramowania. Sesja to mechanizm, który jest przez serwer używany do przechowywania
informacji o stanie podczas pracy z protokołem bezstanowym, takim jak HTTP lub SOAP.
Ryzyko tej kategorii obejmuje wszelkie luki w zabezpieczeniach powodujące ujawnienie
tokenu sesji osobie atakującej. Pod pewnymi względami nakłada się na koncepcje
przedstawione w punkcie „A2. Nieprawidłowe uwierzytelnianie i zarządzanie sesją”
na liście1 dziesięciu największych niebezpieczeństw dla aplikacji internetowych.
1 Tę listę znajdziesz na stronie wiki pod adresem https://www.owasp.org/index.php/Top_10_2013-Top_10 – przyp. tłum.
Poleć książkęKup książkę 40
Rozdział 1 (cid:31) (Nie)bezpieczeństwo aplikacji mobilnych
(cid:31) M10: brak zabezpieczeń binarnych. Ta kategoria ryzyka powoduje osłabienie
mechanizmów obronnych, które programista może — i w większości przypadków
powinien — wbudować w aplikację mobilną. Zabezpieczenia binarne z reguły spowalniają
osobę atakującą, która próbuje analizować lub modyfikować kod binarny aplikacji albo
przeprowadzić proces inżynierii odwrotnej.
Powyższa lista to niewątpliwie użyteczny zasób informacji o pojawiających się typach luk
w zabezpieczeniach, które mogą wystąpić w aplikacjach mobilnych. Można się spodziewać, że
wraz z postępującym coraz lepszym zabezpieczaniem aplikacji mobilnych będzie uzupełniana
o nowo odkryte zagrożenia. Ponadto będzie odgrywała jeszcze większą rolę w edukacji programi-
stów i profesjonalistów zajmujących się kwestiami zapewniania bezpieczeństwa.
Narzędzia rekomendowane przez OWASP Mobile Security
Narzędzia stanowią ważny element arsenału każdego profesjonalisty zajmującego się bezpieczeń-
stwem, niezależnie od tego, czy są przeznaczone po prostu do wspomagania ręcznego przeprowa-
dzania analizy, dostarczania frameworka do opracowania innych narzędzi czy pracy w charakte-
rze zasobu zapewniającego możliwość wzmocnienia możliwości programistów. Projekt OWASP
Mobile Security oferuje wiele narzędzi typu open source, które można wykorzystać podczas za-
pewniania bezpieczeństwa aplikacji. Informacje o nich znajdziesz na stronie wiki pod adresem
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Mobile_Tools. Te narzędzia
mogą okazać się użyteczne w trakcie poznawania tematu zapewniania bezpieczeństwa aplikacji
mobilnych. Poniżej przedstawiłem krótkie omówienie wspomnianych narzędzi:
(cid:31) iMAS (https://www.owasp.org/index.php/OWASP_iMAS_iOS_Mobile_Application_
(cid:180)Security_Project). Ten projekt utworzony przez MITRE Corporation jest rozprowadzanym
jako open source frameworkiem bezpiecznej aplikacji dla systemu iOS. Stanowi idealny
zasób dla programistów lub profesjonalistów zajmujących się zapewnianiem bezpieczeństwa,
którzy chcą poznać lub zrozumieć implementację mechanizmów bezpieczeństwa na
platformie iOS. Celem tego projektu jest zademonstrowanie i dostarczenie implementacji
chroniących aplikacje iOS oraz dane w znacznie większym stopniu niż za pomocą modelu
bezpieczeństwa oferowanego przez Apple. W efekcie powinno nastąpić wyraźne zmniejszenie
ryzyka, że osoba atakująca będzie w stanie przeprowadzić proces inżynierii odwrotnej
aplikacji, manipulować nią lub wykorzystać ewentualne luki w jej zabezpieczeniach.
Aby osiągnąć postawiony sobie cel, w ramach projektu powstało wiele implementacji
open source zapewniających rozwiązania w wielu obszarach, w których mogą występować
luki w zabezpieczeniach, czyli między innymi w zakresie kodów PIN w aplikacji, wykrycia
jailbreakingu urządzenia, ochrony przez debugowaniem i modyfikowaniem środowiska
uruchomieniowego aplikacji. Choć niektórymi z wymienionych tematów dokładnie
zajmiemy się w rozdziałach 2. i 3., projekt iMAS jest niewątpliwie użytecznym zasobem
pomagającym w poznaniu technik defensywnych, a także może służyć w charakterze
przewodnika dla programistów.
Poleć książkęKup książkę Bezpieczeństwo aplikacji mobilnych
41
(cid:31) GoatDroid (https://www.owasp.org/index.php/Projects/OWASP_GoatDroid_Project).
Projekt GoatDroid, opracowany przez Jacka Mannino i Kena Johnsona, dostarcza
samodzielne środowisko testowe dla aplikacji Android. To środowisko oferuje dwie
przykładowe implementacje pomagające w doprowadzeniu do perfekcji własnych
umiejętności. Pierwsza to FourGoats, czyli oparta na danych geolokalizacji sieć
społecznościowa. Druga to Herd Financial, czyli fikcyjna aplikacja bankowości
internetowej. Razem te dwa projekty zapewniają szerokie pokrycie większości
niebezpieczeństw wymienionych wcześniej na liście OWASP Top 10 i stanowią
dobry punkt wyjścia dla osób stawiających pierwsze kroki na obszarze zapewniania
bezpieczeństwa aplikacji Android.
(cid:31) iGoat (https://www.owasp.org/index.php/OWASP_iGoat_Tool_Project). Podobnie jak
w przypadku projektu GoatDroid, iGoat to aplikacja treningowa pozwalająca Ci
na udoskonalenie własnych umiejętności w zakresie oceny i analizy programów
przeznaczonych dla platformy iOS. Ten projekt typu open source został opracowany
przez Kena van Wyka, Jonathana Cartera i Seana Eidermillera. Kod źródłowy znajdziesz
na stronie https://code.google.com/archive/p/owasp-igoat/. Dostarczony jest zarówno
serwer, jak i aplikacja klienta wraz z wieloma ćwiczeniami dotyczącymi ważnych
tematów, na przykład lokalnego magazynu danych, pęku kluczy, SQL injection itd.
(cid:31) Damn Vulnerable iOS (https://www.owasp.org/index.php/OWASP_DVIA).
Ten utworzony przez Prateeka Gianchandaniego projekt dostarcza kolejną zawierającą
luki w zabezpieczeniach aplikację przeznaczoną do celów testowych. W połączeniu
z projektem iGoat obie aplikacje zapewniają dość dobre pokrycie niebezpieczeństw
wymienionych wcześniej na liście OWASP Top 10. Aplikacja składa się z wielu
zadań przeznaczonych do wykonania, co pozwala na jeszcze dokładniejsze poznanie
i zrozumienie tematów z zakresu bezpieczeństwa na platformie iOS. Uwzględnione
zostały tutaj tematy pominięte w iGoat, na przykład wykrycie poddania urządzenia
jailbreakingowi, manipulacje środowiskiem uruchomieniowym aplikacji, modyfikacje
plików binarnych aplikacji, a także zagadnienia związane z kryptografią.
(cid:31) MobiSec (https://www.owasp.org/index.php/OWASP_Mobile_Security_Project). To jest
utworzone przez Tony’ego DeLaGrange’a i Kevina Johnsona środowisko typu live,
przeznaczone do przeprowadzania testów penetracyjnych aplikacji mobilnych. Celem
przyświecającym temu projektowi jest dostarczenie pojedynczego zasobu oraz utrzymywanie
najnowszych wersji wszystkich narzędzi, które mogą okazać się przydatne podczas oceny
i analizy aplikacji mobilnych. W ramach tego projektu otrzymujemy rozwiązanie
podobne, jak stosowane w przypadku innych dystrybucji typu live, na przykład
w popularnej Kali Linux. Jednak projekt MobiSec jest zorientowany na zapewnianie
bezpieczeństwa na platformach mobilnych.
(cid:31) Androick (https://www.owasp.org/index.php/Projects/OWASP_Androick_Project).
W odróżnieniu od pozostałych projektów, ten dotyczy nieco innego tematu i jest
skoncentrowany na zautomatyzowanych zadaniach analizy śledczej aplikacji na platformie
Android, a nie na testach penetracyjnych lub samodzielnym udoskonalaniu umiejętności.
Ten projekt, utworzony przez Floriana Pradinesa, automatyzuje zdobywanie kluczowych
informacji i danych, jak pliki w formacie APK (ang. android package), dane aplikacji,
bazy danych i dzienniki zdarzeń z urządzenia.
Poleć książkęKup książkę 42
Rozdział 1 (cid:31) (Nie)bezpieczeństwo aplikacji mobilnych
Oczywiście w trakcie swojej działalności na polu zapewniania bezpieczeństwa aplikacjom mo-
bilnym napotkasz również inne, niewymienione tutaj narzędzia i nawet będziesz zmuszony do ich
użycia. O wielu z nich wspomnę w dalszych rozdziałach. Jednak projekty przygotowane i zalecane
przez OWASP są szczególnie użyteczne podczas doskonalenia własnych umiejętności, ponieważ
zostały dobrze udokumentowane, są dostępne jako oprogramowanie open source oraz zostały
opracowane specjalnie w celu pokrycia zagrożeń wymienionych na liście Top 10. Dlatego też go-
rąco zalecam zapoznanie się z tymi projektami i potraktowanie ich przez początkujących jako
punktu wyjścia do dalszych eksperymentów.
Przyszłość dziedziny zapewniania bezpieczeństwa
aplikacjom mobilnym
W ciągu minionych pięciu lat smartfony i aplikacje mobilne zyskały wielką popularność wśród
użytkowników. Obecnie nie ma absolutnie żadnych znaków wskazujących na zahamowanie tego
procesu i można oczekiwać, że ten trend będzie kontynuowany w przyszłości. Konsekwencją tej
rosnącej rewolucji mobilnej jest coraz większy nacisk na poznanie i zrozumienie zagrożeń poja-
wiających się podczas wdrażania aplikacji mobilnych, a także opracowanie znacznie efektywniej-
szych sposobów ich pokonywania. Jestem przekonany, że obecne zagrożenia na polu bezpieczeń-
stwa mobilnego nie są dobrze rozumiane, zwłaszcza w społeczności programistów.
Dlatego też można się spodziewać, że klasyczne luki w zabezpieczeniach, takie jak niezabez-
pieczony magazyn danych i niewystarczający poziom bezpieczeństwa warstwy transportowej, nadal
będą dominowały w najbliższej przyszłości.
Z tego względu zapewnianie bezpieczeństwa na platformach mobilnych to nieustannie ewolu-
ująca dziedzina i możemy się spodziewać pojawienia się nowych kategorii ataków wraz z kolej-
nymi zmianami w technologiach mobilnych. Wprowadzanie nowych komponentów sprzętowych,
takich jak czytniki linii papilarnych, oraz coraz szersze wykorzystywanie istniejących technologii,
na przykład NFC, bez wątpienia doprowadzi do odkrycia nowych luk w zabezpieczeniach. Szcze-
gólnie będzie to dotyczyć wdrożeń w środowiskach takich jak przetwarzanie płatności mobilnych,
na przykład używanych przez technologie Google Wallet i Apple Pay.
Podobnie jak w przypadku innych obszarów oprogramowania, w szczególności używanych do
obsługi transakcji finansowych, przestępcy będą szukali możliwości wykorzystania luk w zabez-
pieczeniach i łatwego zdobycia pieniędzy. Jesteśmy już świadkami wzrostu ilości oprogramowa-
nia typu malware atakującego aplikacje przeznaczone do obsługi bankowości internetowej oraz
oszustw związanych z wiadomościami SMS typu premium. Należy spodziewać się kontynuacji tego
trendu w przyszłości. Wspomniany wzrost doprowadził już do pewnych zmian w krajobrazie za-
grożeń. W odpowiedzi na ten wzrost niektórzy programiści zaczęli stosować zabezpieczenia binarne,
aby móc chronić aplikacje przed niebezpieczeństwami. Coraz większa świadomość czyhających nie-
bezpieczeństw prawdopodobnie doprowadzi do szerszego stosowania tego rodzaju zabezpieczeń oraz
użycia technologii takich jak dwupoziomowe uwierzytelnianie (ang. two-factor authentication).
Istnieje również prawdopodobieństwo dalszej ewolucji aplikacji mobilnych niezależnych od
platformy sprzętowej, ponieważ programiści dążą do zmniejszenia fragmentacji wśród różnych
platform mobilnych. To można dostrzec we wzroście dwóch wymienionych poniżej trendów
w programowaniu:
Poleć książkęKup książkę Podsumowanie
43
(cid:31) Aplikacje oparte na przeglądarce WWW. To pojęcie oznacza aplikacje, które są zwykle
„przyjaznym urządzeniom mobilnym” klonem głównej witryny internetowej,
wczytywanym poprzez przeglądarkę WWW urządzenia.
(cid:31) Aplikacje hybrydowe. To pojęcie odwołuje się do aplikacji mobilnych będących
natywnymi opakowaniami dla widoku sieciowego i bardzo często używających
frameworka w celu uzyskania dostępu do natywnych funkcji urządzenia.
Uzupełnieniem dla wspomnianych trendów jest opracowanie ogromnej liczby zarówno ko-
mercyjnych, jak i dostępnych bezpłatnie frameworków, z których każdy ma swoje dziwactwa i niu-
anse prowadzące do powstania różnorodnych luk w zabezpieczeniach. Jak w przypadku większości
zmian w technologii, te trendy przyniosły nowe rodzaje ataków or
Pobierz darmowy fragment (pdf)
