8. UIWebViewDelegate
– webView:shouldStartLoadWithRequest:navigationType:
– webViewDidStartLoad:
– webViewDidFinishLoad:
– webView:didFailLoadWithError:
Questions:
How to recognize whether navigation happened in top document or a frame?
How to block images or JavaScript?
Can webViewDidFinishLoad not happen after webViewDidStartLoad?
Can webViewDidStartLoad not happen before webViewDidFinishLoad?
9. Limitations
• Lack of Nitro
• HTTP 401 not supported natively
• No option to turn off JavaScript
• [Also applies to Mobile Safari]
Content-Disposition: attachment; filename=“download.html”
Content-Type: text/plain
- guess how will UIWebView behave (see CVE-2011-3426, CVE-2013-5151)
• Blocks JavaScript on scrolling
• Limited support for target attribute and window.open() ~ document.location.assign()
• Does not support RSS
11. Advantages
• Content update without App Store update
• HTML5 + JavaScript + CSS
• Possibility to re-use code on many platforms
(+ Apache Cordova / PhoneGap)
• .html / .key / .numbers / .pages / .xls / .pdf / .ppt / .doc / .rftd.zip / .rtf
• Automatic SSL certificate verification
• Same Origin Policy… non-standard one
12. Security guidelines
• “Ensure that all UIWebView calls do not execute without proper input validation. Apply filters
for dangerous JavaScript characters if possible, using a whitelist over blacklist character
policy before rendering. If possible call mobile Safari instead of rending inside of UIWebView
which has access to your application.” (OWASP Mobile Top 10)
• “[…] maintain control of all UIWebView content and pages, and prevent the user from
accessing arbitrary, untrusted web content.” (OWASP iOS Developer Cheat Sheet)
• “Inspect remote content via the use of the NSData class method dataWithContentsOfURL
in an attempt to prohibit the loading of malicious script into a UIWebview. Do not load
content remotely and then process the data returned before passing to a UIWebview (if
at all avoidable) otherwise you grant local file system access to any malicious script that
smuggles itself past your content inspectors.” (MWR Labs blog)
• Sounds dangerous… :-)
13. UIWebView in iOS applications
• Chrome
• Coast
• Facebook
• SkyDrive
• Skype
• WinZip
• and hundreds of others
14. Secure UIWebView - how to start?
Requirements:
• without reducing planned functionality
• without spending weeks on building content filters
(and further ones on maintenance and fixes)
• minimal amount of code added
• efficiently
15. Step 1
Probably NO, if it’s mobile banking:
http://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-
through.html
Is UIWebView needed in your application?
YES
!
NO
These aren't the droids we're looking for.
You can go about your business.
16. Step 2
Do the documents, which you intend to display,
need to be displayed in your application?
YES
!
!
!
NO
!
Use Safari,
Chrome (x-callback-url?)
or another available browser
17. Step 3
Is the presented document loaded directly through HTTP?
YES
- loadRequest(…)
!
Use https://
!
Don’t turn off SSL
certificate validation
NO
- data passed locally
!
!
!
Remember to set baseURL"
19. baseURL vs Same Origin Policy
• file:/// can read local files and any URLs - dangerous!
• nil/NULL == applewebdata:
same privileges as file: - dangerous!
• by default UIWebView assumes file://
(@“test” == @“file://test”)
• for http(s):// standard Same Origin Policy applies
• for about: and data: also, but with separate origin context
20. <script>
a = document.location.href.split('/');
if(a[0]==='file:') {
path = ‘file:///'+a[3]+'/'+a[4]+'/'+a[5]+'/'+a[6]+'/'+a[7]
+'/Library/Cookies/Cookies.binarycookies';
x = new XMLHttpRequest();
x.open('GET', path, false);
x.send();
alert(x.responseText);
}
</script>
31. Step 4
Do you have control over the content loaded to UIWebView?
YES
- I have control over content
!
Make sure the documents are not
vulnerable to XSS
NO
- I don’t have control over content
!
Can the user recognize origin?
!
Use CSP or HTML sandbox
32. User interface
• clear separation of trusted and untrusted content
• address bar with current URL
webView.request.mainDocumentURL.absoluteString
vs
[webView stringByEvaluatingJavaScriptFromString:@"window.location.href"]
• SSL indicator
• warning before first display of untrusted document
• other ideas?
33.
34.
35. Cross-Site Scripting
• Stored (server-side or in the application)
• Reflected (watch for URL scheme handlers)
• DOM-based (!)
• [webView stringByEvaluatingJavaScriptFromString:[NSString
stringWithFormat:@"document.body.innerText='%@'", input]];
44. Step 5
Additional security
Whitelisting allowed URLs
!
http
https
data
about
Turning off JavaScript
!
Content-Security-Policy
HTML5 Sandbox
!
What can go wrong?
