BEZPIECZNE APLIKACJE MOBILNE NAJISTOTNIEJSZE ZAGADNIENIA Autor: Sławomir Jasek slawomir.jasek@securing.pl Wersja: 1.1, 2015.06.09
WSTĘP Dokument zawiera listę najistotniejszych zagadnień, na które należy zwrócić uwagę w trakcie tworzenia aplikacji mobilnych większego ryzyka np. finansowych, przetwarzających dane poufne lub osobowe. Zagadnienia zostały wybrane na podstawie podatności najczęściej identyfikowanych w tego typu aplikacjach. Bezpieczeństwo określonej aplikacji jest cechą indywidualną i zależy od wielu czynników. Poniższej listy nie można więc traktować jako wyczerpującej, a zastosowanie określonych mechanizmów bezpieczeństwa jest uzależnione od ryzyka i potencjalnych skutków ataku na aplikację.
1. ORGANIZACJA, PROJEKTOWANIE 1.1. Analiza ryzyka Scenariusze użycia, przepływ informacji, granice zaufania. Identyfikacja danych wrażliwych przetwarzanych przez aplikację. Cele potencjalnych intruzów i możliwe sposoby ich osiągnięcia. 1.2. Zasada najmniejszych przywilejów Co nie jest wprost zezwolone powinno być domyślnie zabronione. Nie przetwarzaj danych, których nie musisz przetwarzać. Nie wymagaj niepotrzebnych uprawnień. 1.3. Bezpieczeństwo jako proces Wpisz bezpieczeństwo do cyklu tworzenia oprogramowania. Każda zmiana funkcjonalności może mieć wpływ na bezpieczeństwo. Monitoruj znane podatności w używanych komponentach, bibliotekach. Wpływ zmian w nowych wersjach systemów operacyjnych na bezpieczeństwo aplikacji.
2. DANE PRZECHOWYWANE NA URZĄDZENIU 2.1. Dane współdzielone Nie używaj współdzielonych zasobów (np. karta SD) do przechowywania danych wrażliwych. Nie przydzielaj uprawnień umożliwiających dostęp innym aplikacjom do plików znajdujących się w katalogach prywatnych aplikacji (Android). 2.2. Logi, cache Wyłącz tryb debug w aplikacji produkcyjnej. Nie zapisuj w logach systemowych danych wrażliwych. Nie umieszczaj nadmiarowych informacji w crashlog-ach. W krytycznych aplikacjach/funkcjonalnościach nie używaj klawiatury systemowej (lub co najmniej wyłącz opcję autokorekty), ponieważ może zapisywać wprowadzane znaki w cache. Pamiętaj o tym że system automatycznie zachowuje zrzut ekranu (ios) i obiektów GUI (Android) w przypadku przechodzenia aplikacji w tło. Zablokuj przechowywanie zrzutów ekranu (ios). Wymagaj ponownego uwierzytelnienia przy powracaniu z tła (o ile ma to sens dla profilu ryzyka danej aplikacji i drastycznie nie narusza UX). 2.3. Dane w katalogach prywatnych Dane szczególnie wrażliwe (np. hasła dostępu, dane finansowe, dane lokalizacji) nie powinny być zapisywane na stałe w sposób umożliwiający dostęp do formy jawnej nawet w katalogach prywatnych aplikacji (Android) lub Keychain (ios). Dane te mogą być odzyskane z urządzenia np. w przypadku jego kradzieży, zgubienia, malware z uprawnieniami administracyjnymi. W przypadku wymogu biznesowego zapisywania takich danych, użyj mechanizmów szyfrujących uniemożliwiających łamanie siłowe w trybie offline. Patrz również rozdział 4.1.
2.4. Dane w pamięci RAM Przetrzymuj dane wrażliwe jak najkrócej w pamięci w formie jawnej w trakcie pracy aplikacji. W miarę możliwości, tam gdzie dane wrażliwe nie muszą być prezentowane użytkownikowi w formie jawnej (np. nr karty kredytowej), posługuj się mapowanymi po stronie serwera identyfikatorami, lub danymi w formie zaciemnionej.
3. TRANSMISJA 3.1. Weryfikuj certyfikat SSL W pełni weryfikuj dane certyfikatu serwera (common name - hostname, odcisk klucza CA, daty ważności, CRL). Nie akceptuj dowolnych certyfikatów. Jeśli istnieje taka opcja w testowej wersji aplikacji, upewnij się iż jest wyłączona w wersji produkcyjnej. 3.2. Certificate pinning W przypadku aplikacji większego ryzyka użyj mechanizmu tzw. certificate pinning weryfikacja cech certyfikatu serwera zaszytych w aplikacji (np. odcisk CA) 3.3. Nie pozwalaj na połączenia nieszyfrowane Zastosuj mechanizmy przeciwdziałające atakom typu SSL strip (patrz również konfiguracja środowiska serwera rozdział 8.1).
4. KOD I LOGIKA APLIKACJI 4.1. Prawidłowa konstrukcja mechanizmów bezpieczeństwa Kluczowe mechanizmy bezpieczeństwa takie jak uwierzytelnienie, autoryzacja, uzyskiwanie kluczy dostępowych lub szyfrujących powinny być skonstruowane w taki sposób, aby nie było możliwe ich ominięcie lub siłowe łamanie (zwłaszcza offline, po stronie urządzenia). Przykładowy algorytm uzyskiwania klucza w bezpieczny sposób: użytkownik wprowadza hasło, aplikacja wylicza funkcję kryptograficzną f(hasło; losowy seed kryptograficzny zapisany na urządzeniu w trakcie rejestracji; timestamp). W wyniku funkcji powstaje ciąg kryptograficzny, którego forma nie zdradza czy wprowadzone hasło jest poprawne. Ciąg ten jest wysyłany do serwera w celu weryfikacji. Serwer blokuje siłowe próby łamania hasła, jednocześnie nie utrudniając dostępu prawidłowym użytkownikom. 4.2. Nie opieraj bezpieczeństwa na niejawności algorytmu Kod aplikacji może zostać zdekompilowany, poddany analizie, zmodyfikowany i zrekompilowany. 4.3. Używaj sprawdzonych mechanizmów kryptograficznych Nie wymyślaj własnych mechanizmów kryptograficznych. Użyj sprawdzonych algorytmów i bibliotek, zaimplementuj je zgodnie z wytycznymi. 4.4. Nie umieszczaj w kodzie aplikacji kluczy szyfrujących, kodów dostępowych, tokenów Nie umieszczaj na stałe w aplikacji danych takich jak: kluczy szyfrujących będących jedyną składową potrzebną do uzyskania dostępu do danych wrażliwych. Patrz również rozdział 4.1. tokenów OAUTH pozwalających na dostęp np. do API Facebook-a, Google itp, z pozycji twórcy aplikacji. Tokeny takie powinny być przechowywane po stronie serwera, udostępniając funkcjonalność aplikacji przez API.
4.5. Nie używaj identyfikatorów UUID w mechanizmach bezpieczeństwa Unikalny identyfikator urządzenia zwracany przez system operacyjny (UUID) nie może być używany w mechanizmach bezpieczeństwa np. w celu identyfikacji użytkownika. Identyfikator ten może być ujawniony m.in. innej aplikacji działającej na tym samym urządzeniu i nieprawidłowo zabezpieczony (transmisja, serwisy reklamowe, statystyki). W zamian wygeneruj losowy identyfikator. 4.6. Usuń testowe dane Z aplikacji produkcyjnej usuń testowe dane, zaszyte adresy serwerów testowych/akceptacyjnych, metody debug. 4.7. Użyj narzędzi zaciemniających kod W celu utrudnienia procesu reverse-engineering użyj narzędzi zaciemniających kod aplikacji. Przykładowe narzędzia: Android: ProGuard (darmowy, warto poprawić domyślne ustawienia), DexGuard (komercyjny, znacznie skuteczniejsze zaciemnienie) ios: llvm, ios-class-guard (darmowe), Arxan (komercyjny)
5. KOMUNIKACJA IPC W wielu przypadkach domyślne ustawienia mechanizmów komunikacji międzyprocesowej nie są wystarczająco bezpieczne. Stosuj zasadę ograniczonego zaufania, weryfikuj źródło i treść wiadomości, łap wszystkie wyjątki. 5.1. Prawidłowe zabezpieczenie intent-ów (Android) Dla wszystkich wewnętrznych activity ustaw opcję exported=false. W przypadku gdy activity ma być wywołane przez inną aplikację, zweryfikuj jej certyfikat, np. przez ustawienie odpowiednio uprawnień (protectionlevel=signature). Zweryfikuj, czy uprawnienie o tej samej nazwie nie zostało zdefiniowane wcześniej przez wrogą aplikację. Ostrożnie używaj funkcji Pending Intent. Do wewnętrznej komunikacji używaj jedynie intent-ów typu explicit. Unikaj broadcast-ów. Nie przesyłaj danych wrażliwych w treści intent-ów mogą być podsłuchane. Staraj się nie wykorzystywać mechanizmu intent-filter do wewnętrznych activity. Nawet jeśli activity ma opcję exported=false, inna aplikacja może zdefiniować taki sam filtr. W przypadku wywołania spowoduje to wyświetlenie opcji wyboru obsługującej aplikacji użytkownikowi. Prawidłowo zweryfikuj źródło wiadomości w przypadku przetwarzania intentów systemowych. Waliduj dane otrzymane w treści wiadomości. 5.2. Prawidłowe zabezpieczenie mechanizmów Service, Content Provider, Broadcast Receiver... (Android) Odpowiednie uprawnienia, zasada najmniejszych przywilejów, walidacja. 5.3. Prawidłowe użycie URL-handlera (ios) W przypadku gdy aplikacja rejestruje URL-handler, nie pozwalaj na jego automatyczne wykorzystanie bez wiedzy użytkownika np. przez wrogą stronę www. Nie przesyłaj w ten sposób poufnych danych.
6. APLIKACJE HYBRYDOWE Aplikacje będące nakładką na serwis www, lub używające komponentów przeglądarkowych (WebView). Korzystanie z komponentów WebView jest mniej bezpieczne - niesie ze sobą wiele ryzyk (m.in. ataki wykorzystujące znane podatności w silnikach przeglądarek). Jeśli nie jest to niezbędne, staraj się unikać takich konstrukcji. 6.1. Wyłącz obsługę javascript, pluginów Zgodnie z zasadą najmniejszych przywilejów, jeśli javascript nie jest niezbędny, jego obsługa powinna zostać wyłączona. 6.2. Wyłącz cache Nawet zawartość stron HTTPS może być domyślnie przechowywana w lokalnym cache w sposób automatyczny, bez wiedzy programisty. 6.3. Nie ufaj danym zwracanym przez serwer Waliduj dane zwracane przez serwer (m.in. pod kątem wrogiego kodu javascript, clickjacking), zwłaszcza w przypadku korzystania z zewnętrznych serwisów. Patrz również rozdział 8.1.
7. ZEWNĘTRZNE KOMPONENTY 7.1. Komunikacja z zewnętrznymi serwisami Zgodnie z zasadą najmniejszych przywilejów ogranicz użycie komponentów komunikujących się z zewnętrznymi serwisami (zwłaszcza wykorzystując javascript binding) - w celach analitycznych (np. statystyki użycia), analizy wyjątków, wyświetlania reklam. Jeśli użycie takich komponentów jest niezbędne, skonfiguruj bezpieczne połączenie (HTTPS) oraz zminimalizuj ilość przesyłanych informacji. 7.2. Utrzymywanie bieżących wersji W przypadku ujawnienia błędów bezpieczeństwa, aktualizuj używane biblioteki i komponenty.
8. API SERWERA 8.1. Konfiguracja środowiska serwerowego Aktualizacje komponentów (serwery, systemy operacyjne). Prawidłowa konfiguracja SSL (algorytmy, parametry). Odpowiednie nagłówki HTTP, flagi cookies (m.in. Cache-Control, X-Frame- Options, HSTS, flaga Secure cookies...). Zabezpieczenie dostępu do interfejsów administracyjnych. Prawidłowe przechowywanie danych poufnych. 8.2. Bezpieczeństwo API Weryfikacja odporności na ataki w zakresie m.in: prawidłowe uwierzytelnienie bezpieczeństwo sesji kontrola dostępu do danych i funkcji SQL injection XML injection / entity expansion błędy walidacji błędy logiczne znane podatności w komponentach i bibliotekach inne, w zależności m.in. od użytej technologii
9. SECURING SecuRing to zespół ekspertów zajmujących się bezpieczeństwem aplikacji i systemów informatycznych. Naszą misją jest zapewnienie wsparcia dla naszych partnerów na każdym etapie procesu tworzenia i utrzymywania systemów i aplikacji. Oferujemy między innymi: testy bezpieczeństwa aplikacji webowych, mobilnych, WebService, grubego klienta, embeded systems, SaaS, cloud i innych testy i oceny bezpieczeństwa środowisk IT testy skuteczności zabezpieczeń (np. systemy antymalware, Identity Management, IPS, itp ) wsparcie w definiowaniu założeń dotyczących bezpieczeństwa aplikacji, ocena projektu systemu/aplikacji pod względem bezpieczeństwa, pomagamy wpisać bezpieczeństwo w cały cykl rozwoju i utrzymania systemów. Nasza firma działa od 2003 roku i w tym okresie z naszych usług skorzystały czołowe banki, instytucje ubezpieczeniowe, operatorzy telekomunikacyjni, firmy tworzące oprogramowanie a także instytucje administracji centralnej zarówno w Polsce jak i za granicą. Warto podkreślić, że SecuRing nie prowadzi aktywnej sprzedaży produktów związanych z bezpieczeństwem IT. Koncentrujemy się tylko i wyłącznie na usługach. Pozwala nam to zachować należyty obiektywizm i niezbędną w tego typu działalności niezależność od producentów rozwiązań. Zapraszamy do kontaktu. http://www.securing.pl e-mail: info@securing.pl Jontkowa Górka 14a 30-224 Kraków tel./fax.: (12) 425 25 75