Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00067 005895 13604414 na godz. na dobę w sumie
Bezpieczeństwo aplikacji mobilnych. Podręcznik hakera - ebook/pdf
Bezpieczeństwo aplikacji mobilnych. Podręcznik hakera - ebook/pdf
Autor: , , , Liczba stron: 680
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-3694-0 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> hacking >> inne
Porównaj ceny (książka, ebook (-20%), audiobook).

Urządzenia mobilne zapewniają ogromną wygodę. Natychmiastowy dostęp do informacji czy dokumentu, niezależnie od lokalizacji użytkownika, jest czymś oczywistym. W ten sposób wszelkie ważne i wrażliwe informacje, takie jak dane pozwalające na identyfikację, dane finansowe czy poufne dokumenty, są cały czas na wyciągnięcie ręki — niestety, często ta ręka należy do kogoś, kto w żadnym przypadku nie powinien tych informacji uzyskać. Każdy, kto pisze aplikacje mobilne, musi pamiętać o kwestiach związanych z ich bezpieczeństwem. Konsekwencje nieuprawnionego dostępu do danych mogą być niezwykle poważne!

Niniejsza książka jest całościowym, a równocześnie bardzo praktycznym kompendium wiedzy o bezpieczeństwie aplikacji mobilnych. Uwzględniono tu problemy charakterystyczne dla platform iOS, Android i Windows Phone, dzięki czemu zaproponowanie najwłaściwszej strategii zabezpieczenia aplikacji jest o wiele prostsze. Wyjaśniono przyczyny podatności aplikacji mobilnych na ataki, opisano też techniki prowadzenia ataku i wykorzystywania luk w zabezpieczeniach. Bardzo dokładnie przedstawiono także strategie obrony i działania, dzięki którym programiści mogą chronić swoje aplikacje. Poradnik ten docenią przede wszystkim osoby przeprowadzające testy penetracyjne, konsultanci z zakresu bezpieczeństwa oraz oczywiście programiści.

Najciekawsze zagadnienia:

Aplikacja mobilna — popatrz na nią oczami hakera i zabezpiecz ją!


Dominic Chell jest ekspertem w dziedzinie zabezpieczeń aplikacji dla platformy iOS. Jest znany z wystąpień na konferencjach oraz jako autor wielu publikacji dotyczących bezpieczeństwa urządzeń mobilnych.

Tyrone Erasmus zajmuje się badaniami z zakresu bezpieczeństwa systemów. Interesuje się testami penetracyjnymi. Bada nowe narzędzia i techniki pojawiające się w tej sferze.

Shaun Colley jest ekspertem z zakresu bezpieczeństwa w urządzeniach mobilnych i oceny kodu natywnego. Zajmuje się też inżynierią wsteczną.

Ollie Whitehouse specjalizuje się w zapewnieniu bezpieczeństwa aplikacji i urządzeń mobilnych, interesuje się też technikami bezprzewodowymi.

Znajdź podobne książki Ostatnio czytane w tej kategorii

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)

Gdzie kupić całą publikację:

Bezpieczeństwo aplikacji mobilnych. Podręcznik hakera
Autor:
, , ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: