iOS WebViews
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The code of this page was extracted from here. Check the page for further details.
WebViews są wykorzystywane w aplikacjach do interaktywnego wyświetlania treści internetowych. Różne typy WebViews oferują różne funkcjonalności i cechy bezpieczeństwa dla aplikacji iOS. Oto krótki przegląd:
UIWebView, który nie jest już zalecany od iOS 12 ze względu na brak wsparcia dla wyłączania JavaScript, co czyni go podatnym na wstrzykiwanie skryptów i ataki Cross-Site Scripting (XSS).
WKWebView jest preferowaną opcją do włączania treści internetowych w aplikacjach, oferującą lepszą kontrolę nad treścią i funkcjami bezpieczeństwa. JavaScript jest domyślnie włączony, ale można go wyłączyć, jeśli zajdzie taka potrzeba. Obsługuje również funkcje zapobiegające automatycznemu otwieraniu okien przez JavaScript i zapewnia, że cała treść jest ładowana w sposób bezpieczny. Dodatkowo architektura WKWebView minimalizuje ryzyko uszkodzenia pamięci wpływającego na główny proces aplikacji.
SFSafariViewController oferuje ustandaryzowane doświadczenie przeglądania internetu w aplikacjach, rozpoznawalne dzięki specyficznemu układowi, w tym polu adresowym tylko do odczytu, przyciskom udostępniania i nawigacji oraz bezpośredniemu linkowi do otwierania treści w Safari. W przeciwieństwie do WKWebView, JavaScript nie może być wyłączony w SFSafariViewController, który również dzieli pliki cookie i dane z Safari, zachowując prywatność użytkownika w aplikacji. Musi być wyświetlany w sposób wyraźny zgodnie z wytycznymi App Store.
W procesie badania konfiguracji WebViews skupiono się na dwóch głównych typach: UIWebView i WKWebView. Aby zidentyfikować te WebViews w binarnym pliku, wykorzystuje się polecenia, które wyszukują konkretne odniesienia do klas i metody inicjalizacji.
UIWebView Identification
To polecenie pomaga w lokalizowaniu instancji UIWebView poprzez wyszukiwanie ciągów tekstowych związanych z nim w binarnym.
Identyfikacja WKWebView
Podobnie, dla WKWebView, to polecenie przeszukuje binarny plik w poszukiwaniu ciągów tekstowych wskazujących na jego użycie.
Ponadto, aby znaleźć, jak WKWebView jest inicjowany, wykonuje się następujące polecenie, celując w sygnaturę metody związaną z jego inicjalizacją:
Dla WKWebView podkreśla się, że wyłączenie JavaScriptu jest najlepszą praktyką, chyba że jest to wymagane. Przeszukuje się skompilowany plik binarny, aby potwierdzić, że właściwość javaScriptEnabled
jest ustawiona na false
, co zapewnia, że JavaScript jest wyłączony:
WKWebView oferuje możliwość identyfikacji problemów z mieszanym contentem, w przeciwieństwie do UIWebView. Jest to sprawdzane za pomocą właściwości hasOnlySecureContent
, aby upewnić się, że wszystkie zasoby strony są ładowane przez bezpieczne połączenia. Wyszukiwanie w skompilowanym binarnym pliku jest przeprowadzane w następujący sposób:
Analiza dynamiczna polega na inspekcji sterty w poszukiwaniu instancji WebView i ich właściwości. W tym celu używany jest skrypt o nazwie webviews_inspector.js
, który celuje w instancje UIWebView
, WKWebView
i SFSafariViewController
. Rejestruje on informacje o znalezionych instancjach, w tym adresy URL oraz ustawienia związane z JavaScript i bezpieczną zawartością.
Inspekcję sterty można przeprowadzić za pomocą ObjC.choose()
, aby zidentyfikować instancje WebView i sprawdzić właściwości javaScriptEnabled
oraz hasonlysecurecontent
.
Skrypt jest wykonywany za pomocą:
Kluczowe wyniki:
Instancje WebViews są skutecznie lokalizowane i badane.
Weryfikowane są ustawienia włączenia JavaScript i zabezpieczone treści.
To podsumowanie obejmuje kluczowe kroki i polecenia związane z analizowaniem konfiguracji WebView za pomocą podejść statycznych i dynamicznych, koncentrując się na funkcjach zabezpieczeń, takich jak włączenie JavaScript i wykrywanie mieszanej treści.
Obsługa treści w WebViews jest kluczowym aspektem, szczególnie w przypadku różnych protokołów, takich jak http(s)://
, file://
i tel://
. Te protokoły umożliwiają ładowanie zarówno zdalnych, jak i lokalnych treści w aplikacjach. Podkreśla się, że podczas ładowania lokalnych treści należy podjąć środki ostrożności, aby zapobiec wpływowi użytkowników na nazwę lub ścieżkę pliku oraz na edytowanie samej treści.
WebViews oferują różne metody ładowania treści. Dla UIWebView, obecnie przestarzałego, używane są metody takie jak loadHTMLString:baseURL:
i loadData:MIMEType:textEncodingName:baseURL:
. WKWebView z kolei wykorzystuje loadHTMLString:baseURL:
, loadData:MIMEType:textEncodingName:baseURL:
oraz loadRequest:
do treści internetowych. Metody takie jak pathForResource:ofType:
, URLForResource:withExtension:
i init(contentsOf:encoding:)
są zazwyczaj wykorzystywane do ładowania lokalnych plików. Metoda loadFileURL:allowingReadAccessToURL:
jest szczególnie godna uwagi ze względu na swoją zdolność do ładowania konkretnego URL lub katalogu do WebView, co może potencjalnie ujawniać wrażliwe dane, jeśli określony jest katalog.
Aby znaleźć te metody w kodzie źródłowym lub skompilowanym binarnym, można użyć poleceń takich jak poniższe:
Jeśli chodzi o file access, UIWebView pozwala na to uniwersalnie, podczas gdy WKWebView wprowadza ustawienia allowFileAccessFromFileURLs
i allowUniversalAccessFromFileURLs
do zarządzania dostępem z adresów URL plików, przy czym oba są domyślnie ustawione na false.
Przykład skryptu Frida jest podany, aby sprawdzić konfiguracje WKWebView dla ustawień bezpieczeństwa:
Na koniec, przykład ładunku JavaScript mającego na celu eksfiltrację lokalnych plików ilustruje potencjalne ryzyko bezpieczeństwa związane z niewłaściwie skonfigurowanymi WebView. Ten ładunek koduje zawartość plików w formacie szesnastkowym przed przesłaniem ich na serwer, podkreślając znaczenie rygorystycznych środków bezpieczeństwa w implementacjach WebView.
Od iOS 7 Apple udostępnił API do komunikacji między JavaScript w WebView a natywnymi obiektami Swift lub Objective-C. Ta integracja jest głównie ułatwiana przez dwie metody:
JSContext: Funkcja JavaScript jest automatycznie tworzona, gdy blok Swift lub Objective-C jest powiązany z identyfikatorem w JSContext
. Umożliwia to płynne połączenie i komunikację między JavaScript a kodem natywnym.
JSExport Protocol: Poprzez dziedziczenie protokołu JSExport
, natywne właściwości, metody instancji i metody klasowe mogą być udostępniane JavaScript. Oznacza to, że wszelkie zmiany wprowadzone w środowisku JavaScript są odzwierciedlane w środowisku natywnym i odwrotnie. Jednak ważne jest, aby upewnić się, że wrażliwe dane nie są przypadkowo ujawniane tą metodą.
JSContext
in Objective-CW Objective-C, JSContext
dla UIWebView
można uzyskać za pomocą następującej linii kodu:
WKWebView
Dla WKWebView
bezpośredni dostęp do JSContext
nie jest dostępny. Zamiast tego, wykorzystywane jest przesyłanie wiadomości za pomocą funkcji postMessage
, co umożliwia komunikację JavaScript z natywną aplikacją. Obsługiwacze tych wiadomości są ustawiane w następujący sposób, umożliwiając JavaScript interakcję z natywną aplikacją w sposób bezpieczny:
JavaScript może interagować z warstwą natywną, definiując handler wiadomości skryptu. Umożliwia to operacje takie jak wywoływanie funkcji natywnych z strony internetowej:
Aby przechwycić i manipulować wynikiem wywołania funkcji natywnej, można nadpisać funkcję zwrotną w HTML:
Strona natywna obsługuje wywołanie JavaScript, jak pokazano w klasie JavaScriptBridgeMessageHandler
, gdzie wynik operacji, takich jak mnożenie liczb, jest przetwarzany i wysyłany z powrotem do JavaScript w celu wyświetlenia lub dalszej manipulacji:
(Tutorial oparty na tym z https://blog.vuplex.com/debugging-webviews)
Aby skutecznie debugować treści internetowe w iOS webviews, wymagane jest specyficzne ustawienie z wykorzystaniem narzędzi dewelopera Safari, ponieważ wiadomości wysyłane do console.log()
nie są wyświetlane w logach Xcode. Oto uproszczony przewodnik, podkreślający kluczowe kroki i wymagania:
Przygotowanie na urządzeniu iOS: Należy aktywować Web Inspector w Safari na swoim urządzeniu iOS. Można to zrobić, przechodząc do Ustawienia > Safari > Zaawansowane i włączając Web Inspector.
Przygotowanie na urządzeniu macOS: Na swoim komputerze deweloperskim macOS musisz włączyć narzędzia dewelopera w Safari. Uruchom Safari, przejdź do Safari > Preferencje > Zaawansowane i wybierz opcję Pokaż menu Rozwój.
Połączenie i debugowanie: Po podłączeniu urządzenia iOS do komputera macOS i uruchomieniu aplikacji, użyj Safari na swoim urządzeniu macOS, aby wybrać webview, które chcesz debugować. Przejdź do Rozwój w pasku menu Safari, najedź na nazwę swojego urządzenia iOS, aby zobaczyć listę instancji webview, a następnie wybierz instancję, którą chcesz zbadać. Otworzy się nowe okno Web Inspector w Safari w tym celu.
Jednak pamiętaj o ograniczeniach:
Debugowanie tą metodą wymaga urządzenia macOS, ponieważ opiera się na Safari.
Tylko webviews w aplikacjach załadowanych na twoje urządzenie przez Xcode są kwalifikowane do debugowania. Webviews w aplikacjach zainstalowanych przez App Store lub Apple Configurator nie mogą być debugowane w ten sposób.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)