Komunikacja nieszyfrowana

Kategoria OWASP: MASVS-NETWORK: komunikacja sieciowa

Przegląd

Zezwolenie na komunikację sieciową w postaci tekstu nieszyfrowanego w aplikacji na Androida oznacza, że każdy, kto monitoruje ruch w sieci, może zobaczyć i manipulować przesyłanymi danymi. Jest to luka w zabezpieczeniach, jeśli przesyłane dane zawierają informacje poufne, takie jak hasła, numery kart kredytowych lub inne dane osobowe.

Niezależnie od tego, czy wysyłasz informacje poufne, czy nie, używanie tekstu nieszyfrowanego może być luką w zabezpieczeniach, ponieważ ruch w postaci tekstu nieszyfrowanego można też manipulować za pomocą ataków sieciowych, takich jak zatruwanie protokołu ARP lub DNS, co może umożliwić osobom przeprowadzającym ataki wpływanie na działanie aplikacji.

Wpływ

Gdy aplikacja na Androida wysyła lub odbiera dane w postaci tekstu nieszyfrowanego przez sieć, każdy, kto monitoruje sieć, może przechwycić i odczytać te dane. Jeśli te dane zawierają informacje poufne, takie jak hasła, numery kart kredytowych lub wiadomości osobiste, może to prowadzić do kradzieży tożsamości, oszustw finansowych 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 uwierzytelniające nieuczciwemu podmiotowi przechwytującemu ruch. Te dane mogą być następnie używane do uzyskania nieautoryzowanego dostępu do kont użytkownika.

Ryzyko: niezaszyfrowane kanały komunikacji

Przesyłanie danych przez niezaszyfrowane kanały komunikacji naraża dane udostępniane między urządzeniem a punktami końcowymi aplikacji. Te dane mogą zostać przechwycone i potencjalnie zmodyfikowane przez atakującego.

Środki zaradcze

Dane należy wysyłać przez zaszyfrowane kanały komunikacji. Zamiast protokołów, które nie oferują możliwości szyfrowania, należy używać bezpiecznych protokołów.

Szczególne zagrożenia

W tej sekcji zebraliśmy zagrożenia, które wymagają niestandardowych strategii ograniczania ryzyka lub zostały ograniczone na określonym poziomie pakietu SDK i są tu wymienione dla kompletności.

Ryzyko: HTTP

Wskazówki w tej sekcji dotyczą tylko aplikacji, które są przeznaczone na Androida 8.1 (poziom API 27) lub starszego. Od Androida 9 (poziom API 28) klienci HTTP, tacy jak URLConnection, Cronet i OkHttp, wymuszają używanie protokołu HTTPS, dlatego obsługa tekstu nieszyfrowanego jest domyślnie wyłączona. Pamiętaj jednak, że inne biblioteki klientów HTTP, takie jak Ktor, prawdopodobnie nie będą wymuszać tych ograniczeń dotyczących tekstu nieszyfrowanego i należy ich używać ostrożnie.

Środki zaradcze

Użyj funkcji NetworkSecurityConfig.xml, aby zrezygnować z ruchu w postaci tekstu nieszyfrowanego i wymusić używanie protokołu HTTPS w aplikacji, z wyjątkiem tylko tych domen, które są wymagane (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 spowodowanym zmianami adresów URL dostarczanych przez źródła zewnętrzne, takie jak serwery backendu.

Ryzyko: FTP

Używanie protokołu FTP do wymiany plików między urządzeniami wiąże się z kilkoma zagrożeniami, z których najważniejsze to brak szyfrowania w kanale komunikacji. Zamiast tego należy używać bezpieczniejszych alternatyw, takich jak SFTP lub HTTPS.

Środki zaradcze

Podczas implementowania 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 ją zabezpieczyć za pomocą protokołu TLS (Transport Layer Security), co zapewnia że wymiana danych między 2 punktami końcowymi jest szyfrowana, a tym samym uniemożliwia złośliwym użytkownikom podsłuchiwanie komunikacji i pobieranie informacji poufnych.

Architektury klient-serwer zwykle opierają się na interfejsach API należących do programisty. Jeśli Twoja aplikacja zależy od zestawu punktów końcowych interfejsu API, zapewnij dogłębne zabezpieczenia, stosując te sprawdzone metody ochrony komunikacji HTTPS:

  • Uwierzytelnianie – użytkownicy powinni uwierzytelniać się za pomocą bezpiecznych mechanizmów takich jak OAuth 2.0. Uwierzytelnianie podstawowe jest na ogół odradzane, ponieważ nie zapewnia mechanizmów zarządzania sesjami, a jeśli dane uwierzytelniające są nieprawidłowo przechowywane, można je zdekodować z Base64.
  • Autoryzacja – użytkownicy powinni mieć ograniczony dostęp tylko do zamierzonych zasobów zgodnie z zasadą najmniejszych uprawnień. Można to zaimplementować, stosując staranne rozwiązania 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 bezpieczeństwa. Na przykład w razie potrzeby rozważ obsługę protokołu TLSv1.3 z kompatybilnością wsteczną w przypadku komunikacji HTTPS .

Ryzyko: niestandardowe protokoły komunikacji

Implementowanie niestandardowych protokołów komunikacji lub ręczne implementowanie dobrze znanych protokołów może być niebezpieczne.

Niestandardowe protokoły umożliwiają programistom dostosowanie unikalnego rozwiązania, które dostosowuje się do zamierzonych potrzeb, ale każdy błąd podczas procesu tworzenia może potencjalnie prowadzić do luk w zabezpieczeniach. Na przykład błędy w tworzeniu mechanizmów obsługi sesji mogą potencjalnie umożliwić atakującym podsłuchiwanie komunikacji i pobieranie informacji poufnych w czasie rzeczywistym.

Z drugiej strony, implementowanie dobrze znanych protokołów, takich jak HTTPS, bez używania bibliotek systemu operacyjnego lub dobrze utrzymywanych bibliotek innych firm zwiększa prawdopodobieństwo wprowadzenia błędów w kodzie, które mogą utrudnić, a nawet uniemożliwić aktualizację zaimplementowanego protokołu w razie potrzeby. Dodatkowo może to spowodować takie same luki w zabezpieczeniach jak w przypadku używania niestandardowych protokołów.

Środki zaradcze

Używaj utrzymywanych bibliotek do implementowania dobrze znanych protokołów komunikacji

Aby zaimplementować w aplikacji dobrze znane protokoły, takie jak HTTPS, należy używać bibliotek systemu operacyjnego lub utrzymywanych bibliotek innych firm.

Dzięki temu programiści mogą korzystać z rozwiązań, które zostały dokładnie przetestowane, ulepszone z biegiem czasu i są stale aktualizowane pod kątem bezpieczeństwa, aby naprawiać typowe luki w zabezpieczeniach.

Ponadto, wybierając dobrze znane protokoły, programiści korzystają z szerokiej kompatybilności z różnymi systemami, platformami i środowiskami IDE, co zmniejsza prawdopodobieństwo popełnienia błędów przez człowieka podczas procesu tworzenia.

Używanie protokołu SFTP

Ten protokół szyfruje dane w ruchu. Podczas używania tego rodzaju protokołu wymiany plików należy wziąć pod uwagę dodatkowe środki:

Zasoby