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 formie tekstu nieszyfrowanego przez sieć, każdy, kto monitoruje sieć, może je przechwycić i odczytać. 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 tekstu jawnego może przekazać te dane do szkodliwego podmiotu przechwytującego 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.

Zagrożenie: 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 postaci zwykłego tekstu, dlatego należy z nimi postępować ostrożnie.

Środki zaradcze

Użyj funkcji NetworkSecurityConfig.xml, by zrezygnować z ruchu nieszyfrowanego tekstu i wymusić stosowanie protokołu HTTPS w aplikacji, z wyjątkami tylko w przypadku określonych domen (zwykle do celów 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 zamiast tego użyć bezpieczniejszych rozwiązań alternatywnych, takich jak SFTP lub HTTPS.

Środki zaradcze

Wdrażając mechanizmy wymiany danych przez internet, korzystaj z bezpiecznego protokołu, np. 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, że wymiana danych między dwoma punktami końcowymi jest szyfrowana, uniemożliwiając w ten sposób złośliwym użytkownikom podsłuchiwanie komunikacji i pobieranie poufnych danych.

Zwykle architektury klient-serwer bazują na interfejsach API należących do dewelopera. 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, mogą zostać zdekodowane 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 ścisłej kontroli dostępu do zasobów aplikacji.
  • Stosuj przemyślane i najnowsze zestawy szyfrów zgodnie ze sprawdzonymi metodami zapewniania bezpieczeństwa. Na przykład rozważ korzystanie z protokołu TLSv1.3 z zgodnością wsteczną w razie potrzeby na potrzeby 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 protokołów niestandardowych.

Łagodzenie

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, ulepszane z czasem 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żyj SFTP

Protokół ten szyfruje dane w ruchu. Podczas korzystania z tego 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