Zrozumienie 10 najważniejszych zagrożeń OWASP Mobile w rzeczywistych przypadkach

Posiadanie rekordów branżowych w tworzeniu aplikacji w 100% odpornych na ataki hakerów wiąże się z odpowiedzialnością i podstawową gwarancją, że żadne z rozwiązań cyfrowych opracowanych pod naszą nazwą nie będzie narażone na naruszenie bezpieczeństwa.

Aby to osiągnąć, zespół ds. zapewnienia jakości Appinventiv zna wszystkie możliwe zagrożenia bezpieczeństwa, z którymi może mierzyć się aplikacja. Znajomość zagrożeń ułatwia ignorowanie pułapek i pisanie bezpiecznych aplikacji.

Pełna wiedza na temat praktyk bezpiecznego kodowania OWASP (Open Web Application Security Project) pomaga nam być na szczycie, jeśli chodzi o zapewnianie bezpieczeństwa . Jest to internetowa społeczność specjalistów ds. bezpieczeństwa, którzy opracowali bezpłatną dokumentację, materiały szkoleniowe i narzędzia do tworzenia bezpiecznych aplikacji mobilnych i internetowych.

Oprócz innych rzeczy, opracowali również listę 10 zagrożeń bezpieczeństwa OWASP Mobile Top w aplikacjach mobilnych.

Chociaż dokument dotyczący praktyk bezpieczeństwa OWASP jest dość jasny, czasami firmom może być trudno połączyć go z rzeczywistymi sprawami.

W tym artykule przedstawimy podstawowy przegląd 10 najczęstszych zagrożeń bezpieczeństwa mobilnego i podamy przykłady ujawnionych w świecie rzeczywistym luk w zabezpieczeniach dla każdego z nich. Daje Ci wgląd w to, na co przygotowujemy się w Appinventiv, gdy pracujemy nad Twoją aplikacją.

Zanim przyjrzymy się zagrożeniom, przyjrzyjmy się statystykom.

NowSecure przyjrzał się aplikacjom w sklepie Google Play i App Store i stwierdził, że ponad 85% aplikacji narusza jedno z zagrożeń.

Spośród tych aplikacji 50% miało niezabezpieczone przechowywanie danych i gdzieś ta sama liczba aplikacji działała z ryzykiem niezabezpieczonej komunikacji . Oto wykres pokazujący procent występowania 10 największych zagrożeń OWASP Mobile

Lista 10 najczęstszych zagrożeń dla aplikacji mobilnych i najlepsze praktyki, aby ich uniknąć

M1: Niewłaściwe użycie platformy

Kategoria testów bezpieczeństwa OWASP składa się z niewłaściwego wykorzystania funkcjonalności urządzenia lub wystąpienia awarii podczas korzystania z mechanizmów bezpieczeństwa platformy. Może obejmować uprawnienia platformy, intencje Androida, niewłaściwe użycie TouchID, pęku kluczy itp.

Sprawa ze świata rzeczywistego:

Trzy aplikacje na iOS : „Fitness Balance app”, „Heart Rate Monitor” i „Calories Tracker app” wyszły na jaw, aby ominąć Apple Touch ID. Prosili użytkowników o użycie odcisku palca w celu uzyskania informacji o kondycji, podczas gdy używali go do pobierania pieniędzy z App Store.

Najlepsza praktyka, której należy unikać:

• Deweloper nie może zezwalać na szyfrowanie pęku kluczy przez trasę serwera i przechowywać klucze tylko w jednym urządzeniu, aby uniemożliwić wykorzystanie na innych serwerach lub urządzeniach.
• Deweloper musi zabezpieczyć aplikację za pomocą pęku kluczy, aby przechowywać klucz tajny aplikacji, który ma dedykowaną listę kontroli dostępu.
• Deweloper musi uzyskać pozwolenie na ograniczenie, które aplikacje mogą komunikować się z jego aplikacją.
• Deweloper musi kontrolować pierwszą z listy OWASP Mobile Top 10, definiując wyraźne intencje, a tym samym blokując wszystkie inne komponenty, aby uzyskać dostęp do informacji zawartych w intencji.

M2: Niepewne przechowywanie danych

OWASP uważa to za zagrożenie, gdy ktoś uzyska dostęp do zgubionego/skradzionego urządzenia mobilnego lub gdy złośliwe oprogramowanie lub inna przepakowana aplikacja zacznie działać w imieniu przeciwnika i wykonuje akcję na urządzeniu mobilnym.

Luka w niezabezpieczonym przechowywaniu danych zwykle prowadzi do następujących zagrożeń:

• Oszustwo
• Kradzież tożsamości
• Strata materialna.
• Uszkodzenie reputacji
• Naruszenie polityki zewnętrznej (PCI)

Sprawa ze świata rzeczywistego :

Aplikacje randkowe, takie jak Tinder, OKCupid i Bumble , były wielokrotnie sprawdzane pod kątem niezabezpieczonych praktyk przechowywania danych. Luki bezpieczeństwa obecne w tych aplikacjach różnią się w zależności od wykonalności, wagi i wykonalności, mogą ujawniać nazwę użytkownika, dane logowania, historię wiadomości, a nawet lokalizację, oprócz innych działań na koncie osobistym.

Najlepsze praktyki, których należy unikać:

• W przypadku systemu iOS praktyki bezpieczeństwa OWASP zalecają używanie celowo stworzonych podatnych na ataki aplikacji, takich jak iGoat, do modelowania zagrożeń dla ich struktury programistycznej i aplikacji. Pomoże to twórcom aplikacji na ios zrozumieć, w jaki sposób interfejsy API radzą sobie z procesami aplikacji i zasobami informacyjnymi.
• Twórcy aplikacji na Androida mogą używać powłoki Android Debug Bridge do sprawdzania uprawnień do plików docelowej aplikacji i DBMS do sprawdzania szyfrowania bazy danych. Powinni również używać narzędzia do analizy pamięci i monitora urządzeń z systemem Android, aby upewnić się, że pamięć urządzenia nie zawiera niezamierzonych danych.

M3: Niepewna komunikacja

Podczas tworzenia aplikacji mobilnej dane wymieniane są w modelu klient-serwer. Tak więc, gdy dane są przesyłane, powinny najpierw przejść przez sieć nośną urządzenia i Internet. Agenci zagrożeń mogą wykorzystywać luki w zabezpieczeniach i przechwytywać wrażliwe dane podczas podróży przez sieć. Oto różne istniejące zagrożenia:

• Przeciwnik, który udostępnia Twoją sieć lokalną — skompromitowane Wi-Fi
• Urządzenia sieciowe lub Carrier – wieże komórkowe, proxy, routery itp.
• Złośliwe oprogramowanie na urządzeniu mobilnym.

Przechwytywanie wrażliwych danych za pośrednictwem kanału komunikacyjnego skutkowałoby naruszeniem prywatności, co może prowadzić do:

• Kradzież tożsamości
• Oszustwo
• Uszkodzenie reputacji.

Sprawa ze świata rzeczywistego:

Firma ochroniarska Rapid7 ujawniła kilka luk w zabezpieczeniach smartfonów dla dzieci. Zegarki te były reklamowane jako używane przez rodziców do śledzenia dzieci i wysyłania im wiadomości lub wykonywania połączeń na ich smartwatchu.

Z zegarkami miały się kontaktować zatwierdzone numery kontaktowe w trybie białej listy, ale firma stwierdziła, że ​​filtry nawet nie działają. Zegarki przyjmowały nawet polecenia konfiguracyjne za pośrednictwem wiadomości tekstowych. Oznaczało to, że haker mógł zmienić ustawienia zegarka i narazić dzieci na niebezpieczeństwo.

„Możesz określić, gdzie znajduje się telefon lub dziecko, możesz uzyskać dostęp do dźwięku lub dzwonić do dzieci” — powiedział Deral Heiland, kierownik badań IoT w Rapid7.

Najlepsze praktyki, których należy unikać:

• Deweloperzy powinni nie tylko szukać wycieków w ruchu komunikowanym między aplikacją a serwerem, ale także urządzeniem, na którym znajduje się aplikacja i inne urządzenie lub sieć lokalna.

• Stosowanie protokołu TLS/SSL do kanałów transportowych jest również jedną z najlepszych praktyk bezpieczeństwa aplikacji mobilnych, które należy wziąć pod uwagę, jeśli chodzi o przesyłanie poufnych informacji i innych poufnych danych.

• Użyj certyfikatów wydanych przez zaufane weryfikacje łańcucha SSL.
• Nie wysyłaj poufnych danych przez alternatywne kanały, takie jak MMS, SMS lub powiadomienia push.
• Zastosuj osobną warstwę szyfrowania do danych wrażliwych przed przekazaniem do kanału SSL.

M4: Niepewne uwierzytelnianie

Agenci zagrożeń, którzy wykorzystują luki w uwierzytelnianiu, robią to za pomocą zautomatyzowanych ataków, które wykorzystują niestandardowe lub dostępne narzędzia.

Wpływ biznesowy M4 może być:

• Kradzież informacji
• Uszkodzenie reputacji
• Nieautoryzowany dostęp do danych.

Sprawa ze świata rzeczywistego :

W 2019 roku amerykański bank został zhakowany przez cyberprzestępcę, który wykorzystał lukę w witrynie banku i ominął dwuskładnikowe uwierzytelnianie, które zostało zaimplementowane w celu ochrony kont.

Atakujący zalogował się do systemu za pomocą skradzionych danych uwierzytelniających ofiary i po dotarciu do strony, na której należało wprowadzić kod PIN lub odpowiedź bezpieczeństwa, atakujący użył zmanipulowanego ciągu w adresie WWW, który ustawiał komputer jako rozpoznawany. Umożliwiło mu to przejście przez scenę i zainicjowanie przelewów.

Najlepsze praktyki, których należy unikać:

• Zespół ds. bezpieczeństwa aplikacji musi zbadać uwierzytelnianie aplikacji i przetestować je za pomocą ataków binarnych w trybie offline, aby określić, czy można je wykorzystać.
• Protokoły bezpieczeństwa testujące aplikacje internetowe OWASP muszą być zgodne z protokołami aplikacji mobilnych.
• W miarę możliwości korzystaj z metod uwierzytelniania online, podobnie jak w przypadku przeglądarki internetowej.
• Nie włączaj ładowania danych aplikacji, dopóki serwer nie uwierzytelni sesje użytkowników.
• Miejsca, w których dane lokalne mogą się znajdować, zapewniają, że są one zaszyfrowane za pomocą zaszyfrowanego klucza pochodzącego z danych logowania użytkowników.
• Żądanie trwałego uwierzytelnienia również musi być przechowywane na serwerze.
• Zespół ds. bezpieczeństwa powinien zachować ostrożność w przypadku tokenów autoryzacji zorientowanych na urządzenie w aplikacji, ponieważ jeśli urządzenie zostanie skradzione, aplikacja może stać się podatna na ataki.
• Ponieważ nieautoryzowany fizyczny dostęp do urządzeń jest powszechny, zespół ds. bezpieczeństwa musi wymusić regularne uwierzytelnianie poświadczeń użytkownika od strony serwera.

M5: Niewystarczające ryzyko kryptograficzne

Zagrożenia w tym przypadku to ci, którzy mają fizyczny dostęp do danych, które zostały błędnie zaszyfrowane. Lub gdy złośliwe oprogramowanie działa w imieniu przeciwnika.

Zepsuta kryptografia zazwyczaj skutkuje w następujących przypadkach:

• Kradzież informacji
• Kradzież własności intelektualnej
• Kradzież kodu
• Naruszenia prywatności
• Uszkodzenie reputacji.

Sprawa ze świata rzeczywistego :

Niekiedy temu alert z zespołu reagowania kryzysowego DHS Industrial Control Systems i dział doradczy firmy Philips ostrzegał użytkowników o możliwej luce w aplikacji Philips HealthSuite Health na Androida .

Problem, który był spowodowany niewystarczającą siłą szyfrowania, otworzył aplikację dla hakerów, którzy mogli uzyskać dostęp do aktywności tętna użytkowników, ciśnienia krwi, stanu snu, analizy wagi i składu ciała itp.

Najlepsze praktyki, których należy unikać:

• Aby rozwiązać to jedno z najczęściej występujących zagrożeń OWASP Top 10 Mobile , programiści muszą wybrać nowoczesne algorytmy szyfrowania do szyfrowania swoich aplikacji. Wybór algorytmu w dużej mierze dba o podatność.
• Jeśli programista nie jest ekspertem ds. bezpieczeństwa, musi powstrzymać się od tworzenia własnych kodów szyfrujących.

M6: Niepewne ryzyko autoryzacji

W takim przypadku agenci zagrożeń są w stanie uzyskać dostęp do aplikacji innej osoby, zazwyczaj za pośrednictwem zautomatyzowanych ataków, które wykorzystują niestandardowe lub dostępne narzędzia.

Może to prowadzić do następujących problemów:

• Kradzież informacji
• Uszkodzenie reputacji
• Oszustwo

Sprawa ze świata rzeczywistego :

Specjaliści ds. bezpieczeństwa informacji z Pen Test Partners włamali się do inteligentnego systemu alarmowego samochodowego Pandora . Teoretycznie aplikacja służy do śledzenia samochodu, wyłączania silnika w przypadku kradzieży i blokowania go do przybycia policji.

Z drugiej strony haker może przejąć konto i uzyskać dostęp do wszystkich danych oraz funkcji inteligentnego alarmu. Dodatkowo mogli:

• Śledź ruchy pojazdów
• Włącz i wyłącz system alarmowy
• Zablokuj i odblokuj drzwi samochodu
• Wyłącz silnik
• W przypadku Pandory hakerzy uzyskali dostęp do wszystkiego, o czym mówiono w samochodzie, przez mikrofon systemu antykradzieżowego.

Najlepsze praktyki, których należy unikać:

• Zespół ds. kontroli jakości musi regularnie testować uprawnienia użytkowników, uruchamiając tokeny sesji o niskim poziomie uprawnień dla poufnych poleceń.
• Deweloper musi pamiętać, że schematy autoryzacji użytkowników działają nieprawidłowo w trybie offline.
• Najlepszym sposobem zapobiegania temu ryzyku jest uruchamianie sprawdzania autoryzacji uprawnień i ról uwierzytelnionego użytkownika na serwerze, a nie na urządzeniu mobilnym.

M7: Ryzyko złej jakości kodu

W takich przypadkach niezaufane dane wejściowe są przekazywane przez jednostki do wywołań metod wykonanych w kodzie mobilnym. Skutkiem tego mogą być problemy techniczne, które mogą prowadzić do obniżenia wydajności, dużego zużycia pamięci i słabej działającej architektury front-end.

Sprawa ze świata rzeczywistego :

WhatsApp w zeszłym roku załatał lukę, którą hakerzy wykorzystywali do instalowania na smartfonach złośliwego oprogramowania monitorującego o nazwie Pegasus Spyware. Wszystko, co musieli zrobić, to nawiązać połączenie audio WhatsApp na docelowe numery telefonów.

W kilku prostych krokach hakerzy byli w stanie dostać się do urządzeń użytkowników i uzyskać do nich zdalny dostęp.

Najlepsze praktyki, których należy unikać:

• Zgodnie z praktykami bezpiecznego kodowania OWASP , kod powinien zostać przepisany na urządzeniu mobilnym zamiast naprawiania go po stronie serwera. Deweloperzy muszą zauważyć, że złe kodowanie po stronie serwera bardzo różni się od słabego kodowania na poziomie klienta. Oznacza to, że osobną uwagę należy poświęcić zarówno słabym kontrolkom po stronie serwera, jak i kontrolkom po stronie klienta.
• Deweloper musi używać narzędzi innych firm do analizy statycznej, aby zidentyfikować przepełnienia bufora i wycieki pamięci.
• Zespół musi utworzyć listę bibliotek innych firm i okresowo sprawdzać, czy nie ma nowszych wersji.
• Deweloperzy powinni widzieć wszystkie dane wejściowe klienta jako niezaufane i weryfikować je niezależnie od tego, czy pochodzą od użytkowników, czy od aplikacji.

M8: Ryzyko manipulacji kodem

Zazwyczaj w takim przypadku osoba atakująca wykorzystuje modyfikację kodu za pośrednictwem złośliwych form aplikacji hostowanych w zewnętrznych sklepach z aplikacjami. Mogą również nakłonić użytkowników do zainstalowania aplikacji poprzez ataki typu phishing.

Najlepsze praktyki, których należy unikać:

• Deweloperzy muszą upewnić się, że aplikacja jest w stanie wykryć zmiany kodu w czasie wykonywania.
• Plik build.prop musi zostać sprawdzony pod kątem obecności nieoficjalnej pamięci ROM w systemie Android i aby dowiedzieć się, czy urządzenie jest zrootowane.
• Deweloper musi użyć sum kontrolnych i ocenić podpisy cyfrowe, aby sprawdzić, czy doszło do manipulacji plikami.
• Programista może upewnić się, że klucze aplikacji, kod i dane zostaną usunięte po wykryciu manipulacji.

M9: Ryzyko inżynierii odwrotnej

Osoba atakująca zazwyczaj pobiera docelową aplikację ze sklepu z aplikacjami i analizuje ją w swoim lokalnym środowisku za pomocą zestawu różnych narzędzi. Następnie mogą zmienić kod i zmienić działanie aplikacji.

Sprawa ze świata rzeczywistego :

Pokemon Go niedawno spotkało się z naruszeniem bezpieczeństwa, gdy okazało się, że użytkownicy dokonali inżynierii wstecznej aplikacji, aby poznać okolice Pokemonów i złapać je w ciągu kilku minut.

Najlepsze praktyki, których należy unikać:

• Według OWASP mobile security najlepszym sposobem zabezpieczenia aplikacji przed ryzykiem jest użycie tych samych narzędzi, których hakerzy użyliby do inżynierii wstecznej.
• Deweloper musi również zaciemnić kod źródłowy, aby stał się trudny do odczytania, a następnie przeprowadzić inżynierię wsteczną.

M10: Ryzyko związane z zewnętrzną funkcjonalnością

Zazwyczaj haker przegląda obcą funkcjonalność aplikacji mobilnej, aby odkryć ukryte funkcjonalności w systemach zaplecza. Atakujący wykorzystałby obce funkcje z własnych systemów bez udziału użytkowników końcowych.

Sprawa ze świata rzeczywistego :

Ideą aplikacji Wifi File Transfer było otwarcie portu w Androidzie i umożliwienie połączeń z komputera. Problem ? Brak uwierzytelniania, takiego jak hasła, co oznacza, że ​​każdy może połączyć się z urządzeniem i uzyskać do niego pełny dostęp.

Najlepsze praktyki, których należy unikać:

• Upewnij się, że w ostatecznej wersji nie ma kodu testowego
• Upewnij się, że w ustawieniach konfiguracyjnych nie ma ukrytego przełącznika
• Dzienniki nie mogą zawierać żadnego opisu procesu serwera zaplecza
• Upewnij się, że pełne dzienniki systemowe nie są udostępniane aplikacjom przez producentów OEM
• Punkty końcowe interfejsu API muszą być dobrze udokumentowane.