iOS WebViews
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Die kode van hierdie bladsy is onttrek van hier. Kyk na die bladsy vir verdere besonderhede.
WebViews word binne toepassings gebruik om webinhoud interaktief te vertoon. Verskeie tipes WebViews bied verskillende funksionaliteite en sekuriteitskenmerke vir iOS-toepassings. Hier is 'n kort oorsig:
UIWebView, wat nie meer aanbeveel word vanaf iOS 12 nie weens die gebrek aan ondersteuning om JavaScript te deaktiveer, wat dit vatbaar maak vir skripinplanting en Cross-Site Scripting (XSS) aanvalle.
WKWebView is die verkieslike opsie om webinhoud in toepassings in te sluit, wat verbeterde beheer oor die inhoud en sekuriteitskenmerke bied. JavaScript is standaard geaktiveer, maar dit kan indien nodig gedeaktiveer word. Dit ondersteun ook funksies om te voorkom dat JavaScript vensters outomaties oopmaak en verseker dat alle inhoud veilig gelaai word. Boonop minimaliseer WKWebView's argitektuur die risiko van geheuebesoedeling wat die hooftoepassing proses beïnvloed.
SFSafariViewController bied 'n gestandaardiseerde webblaaierervaring binne toepassings, herkenbaar aan sy spesifieke uitleg wat 'n lees-slegs adresveld, deel- en navigasieknope, en 'n direkte skakel om inhoud in Safari te open insluit. Anders as WKWebView, kan JavaScript nie in SFSafariViewController gedeaktiveer word nie, wat ook koekies en data met Safari deel, terwyl dit gebruikersprivaatheid van die toepassing handhaaf. Dit moet prominent vertoon word volgens App Store riglyne.
In die proses om WebViews konfigurasies te ondersoek, word twee primêre tipes gefokus: UIWebView en WKWebView. Om hierdie WebViews binne 'n binêre te identifiseer, word opdragte gebruik om spesifieke klasverwysings en inisialisasiemetodes te soek.
UIWebView Identifikasie
Hierdie opdrag help om voorbeelde van UIWebView te vind deur te soek na teksstringe wat daarmee verband hou in die binêre.
WKWebView Identifikasie
Net so, vir WKWebView, soek hierdie opdrag die binêre vir teksstringe wat aandui dat dit gebruik word.
Verder, om te vind hoe 'n WKWebView geïnitialiseer word, word die volgende opdrag uitgevoer, wat teiken die metode-handtekening wat verband hou met sy inisialisering:
Vir WKWebView word dit beklemtoon dat dit 'n beste praktyk is om JavaScript te deaktiveer tensy dit benodig word. Die gecompileerde binêre word gesoek om te bevestig dat die javaScriptEnabled
eienskap op false
gestel is, wat verseker dat JavaScript gedeaktiveer is:
WKWebView bied die vermoë om gemengde inhoud probleme te identifiseer, in teenstelling met UIWebView. Dit word nagegaan met die hasOnlySecureContent
eienskap om te verseker dat alle bladsyhulpbronne deur veilige verbindings gelaai word. Die soektog in die gecompileerde binêre word soos volg uitgevoer:
Dinamiese analise behels die inspeksie van die heap vir WebView instansies en hul eienskappe. 'n Skrip genaamd webviews_inspector.js
word vir hierdie doel gebruik, wat fokus op UIWebView
, WKWebView
, en SFSafariViewController
instansies. Dit log inligting oor gevonde instansies, insluitend URL's en instellings rakende JavaScript en veilige inhoud.
Heap-inspeksie kan uitgevoer word met behulp van ObjC.choose()
om WebView instansies te identifiseer en javaScriptEnabled
en hasonlysecurecontent
eienskappe te kontroleer.
Die skrif word uitgevoer met:
Belangrike Uitslae:
Instansies van WebViews word suksesvol geleë en ondersoek.
JavaScript-aktivering en veilige inhoudinstellings word geverifieer.
Hierdie opsomming sluit die kritieke stappe en opdragte in wat betrokke is by die analise van WebView-konfigurasies deur middel van statiese en dinamiese benaderings, met fokus op sekuriteitskenmerke soos JavaScript-aktivering en gemengde inhoudsdeteksie.
Die hantering van inhoud in WebViews is 'n kritieke aspek, veral wanneer daar met verskillende protokolle soos http(s)://
, file://
, en tel://
gewerk word. Hierdie protokolle stel die laai van sowel afstands- as plaaslike inhoud binne toepassings in staat. Dit word beklemtoon dat wanneer plaaslike inhoud gelaai word, voorsorgmaatreëls getref moet word om te voorkom dat gebruikers die lêernaam of -pad beïnvloed en die inhoud self redigeer.
WebViews bied verskillende metodes vir inhoudlaai. Vir UIWebView, wat nou verouderd is, word metodes soos loadHTMLString:baseURL:
en loadData:MIMEType:textEncodingName:baseURL:
gebruik. WKWebView, aan die ander kant, gebruik loadHTMLString:baseURL:
, loadData:MIMEType:textEncodingName:baseURL:
, en loadRequest:
vir webinhoud. Metodes soos pathForResource:ofType:
, URLForResource:withExtension:
, en init(contentsOf:encoding:)
word tipies gebruik om plaaslike lêers te laai. Die metode loadFileURL:allowingReadAccessToURL:
is veral noemenswaardig vir sy vermoë om 'n spesifieke URL of gids in die WebView te laai, wat potensieel sensitiewe data kan blootstel as 'n gids gespesifiseer word.
Om hierdie metodes in die bronnekode of gecompileerde binêre te vind, kan opdragte soos die volgende gebruik word:
Betreffende lêertoegang laat UIWebView dit universeel toe, terwyl WKWebView allowFileAccessFromFileURLs
en allowUniversalAccessFromFileURLs
instellings bekendstel om toegang vanaf lêer-URL's te bestuur, met albei wat standaard op vals is.
'n Frida-skripvoorbeeld word verskaf om WKWebView konfigurasies vir sekuriteitsinstellings te inspekteer:
Laastens demonstreer 'n voorbeeld van 'n JavaScript payload wat daarop gemik is om plaaslike lêers te exfiltreer, die potensiële sekuriteitsrisiko wat verband hou met onvanpaste geconfigureerde WebViews. Hierdie payload kodeer lêerinhoud in hex-formaat voordat dit na 'n bediener oorgedra word, wat die belangrikheid van streng sekuriteitsmaatreëls in WebView-implementasies beklemtoon.
Vanaf iOS 7 het Apple API's verskaf vir kommunikasie tussen JavaScript in 'n WebView en native Swift of Objective-C objek. Hierdie integrasie word hoofsaaklik gefasiliteer deur twee metodes:
JSContext: 'n JavaScript-funksie word outomaties geskep wanneer 'n Swift of Objective-C blok aan 'n identifiseerder binne 'n JSContext
gekoppel word. Dit stel naatlose integrasie en kommunikasie tussen JavaScript en native kode moontlik.
JSExport Protocol: Deur die JSExport
protokol te erf, kan native eienskappe, instansiemetodes en klasmetodes aan JavaScript blootgestel word. Dit beteken enige veranderinge wat in die JavaScript-omgewing gemaak word, word in die native omgewing weerspieël, en omgekeerd. Dit is egter noodsaaklik om te verseker dat sensitiewe data nie per ongeluk deur hierdie metode blootgestel word nie.
JSContext
in Objective-CIn Objective-C kan die JSContext
vir 'n UIWebView
met die volgende lyn kode verkry word:
WKWebView
Vir WKWebView
is direkte toegang tot JSContext
nie beskikbaar nie. In plaas daarvan word boodskap oordrag gebruik deur die postMessage
funksie, wat JavaScript aan inheemse kommunikasie moontlik maak. Hanteerders vir hierdie boodskappe word soos volg opgestel, wat JavaScript in staat stel om veilig met die inheemse toepassing te kommunikeer:
JavaScript kan met die inheemse laag kommunikeer deur 'n skrip boodskaphandler te definieer. Dit stel operasies in staat soos om inheemse funksies vanaf 'n webblad aan te roep:
Om die resultaat van 'n inheemse funksie-oproep te vang en te manipuleer, kan 'n mens die terugroep funksie binne die HTML oorskry:
Die inheemse kant hanteer die JavaScript-oproep soos getoon in die JavaScriptBridgeMessageHandler
klas, waar die resultaat van operasies soos die vermenigvuldiging van getalle verwerk en teruggestuur word na JavaScript vir vertoning of verdere manipulasie:
(Tutorial gebaseer op die een van https://blog.vuplex.com/debugging-webviews)
Om webinhoud binne iOS webviews effektief te debugeer, is 'n spesifieke opstelling wat Safari se ontwikkelaarshulpmiddels insluit, nodig omdat boodskappe wat na console.log()
gestuur word, nie in Xcode-logs vertoon word nie. Hier is 'n vereenvoudigde gids, wat sleutelstappe en vereistes beklemtoon:
Voorbereiding op iOS-toestel: Die Safari Web Inspector moet geaktiveer word op jou iOS-toestel. Dit word gedoen deur na Instellings > Safari > Gevorderd te gaan, en die Web Inspector in te skakel.
Voorbereiding op macOS-toestel: Op jou macOS-ontwikkelingsmasjien moet jy ontwikkelaarshulpmiddels binne Safari inskakel. Begin Safari, toegang Safari > Voorkeure > Gevorderd, en kies die opsie om Ontwikkel-menu te wys.
Verbinden en Debugeer: Nadat jy jou iOS-toestel aan jou macOS-rekenaar gekoppel het en jou toepassing begin het, gebruik Safari op jou macOS-toestel om die webview te kies wat jy wil debugeer. Navigeer na Ontwikkel in Safari se menubalk, beweeg oor die naam van jou iOS-toestel om 'n lys van webview-instanties te sien, en kies die instantie wat jy wil inspekteer. 'n Nuwe Safari Web Inspector-venster sal hiervoor oopmaak.
Wees egter bewus van die beperkings:
Debugeer met hierdie metode vereis 'n macOS-toestel aangesien dit op Safari staatmaak.
Slegs webviews in toepassings wat op jou toestel deur Xcode gelaai is, is geskik vir debuggings. Webviews in toepassings wat via die App Store of Apple Configurator geïnstalleer is, kan nie op hierdie manier gedebugeer word nie.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)