Bezpieczeństwo aplikacji w erze agentów

Cześć, jestem Kristen.

Cześć, a ja jestem Sabs.

Chcemy dziś porozmawiać o bezpieczeństwie w erze agentów.

W zeszłym roku w ramach programu Android Bug Hunters wypłaciliśmy ponad 2 miliony dolarów nagród, a w przypadku urządzeń mobilnych – ponad 200 tysięcy dolarów.

W dzisiejszej erze agentów bezpieczeństwo aplikacji stale się zmienia.

Omówmy więc narzędzia, które pomogą nam szybko i skutecznie rozwiązać te problemy.

Aby poprawić skuteczność agentów w zakresie bezpieczeństwa Androida, nie wystarczy lepszy prompt.

Są to narzędzia i przepływy pracy, które pomagają agentom zrozumieć nasze łańcuchy narzędzi i interfejs API, aby zapewnić bezpieczeństwo aplikacji.

Jest 16:30.

W czwartek.

Wydajesz wersję, a CI świeci się na czerwono. Jest tylko 1 błąd: odbiornik został zarejestrowany bez flagi eksportu.

Niezależnie od tego, czy pracujesz w małym zespole, w którym każdy robi wszystko, czy w dużym, gdzie kontrole bezpieczeństwa są przeprowadzane podczas wydawania wersji, rzeczywistość jest taka sama.

Jesteśmy inżynierami produktu, którzy szybko wprowadzają wysokiej jakości funkcje, i niekoniecznie zajmujemy się badaniami nad bezpieczeństwem.

Jaka jest naturalna reakcja?

Przekazujemy więc to ostrzeżenie narzędziu agentowemu i prosimy agenta o rozwiązanie problemu.

Jednak narzędzie agentowe, które działa bez kontekstu projektu, ma 3 słabe punkty.

Może nie wiedzieć, że aplikacja jest zbudowana z modułów funkcji dynamicznych lub pakietów z wieloma plikami APK.

Widzi plik, a nie dostarczony artefakt.

Może nie być w stanie prześledzić przepływu danych z interfejsu Kotlin do współdzielonej logiki KMP i natywnych wywołań JNI w C++.

Widzi tylko jedną warstwę.

Wreszcie może nie mieć informacji o minimalnej wersji pakietu SDK ani o wariantach kompilacji Gradle.

Wskazaliśmy więc agentowi aplikację i poprosiliśmy o audyt bezpieczeństwa.

Otrzymaliśmy 6 wyników.

I tu jest haczyk.

Każda z nich jest poprawna.

Są one uzasadnione, ale tylko jeden z nich jest błędem, od którego zaczęliśmy.

Pozostałe informacje to połączenie sprawdzonych metod, kwestii do dalszego zbadania, spekulacji i rzeczy, które mogą nawet nie mieć zastosowania.

Jeśli teraz przeskalujesz to do prawdziwej bazy kodu z większą liczbą ostrzeżeń, w każdym żądaniu pull będziesz mieć pokusę, aby użyć suppress lint.

Możesz nie mieć możliwości scalenia tej zmiany, a nawet całkowicie przeoczyć lukę w zabezpieczeniach.

W ten sposób prawdziwe luki w zabezpieczeniach mogą zostać niezauważone.

Narzędzie nie było nieostrożne, ale ostrożność nie jest równoznaczna z przydatnością.

Przeanalizujmy konkretny przykład.

Załóżmy, że poprosisz agenta o sprawdzenie każdego wyeksportowanego komponentu w aplikacji pod kątem przekierowania intencji aplikacji.

To prawdziwe zadanie związane z bezpieczeństwem, a w przypadku aplikacji wielomodułowej jest ono bardzo duże.

To jest rodzaj żądania, w którym faktycznie pojawia się koszt.

Bez wskazówek dotyczących Androida agent nie ma strategii na to pytanie.

Dlatego stosuje metodę brute-force.

Może odczytywać moduły, które nic nie eksportują.

Może on ponownie wyprowadzić z podstawowej zasady to, co sprawia, że przekierowanie intencji jest możliwe do wykorzystania.

Może podążać ścieżkami, które nigdy nie były dostępne.

Płacisz za eksplorację, a nie za analizę.

Umiejętność to brakująca strategia.

Na przykład umiejętności związane z bezpieczeństwem Androida zapewniają agentowi instrukcje zgodne z aktualnymi wytycznymi, czyli taką samą sekwencję kroków, jaką wykonałby badacz ds. bezpieczeństwa, dzięki czemu agent nie musi zgadywać.

Nie wykrywa ponownie reguł, ponieważ zostały one dostarczone przez umiejętność.

Obecnie wprowadziliśmy 2 umiejętności związane z bezpieczeństwem: bezpieczeństwo intencji i uprawnienia.

Bezpieczeństwo intencji dotyczy tego, co inne aplikacje mogą wymusić na Twojej aplikacji.

Twoja aplikacja ma uprawnienia i sesję logowania, których nie ma strona internetowa.

Dlatego każdy wyeksportowany komponent i każda przekazana intencja oczekująca to potencjalny sposób na działanie za Twoim pośrednictwem.

Ta umiejętność pomaga temu zapobiec.

Umiejętność dotycząca uprawnień pomaga zmniejszyć różnicę między uprawnieniami zadeklarowanymi a faktycznie egzekwowanymi.

Może pomóc Ci napisać odpowiedni test uprawnień.

Pomaga to określić, czy dostawca ze ścieżką z symbolem wieloznacznym przyznaje dostęp do całej bazy danych, a nie tylko do jednego katalogu.

Wykrywa też nadmierne prośby o uprawnienia.

Na przykład proszenie o szeroki dostęp, gdy wystarczyłby selektor zdjęć.

Użyj go z interfejsem wiersza poleceń Androida, a następnie zapytaj: „Audit for intent security” (Przeprowadź kontrolę pod kątem bezpieczeństwa intencji).

Brak konfiguracji.

Brak dostrajania reguł.

Dzięki temu dane wyjściowe nie są ścianą ostrzeżeń.

To jest opinia.

Oto błąd, oto dlaczego jest on ważny dla Twojej aplikacji i oto rozwiązanie.

Oto profesjonalna wskazówka.

Interfejs wiersza poleceń Androida ułatwia znajdowanie i instalowanie.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

A ponieważ umiejętność dokładnie wie, czego szukać w projekcie, widzi aplikację w takiej postaci, w jakiej jest ona faktycznie dostarczana.

Uwzględnia minimalną wersję pakietu SDK, dzięki czemu poprawka się kompiluje, a także rzeczywiste ścieżki plików i numery wierszy.

Oto opinia, którą otrzymasz.

Wskazuje dokładny plik i wiersz, wyjaśnia rzeczywiste zagrożenie i powód zmiany, a nie tylko powołuje się na Lint.

Wskazuje, której umiejętności użył.

Odczytał konfigurację kompilacji, zobaczył minimalną wersję pakietu SDK 26 i wybrał ContextCompat, dzięki czemu poprawka działa, i przekazał Ci różnicę, aby można było ją zastosować.

To jest ostrzeżenie, od którego zaczęliśmy, ale teraz zawiera ono sugerowane rozwiązanie i dodatkowe uzasadnienie.

Wcześniejsze umiejętności wykrywają błędy w zabezpieczeniach.

Przejdźmy teraz do innego obszaru, czyli zgodności z zasadami dotyczącymi aplikacji.

Wyobraź sobie na przykład, że jesteś nowym deweloperem aplikacji i chcesz opublikować swoją aplikację w Sklepie Play.

Wypełnienie formularza Bezpieczeństwa danych to ważny krok w procesie publikowania aplikacji, dlatego warto skorzystać ze wszystkich dostępnych narzędzi, aby upewnić się, że wszystko jest w porządku, zanim prześlesz aplikację.

Umiejętność dotycząca zasad Google Play przeprowadza analizę statyczną bazy kodu.

Jeśli publikujesz istniejącą aplikację ze Sklepu Play, może ona również porównywać dane z różnych kanałów analizy kodu statycznego z deklaracjami w Sklepie Play.

Uruchomienie tej umiejętności może pomóc Ci wykryć potencjalne problemy z zasadami Google Play przed przesłaniem aplikacji, a nie po, i przyspieszyć proces przesyłania.

Przebieg pracy jest podobny do innych umiejętności, które omawialiśmy: zaimportuj aplikację, a następnie poproś o jej sprawdzenie pod kątem zgodności z zasadami Google Play przed przesłaniem.

Po prawej stronie zobaczysz zrzut ekranu z przykładowym raportem, a poniżej polecenia interfejsu wiersza poleceń Androida, które służą do jego instalacji.

android skills list
android skills add play-policy-insights

Wszystko, o czym do tej pory mówiliśmy, dzieje się przed wysłaniem: audyt intencji, sprawdzanie uprawnień, weryfikacja zgodności.

To zabezpieczenia na etapie kompilacji, które są niezbędne.

Istnieje jednak cała klasa zagrożeń, które pojawiają się dopiero po udostępnieniu pliku APK i uruchomieniu go na urządzeniach, nad którymi możesz nie mieć kontroli.

Interfejs Play Integrity API odpowiada w czasie działania na 3 pytania, na które Twój kod nie może odpowiedzieć sam: Czy to oryginalna, niezmodyfikowana kompilacja Twojej aplikacji?

Czy działa na oryginalnym urządzeniu z Androidem?

Czy to jest konto użytkownika Google Play?

Możesz więc używać interfejsu Play Integrity API do zwracania ocen integralności aplikacji, integralności urządzenia i innych.

Oprócz tego, że publikowanie aplikacji jest teraz szybsze i łatwiejsze, ułatwiamy też zabezpieczanie przychodów i reputacji aplikacji.

Chroń swoją firmę przed oszustwami i nadużyciami.

Nowy panel Chronione przez Google Play, który widzisz tutaj, ułatwia monitorowanie i konfigurowanie zabezpieczeń integralności, dystrybucji i zarabiania w jednym miejscu.

Zmniejszamy też czas oczekiwania na rozgrzanie interfejsu Play Integrity API, aby można było używać tych kontroli podczas ścieżek użytkownika, w których szybkość ma kluczowe znaczenie, i szybciej blokować zagrożenia oraz ryzykowne urządzenia.

Omówiliśmy już funkcje i narzędzia Androida, które pomagają dbać o bezpieczeństwo aplikacji. A co z użytkownikami?

Najpierw przyjrzyjmy się ochronie haseł jednorazowych wysyłanych SMS-em.

Załóżmy, że chcesz wdrożyć w aplikacji weryfikację użytkowników za pomocą SMS-ów i wysyłać kody weryfikacyjne.

Uprawnienia do SMS-ów zapewniają aplikacji dostęp do danych dotyczących wiadomości, w tym danych wrażliwych, takich jak hasła jednorazowe.

Wprowadziliśmy więc w aplikacji kilka interfejsów API, które umożliwiają wdrożenie tej funkcji. Dzięki temu nie musisz prosić o szerokie uprawnienia do SMS-ów, ale nadal możesz odbierać kody OTP SMS do weryfikacji.

Interfejs SMS Retriever API umożliwia aplikacji automatyczną weryfikację haseł jednorazowych bez konieczności uzyskiwania szerokich uprawnień do SMS-ów.

Do wiadomości dołączasz 11-znakowy identyfikator aplikacji, a system przekazuje Ci tylko tę jedną wiadomość.

Jeśli nie możesz kontrolować formatu wiadomości, użyj interfejsu API do zarządzania zgodą użytkowników SMS.

System wyświetla pojedynczy, jednorazowy prompt.

Użytkownik klika „Zezwól” lub „Odrzuć”. Jeśli zezwoli, otrzymasz tę jedną wiadomość.

Nadal nie ma potrzeby przyznawania szerokich uprawnień do SMS-ów.

Niektóre aplikacje mogą potrzebować dokładnej lokalizacji tylko raz, aby wykonać zadania.

Dotychczasowe jednorazowe zezwolenie jest uciążliwe dla użytkowników, dlatego deweloperzy czasami proszą o szersze uprawnienia do dokładnej lokalizacji.

Przycisk lokalizacji to narzędzie, które umożliwia łatwe przyznanie aplikacji jednorazowego dostępu do dokładnej lokalizacji.

Jest to element interfejsu Androida, który deweloperzy aplikacji mogą dostosowywać i umieszczać w swoich aplikacjach.

W czerwcu wprowadziliśmy pierwszą wersję biblioteki Jetpack przycisku lokalizacji w wersji alfa.

Tutaj możesz zobaczyć uprawnienia wymagane do włączenia przycisku lokalizacji w pliku manifestu Androida.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

Musisz zadeklarować standardowe uprawnienia dostępu do lokalizacji, dodając flagę uprawnień onlyForLocationButton wraz z dedykowanymi uprawnieniami USE_LOCATION_BUTTON wymaganymi przez usługę renderowania zdalnego systemu.

Po prawej stronie znajduje się kod Jetpack, który należy zaimplementować.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

Jak widać, tworzymy przycisk lokalizacji i inicjujemy wywołanie zwrotne.

To wywołanie zwrotne jest aktywowane, gdy użytkownik kliknie przycisk lokalizacji, aby podjąć decyzję o przyznaniu lub odmowie uprawnień.

Tryb ochrony zaawansowanej to funkcja przeznaczona dla użytkowników, którzy są narażeni na ataki lub dbają o bezpieczeństwo, ale każdy może z niej skorzystać.

Jeśli na przykład masz aplikację bankową, nie wymuszasz dodatkowego uwierzytelniania wieloskładnikowego przy każdym przelewie, ponieważ użytkownicy nie lubią takich utrudnień.

Gdy jednak tryb ochrony zaawansowanej jest włączony, aplikacja wie, że użytkownik chce maksymalnej ochrony, więc możesz automatycznie wymagać uwierzytelnienia biometrycznego przy każdym przelewie.

Tryb ochrony zaawansowanej wdraża zestaw wstępnie zdefiniowanych konfiguracji, które mają na celu zwiększenie ochrony urządzenia.

Tutaj pokazujemy, jak zintegrować go z aplikacją.

Musisz poprosić o uprawnienia, wysłać zapytanie do trybu ochrony zaawansowanej i sprawdzić, czy użytkownik włączył tryb ochrony zaawansowanej, korzystając z wywołania na urządzeniu usługi systemowej Menedżer trybu ochrony zaawansowanej.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

Następnie możesz nasłuchiwać zmian w czasie działania, rejestrując wywołanie zwrotne.

Omówiliśmy dziś wiele tematów.

Oto krótkie linki, jeśli chcesz dowiedzieć się więcej.

Zatrzymajmy się na chwilę, aby można było zapisać potrzebne adresy URL.

Dziękujemy.

Dziękujemy.