Komunikacja nieszyfrowana

Kategoria OWASP: MASVS-NETWORK: komunikacja sieciowa

Omówienie

Zezwalanie na komunikację sieciową w postaci zwykłego tekstu w aplikacji na Androida oznacza, że każdy, kto monitoruje ruch w sieci, może zobaczyć przesyłane dane i zmodyfikować je. Jest to luka, jeśli przesyłane dane obejmują informacje poufne, takie jak hasła, numery kart kredytowych lub inne dane osobowe.

Bez względu na to, czy wysyłasz informacje poufne, czy nie, używanie niezaszyfrowanego tekstu może stanowić lukę w zabezpieczeniach, ponieważ ruch w postaci niezaszyfrowanego tekstu może być również modyfikowany przez ataki sieciowe, takie jak ARP czy zatrucie DNS, co może umożliwić atakującym wpływanie na działanie aplikacji.

Wpływ

Gdy aplikacja na Androida wysyła lub odbiera dane w pełnym tekście przez sieć, każdy, kto monitoruje sieć, może przechwycić i odczytać te dane. Jeśli te dane obejmują informacje poufne, takie jak hasła, numery kart kredytowych czy wiadomości osobiste, może to doprowadzić do kradzieży tożsamości, oszustwa finansowego i innych poważnych problemów.

Na przykład aplikacja przesyłająca hasła w postaci zwykłego tekstu może ujawnić te dane logowania złośliwemu aktorowi przechwytującemu ruch. Te dane mogą zostać wykorzystane do uzyskania nieautoryzowanego dostępu do kont użytkowników.

Zagrożenie: niezaszyfrowane kanały komunikacji

Przesyłanie danych przez niezaszyfrowane kanały komunikacji ujawnia dane udostępniane między urządzeniem a punktami końcowymi aplikacji. Dane te mogą zostać przechwycone i potencjalnie zmodyfikowane przez osobę przeprowadzającą atak.

Środki zaradcze

Dane powinny być przesyłane przez szyfrowane kanały komunikacji. Bezpieczne protokoły powinny być używane jako alternatywa dla protokołów, które nie oferują możliwości szyfrowania.

Konkretne zagrożenia

W tej sekcji zebraliśmy zagrożenia, które wymagają niestandardowych strategii łagodzenia lub zostały złagodzone na określonym poziomie pakietu SDK.

Ryzyko: HTTP

Wskazówki w tej sekcji dotyczą tylko aplikacji kierowanych na Androida 8.1 (poziom interfejsu API 27) lub starszego. Począwszy od Androida 9 (poziom API 28) klienci HTTP, tacy jak URLConnection, Cronet i OkHttp, wymuszają używanie HTTPS, dlatego obsługa w formie zwykłego tekstu jest domyślnie wyłączona. Pamiętaj jednak, że inne biblioteki klienta HTTP, takie jak Ktor, prawdopodobnie nie będą egzekwować tych ograniczeń w formie zwykłego tekstu, dlatego należy z nimi postępować ostrożnie.

Środki zaradcze

Użyj pliku NetworkSecurityConfig.xml, aby zrezygnować z ruchu nieszyfrowanego i wymusić HTTPS w aplikacji z wyjątkami tylko dla określonych domen (zwykle do debugowania):

Xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

Ta opcja pomaga zapobiegać przypadkowym regresjom w aplikacjach z powodu zmian adresów URL udostępnianych przez źródła zewnętrzne, takie jak serwery zaplecza.

Ryzyko: FTP

Korzystanie z protokołu FTP do wymiany plików między urządzeniami wiąże się z kilkoma zagrożeniami, z których największym jest brak szyfrowania kanału komunikacyjnego. Należy używać bezpieczniejszych alternatyw, takich jak SFTP lub HTTPS.

Środki zaradcze

Podczas wdrażania w aplikacji mechanizmów wymiany danych przez Internet należy używać bezpiecznego protokołu, takiego jak HTTPS. Android udostępnia zestaw interfejsów API, które umożliwiają programistom tworzenie logiki klient-serwer. Można to zabezpieczyć za pomocą protokołu TLS, który zapewnia szyfrowanie danych przesyłanych między dwoma punktami końcowymi, uniemożliwiając w ten sposób złośliwym użytkownikom podsłuchiwanie komunikacji i pobieranie poufnych danych.

Architektury klient-serwer często korzystają z interfejsów API należących do deweloperów. Jeśli Twoja aplikacja zależy od zestawu punktów końcowych interfejsu API, zadbaj o szczegółowe zabezpieczenia, stosując te sprawdzone metody dotyczące bezpieczeństwa, które chronią komunikację HTTPS:

  • uwierzytelniania – użytkownicy powinni się uwierzytelniać za pomocą bezpiecznych mechanizmów, takich jak OAuth 2.0; Nie zalecamy korzystania z uwierzytelniania podstawowego, ponieważ nie zapewnia ono mechanizmów zarządzania sesją, a jeśli dane uwierzytelniające są nieprawidłowo przechowywane, można je odkodować z formatu Base64.
  • Autoryzacja – użytkownicy powinni mieć dostęp tylko do zasobów docelowych zgodnie z zasadą najmniejszych uprawnień. Można to zaimplementować, stosując rozwiązania do starannej kontroli dostępu do zasobów aplikacji.
  • Upewnij się, że używane są przemyślane i najnowsze zestawy szyfrów zgodnie ze sprawdzonymi metodami dotyczącymi zabezpieczeń. Rozważ na przykład obsługę protokołu TLSv1.3 z kompatybilnością wsteczną (w razie potrzeby) w przypadku komunikacji HTTPS.

Ryzyko: niestandardowe protokoły komunikacji

Wdrażanie niestandardowych protokołów komunikacji lub próba ręcznego wdrażania znanych protokołów może być niebezpieczne.

Chociaż protokoły niestandardowe umożliwiają deweloperom tworzenie niepowtarzalnych rozwiązań dostosowanych do potrzeb, każdy błąd w procesie tworzenia może potencjalnie spowodować luki w zabezpieczeniach. Na przykład błędy w rozwijaniu mechanizmów obsługi sesji mogą sprawić, że atakujący będą mogli podsłuchiwać komunikacji i pozyskiwać poufne informacje w biegu.

Z drugiej strony implementowanie znanych protokołów, takich jak HTTPS, bez używania systemu operacyjnego lub dobrze utrzymanych bibliotek innych firm, zwiększa prawdopodobieństwo wprowadzenia błędów kodowania, które mogą utrudnić, a nawet uniemożliwić aktualizację zaimplementowanego protokołu w razie potrzeby. Może to też spowodować luki w zabezpieczeniach podobne do tych, które występują w przypadku korzystania z protokołów niestandardowych.

Środki zaradcze

Korzystanie z bibliotek z aktualizacjami do implementowania znanych protokołów komunikacyjnych

Aby zaimplementować w aplikacji znane protokoły, takie jak HTTPS, należy użyć bibliotek systemowych lub bibliotek innych firm.

Dzięki temu deweloperzy mogą korzystać z rozwiązań, które zostały dokładnie przetestowane, ulepszone z upływem czasu i stale otrzymują aktualizacje zabezpieczeń w celu naprawiania typowych luk w zabezpieczeniach.

Ponadto wybór dobrze znanych protokołów zapewnia deweloperom szeroką zgodność z różnymi systemami, platformami i IDE, co zmniejsza prawdopodobieństwo popełnienia błędu przez człowieka w trakcie procesu tworzenia.

Używanie SFTP

Ten protokół szyfruje dane podczas przesyłania. Podczas korzystania z tego typu protokołu wymiany plików należy wziąć pod uwagę dodatkowe środki ostrożności:

  • SFTP obsługuje różne rodzaje uwierzytelniania. Zamiast uwierzytelniania za pomocą hasła należy użyć metody uwierzytelniania za pomocą klucza publicznego. Takie klucze powinny być tworzone i przechowywane w bezpieczny sposób. W tym celu zalecamy korzystanie z magazynu kluczy Androida.
  • Upewnij się, że obsługiwane szyfry są zgodne ze sprawdzonymi metodami zapewniania bezpieczeństwa.

Materiały